Schlagwort-Archive: Firewall

iptables – Debian Firewall Regeln für einen Webserver

In diesem Artikel werde ich erklären wie man die Firewall iptables auf einem Debian Linux einrichten um nur Zugriffe auf die erwarteten Dienste (HTTP, HTTPS und SSH) zu erlauben.

Firewall Grundlagen

Iptables bestimmt wie die meisten Firewalls ob ein Packet durch darf oder nicht indem es das eingerichtete Regelwerk von oben noch unten durchgeht. Sobald die erste Regel gefunden wird, die auf das Packet passt, wird diese Angewendet. Wenn unser Regelwerk also wie folgt aussehen würde, dann würden nur SSH Verbindungen zustande kommen und keine HTTP Verbindungen:

  1. Erlaube alle SSH Verbindungen
  2. Verbiete alle Verbindungen
  3. Erlaube HTTP Verbindungen

Es ist also wichtig auf die Reihenfolge der Regeln zu achten und am Schluss sollte immer eine Regel stehen “Verbiete alle Verbindungen” (Deny All).

 IPv4 vs IPv6

Die meisten Webserver sind heute sowohl über eine IPv4 wie auch eine neue IPv6 Adresse erreichbar. Die neue Protokollversion wird jedoch oft sträflich vernachlässigt obwohl diese auf den Systemen aktiv ist. Dies ist bei Firewalls im besonderen ein Problem. Wenn wir bei dem Beispiel oben bleiben und in der Standardkonfiguration von IPtables nun via IPv6 eine HTTP Verbindung öffnen würden, so würden wir bis zu dem Webserver kommen. Da IPv6 die Zukunft ist empfehle ich daher explizit nicht einfach alle solchen Verbindungen zu verbieten sondern die Regeln auch für dieses Protokoll einzurichten. Bei iptables ist dies besonders einfach, da die meisten Befehle in beiden Versionen funktionieren und das einzige was man ändern muss ist der Programmname (von iptables zu ip6tables). In meinem Beispielen führe ich daher jeweils beide Befehlssätze (IPv4 & IPv6) auf.

System Vorbereiten

Viel ist nicht nötig um mit der Konfiguration anfangen zu können. Wir müssen im wesentlichen nur ein Packet installieren (welches häufig schon vorhanden ist):

apt-get install iptables iptables-persistent

Filterregeln erstellen

Es gibt bei iptables im wesentlichen zwei Möglichkeiten Regeln zu erstellen. Man kann diese entweder in eine Datei schreiben und diese vom System automatisch laden lassen oder man schreibt die Regeln in den (flüchtigen) Speicher von iptables und lässt iptables am Ende das File schreiben. Ich bevorzuge und verwende hier letzteren Weg, da man hier bei einem Fehler das System nur neustarten muss um einen Weitere Versuch zu erhalten.

Derzeitiges Regelwerk anschauen

Um sich das aktuell vorhandene Regelwerk anzuschauen genügt ein einfacher Befehl. Im Auslieferungszustand sollte das Ergebnis wie folgt aussehen:

IPv4

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

IPv6

# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Regel für SSH Zugang und den Loopback Verkehr einrichten

Die erste Regel sollte immer für den Loopback Verkehr und dann für den Remotezugang verwendet werden. So wird verhindert, dass man sich zu einem späteren Zeitpunkt durch eine falsche Regel aussperrt bzw das System zu viel Zeit verbraucht um z. B. Verbindungen zum lokalen Datenbankserver aufzubauen.

IPv4

# iptables -I INPUT -p tcp --dport 22 -j ACCEPT
# iptables -I INPUT -i lo -j ACCEPT

IPv6

# ip6tables -I INPUT -p tcp --dport 22 -j ACCEPT
# ip6tables -I INPUT -i lo -j ACCEPT

Alle nicht explizit erlaubten Verbindungen ignorieren

Nachdem die SSH Regel gesetzt wurde können wir iptables scharf schalten und in der base policy einstellen, dass nur explizit erlaubte Verbindungen an unseren Server heran kommen dürfen.

IPv4

# iptables -P INPUT DROP

IPv6

# ip6tables -P INPUT DROP

Regeln für den Webserver anhängen

Für unseren Webserver erlauben wir nun noch HTTP und HTTPS Verbindungen auf den Ports 80 und 443:

IPv4

# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp --dport 443 -j ACCEPT

IPv6

# ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
# ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT
# iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Im Gegensatz zu dem Befehl den wir zum Anlegen der SSH Regel verwendet haben, haben wir hier den Parameter –I durch den Parameter –A ersetzt. Dies bewirkt, dass die Regel an das Regelwerk angehängt (append) wird.

Etablierte Verbindungen zulassen

Mit dem bestehenden Regelwerk würde der Webserver und der SSH Server wie erwartet funktionieren. Allerdings würdet Ihr vermutlich recht schnell über Fehlermeldungen z. B. von apt fallen, da hier verschiedene Verbindungen nicht durch gehen würden. Es ist daher ratsam noch folgende Regel hinzuzufügen:

IPv4

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

IPv6

# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ip6tables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Filterregeln permanent speichern

Alle Regeln die wir bis jetzt eingerichtet haben wären nach einer Reboot wieder weg. Um diese zu speichern ist ein kurzer Befehl notwendig:

# iptables-save > /etc/iptables/rules.v4
# ip6tables-save > /etc/iptables/rules.v6

Nach einem Reboot werden die Regeln nun automatisch wieder gelesen und geladen. Zur Sicherheit sollte man das System neustarten und prüfen ob dies auch der Fall ist.

Alles in einem Script für Schreibfaule

Um das setzen der Regeln zu vereinfachen habe ich alle Befehle in eine bash Datei geworfen. Ihr müsste diese also nur auf euer System herunter laden, die Datei ausführbar machen (chmod +x [name]) und danach ausführen. Den Schritt um die Regeln zu persistieren habe ich nicht mit aufgenommen um Fehlern vorzubeugen.

Datei herunterladen

SQL Server “A network-related or instance-specific error occurred”

Nach der Installation eines SQL Servers (in meinem Fall 2008 R2 auf einem Windows 2008 R2 x64 Server) erhält man beim Versuch einen Remoteverbindung über das SQL Server Management Studio herzustellen in der Regel folgende Fehlermeldung:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 5)

Der Grund dafür ist recht simpel. Die Windows Firewall blockt den Port für den SQL Server (1433). Leider sieht die Installation noch immer nicht vor den Port im Laufe der Installation öffnen zu lassen. Man kann sich nun entweder durch die Windows Firewall GUI klicken oder einfach folgenden Befehl in einer CMD Box (muss als Admin ausgeführt werden!) eingeben:

netsh firewall set portopening protocol = TCP port = 1433 name = SQLPort mode = ENABLE scope = SUBNET profile = CURRENT

image_thumb4-5245991

Thats it. Der nächste Verbindungsversuch führt zum Erfolg :-).

Lüfterlose Astaro Firewall im Selbstbau

Nachdem ich nun eine neue Wohnung in Deutschland habe stand ich auch wieder vor dem Problem, dass ich meinen Internetzugang neu “regeln” musste (die Router in UK basieren auf Annex A und Deutschland hat Annex B). Nach ausgiebigen Produktvergleichen waren zwei SoHo Router (mit Firewall) in meiner Endauswahl. Beide Modelle hätten jeweils etwas mehr als 300 € gekostet. Leider hätte ich selbst bei den 300 € Routern noch Abstriche im Funktionsumfang hinnehmen müssen. Daher habe ich mich auf die Suche nach einer bezahlbaren Alternative gemacht – und bin fündig geworden.

Astaro Firewalls (die Software) ist für Privatanwender für bis zu 50 IP’s frei (sollte reichen). Da mir das Produkt sowieso gut gefällt (hab ich schon in meinem Testlab im Einsatz) blieb nun also nur noch das Problem der Hardware. Die Firewall soll 24 / 7 laufen und somit möglichst wenig Strom brauchen – zudem wäre es nicht schlecht, wenn das Gerät möglichst leise / unhörbar ist.

Nach ausgiebigem Preisvergleichen habe ich mir folgende Teile (bei Atelco) bestellt:

  • MSI IM-945GSE (lüfterloses Mainboard mit zwei NIC’s)
  • 2GB Kingston SO-Dimm PC5300/667
  • Samsung HM251JI (geht auch kleiner, war aber die günstigste von Samsung – und ich mag Samsung 😉 )
  • JCP Mini-ITX Gehäuse, 60W ext. PSU, schwarz

Das ganze hat zusammen 321 Euro gekostet:

image_thumb1-8949150

Die Installation der Software war in wenigen Minuten erledigt – da mir das Webinterface schon bekannt ist, war auch die Konfiguration kurz darauf abgeschlossen (auch Astaro Anfänger sollten das in sehr kurzer Zeit hin bekommen).

Das Beste ist, die Box braucht bei mir im normalen Betrieb nicht mal 20 W – und das obwohl ich hier nun eine absolut vollwertige Firewall stehen habe, die einem alles bietet was man so brauchen kann 😀  – hören tut man von der Box natürlich auch nichts (hat ja keine Lüfter).

P. S. (1) Ich hatte zuhause noch eine Riser Card und NIC – die steuern jetzt meine DMZ an

P. S. (2) Zur Installation der Astaro muss zwingend ein CD Laufwerk angeschlossen werden – das sollte man also noch zuhause herum liegen haben.

Exchange 2007 & BlackBerry Enterprise Server

Heute habe ich auf ServerHowTo.de eine neue Anleitung veröffentlicht welche die Installation eines BlackBerry Enterprise Servers in einer Exchange 2007 Umgebung beschreibt. Finden können Sie die Anleitung unter:

http://www.ServerHowTo.de/(…)

Ergänzend zu dem Artikel noch einige Hinweise zum Thema Sicherheit.

Da der BlackBerry Server eine Verbindung ins Internet aufbaut um dort mit den Servern von RIM die Mails auszutauschen, gehört der BES bzw. besser der BlackBerry Router in eine DMZ die auf der einen Seite die Kommunikation mit den RIM Servern erlaubt und auf der anderen Seite die Verbindung zum Exchange Server ermöglicht.

Der Account (BESAdmin) unter dem i. d. R. der BlackBerry Enterprise Server installiert wird besitzt sehr weitgehende Rechte auf die Mailboxen der BlackBerry Benutzer. Es sollte daher sicher gestellt werden, dass der Account nur die nötigsten Rechte erhält. Das setzen des „senden als“ Recht für alle Benutzer sollte daher nur dann gewählt werden, wenn tatsächlich alle oder nahezu alle Benutzer in der Exchange Umgebung einen BlackBerry benutzen. Des Weiteren sollte das Passwort des BESAdmin in einem Notuserverfahren verwaltet werden um das unbemerkte mitlesen von fremden eMails durch Administratoren über diesen Account verhindern zu können.

Die BlackBerry Endgeräte bieten die Möglichkeit die gespeicherten Inhalte zu verschlüsseln. Diese Option sollte insbesondere dann aktiviert werden, wenn vertrauliche Informationen (was heute fast überall der Fall ist) über das Medium eMail ausgetauscht werden. Zusätzlich bietet der BlackBerry Enterprise Server die Möglichkeit ein gestohlenes oder verlorenes zu „putzen“ und zu deaktivieren. Gestohlene BlackBerry Endgeräte sind daher recht wertlos für einen Dieb.

Der BES verfügt über die Möglichkeit Richtlinien an die Clients zu verteilen. Die vorhandenen Einstellungen sollten entsprechend der Sicherheitsbedürfnisse des Unternehmens angepasst werden. Dinge wie das erzwingen von Anmeldepassworten sollten dabei obligatorisch sein und von den Anwendern auch nicht geändert werden können. Nach einem Update lohnt es sich i. d. R. immer einen Blick in die Richtlinien zu werfen – diese werden dabei regelmäßig erweitert.

Beim Patchen der Exchange und BES Server ist Vorsicht geboten. Nicht selten hört man, dass nach einem Patch des Exchange Servers die „senden als“ Rechte des BESAdmin verschwunden sind. Wenn Sie also nach einem Update von Ihren Benutzern hören, dass diese zwar Mails empfangen aber nicht senden können sollten Sie diese Berechtigungen zuerst prüfen. Des Weiteren ist der BES sehr empfindlich, was seine API zum Exchange Server angeht. Ein Update des Exchange Servers macht daher u. U. auch ein entsprechendes Update des BES notwendig!

Astaro Firewall

Hi,

da ich gerade mein Netzwerk in London neu Aufbaue war ich auch auf der Suche nach einer neuen Firewall. Bei der für Homeuser kostenlosen Astaro Firewall bin ich fündig geworden. Das Produkt zeichnet sich u. A. durch die BSI Auszeichnung nach Common Criteria aus zudem hat die Firma ihren Sitz in Karlsruhe (im schönen Baden). 🙂

Die für mich entscheidenten Kriterien für die Auswahl von Astaro waren:

  • freier Code
  • eingebauter VPN Server
  • Content Firewall inkl. Virenschutz für Web- und eMail
  • kostenlos für Homeuser