Regelwerk

Eine Firewall ist nur so sinnvoll wie das Regelwerk, das der zuständige Paketfilter umzusetzen hat. Im Falle von Portsmith sieht die grundlegende Policy nach dem Start wie in Listing 1 aus.

Chain INPUT (policy DROP 22 packets, 3590 bytes)
 pkts bytes target     prot opt in     out     source               destination
    7   476 ACCEPT     all  --  eth1   *       192.168.2.0/24       0.0.0.0/0
  200 17460 ACCEPT     all  --  lo     *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:25
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    1    62 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 15/sec burst 5 udp spt:53 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       192.168.2.0/24       0.0.0.0/0           limit: avg 5/sec burst 5
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       192.168.2.0/24       0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 233 packets, 21730 bytes)
 pkts bytes target     prot opt in     out     source               destination

Das interne Netzwerk 192.168.2.0/24, das hinter dem Interface eth1 liegt, darf uneingeschränkt und mit Port Address Translation versehen mit dem großen weiten Internet kommunizieren. Mag dies für den einfachen Hausgebrauch oder sehr kleine Unternehmen noch akzeptabel sein, birgt diese Grundeinstellung doch hohes Gefahrenpotenzial.

Entgegen des auf der Portsmith-Homepage genannten Credos "alle externen Ports sind geblockt bis sie nach der Anmeldung freigeschaltet werden" sind hier jedoch nicht nur Port 80 und 443 für den Zugang zu den Webseiten, sondern auch Port 25 für den Mailverkehr freigeschaltet. Welchem Zweck diese Freischaltung dienen soll, bist unklar. Geblockt werden hingegen sämtliche ICMP-Pakete, die auf dem externen Interface ankommen, auch wenn dadurch teils wertvolle Informationen zur Fehlersuche verloren gehen. Erfreulich ist jedoch der Rückgriff auf die RELATED- und ESTABLISHED-States, so dass der Rückkanal bestehender TCP- und DNS-Verbindungen aus dem internen Netz (stateful) automatisch erlaubt ist.

Weitere Rätsel gibt die standardmäßig aktivierte Source-NAT auf eine nicht näher spezifizierte IP-Adresse (192.168.1.250) auf (Listing 2).

Chain PREROUTING (policy ACCEPT 1603 packets, 117K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9100 to:192.168.1.250:9100

Vermutlich handelt es sich um das Überbleibsel einer Weiterleitung auf den LPD-Port eines internen Printservers. Auch wenn der TCP-Port 9100 standardmäßig "dicht" ist, könnte der Eintrag im Falle eines ähnlichen Setups zu Fehlern führen, deren Ursache sich nicht auf den ersten Blick erschließt.

Glücklicherweise lässt sich die grundlegende Policy ganz den Bedürfnissen des Admins und der Sicherheitspolicy anpassen. Hierzu sind die Vorgaben aus der »/usr/local/bin/fw_policy« einfach zu löschen oder den Wünschen entsprechend zu erweitern, wodurch auch komplexeste initiale Regelwerke problemlos ermöglicht werden. Wem die grundlegenden IPTables-Kenntnisse fehlen, der sollte dabei lieber fachkundige Hilfe in Anspruch nehmen.

Nach erfolgtem Login eines Nutzers und der Freischaltung der für ihn vorgesehenen SSH-Verbindung wurde die INPUT-Chain entsprechend erweitert (Listing 3).

Chain INPUT (policy DROP 122 packets, 14737 bytes)
 pkts bytes target     prot opt in     out     source               destination
   85  7589 ACCEPT     tcp  --  eth0   *       192.168.0.10         0.0.0.0/0           tcp dpt:22
   14   961 ACCEPT     all  --  eth1   *       192.168.2.0/24       0.0.0.0/0
 2497  640K ACCEPT     all  --  lo     *       127.0.0.1            0.0.0.0/0
   23  3652 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:25
  262 37622 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 tcp dpt:443
  114 22241 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    3   204 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 15/sec burst 5 udp spt:53 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       192.168.2.0/24       0.0.0.0/0           limit: avg 5/sec burst 5

Wie hier unschwer zu erkennen werden die dynamischen Regeln nach ganz oben gesetzt. Potentiellen Überscheidungen mit existierenden, nicht so exakt gefassten Einträgen wird somit aus dem Weg gegangen. Ein wenig erschreckend hingegen ist die Destination (0.0.0.0) der neuen Regel, da sie laut der Portsmith-eigenen Policy ausschließlich auf die externe IP begrenzt sein sollte.

Sicherheit

Besonderes Augenmerk weiterer sicherheitstechnischer Betrachtungen ist in diesem Fall sicherlich nicht der Paketfilter an sich, sondern vor allem der ständig erreichbare Webserver, insbesondere die dabei zum Einsatz kommende Scriptsprache PHP. Ließe sich die Authentifizierung an dieser Stelle durch Schwachstellen innerhalb der Programmierung oder der Sprache selbst aushebeln, wäre das gesamte Netz potentiell gefährdet, einem Angreifer stünden so Tür und Tor offen. Ein weiteres lohnendes Ziel stellt die Datenbankanbindung dar. Lässt sich das Regelwerk durch eine passende SQL-Injection "anpassen", wird der Schutz, den die Firewall eigentlich bieten sollte, mehr als löchrig. Auch wenn bisherige Untersuchungen des Portsmith-PHP keine offensichtlichen Schwachstellen zutage förderten, ist ein erfolgreicher Angriff nicht auszuschließen. Dass Updates an dieser Stelle so zeitnah wie möglich eingespielt werden, versteht sich von selbst. Für einen erweiterten Schutz wäre die zusätzliche Installation von Suhosin [8] und / oder Mod-Security [9] anzuraten, die günstigstenfalls auch gegen bislang unbekannte Attacken schützen könnten.

Das System basiert darauf, dass die IP-Adresse des authentisierten Clients für die jeweiligen Verbindungen freigeschaltet werden. Die Adresse wird folglich über die Quell-IP gewonnen, die auf Port 443 des Webservers ankommt. Dieses Verhalten könnte sich wiederum als mögliche Gefahrenquelle erweisen: Im einfachsten Fall sitzt der Client ohne es zu wissen hinter einem Proxy, der die Verbindung zur Portsmith-Firewall stellvertretend für den Webbrowser aufbaut, wodurch nicht die Adresse des Clients, sondern die des Proxies freigeschaltet würde. Dies hätte zur Folge, dass jeder Benutzer dieses Proxies analog der Rechte des eigentlichen Nutzers Zugang zu dessen freigegebenen Ressourcen erhalten würde. Noch schlimmer wäre der Fall, in dem ein Angreifer den Client unbemerkt über einen durch ihn kontrollierten Proxyserver umleitet. Im Zusammenspiel mit der relativen Langlebigkeit der Freischaltung wäre weiteren Angriffen Tür und Tor geöffnet.