Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Sicherheit hat aber der counter intelligence Mechanismus verhindert, daß der<br />
Systemadministrator entdecken könnte, daß die Ports tatsächlich geöffnet sind. So führen<br />
<strong>Firewall</strong>s Portscanner in die Irre <strong>und</strong> verhindern, daß Sicherheitslücken entdeckt werden<br />
können. Für einen unerfahrenen Administrator ist dieses unmöglich zu durchschauen.<br />
Ein Traceroute sagt vielleicht mehr aus:<br />
13 access2-fa2-1-0.nl1.concert.net (195.99.66.3) 65.666 ms 43.910 ms 47.275 ms<br />
14 194.73.74.110 (194.73.74.110) 84.096 ms 84.434 ms 85.156 ms<br />
15 ns.nobbelazzo.com (195.99.32.6) 60.055 ms 8<strong>2.0</strong>62 ms 65.236 ms<br />
Es scheint, daß 194.73.74.110 der Übeltäter zu sein, der die Portscans verhindert, eine<br />
genauere Analyse des TCP Inkrements, z.B., wird einem erfahreneren Angreifer genau<br />
sagen, welche <strong>Firewall</strong> auf welchem Betriebssystem installiert ist. Hier<strong>für</strong> benötigt man<br />
aber tiefere Kenntnisse. Offensichtlich ist es aber möglich , sowohl Port 25 (SMAP), Port<br />
53 (DNS) <strong>und</strong> sogar Port 8080 (eine Sicherheitslücke?) von außen zu erreichen. Die<br />
Wahrscheinlichkeit, das ein "buffer overfow" auf Port 8080 <strong>und</strong> 53 erfolgreich ist, ist hoch.<br />
Port 25 mit SMAP ist "bullet proof", hat also kaum Chancen auf Erfolg. Der Aufbau<br />
entspricht der "screened host" Architektur, d.h. selbst wenn der "buffer overflow" Angriff<br />
erfolgreich wäre, so müßte ein Angreifer doch erhebliche "Umwege" in Kauf nehmen, um<br />
nicht entdeckt zu werden. Spezielle Angriffe, die "source routing" <strong>und</strong> "spoofing" erfordern,<br />
sind somit schon einmal erschwert. Soweit zu den Chancen, die <strong>Firewall</strong> direkt<br />
anzugreifen. Viel kommunikationsfreudiger sind die Mitarbeiter, die E-Mail - Anschluß<br />
haben. Sie freuen sich über jeden neuen Gruß, eine kleine Animation, einen<br />
Weihnachtsmann, ein Spiel, einem trojanischen Pferdchen z.B o.ä. Da Attachments in<br />
dieser Firma nicht heraus gefiltert werden, sollte klar sein, wie z.B. ein Tunnel aufgebaut<br />
werden kann. Von einer beliebigen internen IP-Adresse über Port 8080 des<br />
Internetgateways. Das Unternehmensinterne »routing« wird den Weg schon finden. Was<br />
der Angreifer nun nachprogrammieren muß, ist ein Tunnelprogramm, welches mit dem<br />
PROXY- Mechanismus des Gateways, Port 8080 kommuniziert, <strong>und</strong> die Eigenschaften<br />
von NetBus oder BO besitzt. Danach wird es mit einem Spiel versehen, <strong>und</strong> an alle<br />
Mitarbeiter des Unternehmens verschickt, die »surfen« dürfen. Nachdem die wichtigsten<br />
Werkzeuge schon geschrieben sind, müssen nur noch ein paar Tage investiert werden,<br />
um ein allgemein anwendbares Werkzeug zur Verfügung zu haben. Auch ein Angriff auf<br />
Anwendungsebene würde hier aber äußerst erfolgreich sein, E-Mails mit Attachments<br />
(Weihnachtsgrüße o.ä.) kommen stets an. Ein Angreifer muß nur irgendeinen "Dummen"<br />
aus dem Bereich Sekretariat oder Verkauf nach seiner E-Mail - Adresse fragen <strong>und</strong> schon<br />
läßt sich ein trojanisches Pferd genau plazieren. Der offene Port 8080, der existiert, jedoch<br />
von Außen nicht nutzbar ist,läßt vermuten, daß von vielen Arbeitsplätzen aus über Port<br />
8080 <strong>und</strong> ns.nobbelazzo.com als Gateway ein Herausschleusen von Informationen<br />
möglich ist. Die <strong>Firewall</strong> dient dann nur noch zur Aufzeichnung eines Angriffs, um<br />
hinterher genau feststellen zu können, daß die Informationen an irgendeinen Host im<br />
Internet (z.B. in Japan) gesendet wurden, von welchem aus sich die Spur verliert. Die<br />
Information, daß innerhalb des Netzwerkes Exchange 5.5 zum Einsatz kommt, spielt<br />
weniger eine Rolle. Es läßt vermuten, daß hier Virenscanner u.ä. installiert sind, welche<br />
allzu schnell einem DoS Angriff zum Opferfallen könnten, ebenso wie ns.nobbelazzo.com<br />
wahrscheinlich, da es auf <strong>LINUX</strong> basiert, mit einem älteren TCP/IP-Stack Problem<br />
konfrontiert, schnell seine Arbeit einstellen würde. Es spielt heute <strong>für</strong> einen Angreifer kaum<br />
noch eine Rolle, ob eine <strong>Firewall</strong> installiert ist, oder nicht, das eigentliche Problem sind die<br />
Windows NT Arbeitstationen <strong>und</strong> die Anwendungsprogramme, Office <strong>und</strong> der Internet-<br />
Explorer.<br />
Angriff auf eine <strong>LINUX</strong>- <strong>Firewall</strong><br />
<strong>LINUX</strong> wird immer wieder gerne als Kompaktlösung , also als E-Mail Gateway, PROXY-<br />
Cache, ISDN- Router <strong>und</strong> <strong>Firewall</strong> eingesetzt. Perfekt sind die <strong>Firewall</strong>-Regeln aufgesetzt,<br />
es ist kein Port nach außen geöffnet, E-Mails werden stündlich via fetchmail von einem<br />
Sammelaccount im Internet auf den Server geladen. Soweit ergeben sich keine<br />
Angriffspunkte <strong>für</strong> einen Einbruch in das System von außen. Das System ist von innen<br />
heraus einfach mit webmin via Netscape zu konfigurieren. Installiert wurde es auf Port<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins
Change language