iptables komisch... reload

[Jupsihok]

iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

iptables -A INPUT -p tcp --dport 80 --sport 1024:65535 -m state -state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 80 --dport 1024:65535 -m state -state RELATED,ESTABLISHED -j ACCEPT




Ziel ist es eigentlich ausschließlich Port 80 auf dem Webserver zu öffnen.
Würde denken daß es so richtig ist.

URL ist auch ansurfbar, allerdings funktioniert der Reload nicht...?!

PS: Gibt es irgendwo ein iptables-script was man als Vorlage nehmen könnte um trotz VPS die gängigen Spoofing,.... etc. Attacken verhindern zu können?
Bisher habe ich nur Möglichkeiten mit Kernelzugriff gefunden, welche in meinem Falle nicht funktionieren können.
Eigentlich habe ich nicht vor das Rad neu zu erfinden, oder dicke Bücher zu lesen... Webserver gibts wie Sand am Meer....



Lieber Gruß
Jupsihok

 

[Dennis Wronka]

iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

Erstmal hierzu: Von dieser Konstellation halte ich persoenlich nicht viel da sie nicht RFC-konform arbeitet.
Unerwuenschte Pakete sollten nicht einfach gedroppt werden sondern dem Protokoll entsprechend abgewiesen. Dabei hilft das REJECT-Target zusammen mit seinem Parameter --reject-with.

iptables -A INPUT -p tcp --dport 80 --sport 1024:65535 -m state -state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 80 --dport 1024:65535 -m state -state RELATED,ESTABLISHED -j ACCEPT

Mich persoenlich wundert es dass ueberhaupt die Seite abgerufen wird.
Bist Du sicher dass der erste Aufruf nicht aus dem Browser-Cache kommt und Du das Problem somit erst beim Reload, welches ja den Cache umgeht, zu sehen bekommst?
Grund fuer meine Vermutung ist dass Du naemlich durch die hier genutzte Output-Regel, genauer das darin genutzte Connection-Tracking, schon den 3-Way-Handshake unterbindest, welcher ja noetig ist bevor ueberhaupt Daten uebertragen werden koennen.

Fuer den Server unterscheidet sich ein Reload ja nicht von einer normalen Anfrage, und wenn waere der Unterschied wohl auf der Applikationsebene, also im HTTP-Protokoll, zu suchen, und damit befasst sich IPTables/Netfilter ja nicht.

Ich persoenlich tendiere dazu ausgehenden Traffic eigentlich nicht einzuschraenken, sondern eben nur eingehenden.

Die folgende Konfiguration sollte eingehende Pakete blocken, bis auf Pakete an Port 80, und arbeitet (meiner Meinung nach) RFC-konform in der Abweisung von Paketen.

iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

Die Policies aller Ketten bleibt hierbei ACCEPT.
Die ersten beiden Regeln kuemmern sich um das Connection-Tracking. Ungueltige Verbindungen werden fallen gelassen. Viele Hits hab ich bei dieser Regel (der ersten) aber bislang nicht sehen koennen. Die zweite Regel erlaubt Verbindungen die bereits aufgebaut wurden oder zugehoerig sind. RELATED ist fuer HTTP nicht noetig, FTP und andere Protokolle die mit 2 Verbindungen arbeiten brauchen diese Regel aber.

Dadurch trifft die dritte Regel nur zu wenn es sich um eine neue Verbindung handelt.
Ich persoenlich finde diesen Aufbau insofern ganz nett da er fuer Statistiken besser geeignet ist.

Anschliessend werden alle anderen Pakete abgewiesen. TCP-Pakete mit einem Reset, UDP-Pakete mit dem Hinweis dass der Port nicht erreichbar ist, und alle anderen mit dem Hinweis dass das Protokoll nicht verfuegbar ist.
Dies bildet mehr oder weniger nach was auch ein OS ohne Paketfilter macht wenn Pakete an geschlossenen Ports bzw. nicht-verfuegbare Protokolle schickt.

PS: Gibt es irgendwo ein iptables-script was man als Vorlage nehmen könnte um trotz VPS die gängigen Spoofing,.... etc. Attacken verhindern zu können?

Mir ist da nichts bekannt. Das liegt aber wahrscheinlich daran dass ich meine Filterregeln selbst schreibe.

Verweisen moechte ich Dich daher erstmal auf mein IPTables-Tutorial, welches weit weniger umfangreich ist als das "offizielle Tutorial" welches ich manchmal zur Hand nehme um was nachzuschlagen und auch weitaus weniger schwer im Magen liegt als irgendwelche IPTables-Buecher, wobei ich zugeben muss noch keines gelesen zu haben (aber ich weiss dass es zumindest eines im Addison-Wesley-Verlag gibt).

 

[Jupsihok]

Wow, danke für Deine ausführlichen Informationen!

Nunja, von der Sache her liegst Du bestimmt richtig, allerdings stelle ich mir die Frage ob es aus Sicherheitsaspekten nicht doch sinnvoll ist den ausgehenden Verkehr einzuschränken.

JA, Du hast recht... die Seite war gecache't...! *grml*

------------------------------------
Kurze Zwischeninfo:
Ich habe den VPS nur um ein Webprojekt so umsetzen zu können, wie ich es möchte. Mein Ex Hoster verlangt für jede php.ini Änderung (1 Zeile) 15 € um einem dann zu sagen daß man den Server wechseln soll, um diese und jede Funktion auch noch zu Verfügung zu haben. Das sind dann wieder 20 €... und so weiter.... ich verstehe daß man als Hoster Geld verdienen muß, aber ein VPS liegt aus Kostengründen jetzt aufgrund der komplexität schlichtweg näher.

Naja, nun sitze ich hier und versuche den VPS sicher zu bekommen, Managed ist wiederum aus Kostengründen aktuell vor Launch nicht sinnvoll.
Bin also relativ neu auf dem Gebiet... und hoffe hier keine Aggressionen durch unbedachte Fragen zu erzeugen... ich versuche mein bestes mich in die Materie einzuarbeiten.
-----------------------------------

Fortsetzung:
Ich weiß nicht ob ich mit der Annahme des ausgehenden Verkehrs falsch liege,
mein Gedanke rührt daher, daß sobald der Server kompromittiert würde.... sagen wir mal SQL-Injection oder ähnliches.... (kann immer mal passieren, es gibt auf jedem System schwachstellen...) ....
zunächst root gehackt werden müßte um an die iptables zu kommen damit entsprechende ausgehende Ports geöffnet werden können.

Damit habe ich dann weitere Handlungen ersteinmal zumindest erschwert.

Weiterhin werden kompromittierte Server oft für Filesharing eingesetzt... auch hier sofern die ausgehenden Ports geblockt sind, sicherlich ein Ärgernis für die Angreifer.

Wenn der Angreifer den Server für Spamversand einsetzen will... sind alle Mail-Ports geschlossen, es dürfte also auch in diesem Fall sinnig sein ausgehende Ports einzuschränken.

Wie gesagt, bin nicht besonders firm in der Materie... aber das wären nach meinem Kenntnisstand (der zugegebenermaßen nicht besonders fundiert ist...) wohl die wichtigsten Gründe ausgehende Pakete zu blocken.

Im Hintergrund halt der Gedanke der Kompromettierung des Servers.

Würde mich freuen wenn Du mir sagen könntest ob mein Gedankengang falsch oder richtig ist. Bin mir aktuell schlichtweg nicht sicher.

Grundsätzlich würde ich sagen, alle Ports zu.... in jegliche richtung, außer Port80.... der benötigt wird.....

3-Way Handschake?

Ähm, also... wie muss ein Iptable aussehen, damit ein Apache ausschließlich
Webseiten ausliefern kann, und alle anderen Ports bidirektional geschlossen sind?

Ich würde mir dann ein zweites Script schreiben, mit dem ich in Wartungsfällen ebenfalls APT-GET,DNS,SSH und FTP freischalte. Info: Ich kann durch einen reboot als Admin beim Hoster, eine andere Konfiguration starten... sperre mich also nicht aus....

Im Default will ich den Server "as save as possible" laufen lassen.
Ich wundere mich, warum man so schwer an Default-Konfigurationen kommt.

Um den Server zu sichern habe ich bisher:
-update/upgrade
-ssh Port umgelegt >65000
-rootlogin verboten
-pseudo user angelegt
-fail2ban nach 3 Versuchen, 24h Sperre, email Benachrichtigung
-iptables Grundkonfiguration (bis auf den Apache alles geschlossen, mit reload Problem)<<< Fehler, setzte jetzt meine erste IPtables ein... (copy&paste aus dem Web/nicht akzeptabel)...
-lange kryptische Passwörter (vermeintlich pseudo sicher)
-Suoshin Patch
-Traffic Hard-Limit

... noch ideen?



Naja, wenn Du diesen ganzen Psalm gelesen hast, vielleicht magst Du ja antworten, ich habe das Gefühl daß Du im Gegensatz zu vielen Anderen ne Menge Plan von der Materie hast.

Vielen Dank für die bisherige Erklärung,
Lieber Gruß
Jupsihok

 

[Dennis Wronka]

Nunja, von der Sache her liegst Du bestimmt richtig, allerdings stelle ich mir die Frage ob es aus Sicherheitsaspekten nicht doch sinnvoll ist den ausgehenden Verkehr einzuschränken.

Im Grunde schon. Ich persoenlich logge ausgehenden Verkehr eher als ihn einzuschraenken.
Ansonsten kannst Du aehnlich verfahren wie beim eingehenden Traffic. Auf den ESTABLISHED,RELATED-Kram kannst Du hier aber im Grunde verzichten. Wie viele neue Verbindungen zum Webserver aufgebaut wurden solltest Du anhand der Eingangsregel aus meinem vorigen Post erfassen koennen.

iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A OUTPUT -j REJECT --reject-with icmp-proto-unreachable

Vereinfachen kannst Du das nun indem Du eine neue Kette anlegst und diese sowohl in INPUT als auch in OUTPUT als Target nutzt.
Ganz einfach saehe das ungefaehr so aus:

iptables -N myfilter
iptables -A myfilter -m state --state INVALID -j DROP
iptables -A myfilter -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A myfilter -p tcp --dport 80 -j ACCEPT
iptables -A myfilter -p tcp --sport 80 -j ACCEPT
iptables -A myfilter -p tcp -j REJECT --reject-with tcp-reset
iptables -A myfilter -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A myfilter -j REJECT --reject-with icmp-proto-unreachable
iptables -A INPUT -j myfilter
iptables -A OUTPUT -j myfilter

Aber Vorsicht: Dieses Regelwerk hat ein gravierendes Problem! Wie Du vielleicht siehst werden hier Pakete von Port 80 zugelassen. Dies ist aufgrund der Bestimmung dass Apache Daten senden koennen soll.
Problem dabei ist dass dies auch einem entfernten Benutzer ermoeglicht von seinem Port 80 auf einen beliebigen Port bei Dir zu verbinden.

Ohne gross zusaetzliche Ketten zu erstellen sollte man dies mithilfe von -i und -o absichern koennen.
-i prueft das Interface an dem ein Paket reinkommt, -o prueft das Interface an dem es rausgeht.
Da das Ausgangsinterface in INPUT nicht bekannt ist kann eine solche Regel dann auch nicht zutreffen.

Korrigiert saehe die Regel also z.B. so aus:

iptables -A myfilter -p tcp --sport 80 -o eth0 -j ACCEPT

eth0 muss natuerlich gegebenenfalls noch durch das entsprechende Interface ersetzt werden.

Fortsetzung:
Ich weiß nicht ob ich mit der Annahme des ausgehenden Verkehrs falsch liege, mein Gedanke rührt daher, daß sobald der Server kompromittiert würde.... sagen wir mal SQL-Injection oder ähnliches.... (kann immer mal passieren, es gibt auf jedem System schwachstellen...) ....
zunächst root gehackt werden müßte um an die iptables zu kommen damit entsprechende ausgehende Ports geöffnet werden können.

Auch um einen Dienst zu starten der nicht laeuft, z.B. den Mail-Service, muss man root sein.
Und um aus einer simplen SQL-Injektion was groesseres zu machen ist meiner Meinung nach doch etwas mehr erforderlich als in den Faehigkeiten (und oft auch im Interesse) der meisten Angreifer liegt.

Weiterhin werden kompromittierte Server oft für Filesharing eingesetzt... auch hier sofern die ausgehenden Ports geblockt sind, sicherlich ein Ärgernis für die Angreifer.

Richtig, unsichere Server werden gern fuer sowas eingesetzt. Meiner Meinung nach handelt es sich dabei aber bevorzugt um unsichere FTP-Server.
Wenn auf Deinem Server kein FTP-Service laeuft hast Du da schonmal einen gewaltigen Vorteil.

Wenn der Angreifer den Server für Spamversand einsetzen will... sind alle Mail-Ports geschlossen, es dürfte also auch in diesem Fall sinnig sein ausgehende Ports einzuschränken.

Wie gesagt, dafuer muss dann eventuell erstmal der Mail-Service gestartet werden. Was root-Rechte benoetigt. Natuerlich ist es im Grunde moeglich den SMTP-Server auf einem unpriviligierten Port laufen zu lassen und somit die Notwendigkeit fuer root-Rechte umgehen. Spam-Filter duerften darauf aber wahrscheinlich allergisch reagieren.
Zudem kann man auch festlegen dass jeglicher SMTP-Verkehr zuvor durch ein Login authorisiert werden muss.
Was natuerlich kein Problem fuer den Angreifer darstellt sollte er einmal root-Rechte erlangt haben. Dann aber sind, auf den meisten Systemen, im Grunde eh alle Massnahmen fuer die Katz.

Würde mich freuen wenn Du mir sagen könntest ob mein Gedankengang falsch oder richtig ist. Bin mir aktuell schlichtweg nicht sicher.

Im Grunde ist Dein Gedankengang richtig. Und vor allem finde ich es lobenswert dass Du Dir ueberhaupt solche Gedanken machst. Der Grossteil der Leute die sich so einen Server anschaffen sch..ssen auf korrekte Absicherung.

Und vergiss auch nicht dass mehr zur Systemsicherheit gehoert als ein Paketfilter. Regelmaessige Updates und natuerlich auch eine sicher programmierte Web-Applikation gehoeren, unter anderem, auch dazu.

Ähm, also... wie muss ein Iptable aussehen, damit ein Apache ausschließlich Webseiten ausliefern kann, und alle anderen Ports bidirektional geschlossen sind?

Wenn Du den zweiten und dritten Code-Block aus diesem Post kombinierst solltest Du zu dem gewuenschten Ergebnis kommen.

Problem ist dass Du mit IPTables nicht bestimmen kannst welcher Dienst was darf. Um diese Granularitaet zu bekommen brauchst Du mehr, z.B. SELinux oder AppArmor (ich bin nicht sicher ob AppArmor das kann, gehe aber mal davon aus).

Ich würde mir dann ein zweites Script schreiben, mit dem ich in Wartungsfällen ebenfalls APT-GET,DNS,SSH und FTP freischalte. Info: Ich kann durch einen reboot als Admin beim Hoster, eine andere Konfiguration starten... sperre mich also nicht aus....

apt-get sollte, vorausgesetzt es nutzt HTTP und nicht FTP, mit der oben gezeigten Konfiguration arbeiten koennen da es ja dann auf Port 80 eines anderen Servers zugreift, was ja durch die Regeln erlaubt ist.
Andere Ports koennten gegebenenfalls mittels Port-Knocking geoeffnet werden. Dabei kontaktierst Du eine Sequenz geschlossener Ports und anschliessend wird fuer Deine IP z.B. der SSH-Port geoeffnet, fuer eine bestimmte Zeit versteht sich.

Im Default will ich den Server "as save as possible" laufen lassen.
Ich wundere mich, warum man so schwer an Default-Konfigurationen kommt.

Jeder hat eine andere Vorstellung davon wie sein Server konfiguriert sein soll. Entsprechend gibt es auch nicht "die eine Konfiguration" die alle gluecklich macht.

Um den Server zu sichern habe ich bisher:
-update/upgrade
-ssh Port umgelegt >65000
-rootlogin verboten
-pseudo user angelegt
-fail2ban nach 3 Versuchen, 24h Sperre, email Benachrichtigung
-iptables Grundkonfiguration (bis auf den Apache alles geschlossen, mit reload Problem)<<< Fehler, setzte jetzt meine erste IPtables ein... (copy&paste aus dem Web/nicht akzeptabel)...
-lange kryptische Passwörter (vermeintlich pseudo sicher)
-Suoshin Patch
-Traffic Hard-Limit

... noch ideen?

Schon ganz gut. fail2ban koennte man im Grunde rausnehmen indem man das IPTables-Modul recent nutzt. Die Konfiguration duerfte aber etwas komplexer ausfallen als es mit fail2ban der Fall ist. Kann ich aber nicht genau sagen. Hab's einmal mit recent gemacht, aber bislang nicht mit fail2ban gespielt.

Welche Distribution hast Du? Welche Virtualisierungsloesung wird genutzt?
Je nachdem wie diese Informationen aussehen koennte man eventuell ueber SELinux oder AppArmor (wobei ich selbst nur mit ersterem gearbeitet habe und aus diversen Gruenden absolut vorziehe) nachdenken.

Naja, wenn Du diesen ganzen Psalm gelesen hast, vielleicht magst Du ja antworten, ich habe das Gefühl daß Du im Gegensatz zu vielen Anderen ne Menge Plan von der Materie hast.

Ich bin weiss Gott kein Security-Gott, lese aber 'ne Menge und hab sehr viel mit IPTables und anderem Kram rumgespielt.

 

[Jupsihok]

Du bist der Hammer... und ich nenne Dich jetzt einfach mal trotzdem Gott!

Also das muß ich erstmal durcharbeiten, und nach möglichkeit verstehen....
dauert nen bissel, bin auf der Arbeit....

Eingesetzt wird Debian 4.0 Confixx Bundle.... auf nem Virtuozzo VPS.
Kernel Zugriff habe ich wie gesagt nicht.... denke langfristig ist dies so trotzdem eine gute Kombi, falls man nach positiver Testphase irgendwann mal weitere eigene Kundenprojekte hosten will....

Ich gehe jetzt mal nen Käffchen trinken, und dann werde ich falls noch kein Kunde Alarm macht, mal detailierter in Dein Posting gucken...

Ansonsten melde ich mich morgen nochmal...

Wirklich, herzlichen Dank für Deine Hilfe... ich habe nun schon reichlich Seiten durchstöbert... aber wirklich verständlich war kaum etwas... zumindest wenn einem das KnowHow fehlt... was bei mir als Webseiten/Programmierer eben Paketfiltering bisher ausschließt.

Vielen Dank!
Lieber Gruß
Jupsihok

PS: Ich durfte vor 2 Jahren erfahren, was es bedeutet wenn der eigene Server aufeinmal nicht mehr der eigene Server ist... war allerdings nen Root, und der gehörte einem Bekannten...
Er hatte keine Ahnung von Linux, ich ein bisschen... und so durfte ich Live am Telefon miterleben, was passiert... und wie Kunden reagieren wenn die Datenbestände (Mysql) weg, die Seite off und der Server inzwischen von Hoster stillgelegt worden ist.... weil in der Letzten Nacht das maximum an Traffic erreicht worden ist.... Ihm wolten etwas über 50 Kunden an den Kragen.... knapp 10 davon waren dabei sehr aktiv.... der Hoster wollte Geld, denke mal diese Erfahrung die ich nicht unmittelbar sondern nur aus nächster Nähe machen durfte haben mich in Sachen Absicherung nen bissel geprägt.
Mein Job war damals nur nen DB-Backup/Backup von den Resten anzufertigen... aber man hört an der Stimmlage was jemand der gerade voll auf die Nase gefallen ist denkt und fühlt...
Waren nen paar größere Seiten dabei... z.B. eine Institution die Bundesweit Ihre Tagesabwicklung aller Zentralen über das Web koordinieren.... da war absoluter Stillstand angesagt. Die Drohungen entsprechend. Ich bin lieber vorher zu Vorsichtig, als hinterher genau so ein "armes Schwein..." ... Jeder der einen Server betreibt trägt die Verantwortung für einen Server.... vergessen viele.

 

[Jupsihok]

Ich quote jetzt mal um zu verstehen was passiert....

# 1. Ich mache eine iptables Regel mit dem Namen myfilter auf
iptables -N myfilter

# 2. Ich droppe alle invaliden Pakete
iptables -A myfilter -m state --state INVALID -j DROP

# 3. Ich erlaube alle neuen Verbindungen, die sich auf bestehende beziehen
iptables -A myfilter -m state --state ESTABLISHED,RELATED -j ACCEPT

# 4. Ich erlaube alle ausgehenden Verbindungen zu Port 80 über TCP
iptables -A myfilter -p tcp --dport 80 -j ACCEPT

# 5. Ich erlaube alle eingehenden Verbindungen zu Port 80 per TCP
iptables -A myfilter -p tcp --sport 80 -j ACCEPT

# 6. Was wird hier rejected Alles andere?
iptables -A myfilter -p tcp -j REJECT --reject-with tcp-reset
iptables -A myfilter -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A myfilter -j REJECT --reject-with icmp-proto-unreachable

#7. Anwenden auf Input und Output
iptables -A INPUT -j myfilter
iptables -A OUTPUT -j myfilter

mmh,...
Ok, also ich verstehe nicht, warum ich einen sport und einen dport angebe,
wenn ich später diese auf Input und Output anwende.
Das ganze ist doch eigentlich eine Regel oder geht das nicht?

Würde im Fall von # 4. ja bedeuten daß ich eine dport von 80 auf den INPUT und OUTPUT lege und bei #5. einen sport auf 80 ebenfalls auf INPUT und OUTPUT.

Von der Sache her hätte ich gedacht daß ein:

iptables -A myfilter -p tcp --dport 80 --sport 80 -j ACCEPT

möglich sein müßte.

Wenn ich #6. einigermaßen interpretieren kann, dann werden sonst alle TCP Verbindungen rejected. Außer die die auf Port 80 eingehen und auf Port 80 ausgehen.

Wenn ein externer Besucher also per Port 75 surft, oder versucht per Port 79 meinen Server zu erreichen, dann müßte er eigentlich rejected werden.
Eingangs- und Ausgangsport sind doch als 80 definiert und erlaubt.
Würde ich zumindest denken.

Aber Vorsicht: Dieses Regelwerk hat ein gravierendes Problem! Wie Du vielleicht siehst werden hier Pakete von Port 80 zugelassen. Dies ist aufgrund der Bestimmung dass Apache Daten senden koennen soll.
Problem dabei ist dass dies auch einem entfernten Benutzer ermoeglicht von seinem Port 80 auf einen beliebigen Port bei Dir zu verbinden.

Genau das verstehe ich nicht, da ich alle Inputs auf 80 begrenze, kann doch der User zwar versuchen auf Port 90 anzuklopfen, bekommt aber ein REJECT?
Da alle Outputports bis auf 80 verboten sind, bzw. nur auf Port 80 der Apache ausgibt, habe ich doch dann auschließlich Kommunikation über Port 80 eingehend,ausgehend und die RELATED Verbindungen.

(Die sind für den 3-Way Handshake?, oder warum benötige ich die Related Verbindungsmöglichkeit?)

Ich würde dein Iptable insofern interpretieren, daß
-Port 80 INPUT OUTPUT frei ist
-Die RELATED Verbindungen frei sind
-Alle anderen verboten sind
-icmp pakete verworfen werden

Nun, jetzt besteht tatsächlich das Problem, daß jemand per ssh, oder smtp etc. versucht auf Port 80 zu connecten... aber was soll dabei rauskommen.

Du hast "Vorsicht" geschireben... das Problem an dieser Stelle verstehe ich noch nicht.

Du merkst, halbwissen, nen haufen Fragen.... sicherlich ist das eine oder andere selbst zu lösen....

Die Bindung ans Ausgabeinterface ist eigentlich ohnehin sinnig, da ich sonst bspw. zur MySQL Datenbank keine Verbindung bekomme... würde ich denken....
Die Bindung an das Eingabeinterface sicherlich auch.... so kann der VPS Hoster noch per Lan / lokalhost spionieren

mmh, trotzdem... seit dem ich verstehen will was wir hier machen, fühle ich mich jetzt nen bissel ratlos....

Lass Dir Zeit.... ich habe ganz bewußt eine Testphase mit eingeplant... solange ist der VPS außer für kurze Tests eh offline....

Würde mich freuen, wenn wir daß trotzdem noch nen bisschen abhandeln können.

PS: Bilde mir ein gesehen zu haben (finde es nur nicht wieder) daß iptables in der Lage ist über eine Dienstdefinition regeln zu binden... meine da gabs ein SSH beispiel, wo über einen Parameter SSH definiert wurde... und iptables also SSH anfragen nach einer bestimmten Regel behandelt hat.

Wenn das keine Haluzination war, dann wäre es sicher sinnvoll web/http oder wie auch immer diese Definition heißen würde... an das Regelwerk zu binden.
Zumindest wenn iptables am Header erkennt um was es sich bei der Kommunikation tatsächlich handelt. Ich bin mir nicht sicher, ob ich daß falsch verstanden habe, da das ganz zu Anfang meiner Recherche war. Ansonsten ist es wohl das sicherste einen http/web Header Inhalt/Anfrage direkt auf Port80 / Apache zu routen.

mmh...


EDIT: Es war keine Haluzination, aber läßt sich bei mir nicht nutzen wegen Kernelpatch.
Falls es Dich interessiert.... http://l7-filter.sourceforge.net/


Nuja, jetzt muß ich erstmal weitermachen....

Schönen Gruß nach HonkKong....
Jupsihok

 

[Dennis Wronka]

Eingesetzt wird Debian 4.0 Confixx Bundle.... auf nem Virtuozzo VPS.
Kernel Zugriff habe ich wie gesagt nicht.... denke langfristig ist dies so trotzdem eine gute Kombi, falls man nach positiver Testphase irgendwann mal weitere eigene Kundenprojekte hosten will....

Virtuozzo/OpenVZ ist eine ganz gute Loesung. Man hat zwar, wie Du schon festgestellt hast keinen eigenen Kernel, aber dafuer ist diese Art der Virtualisierung sehr performant.
Ich hab eine Weile mit OpenVZ gespielt und konnte in einem bereits virtualisierten System (Vollvirtualisierung mittels KVM) locker mehrere OpenVZ-VMs laufen lassen.

Wirklich, herzlichen Dank für Deine Hilfe... ich habe nun schon reichlich Seiten durchstöbert... aber wirklich verständlich war kaum etwas... zumindest wenn einem das KnowHow fehlt... was bei mir als Webseiten/Programmierer eben Paketfiltering bisher ausschließt.

So ist das eben heute in der Informatik. Ich hab Fachinformatiker, Fachrichtung Systemintegration gelernt und die letzten Jahre meist mein Brot mit PHP verdient...

# 1. Ich mache eine iptables Regel mit dem Namen myfilter auf
 iptables -N myfilter
 
 # 2. Ich droppe alle invaliden Pakete
 iptables -A myfilter -m state --state INVALID -j DROP
 
 # 3. Ich erlaube alle neuen Verbindungen, die sich auf bestehende beziehen
 iptables -A myfilter -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 # 4. Ich erlaube alle ausgehenden Verbindungen zu Port 80 über TCP
 iptables -A myfilter -p tcp --dport 80 -j ACCEPT
 
 # 5. Ich erlaube alle eingehenden Verbindungen zu Port 80 per TCP
 iptables -A myfilter -p tcp --sport 80 -j ACCEPT
 
 # 6. Was wird hier rejected Alles andere?
 iptables -A myfilter -p tcp -j REJECT --reject-with tcp-reset
 iptables -A myfilter -p udp -j REJECT --reject-with icmp-port-unreachable
 iptables -A myfilter -j REJECT --reject-with icmp-proto-unreachable
 
 #7. Anwenden auf Input und Output
 iptables -A INPUT -j myfilter
 iptables -A OUTPUT -j myfilter

1. Ist nur ein Detail-Punkt, aber Du erstellst hierbei eine neue Kette, welche dann anschliessend mit Regeln gefuellt wird.
2. Richtig. Zumindest mehr oder weniger. Hier werden alle Pakete gedroppt die das Connection-Tracking, aus welchem Grund auch immer, als ungueltig erachtet. Ich denke dass hier inkomplette Verbindungen, z.B. bei einem unsauber durchgefuehrten Replay-Angriff, gefiltert werden duerften.
3. Nicht ganz. Hier erlaubst Du Verbindungen die bereits vollstaendig aufgebaut wurden (ESTABLISHED) und Verbindungen die zu einer bereits aufgebauten Verbindung zugehoerig sind (RELATED). Letzteres ist z.B. bei FTP der Fall, da das Protokoll 2 Verbindungen (Control- und Data-Connection) verwendet.
   Du kannst Dir im Grunde das RELATED sparen, ich hab es aus Gewohnheit reingesetzt.
4. Auch nicht ganz. Hier werden alle Pakete zu TCP-Port 80 erlaubt. Egal ob sie reinkommen oder rausgehen. Entsprechend sollte diese Regel also sowohl fuer Apache als auch fuer apt-get funktionieren.
5. Nein. Alles was von Port 80 kommt, ob nun von Deinem Port 80, also Antworten Deines Webservers, aber auch Pakete von fremden Rechnern von Port 80, werden hier zugelassen.
   Wie gesagt, dass ist ein Problem da ich ja z.B. einen Port-Scan von meinem Port 80 starten koennte. Das, in Zusammenspiel mit dieser Regel, hebelt dann den Paket-Filter komplett aus da ja meine Pakete von Port 80 kommen und somit von dieser Regel zugelassen werden. Egal auf welchen Port ich bei Dir zugreifen will.
   Entsprechend sollte diese Regel, wie im anderen Beispiel gezeigt, durch die Bindung an das Output-Interface (Parameter -o) auf ausgehende Verbindungen limitiert werden.
6. Richtig. Alles was zuvor nicht explizit zugelassen wurde wird hier abgewiesen.
7. Richtig. Damit alle Pakete die reinkommen und rausgehen durch die eigene Kette laufen muss diese natuerlich in INPUT und OUTPUT als Target fuer alle Pakete (also ohne irgendwelche Konditionen) angegeben werden. Ansonsten ist die Kette zwar da, macht aber nix.

Ok, also ich verstehe nicht, warum ich einen sport und einen dport angebe, wenn ich später diese auf Input und Output anwende.
Das ganze ist doch eigentlich eine Regel oder geht das nicht?

Nein, das kannst Du nicht in eine Regel packen. Konditionen sind mittels AND verknuepft, nicht mittels OR.
Wuerdest Du also --sport 80 und --dport 80 in einer Regel anwenden wuerden davon ausschliesslich Pakete zugelassen die von Port 80 nach Port 80 gehen. Im Normalfall waere diese Regel ziemlich unpraktisch und wuerde Deinen Server praktisch vor der Aussenwelt verschliessen da Browser nicht von Port 80 ihre Anfragen senden.

Wenn ich #6. einigermaßen interpretieren kann, dann werden sonst alle TCP Verbindungen rejected. Außer die die auf Port 80 eingehen und auf Port 80 ausgehen.

Nicht ganz. Da die eigene Kette sowohl in INPUT als auch in OUTPUT verankert wird ist die Richtung der Pakete unbestimmt. Daher ja auch die eine Anpassung der --sport-Regel um dem ganzen eine Richtung zu geben, und zwar nach draussen.
Zudem muss bedacht werden dass bei der Abarbeitung der Regeln ein Paket nur solange den Filter durchlaeuft bis es auf eine Regel stoesst die zutrifft. In diesem Fall wird das Paket aus der Verarbeitung genommen (ausser es handelt sich um einen Sprung in eine andere Kette oder beim Logging) und die Aktion der zutreffenden Kette wird angewandt.

Zur Veranschaulichung das Beispiel aus meinem Tutorial:

iptables -A INPUT -p icmp -j DROP
iptables -A INPUT -p icmp -s 192.168.0.22 -j ACCEPT

In der ersten Zeile werden alle ICMP-Pakete gedroppt.
In der zweiten Zeile werden ICMP-Pakete die von 192.168.0.22 kommen akzeptiert.
Da aber bereits zuvor alle ICMP-Pakete gedroppt wird die zweite Regel nie zutreffen.
Um ICMP-Pakete von 192.168.0.22 zuzulassen muss die Reihenfolge vertauscht werden sodass eben erst die erwuenschten Pakete zugelassen werden und anschliessend alle anderen gedroppt werden.

Wenn ein externer Besucher also per Port 75 surft, oder versucht per Port 79 meinen Server zu erreichen, dann müßte er eigentlich rejected werden.

Richtig, auch bei der unsicheren Konfiguration die die --sport-Regel nicht auf ausgehende Verbindungen limitiert. Ganz einfach weil es weder eine Regel mit --sport 75 noch eine Regel mit --dport 79 gibt.

Eingangs- und Ausgangsport sind doch als 80 definiert und erlaubt.
Würde ich zumindest denken.

Richtig. Es ist aber nicht spezifiziert wessen Port das ist.
Genau darum ermoeglicht die --dport-Regel ja sowohl den Zugriff auf Deinen Apache (Dein Ziel-Port 80), als auch die Funktion von apt-get (fremder Ziel-Port 80).
Und darum ist auch die --sport-Regel in der oben gezeigten Variante unsicher. Sie erlaubt zwar Deinem Apache (Dein Quell-Port 80) Pakete zu schicken, sie erlaubt aber auch jedem (fremder Quell-Port 80) anderen Pakete an beliebige Ports bei Dir zu schicken.

Da alle Outputports bis auf 80 verboten sind, bzw. nur auf Port 80 der Apache ausgibt, habe ich doch dann auschließlich Kommunikation über Port 80 eingehend,ausgehend und die RELATED Verbindungen.

(Die sind für den 3-Way Handshake?, oder warum benötige ich die Related Verbindungsmöglichkeit?)

Wie oben gesagt sind die RELATED-Verbindungen fuer Verbindungen welche mit einer bereits bestehenden Verbindungen eine "Verwandtschaft" haben, wie z.B. bei FTP.

Nun, jetzt besteht tatsächlich das Problem, daß jemand per ssh, oder smtp etc. versucht auf Port 80 zu connecten... aber was soll dabei rauskommen.

Das kann er gern probieren. Viel passieren wird da nicht es ein Missverstaendnis auf Applikationsebene geben wird. Apache wird die Anweisungen die vom SMTP- oder SSH-Client nicht verstehen und, hoechtwahrscheinlich, die Verbindung trennen.

Du hast "Vorsicht" geschireben... das Problem an dieser Stelle verstehe ich noch nicht.

Siehe oben. Problem ist dass --sport nicht auf eine bestimmte Richtung begrenzt ist.

Die Bindung ans Ausgabeinterface ist eigentlich ohnehin sinnig, da ich sonst bspw. zur MySQL Datenbank keine Verbindung bekomme... würde ich denken....

Anbindung an MySQL erfolgt, wenn der MySQL-Server auf dem gleichen Rechner ist wie Apache, in der Regel ueber Unix-Sockets, geht also glatt am Paket-Filter vorbei.

Allgemein ist es aber dennoch eine gute Idee Pakete ueber das Loopback-Interface (lo) zuzulassen.

Würde mich freuen, wenn wir daß trotzdem noch nen bisschen abhandeln können.

Ich freu mich immer wenn mal ein IPTables-Thema kommt. Die machen immer wieder Spass.

PS: Bilde mir ein gesehen zu haben (finde es nur nicht wieder) daß iptables in der Lage ist über eine Dienstdefinition regeln zu binden... meine da gabs ein SSH beispiel, wo über einen Parameter SSH definiert wurde... und iptables also SSH anfragen nach einer bestimmten Regel behandelt hat.

Wenn das keine Haluzination war, dann wäre es sicher sinnvoll web/http oder wie auch immer diese Definition heißen würde... an das Regelwerk zu binden.
Zumindest wenn iptables am Header erkennt um was es sich bei der Kommunikation tatsächlich handelt. Ich bin mir nicht sicher, ob ich daß falsch verstanden habe, da das ganz zu Anfang meiner Recherche war. Ansonsten ist es wohl das sicherste einen http/web Header Inhalt/Anfrage direkt auf Port80 / Apache zu routen.

mmh...


EDIT: Es war keine Haluzination, aber läßt sich bei mir nicht nutzen wegen Kernelpatch.
Falls es Dich interessiert.... http://l7-filter.sourceforge.net/

Hab ich mal drueber gelesen, aber nicht mit rumgespielt. Sollte ich vielleicht mal machen.

 

[Jupsihok]

Boah, hallo Dennis....

mir ist die Platte abgeschmiert... und ich hatte voll vergessen WO ich mit Dir kontakt hatte.... endlich gefunden *JUBEL*

Nuja, inzwischen hat sich auch mein Hoster geändert... bin von Vanager zu Strato.

Und jetzt fängt das Spiel von vorn an... *lach*

Naja, ich benutze unsere bisherige Erörterung mal als Grundlage....

Ich würde jetzt unser Regularium ausschlißlich an das externe Interface binden...
bei mir soweit ich das sehe venet0:0 .... mit der externen IP...

Was mir noch nicht so ganz einleuchtet ist das ich lo und venet0 anscheinend als loopback habe...

lo ist ja nun definitiv loopback, aber warum venet0 ebenfalls loopback ist... mmh, grübel... naja, zunächst ja egal....

Wollte mich nach meinem "Wiederfinden" nur mal kurz gemeldet haben...

Lieber Gruß
Jupsihok

 

[Jupsihok]

Och Menno...
hätte jetzt gedacht, daß das so richtig ist.... allerdings schmiert mir der SSH Zugang auf der 62000 ab... wenn ich das so aufrufe, kann ich den Server gleich neu booten

Würdest Du mir bitte nochmal einen Tipp geben, was hier verkehrt läuft?

Und zweites Problem... ich deklariere die DROPS ja global sozusagen, wie schalte ich den Loopback komplett frei... bzw. wie binde ich die Freischaltungsregel "Alles akzeptieren" an das Loopbackinterface....

Wäre über noch ein bisschen Profiwissen sehr erfreut....

Lieber Gruß
Jupsihok

iptables -F
iptables -X

iptables  -P INPUT DROP
iptables  -P OUTPUT DROP
iptables  -P FORWARD DROP

iptables -N GUARDIAN
iptables -A GUARDIAN -i venet0 -m state --state INVALID -j DROP
iptables -A GUARDIAN -i venet0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --dport 80 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --sport 80 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --dport 62000 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --sport 62000 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp -j REJECT --reject-with tcp-reset
iptables -A GUARDIAN -i venet0 -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A GUARDIAN -i venet0 -j REJECT --reject-with icmp-proto-unreachable

iptables -i -A INPUT -j GUARDIAN
iptables -i -A OUTPUT -j GUARDIAN

 

[Jupsihok]

Aua aua aua... aua aua aua

Blöd gebohren und nix dazugelernt....

Ja, mußte mich erst einmal wieder erinnern... lang ists her,
war ja totaler quatsch meine Frage....

So habe ich es jetzt.... wenn Du da noch was siehst was falsch läuft, wärs trotzdem nett darauf nochmal einzugehen....

iptables -F
iptables -X

iptables -N GUARDIAN
iptables -A GUARDIAN -i venet0 -m state --state INVALID -j DROP
iptables -A GUARDIAN -i venet0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --dport 80 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --sport 80 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --dport 62000 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp --sport 62000 -j ACCEPT
iptables -A GUARDIAN -i venet0 -p tcp -j REJECT --reject-with tcp-reset
iptables -A GUARDIAN -i venet0 -p udp -j REJECT --reject-with icmp-port-unreach$
iptables -A GUARDIAN -i venet0 -j REJECT --reject-with icmp-proto-unreachable

iptables -A INPUT -j GUARDIAN
iptables -A OUTPUT -j GUARDIAN

Lieber Gruß
Jupsihok