Sinnvolle Firewall für Webserver

brahma

brahma

Netzpirat
Ich möchte meine Firewall auf dem Webserver auf die minimalen Ports beschwänken, ist nur die Frage welche ich unbedingt brauche. ;)

Also nötig sind meines erachtens:


  1. 20 + 21 ftp (brauch ich etch beide?)
  2. 22 ssh (seeeehr wichtig)
  3. 25 smtp
  4. 80 http
  5. 110 pop3
  6. 113 ident (nötig damit der server trusted ist im IRC für mehr als 3 Verbindungen)
  7. 143 imap
  8. 443 https
  9. xxxx Port meines BNC
  10. 6881-6999 Ports für BT

Aber was ist mit folgenden, sind die nötig?
  1. 43 whois
  2. 53 dns
  3. 123 ntp (zeit wird per ntp aktualisiert)
  4. 1080 socks
  5. 3306 mysql (läuft nur lokal)

MySQL soll nur für den Rechner selber zur Verfügung stehen, nicht von ausserhalb nutzbar sein. Soweit ich das weiss muss der Port offen bleiben, aber ich kann verbindungen ja nur von localhost zulassen.

Hab ich Ports vergessen?
Bietet sich denn die IPTables-Option DROP oder REJECT für eine Server-Firewall an? DROP ist ja sicher praktisch um die Leute im unklaren zu lassen, kann natürlich auch dazu führen das gewollte Anfragen meinen das der Server down ist. Wie haltet ihr das?
 
MySQL soll nur für den Rechner selber zur Verfügung stehen, nicht von ausserhalb nutzbar sein. Soweit ich das weiss muss der Port offen bleiben, aber ich kann verbindungen ja nur von localhost zulassen.
Hallo,

ich denke der Port muß in IP-Tables nicht offen sein, ebenso die für alle Dienste, die du zwar woanders abfragst, aber die nicht nach außen hin irgend was liefern. So z.B. DNS - solange niemand deinen Server als DNS braucht, braucht der auch nicht offen zu sein. Notfalls kannst du das nach innen öffnen und an ein bestimmtes Netzwerkdevice binden, sodaß Rechner von intern den nutzen können. Ich habe z.B. einen DNS laufen und einen DHCP nach innen, der den bei intern sich anmeldenden Rechnern dahin übergibt. Und der selber ist nur ein Forwarder an den DNS von Hansenet, das funzt primös. Was soll ich a) DNS-Tabellen verwalten und b) diese nach außen anbieten?

MySQL ist auf unseren Firmenservern auch nach außen zu, wird aber intern rege von Scripten genutzt. Die Scripte laufen als ein User und der muß das in MySQL dürfen, was er dort will, das reicht eigentlich nach meiner Erfahrung...
 
Die sinnvollste Firewall für einen Webserver ist gar keine.

Alle Ports auf die nicht zugegriffen werden können soll, sollten so oder so geschlossen sein.
Und wenn alle Ports geschlossen sind auf die nicht zugegriffen werden soll dann brauchst du auch keine Firewall.

Ein reiner Portfilter auf einem Webserver frisst nur Performance und schafft ein Sicherheitsgefühl ohne tatsächlich vorhandene Sicherheit.

Dein Hauptproblem sind Sicherheitslücken in Diensten und da hilft die Firewall gar nichts, da du ja den Zugriff erlauben musst sonst kann keiner mehr auf deinen Webserver zugeifen etc.

Konfiguriere lieber deinen Server richtig, so dass die Datenbank nur auf den Lokalhost hört etc.

Eine Firewall hat als reine Absicherung für deine Ports auf einem Webserver nichts zu suchen.

Gruß sono
 
wenn du nur nen webserver hast dann alle dienste und ports ausser 80 und 443 dicht machen. ;)
 
Nicht ganz, Mail-und Webserver isses, auf dem aber auch ein BNC läuft.

Naja, die Diskussion über unsinn einer Firewall auf einem Webserver hab ich schon öfter gelesen, das kann man durchaus geteilter Meinung sein war das Resumé. Es laufen auch nur die Dienste die nötig sind, alles andere ist aus, dafür hab ich ja schon gesorgt. Mein Server wurde auch 2x missbraucht in den letzten (>5) Jahren, alle durch Lücken in der ehemals verwendeten Foren-Software phpBB, nicht durch andere Aktionen die direkt mit den Programmen zusammen hängen.

Meine idee war nur, dicht zu machen was nicht gebraucht wird, sicher ist das trügerisch, aber ich denke schaden kanns nicht, oder seh ich da was falsch?
 
Wie schon bemerkt bringt dir auch eine Firewall nicht wirklich viel wenn eine Webapplikation die von aussen erreichbar ist Fehler enthält!
 
Jo, das mir klar, genauso wie wenn z.B. der Apache ne Lücke hat, liegt ja auch der Hand. Also lohnt es sich net, frisst nur Resourcen ist das Statement?!
 
mit einer guten firewall kann man:

. auch BufferOverrun pakete abfangen !
. dem ssh benutzer root nur eine 300B/s leitung vorgaukeln
. oder noch so lustiege sachen wie alle ungenutzen ports zu mirror'n

UND DAS ALLES IM KERNELSPACE

iptables ist schon was wert :D
 
Nun, wie gesagt als reiner Paketfilter bringt iptables gar nichts.

Wenn deine apps auf dem webserver unsicher sind dann hilft dir iptables gar nichts.

Wenn jemand auf einen Port nicht zugreifen soll, warum ist der dann bitte offen?

Bufferoverflow Pakete abfangen usw würde ein ids machen afaik, und das solltest du auf keinen Fall parallel auf dem server laufen lassen.

Für Bandbreiten Beschränkung kann mans nehmen, aber vielleicht sollte man da doch lieber tc nehmen. ( Oder meinen wir da gerade dasselbe? )

Wobei da würde ich erst mal schaun ob die app deren Bandbreite ich beschneiden will das nicht von Haus aus kann.

Also es gibt keinen Grund als reinen Paketfilter zu verwenden. ( Es gibt durchaus nützliche Anwendungsmöglichkeiten, siehe Port Knocking http://en.wikipedia.org/wiki/Port_knocking z.B )

Öhm, wo wir gerade so begeistert von Kernelspace reden, eine Lücke in iptables oder der verwendeten iptableserweiterung und der Angreifer hat sofort Rootrechte.

Also du hast keine Vorteile bei dem was du machen willst, es kostet performance und wenn ne Lücke auftritt hat der Angreifer sofort Rootrechte.

Würde er deinen Webserver hacken, hätte er erst mal nur die Rechte des Webservers. Und du noch die Kontrolle über den Server. ( Ok wenn du nicht reagierst hast du die unter umständen auch nicht lange. )

Gruß Sono
 
( Ok wenn du nicht reagierst hast du die unter umständen auch nicht lange. )

Hehe, der Spruch gefällt mir :D

Zurück zum Thema: Ne, es laufen nur die Prozesse die laufen sollen, alles ausser Basis und ssh hab ich selber installiert, daher sind keine unnötigen "Standart-Prozesse" an die z.B. eine Desktop-Auto-Installation hat. Inetd ist z.B. aus, braucht ja keiner momentan :D

Das eine FW die Ports der laufen Prozesse nicht schützen kann, ist klar, ein Apache bringt nix, wenn Port 80 und 443 geblockt werden ;)

Und das die offenen Standart-Ports ohne laufen Prozess (z.B. IRC) durchaus offen bleiben können, liegt auch auf der Hand, wo nix ist, kann auch keiner Anagreifen, man kann ja auch durch keine Tür einbrechen hinter der kein Raum ist (ok, vlt. nicht das beste Beispiel) :D

Was ist denn mit dem blocken der unnötigen Ports nach draussen? Oder auch von aussen? Als Szenario hab ich im Kopf, das es einer schafft eine Lücke in PHP zu nutzen, seinen Root-Kit oder ähnliches auf den Server setzt und erstmal vlt. nix macht. Wenn jetzt die Standart-Ports dicht sind, kommt der an seinen Kit nicht ran, und sein Kit auch nicht raus. Ausserdem kann die FW solche Verbindungsversuche ja protokollieren und macht es einem leichter das nachzuvollziehen.

Ich hab mittlerweile viel gegoogelt dazu, und hab eben beide Seiten dazu mit verbünftigen Argumenten gelesen. Also nicht glauben das ich an deiner Aussage zweifel, ich guck gerade nur nach den Optionen :D
BTW. ist eine FW nicht eben auch eine zusätzliche Sicherheitschicht, die zusammen mit sinnvoller Konfiguration, Monitoring und Backups einem helfen kann? Das war nämlich meine Idee dahinter :D
 
Wenn jetzt die Standart-Ports dicht sind, kommt der an seinen Kit nicht ran, und sein Kit auch nicht raus.
Hallo,

na ja raus kann er sowieso und durch Firewalls kann man auch tunneln bzw. "hole punching" betreiben. Auf Heise gab's mal einen interessannten Artikel dazu, wie Skype das beispielsweise macht...

Ausserdem kann die FW solche Verbindungsversuche ja protokollieren und macht es einem leichter das nachzuvollziehen.
Ja, das finde ich auch sinnvoll (und ist auch übrigens genau der Punkt, an dem Tools wie "fail2ban" ansetzen - das finde ich eigentlich noch schöner als "port knocking": Wenn z.B. jemand mehrfach für SSH ein falsches Kennwort eingibt (Bruteforce-Attacken tun das prinzipiell...), wird einfach seine IP für einen festzulegenden Zeitraum geblockt, alle anderen nicht und man selber kann mit richtigen Zugangsdaten jeder Zeit drauf, ohne ein "knock secret" zu schicken vorher, das ja auch aus Paketen besteht, die abgehört werden können.

Das schöne an IP-Tables ist, daß man es dynamisch im laufenden Betrieb an irgend welche Gegebenheiten anpassen kann, wie das Beispiel fail2ban zeigt: Nämlich einen genutzten Port unter bestimmten Umständen und nur für bestimmten Verkehr zu sperren, während er vorher, nachher oder für bestimmte Leute sogar während der Sperre offen bleibt, ohne jedes mal manuell in die Dienstekonfiguration hinein und den Dienst reloaden zu müssen.

Also ich benutze das eigentlich öfters, was aber den genannten Schwächen keinen Abbruch tut. Die Frage ist eher, ob bei einem dedizierten Web- und /oder Mailserver solche flexiblen Szenarien überhaupt eintreten oder nicht doch 3-5 wichtige Dienste laufen und das war's einfach...

Die Debatte über für und wider geht hoch her (ebenso in der Windows-Welt, wo der tügerische Glaube an Schutzsoftware eher noch viel verbreiteter ist, aber auch XP kann man von den Diensten her so zu nageln, daß nmap rein gar nichts mehr anzeigt). Das Beispiel mit der Tür ohne Raum dahinter trifft es eigentlich, bzw. eher ein Türsteher vor ner Wand, in der keine Tür ist... stünde der gar nicht da, könnte man ihn nicht mal bestechen und zu auftragsfremden Handlungen anstiften :O
 

Ähnliche Themen

iptables-skript, Verbesserungsvorschläge

Squid nur zum maskieren der eigenen IP, nicht für Webserver auf port 80

Mysql hinter Firewall

Suche jemanden für UNIX/IMAP Installation

Problem mit IPTables

Zurück
Oben