Viele werden sagen: Linux ohne Firewall? Einfach nicht aktivieren. Das ist grundlegend richtig. Die Firewall ist bei den gängigen Linux Distributionen sowieso nicht aktiviert. Warum auch? Sind doch die Distributionen so konfiguriert, dass nach einer Standard- Installation keine Dienste offene Ports – also Zugänge zu einem Dienst – anbieten. Überprüfen kann man das z.B. mit nmap.

Eine Firewall kann dem Administrator aber ein besseres Gefühl geben, wenn damit Arbeitsstationen und Server z.B. gegen Sicherheitslücken oder Fehlkonfiguration abgesichert sind. Vielleicht gibt es im geschäftlichen Betrieb sogar Auflagen von Versicherungen, Datenschutzvorgaben oder Gesetzen … Aber klar ist auch, dass eine Firewall immer erst jede Menge Mehrarbeit für den Administrator bedeutet – egal ob im geschäftlichen oder privaten Umfeld.

Im privaten Bereich einen Linux Server zu betreiben kann schon eine Herausforderung bedeuten. Samba für die Datenfreigabe, ein bischen Mailserver, vielleicht noch NFS und der Webserver mit WordPress für die Familienfotos – wenn man jetzt auf der Konsole eines Linux Servers den Befehl netstat -tan eingibt, bekommt Admina einen einfachen Überblick, wieviele Ports plötzlich offen sind. Eine Firewall soll da beruhigen?! Letztlich kommt es dann doch auf die Qualität der Konfiguration eines aktiven Dienstes an. Sollte der Mailserver als offenes Spam- Relay oder Samba zum Internet offen konfiguriert sein, nutzt eine Firewall auch nichts.

Eine Firewall scheint es auch einfacher zu machen, das Routing und NAT für das Heimnetzwerk zu ermöglichen. So wird z.B. die Shorewall Firewall so konfiguriert, dass sie Routing und NAT übernehmen kann. Alle Rechner aus dem Heimnetzwerk kommen so über den Linux Server in das Internet. Das Routing leitet die Pakete weiter und das NAT tarnt Heimrechner mit der zugewiesenen öffentlichen Adresse vom Internet Provider im Internet. Gut ist. Das geht aber auch ohne Firewall!

Nur die Dienste? Die zugehörigen Ports bilden den Zugang zu den Diensten eines Servers. Wie sollte es auch sonst gehen? Systeme – egal ob Linux, BSD oder Windows – bilden ansonsten eine steile Eiswand, an der sonstige Anfragen nicht greifen können. Folglich ist die Dienste Konfiguration das A und O. Betrachten wir einen Server ohne Firewall mal genauer. (Alle Pfad- Angaben in diesen Artikel beziehen sich auf Ubuntu Linux.)

Routing und NAT

Prüfe vorher, ob das Paket iptables installiert und mit iptables -vnL das keine Firewall Konfiguration eingerichtet ist – die Ausgabe von diesen Befehl sollte keine Regelsätze anzeigen. Öffne die Datei /etc/sysctl.conf und aktiviere den net.ipv4.ip_forward=1 Eintrag. Damit kann der Server mit zwei Netzwerkkarten die Daten von der Netzwerkkarte des einen verbundenen (Heim-)Netzwerks zu der Netzwerkkarte mit Internet Zugang weiterleiten. NAT – also die Tarnung der privaten Rechner z.B. 192.168.2.0 mit der zugewiesenen Internet Adresse vom Provider – wird durch folgenden Eintrag in der /etc/rc.local aktiviert:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Wobei -o eth0 auf das Device angepasst werden muss, welches Zugang zum Internet hat. Fertig.

Sollte dieser NAT Eintrag nach einen reboot nicht(!) wirksam werden, ist sicherlich fail2ban auf deinen Rechner aktiviert. Dann kann folgendes helfen:

• Füge in die rc.local in eine Zeile vor dem obigen Eintrag sleep 5 ein. Das script wartet dann 5 Sekunden, bevor es die iptables Anweisung ausführt. Bis dahin sollte fail2ban fertig sein.
• Oder deaktiviere und aktiviere fail2ban mit: update-rc.d fail2ban disable bzw. enable. Danach konnte ich sogar den sleep 5 Eintrag weglassen.
• Alternativ hat Admina vielleicht ein Linux, in dem die rc.local nicht ausführbar ist. Ein chmod +x rc.local hilft vielleicht …

Damit ist der Linux Server vorbereitet, ein angeschlossenes Netzwerk in das Internet zu schleusen. Ohne Firewall.

Keine Reaktion auf pings bitte!

Viele Administratoren konfigurieren die Firewall so, dass keine Antwort auf einen ping erfolgt. Ein ping sendet ein Datenpaket an einen Rechner und in der Regel antwortet er darauf. Damit können z.B. Schadprogramme regelmäßig Rechner auf online Verfügbarkeit testen. Das abschalten einer Reaktion auf einen ping wird damit als Teil einer Sicherheitsstrategie empfunden. Grundsätzlich halte ich diese Ansicht mittlerweile für kalten Kaffee. Neuere Schadprogramme lassen sich mit dieser ‘Unsichtbarkeit’ nicht mehr irritieren. Wenn aber Admina trotzdem und unbedingt den ping Schutz – auch ohne Firewall – aktiviert haben will, dann schreibe in die /etc/sysctl.conf folgende Zeile:

net.ipv4.icmp_echo_ignore_all = 1

und lasse diese Änderung mit sysctl -p ohne Neustart des Servers wirksam werden. Teste aber hinterher, ob alle Dienste wie gewohnt funktionieren und die Performance stabil ist. Alles ohne Firewall.

Rechner vorbereiten

Klar muss sein, dass ich hier nur über den Linux Server schreibe. Sollten z.B. im Heimnetzwerk Rechner stehen, die mit Linux betankt sind, gilt das oben gesagte: In der Standard Installation sind keine ports offen. Bei Windows Rechner kann das anders aussehen. Allerdings ist nach einer Windows Installation eine Firewall aktiviert.

Dienste sichern (Beispiele)

Bei den üblichen Serverdiensten ist es eigentlich selbstredend, dass es nur einen kontrollierten Zugang zu den Ressourcen gibt. SSH erfordert eine Anmeldung, für den Mailserver ist (normalerweise) ebenfalls eine Authentifizierung notwendig und der Webserver ist (mit den Standard- Modulen) nur ein stummer Diener. Bei Samba (der Fileserver unter Linux) wäre ich da schon vorsichtiger. Normalerweise sagt Admina, dass auf einen Rechner welcher auch eine Verbindung zu fremden Netzen (Internet) hat, keine Daten gelagert werden sollen. Im Heimnetzwerk ist es aber wohl gängig, dass es einen all-inclusive-Server gibt. Deswegen sollte Admina den Samba Server in der /etc/samba/smb.conf noch mit folgender Optionen absichern:

interfaces = 127.0.0.0/8 eth1
bind interfaces only = yes

Die Option eth1 muss natürlich dem eigenen Netzwerk angepasst werden und beschreibt die Netzwerkkarte, welche die Verbindung zum Heimnetzwerk hat.

Aber auch der Mailserver kann eine unerfreuliche Überraschung beherbergen. Damit sind die Standard Ports (25, 143, 587, 993) garnicht so sehr das Thema. Interessanter ist, dass der spamd Dienst (spamassassin) den Port 783 oder der Postfix SMTP Server den Port 10025 z.B. für einen proxy_filter / content_filter öffnet. Und dann könnte Admina in der /etc/postfix/master.cf die Einträge für diese Ports überprüfen. Bei einen sicheren Postfix Server steht z.B.

-o smtpd_recipient_restrictions = permit_mynetwork,reject
-o mynetwork = 127.0.0.0/8

in der master.cf für einen proxy_filter. Wie schon gesagt: Die Beispiele sollen mögliche ungesicherte Zugänge zum Server aufzeigen und anregen, den eigenen Server entsprechend kritisch zu prüfen.

UDP Dienste sichern (Beispiele)

Da es nicht nur das TCP Protokoll gibt sondern auch bei einigen Diensten das UDP Protokoll wichtig ist, sollte Admina prüfen, was mit diesen Protokoll auf dem Server so angeboten wird. Dazu eignen sich folgende Befehle:

lsof -i
netstat -tulpen

Gerade ein avahi-daemon – Standard bei einer Ubuntu Installation – kann da vielleicht eine Sicherheitslücke darstellen, weil dieser Dienst gewissenhaft das Heimnetz nach Ressourcen aller Art scannt und den Clients zur Nutzung anbietet.

So kann man wenigstens in der /etc/avahi/avahi-daemon.conf die folgenden Optionen abschalten:

disable-publishing=yes
disable-user-service-publishing=yes

Damit wird das Anbieten von Resssourcen über avahi abgeschaltet. Sollte Admina avahi trotzdem nutzen wollen/müssen, kann in der genannten Datei auch das Netzwerk Device festgelegt werden, über das dieser Dienst kommuniziert. Zusätzlich kann Admina das Programm ‘Avahi Zeroconf Browser’ auf einen Linux Client im Heimnetz installieren. Mit diesen Programm werden die Ressourcen aufgelistet, welche von Avahi gefunden werden.

Interessant wäre es vielleicht noch den ntp und memcache(d) Service zu betrachten.

Blacklist und Zugriff

Häufig werden Firewalls genutzt, um Rechnern den Zugriff auf Ressourcen zu verweigern. Dafür bieten sich blacklists an oder es werden Bedingungen formuliert, die ein Rechner erfüllen muss, damit er den Zugriff bekommt. Wenn nun die Firewall wegfällt: Welche Möglichkeiten hat Admina den Zugriff auf Ressourcen zu verweigern?

Sehr gute – sprich: problemlose – Erfahrungen habe ich mit dem Programm denyhosts gemacht, um den SSH Zugang abzusichern. Allerdings wird dieses Programm aktuell nicht weiter betreut und ist damit aus Ubuntu 14 rausgeflogen. Allerdings gibt es einen vollwertigen und umfangreicheren Ersatz: fail2ban.

Das Programm fail2ban erfordert etwas mehr Zeit um es vollständig zu verstehen – bietet aber auch einen hervorragenden Ersatz für sonstige blacklist Mechanismen. Fail2ban ist für alle möglichen Programme nutzbar. Beispiel: Die mehrmalige fehlerhafte Anmeldung an SSH erscheint in /var/log/auth.log, fail2ban zählt diese und blockt nach dem erreichen der voreingestellten Fehlversuchen diesen Rechner. Damit ist dieser Rechner als Angreifer neutralisiert. Alles ohne Firewall.

Gezielt Rechner neutralisieren

Eine weitere Möglichkeit Zugriffe auf einzelne Dienste zu unterbinden, ist die Nutzung der Datei /etc/hosts.deny. Die Datei gehört zum sogenannten TCP wrapper und ermöglicht durch einfache Konfiguration eine gezielte Neutralisierung von Rechnern oder Rechnergruppen, welche einen Dienst auf dem eigenen Server ständig in Anspruch nehmen. Ein einfacher Eintrag wäre:

ALL : *.hinet.net

Damit wird die Nutzung aller Dienste von allen Rechnern mit der Domäne hinet.net im Namen gesperrt. Allerdings kann der TCP wrapper nur Dienste filtern, die auch die libwrap.so eingebunden haben. Teste also vorher den gewünschten Dienst auf deinen Server, hier z.B. SSH:

ldd /usr/sbin/sshd

Siehst Du in der folgenden Auflistung eine Datei libwrap.so dann unterstützt dieser Dienst den TCP wrapper und kann die /etc/hosts.deny auslesen und nutzen. Zugriffe auf Postfix, Dovecot oder Apache2 mit dem TCP wrapper sperren, ist unter Ubuntu 14.04 nicht möglich, weil diese Programme kein libwrap.so eingebunden haben (prüfe mit ldd).

Fazit

Ein Server Betrieb mit Linux ohne Firewall ist – aus eigener Erfahrung – ohne Probleme möglich. Die Server Dienste haben in der Regel gesicherte Zugänge durch Authentifizierung. Ein Problem könnte ein nicht-gesicherter Dienst sein, welcher im Hintergrund läuft und vielleicht nur von einem anderen Dienst benutzt wird. Aber hier kann ein netstat oder lsof und eine genaue Analyse der Ausgabe dieser Befehle die entscheidende Sicherheit geben: Welche offenen Ports mit welchen Protokoll stehen für welchen Dienst und ist wie im Zugriff? Auch typische Firewall Mechanismen (blacklist, NAT, usw.) können durch andere Lösungen realisiert werden. Eine einfache Regel sollte berücksichtigt werden: Dienste, die nicht benötigt werden, müssen abgeschaltet werden. Sollte Admina dann noch einen regel- mäßigen Server-Check machen, steht einem sicheren Serverbetrieb auch ohne Firewall nichts im Wege.

---