morgen, mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall. kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit? ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich? mfg dominik 'ara' thüriedl
On Tue, Jun 17, 2003 at 01:08:00AM +0200, Dominik Thüriedl wrote:
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Auf meinem Rootserver bei 1&1 habe ich iptables in Betrieb genommen. Dazu verwende ich das beigefügte Script, das ich in /etc/init.d/kkfirewall installiert habe. Das Script lädt ein Shellscript /etc/kkfirewall/kettenhemdhuehner.de.fw, das ich mit fwbuilder erzeugt habe (http://www.fwbuilder.de). Anders als SuSEFirewall2 ist die mit fwbuilder generierte Firewall frei konfigurierbar, die Rules sind leichter zu lesen und zu warten und man kann beliebige Sonderwünsche realisieren. Während SuSEFirewall2 also für ein vorgegebenes Standardssetup daheim besser geeignet ist, ist fwbuilder für Leute, die sich auskennen und die besondere Anforderungen haben, das Werkzeug der Wahl. Außerdem will man sich noch iptstate runterladen und installieren, egal ob man SuSEFirewall2 oder fwbuilder verwendet, damit man die State-Tabelle der Firewall im Betrieb "top"-artig beobachten kann. Die Firewall-Rules, die ich verwende, sehen so aus: http://vvv.koehntopp.de/fwbuilder1.png http://vvv.koehntopp.de/fwbuilder2.png Kristian #! /bin/sh # # System startup script for kkfirewall # ### BEGIN INIT INFO # Provides: kkfirewall # Required-Start: $remote_fs $syslog $network # Required-Stop: $remote_fs $syslog $network # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Description: Start kkfirewall ### END INIT INFO FWCONFIG=/etc/kkfirewall/kettenhemdhuehner.de.fw FWLOG=/var/log/firewall # Source SuSE config (if still necessary, most info has been moved) test -r /etc/rc.config && . /etc/rc.config test -f $FWCONFIG || exit 6 # Shell functions sourced from /etc/rc.status: # rc_check check and set local and overall rc status # rc_status check and set local and overall rc status # rc_status -v ditto but be verbose in local rc status # rc_status -v -r ditto and clear the local rc status # rc_failed set local and overall rc status to failed # rc_failed <num> set local and overall rc status to <num><num> # rc_reset clear local rc status (overall remains) # rc_exit exit appropriate to overall rc status # rc_active checks whether a service is activated by symlinks . /etc/rc.status # First reset status of this service rc_reset # Return values acc. to LSB for all commands but status: # 0 - success # 1 - generic or unspecified error # 2 - invalid or excess argument(s) # 3 - unimplemented feature (e.g. "reload") # 4 - insufficient privilege # 5 - program is not installed # 6 - program is not configured # 7 - program is not running # # Note that starting an already running service, stopping # or restarting a not-running service as well as the restart # with force-reload (in case signalling is not supported) are # considered a success. case "$1" in start) echo -n "Starting kkfirewall" echo "`date`: Starting firewall." >> $FWLOG sh $FWCONFIG >> $FWLOG 2>&1 # Remember status and be verbose rc_status -v ;; stop) echo -n "Shutting down kkfirewall" echo "`date`: Stopping firewall." >> $FWLOG iptables -P OUTPUT ACCEPT iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -F # Remember status and be verbose rc_status -v ;; restart) ## Stop the service and regardless of whether it was ## running or not, start it again. $0 stop $0 start # Remember status and be quiet rc_status ;; status) echo -n "Checking for service kkfirewall: " ## Check status with checkproc(8), if process is running ## checkproc will return with exit status 0. iptables -n -L rc_status -v ;; *) echo "Usage: $0 {start|stop|status|restart}" exit 1 ;; esac rc_exit
Hallo,
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
In letzter Zeit wurden viele DoS-Attacken auf 1&1-Server gestartet. Ich empfehl dir deswegen ne Firewall! Gruß Thomas
Am Dienstag, 17. Juni 2003 09:20 schrieb Thomas Worm:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall. kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Wenn auf dem Rechner nur der Apache und ein sshd laufen, ist ein Paketfilter (der ist wohl hier mit Firewall gemeint) reichlich sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen. Auf dem Rechner müssen wohl - Apache - sshd - ftpd laufen. Du brauchst also die Ports 21, 22 und 80. Geöffnet werden die von den jeweiligen Dämonen. Alle anderen sind zu. Auch ohne Paketfilter. Der macht deinen Apache ungefähr überhaupt nicht sicherer. Viel wichtiger ist es, nur die Services laufen zu lassen, die du benötigst und zu diesen jeweils als sicher[tm] eingestufte Versionen der Software einzusetzen. Etwas anderes ist es, wenn du zum Beispiel ftp-Uploads oder ssh-login nur von bestimmten Adressen aus erlauben willst. Oder auf den Datenbankserver nur vom Webserver aus zugegriffen werden soll. Dann brauchst du einen Paketfilter.
In letzter Zeit wurden viele DoS-Attacken auf 1&1-Server gestartet. Ich empfehl dir deswegen ne Firewall!
Kannst du noch kurz anreißen, wie deine Firewall![1] eine DoS-Attacke verhindert? Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert wrote:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall. kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Wenn auf dem Rechner nur der Apache und ein sshd laufen, ist ein Paketfilter (der ist wohl hier mit Firewall gemeint) reichlich sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen.
Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab! Und zum Thema. Ein gut konfigurierter Paketfilter verhindert auch noch viele andere Schweinereien z.B. gefakte Ip-Adressen, Syn-Floods, Ping-of-Death, Port-Scans. Und was, wenn es einen Fehler im Apache,FtpD oder Kernel gibt, ein Benutzer bekommt ne Shell und verschickt mal eben ein paar hunderttausend Mails, oder Ping't andere Rechner zu Tode, mit DEINER Ip! Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen und eine Firewall ist erstens von Hause aus dabei und zum anderen auch nicht soo schwierig zu konfigurieren. Gruß, Andreas
Andreas Winkelmann wrote:
Martin Borchert wrote:
Wenn auf dem Rechner nur der Apache und ein sshd laufen, ist ein Paketfilter (der ist wohl hier mit Firewall gemeint) reichlich sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen.
Ein gut konfigurierter Paketfilter verhindert auch noch viele andere Schweinereien z.B. gefakte Ip-Adressen,
das problem mit gespooften IPs ist in diesem falle welches?
Syn-Floods,
TCP syncookies haben nichts mit dem paketfilter zu tun.
Ping-of-Death,
wir sind doch nicht mehr im mittelalter.
Port-Scans.
das problem mit portscans ist gleich noch welches?
Und was, wenn es einen Fehler im Apache,
der paketfilter nutzt dann noch was?
FtpD
woher kommt jetzt der ftpd?
oder Kernel gibt,
am besten in der netfilter-implementierung.
ein Benutzer bekommt ne Shell
woher bekommt er die jetzt?
und verschickt mal eben ein paar hunderttausend Mails,
neben dem ftpd taucht jetzt auch noch ein smtp aus dem nichts auf?
oder Ping't andere Rechner zu Tode,
echt? wie denn?
mit DEINER Ip!
woher willst du das wissen? könnte doch gespooft sein.
Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen
richtig. dazu gehört aber auf _keinen_ fall, sich auf einen paketfilter zu verlassen. nicht benötigte dienste sind zu deaktivieren, benötigte dienste sind nur an die benötigten devices zu binden. wenn dann also nur noch die benötigten dienste an das world-device gebunden sind, wozu der paketfilter?
und eine Firewall ist erstens von Hause aus dabei
wo?
und zum anderen auch nicht soo schwierig zu konfigurieren.
das erzähle mal unserem gruppenidioten. micha
Am Dienstag, 17. Juni 2003 15:24 schrieb Peter Wiersig:
Michael Meyer wrote:
Andreas Winkelmann wrote:
Syn-Floods, TCP syncookies haben nichts mit dem paketfilter zu tun. iptables -m limit -p tcp --tcp-flags SYN --limit 3/second \ --limit-burst 5
Und schon hast du einen DoS. Du _kannst_ nicht zwischen legalem und illegalem Verkehr unterscheiden. Statt dessen blockst du zufällig Pakete und hinderst deine Nutzer an der Kommunikation. Dein Paketfilter hat also nur marginale Auswirkungen. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 15:24 schrieb Peter Wiersig:
Michael Meyer wrote:
Andreas Winkelmann wrote:
Syn-Floods, TCP syncookies haben nichts mit dem paketfilter zu tun. iptables -m limit -p tcp --tcp-flags SYN --limit 3/second \ --limit-burst 5
Du _kannst_ nicht zwischen legalem und illegalem Verkehr unterscheiden.
Ich kann. Zulaessiger Verkehr kommt aus meinem Class-C Netz. Die Anweisung, die ich da oben gepostet habe sollte sicher nicht so fuer sich alleine stehen. Mein Class-C wuerde ich auch nicht durch die limit-Anweisung leiten.
Statt dessen blockst du zufällig Pakete und hinderst deine Nutzer an der Kommunikation.
Ja, stimmt, so ohne Bezug auf einen Kunden zu nehmen ist die Regel bloed. Peter
Am Dienstag, 17. Juni 2003 16:44 schrieb Peter Wiersig:
Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 15:24 schrieb Peter Wiersig:
Michael Meyer wrote:
Andreas Winkelmann wrote:
Syn-Floods, TCP syncookies haben nichts mit dem paketfilter zu tun. iptables -m limit -p tcp --tcp-flags SYN --limit 3/second \ --limit-burst 5 Du _kannst_ nicht zwischen legalem und illegalem Verkehr unterscheiden. Ich kann. Zulaessiger Verkehr kommt aus meinem Class-C Netz.
Ok, du kannst. Dominik kann nicht.
Die Anweisung, die ich da oben gepostet habe sollte sicher nicht so fuer sich alleine stehen. Mein Class-C wuerde ich auch nicht durch die limit-Anweisung leiten.
Ich kann den Sinn nicht entdecken. Wenn ich weiß, dass der Ursprung illegal ist, dann rejecte ich ihn. Wenn ich das nicht weiß, muss ich ihn annehmen, um den Service aufrecht zu erhalten. Sonst hat der DoSer gewonnen. Die Anzahl der akzeptierten Pakete wahllos zu beschränken halte ich für eine selten dämliche Heuristik. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Michael Meyer wrote: [kopfschütteln] Eine Firewall oder von mir aus ein Paket-Filter ist einfach nur ein _zusätzliches_ Stück Sicherheit. Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert man muss ihn (nur) konfigurieren. Und ich wüsste wirklich keinen Grund darauf zu verzichten. Gruß, Andreas
Andreas Winkelmann wrote:
Michael Meyer wrote: [kopfschütteln]
worüber?
Eine Firewall oder von mir aus ein Paket-Filter ist einfach nur ein _zusätzliches_ Stück Sicherheit.
das kommt darauf an ...
Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert
bei so gut wie allen aktuellen? bei welchen den nicht? micha
Michael Meyer wrote:
Eine Firewall oder von mir aus ein Paket-Filter ist einfach nur ein _zusätzliches_ Stück Sicherheit.
das kommt darauf an ...
Worauf ?
Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert
bei so gut wie allen aktuellen? bei welchen den nicht?
Es dürfte dutzende Linux-Distributionen geben, da ich sie nicht alle kenne, weiss ich auch nicht ob sie bei allen dabei ist. Schliesslich ist es eine Kernel-Option, die man auch weglassen könnte. Hmm, sag Du doch einfach mal ein Argument, was explizit _gegen_ eine Firewall spricht. Gruß, Andreas
Andreas Winkelmann wrote:
Michael Meyer wrote:
Eine Firewall oder von mir aus ein Paket-Filter ist einfach nur ein _zusätzliches_ Stück Sicherheit.
das kommt darauf an ...
Worauf ?
auf das _konzept_.
Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert
bei so gut wie allen aktuellen? bei welchen den nicht?
Es dürfte dutzende Linux-Distributionen geben, da ich sie nicht alle kenne, weiss ich auch nicht ob sie bei allen dabei ist.
worum geht es? um 'Linux-Versionen' oder 'Linux-Distributionen'? du kennst den unterschied? glaubst du mir, wenn ich behaupte, dass wohl jede linux-distribution auch linux benutzt?
Schliesslich ist es eine Kernel-Option, die man auch weglassen könnte.
richtig.
Hmm, sag Du doch einfach mal ein Argument, was explizit _gegen_ eine Firewall spricht.
unter umständen mein konzept. wie hier auch schon gesagt wurde, kannst du dir nicht sicher sein, dass es nicht auch im netfilter potentielle angriffsmöglichkeiten gibt. habe ich also einen _sauberen_ server auf dem nur der apache läuft, verzichte ich auf den paketfilter und habe somit eine potentielle angriffsmöglichkeit eleminiert. ich habe dadurch keinerlei nachteile in punkto sicherheit. oftmals bedeutet der einsatz von paketfilter nur: 'ich bin zu faul mein system ordentlich abzusichern. deshalb benutze ich zur sicherheit eine voll krasse firewall'. micha
On Tue, Jun 17, 2003 at 08:53:59PM +0200, Michael Meyer wrote:
ich habe dadurch keinerlei nachteile in punkto sicherheit. oftmals bedeutet der einsatz von paketfilter nur: 'ich bin zu faul mein system ordentlich abzusichern. deshalb benutze ich zur sicherheit eine voll krasse firewall'. Was für ein unsinn. Wer seine Paketfilterregeln selbst zusammenstellt hat sich stundenlang mit der Thematik beschäftigen müssen. Ein sauberer Paketfilter ist viel Arbeit und kann nicht einfach zusammengeklickert werden. Wer das glaubt hat mit und ohne Paketfilter ein unsicheres System.
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Dienstag, 17. Juni 2003 16:16 schrieb Andreas Winkelmann:
Michael Meyer wrote:
Eine Firewall oder von mir aus ein Paket-Filter
Es gibt wirklich erhebliche Unterschiede zwischen Firewall und Paketfilter. Nix mit "von mir aus".
ist einfach nur ein _zusätzliches_ Stück Sicherheit.
Für geeignete Setups ja. Siehe unten.
Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert
Es wird mitgeliefert? Das ist eines der Hauptargumente für den Einsatz eines Paketfilters? Jetzt muss ich mal den Kopf schütteln.
man muss ihn (nur) konfigurieren. Und ich wüsste wirklich keinen Grund darauf zu verzichten.
Der Grund es zu lassen ist einfach: Es ist zusätzliche Software und mithin zusätzliche Angriffsfläche. Keiner weiß, welche Leichen da begraben sind. Das Risiko eines Fehlverhaltens erhöht sich also. Wenn im Gegenzug nicht die Sicherheit des Systems erkennbar verbessert wird, macht es keinen Sinn, so etwas einzusetzen. Auf einem Webserver unter meiner Kontrolle, auf dem die Ports 80, 21 und 22 offen sind, brauche ich genau _keinen_ Paketfilter. Er bringt einfach keinen zusätzlichen Nutzen. Ist doch eigentlich nicht so schwer. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
[Martin Borchert]:
Am Dienstag, 17. Juni 2003 16:16 schrieb Andreas Winkelmann:
Michael Meyer wrote:
Eine Firewall oder von mir aus ein Paket-Filter
Es gibt wirklich erhebliche Unterschiede zwischen Firewall und Paketfilter. Nix mit "von mir aus".
ACK.
ist einfach nur ein _zusätzliches_ Stück Sicherheit.
Für geeignete Setups ja. Siehe unten.
Er wird bei so gut wie allen aktuellen Linux-Versionen im Kernel schon mitgeliefert
Es wird mitgeliefert? Das ist eines der Hauptargumente für den Einsatz eines Paketfilters? Jetzt muss ich mal den Kopf schütteln.
*zustimm*
man muss ihn (nur) konfigurieren. Und ich wüsste wirklich keinen Grund darauf zu verzichten.
Der Grund es zu lassen ist einfach: Es ist zusätzliche Software und mithin zusätzliche Angriffsfläche. Keiner weiß, welche Leichen da begraben sind. Das Risiko eines Fehlverhaltens erhöht sich also. Wenn im Gegenzug nicht die Sicherheit des Systems erkennbar verbessert wird, macht es keinen Sinn, so etwas einzusetzen.
Auf einem Webserver unter meiner Kontrolle, auf dem die Ports 80, 21 und 22 offen sind, brauche ich genau _keinen_ Paketfilter. Er bringt einfach keinen zusätzlichen Nutzen. Ist doch eigentlich nicht so schwer.
Nein, man braucht ihn wirklich nicht. Aber wie du oben schon schreibst: Paketfilter != Firewall Und wenn ich Daten von außen auf meinen Rechner lasse, dann lasse ich mir auch ein Sicherheitskonzept einfallen und spiele verschiedene Szenarien durch. Und da ist mir teilweise doppelte Sicherheit lieber als keine (wegen Konfigurationsfehlern im Daemon z.B.). Und ich finde das Argument: "Firewall = zusätzliche Software = zusätzliche Angriffsfläche" nicht sehr überzeugend, denn sicherheitsrelevante Software wie z.B. iptables steht wohl in besonderem Maße unter ständiger Beobachtung, ob da noch Lücken geschlossen werden müssen. Dazu noch was "hinkendes": Wenn ich ein zweites Schloss an meiner Tür anbringe, schwächt das an dieser Stelle sicherlich die Tür (Bohrungen, Schrauben, ..) Aber ein Einbrecher muss nicht nur des Hauptschloss, sondern auch noch ein weiteres Schloss knacken. Oder er findet einen anderen Weg, aber daran muss ich vorher denken. -- Gruß MaxX
Am Dienstag, 17. Juni 2003 17:11 schrieb Matthias Houdek:
[Martin Borchert]:
Der Grund es zu lassen ist einfach: Es ist zusätzliche Software und mithin zusätzliche Angriffsfläche. Keiner weiß, welche Leichen da begraben sind. Das Risiko eines Fehlverhaltens erhöht sich also. Wenn im Gegenzug nicht die Sicherheit des Systems erkennbar verbessert wird, macht es keinen Sinn, so etwas einzusetzen. Und ich finde das Argument: "Firewall = zusätzliche Software = zusätzliche Angriffsfläche" nicht sehr überzeugend, denn sicherheitsrelevante Software wie z.B. iptables steht wohl in besonderem Maße unter ständiger Beobachtung, ob da noch Lücken geschlossen werden müssen.
Ja. Ich denke die steht genauso unter ständiger Beobachtung wie andere sicherheitsrelevante Software: sendmail, proftp, bind, ssh, der apache nebst Modulen hat auch eine gewisse Geschichte auf Securityfocus. Fehlerfreie Software ist eine Illusion. Und wenn der master-httpd erstmal aufgemacht ist, ist iptables schneller abgeschaltet als du Sicherheitsloch sagen kannst. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
[Martin Borchert]:
Am Dienstag, 17. Juni 2003 17:11 schrieb Matthias Houdek:
[Martin Borchert]:
Der Grund es zu lassen ist einfach: Es ist zusätzliche Software und mithin zusätzliche Angriffsfläche. Keiner weiß, welche Leichen da begraben sind. Das Risiko eines Fehlverhaltens erhöht sich also. Wenn im Gegenzug nicht die Sicherheit des Systems erkennbar verbessert wird, macht es keinen Sinn, so etwas einzusetzen.
Und ich finde das Argument: "Firewall = zusätzliche Software = zusätzliche Angriffsfläche" nicht sehr überzeugend, denn sicherheitsrelevante Software wie z.B. iptables steht wohl in besonderem Maße unter ständiger Beobachtung, ob da noch Lücken geschlossen werden müssen.
Ja. Ich denke die steht genauso unter ständiger Beobachtung wie andere sicherheitsrelevante Software: sendmail, proftp, bind, ssh, der apache nebst Modulen hat auch eine gewisse Geschichte auf Securityfocus.
Eben, Und deshalb gehe ich eher davon aus, dass ich nicht neben vorhandene Löcher noch weitere haue, sondern eine dichte Wand noch einmal abdichte. Falls doch irgendwo ein Loch oder Riss sein sollte. Und dass beide Schichten an der gleichen Stelle ein Loch haben ...
Fehlerfreie Software ist eine Illusion. Und wenn der master-httpd erstmal aufgemacht ist, ist iptables schneller abgeschaltet als du Sicherheitsloch sagen kannst.
Wenn. Aber genau das versucht man ja zu verhindern. Außerdem kann man es Einbrechern auf einem eigenen System immer noch schwer machen, das Richtige zu finden. Ein Blinder kann in seiner eigenen Wohnung "sehen", dazu braucht er kein Licht. Ein Fremder ist ohne Lampe in dieser Wohnung wirklich blind. Und wenn er seine Taschenlampe vergessen, braucht er ziehmlich lange, um sich zurecht zu finden *g*. -- Gruß MaxX
Am Dienstag, 17. Juni 2003 18:55 schrieb Matthias Houdek:
[Martin Borchert]:
Am Dienstag, 17. Juni 2003 17:11 schrieb Matthias Houdek:
[Martin Borchert]:
Und ich finde das Argument: "Firewall = zusätzliche Software = zusätzliche Angriffsfläche" nicht sehr überzeugend, denn sicherheitsrelevante Software wie z.B. iptables steht wohl in besonderem Maße unter ständiger Beobachtung, ob da noch Lücken geschlossen werden müssen. Ja. Ich denke die steht genauso unter ständiger Beobachtung wie andere sicherheitsrelevante Software: sendmail, proftp, bind, ssh, der apache nebst Modulen hat auch eine gewisse Geschichte auf Securityfocus. Eben, Und deshalb gehe ich eher davon aus, dass ich nicht neben vorhandene Löcher noch weitere haue, sondern eine dichte Wand noch einmal abdichte. Falls doch irgendwo ein Loch oder Riss sein sollte. Und dass beide Schichten an der gleichen Stelle ein Loch haben ...
Eben nicht. Mir ist nicht ganz klar, wie das funktionieren soll. Mit einem exploit für den apache mach ich den auf und kann Unfug mit dessen Rechten machen Möglicherweise wird es sogar zu einem root-exploit. Jedenfalls bin ich dann lokal und der Paketfilter kümmert mich nicht mehr. Mit einem exploit für den netfilter-code genauso. Nur dass ich, wenn ich den ausnutzen kann, gleich root bin. Man macht damit eben _nicht_ ein Loch dichter, sondern baut ein potenzielles neues ein.
Fehlerfreie Software ist eine Illusion. Und wenn der master-httpd erstmal aufgemacht ist, ist iptables schneller abgeschaltet als du Sicherheitsloch sagen kannst. Wenn. Aber genau das versucht man ja zu verhindern.
Aber doch nicht mit einem Paketfilter. Darum geht es doch hier. _Man_ _kann_ _einen_ _angreifbaren_ _Service_ _nicht_ _mit_ _einem_ _Paketfilter_ _abdichten_. Jedenfalls nicht, wenn er öffentlich erreichbar sein soll.
Außerdem kann man es Einbrechern auf einem eigenen System immer noch schwer machen, das Richtige zu finden.
Das ist Security by Obscurity und funktioniert nicht.
Ein Blinder kann in seiner eigenen Wohnung "sehen", dazu braucht er kein Licht. Ein Fremder ist ohne Lampe in dieser Wohnung wirklich blind. Und wenn er seine Taschenlampe vergessen, braucht er ziehmlich lange, um sich zurecht zu finden *g*.
Der richtige Einbrecher(TM) bringt sich sein Zeug mit. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Am Dienstag, 17. Juni 2003 14:44 schrieb Andreas Winkelmann:
Martin Borchert wrote:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall. kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Wenn auf dem Rechner nur der Apache und ein sshd laufen, ist ein Paketfilter (der ist wohl hier mit Firewall gemeint) reichlich sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen. Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab!
Nicht alles was hinkt ist ein Vergleich. Sei's drum: Welchen Sicherheitsgewinn erreichst du durch Abschließen der Haustür gegenüber einfachem Zuziehen?
Und zum Thema. Ein gut konfigurierter Paketfilter verhindert auch noch viele andere Schweinereien z.B. gefakte Ip-Adressen,
Wie konfigurierst du deinen Paketfilter, damit er erkennt, dass die IP 217.229.180.224 gefälscht ist? Oder die 217.229.180.223?
Syn-Floods,
Wie unterscheidest du gewollten von ungewolltem Verkehr?
Ping-of-Death,
Gibt es tatsächlich noch Systeme, die dafür anfällig sind? http://www.pp.asu.edu/support/ping-o-death.html listet ein paar. Naja...
Port-Scans.
Was ist schlimm an einem Portscan?
Und was, wenn es einen Fehler im Apache,FtpD oder Kernel gibt, ein Benutzer bekommt ne Shell und verschickt mal eben ein paar hunderttausend Mails, oder Ping't andere Rechner zu Tode, mit DEINER Ip!
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null.
Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen und eine Firewall ist erstens von Hause aus dabei und zum anderen auch nicht soo schwierig zu konfigurieren.
Und in vielen Fällen imo sinnlos. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Am Die, 2003-06-17 um 15.36 schrieb Martin Borchert:
Am Dienstag, 17. Juni 2003 14:44 schrieb Andreas Winkelmann:
Martin Borchert wrote:
[...]
Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab!
Nicht alles was hinkt ist ein Vergleich. Sei's drum: Welchen Sicherheitsgewinn erreichst du durch Abschließen der Haustür gegenüber einfachem Zuziehen?
Einen grossen sogar: Wenn Du mit einem grossen Schraubendreher oder einem kleinem Stemmeisen die Blende des Türschlosses entfernst kannst Du mit einer Zange bei *vielen* Schliessanlagen die dicke Mutter aussen drehen, welche *innen* an der Klinge fest ist...(man "drückt" also die Klinke von aussen) Profis schaffen dass in < 1min, geht natürlich *nur* wenn die Türe nicht abgeschlossen ist, und die Schliessanlage nicht besonders teuer war. Damit habe ich mir schon mal aus der Patsche geholfen :)
Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen und eine Firewall ist erstens von Hause aus dabei und zum anderen auch nicht soo schwierig zu konfigurieren.
Und in vielen Fällen imo sinnlos.
ACK Auf einem "hardened" System ist ein Packetfilter sinnlos. Der Rechner sollte auch *ohne* Firewall keine ungewollten Ports nach aussen zeigen Die meissten Dienste kann man so einstellen, dass Sie nur auf localhost und / oder feste IPs lauschen. Sobald ein Bug im Indianer bekannt wird hat man eh die Ar***karte. (bevor jetzt einer meine Domain scanned: Die wird von Strato gewartet, nicht von mir) -- Matthias Hentges Cologne / Germany [www.hentges.net] -> PGP welcome, HTML tolerated ICQ: 97 26 97 4 -> No files, no URL's My OS: Debian Woody: Geek by Nature, Linux by Choice
Am Dienstag, 17. Juni 2003 16:35 schrieb Matthias Hentges:
Am Die, 2003-06-17 um 15.36 schrieb Martin Borchert:
Am Dienstag, 17. Juni 2003 14:44 schrieb Andreas Winkelmann:
Martin Borchert wrote: Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab! Nicht alles was hinkt ist ein Vergleich. Sei's drum: Welchen Sicherheitsgewinn erreichst du durch Abschließen der Haustür gegenüber einfachem Zuziehen? Einen grossen sogar: [...]
Das Einfallstor bleibt aber immer noch die Tür. Um bei der (schlechten) Analogie zu bleiben: Der Paketfilter wäre hier eher eine 4 Meter hohe Mauer um den Rest des Hauses. Vor der Tür kannst du die aber nicht hinsetzen, dann kommst du selbst nicht mehr rein. Und wenn du keine unsicheren Fenster/Verandatüren hast, bringt dich die Mauer nicht weiter. Auf einem Webserver muss ich alles reinlassen, was durch die Tür (Port 80) kommt. Der Paketfilter ist dann der große, böse aussehende Mann, der aufpasst, dass durch den Keller (3306, mysql) nur die Jungs vom Catering reinkommen. Wenn ich kein Catering habe, mach ich die Kellertür zu und brauche den großen bösen Mann nicht mehr.
Auf einem "hardened" System ist ein Packetfilter sinnlos. Der Rechner sollte auch *ohne* Firewall keine ungewollten Ports nach aussen zeigen Die meissten Dienste kann man so einstellen, dass Sie nur auf localhost und / oder feste IPs lauschen.
Die meisten. Wie Kristian weiter oben schrieb, gibt es Dienste, mit denen geht sowas nicht. Das trifft auf $Subject aber wohl nicht zu. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert wrote:
Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab!
Nicht alles was hinkt ist ein Vergleich. Sei's drum: Welchen Sicherheitsgewinn erreichst du durch Abschließen der Haustür gegenüber einfachem Zuziehen?
Hmm, geh doch einfach mal zum Schlüsseldienst oder Polizeistation Deines Vertrauens und lass Dich aufklären. Ich glaube auch einige Versicherungen können Dir über diesen feinen Unterschied Auskunft geben.
Und zum Thema. Ein gut konfigurierter Paketfilter verhindert auch noch viele andere Schweinereien z.B. gefakte Ip-Adressen,
Wie konfigurierst du deinen Paketfilter, damit er erkennt, dass die IP 217.229.180.224 gefälscht ist? Oder die 217.229.180.223?
Ich weiss so gut wie hundert prozentig, dass eine Ip gefaket ist, wenn sie meine eigene ist oder aus einem privaten Bereich ist _und_ sie mir auf meinem aussendevice entgegenkommt! Sieht man gar nicht so selten.
Syn-Floods,
Wie unterscheidest du gewollten von ungewolltem Verkehr?
Wenn pro sekunde 1000 syn-pakete kommen, weisst Du es! Und wenn sie von einer Ip kommen, lässt sich diese in einem Paketfilter einfach sperren! Muss ja nur für ein paar Stunden sein.
Ping-of-Death,
Gibt es tatsächlich noch Systeme, die dafür anfällig sind? http://www.pp.asu.edu/support/ping-o-death.html listet ein paar. Naja...
Port-Scans.
Was ist schlimm an einem Portscan?
Was ist schlimm an einem fremden Typen, der alle paar Stunden an Deinem Haus vorbeistreift und kontrolliert ob alle Türen und Fenster richtig geschlossen sind... Nichts... Ist doch pure Freundlichkeit, Oder ? Ist in manchen Ländern IMHO sogar unter Strafe gestellt (portscans).
Und was, wenn es einen Fehler im Apache,FtpD oder Kernel gibt, ein Benutzer bekommt ne Shell und verschickt mal eben ein paar hunderttausend Mails, oder Ping't andere Rechner zu Tode, mit DEINER Ip!
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null.
Das ist der schlimmste Fall, aber es gibt Gründe Server-Dienste unter Benutzeraccounts laufen zu lassen. Falls mal etwas passiert kann der Angreifer _nur_ im Sicherheitskontext des Benutzers unsinn machen. Ohne Firewall kommt man dann von dort aus aber auch nach draussen, mit Deiner Ip. Es gehört nur ein telnet dazu dem president@whitehouse.gov mal so richtig die Meinung zu sagen ;-) Das ist an und für sich noch harmlos, aber es ist mit einer Firewall sehr einfach zu sperren.
Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen und eine Firewall ist erstens von Hause aus dabei und zum anderen auch nicht soo schwierig zu konfigurieren.
Und in vielen Fällen imo sinnlos.
Und wenn es nur einen einzigen sinnvollen Fall gibt....... Gruß, Andreas
Am Dienstag, 17. Juni 2003 17:35 schrieb Andreas Winkelmann:
Martin Borchert wrote:
Sorry, aber das ist quatsch. Meine Haustür hat von aussen auch keine Klinke, trotzdem schliesse ich sie ab! Nicht alles was hinkt ist ein Vergleich. Sei's drum: Welchen Sicherheitsgewinn erreichst du durch Abschließen der Haustür gegenüber einfachem Zuziehen? Hmm, geh doch einfach mal zum Schlüsseldienst oder Polizeistation Deines Vertrauens und lass Dich aufklären. Ich glaube auch einige Versicherungen können Dir über diesen feinen Unterschied Auskunft geben.
Das Ding mit dem Haus haben wir gerade nebenan diskutiert.
Und zum Thema. Ein gut konfigurierter Paketfilter verhindert auch noch viele andere Schweinereien z.B. gefakte Ip-Adressen, Wie konfigurierst du deinen Paketfilter, damit er erkennt, dass die IP 217.229.180.224 gefälscht ist? Oder die 217.229.180.223? Ich weiss so gut wie hundert prozentig, dass eine Ip gefaket ist, wenn sie meine eigene ist oder aus einem privaten Bereich ist _und_ sie mir auf meinem aussendevice entgegenkommt! Sieht man gar nicht so selten.
Das halte ich für ein Gerücht. Was hast du denn für eine Anbindung, wenn da auf dem ext_iface Ip-Pakete mit einer privaten Quelle ankommen? Die werden üblicherweise vom Router deines Vertrauens schon verworfen.
Syn-Floods, Wie unterscheidest du gewollten von ungewolltem Verkehr? Wenn pro sekunde 1000 syn-pakete kommen, weisst Du es! Und wenn sie von einer Ip kommen, lässt sich diese in einem Paketfilter einfach sperren! Muss ja nur für ein paar Stunden sein.
SynFloods mit einer Quell-Adresse macht man nicht. SynFloods mit Millionen von gefakten Adressen sind effektiver. Die kannst du nicht mehr auseinanderhalten. Ok, du könntest mal eben den Adressraum von dip.t-dialin.net sperren. Und nu? Kein Verkehr mehr. DoS. Der Angreifer hat gewonnen und dein Paketfilter versagt.
Port-Scans. Was ist schlimm an einem Portscan? Was ist schlimm an einem fremden Typen, der alle paar Stunden an Deinem Haus vorbeistreift und kontrolliert ob alle Türen und Fenster richtig geschlossen sind... Nichts... Ist doch pure Freundlichkeit, Oder ?
Das mit dem hinken hatten wir schon. Wenn mein System korrekt konfiguriert ist, kann da einer noch so viel scannen. Das bringt ihn nicht weiter. Wenn ich es nicht hinbekommst, Dienste abzuschalten oder die Bindung an ext_iface abzuschalten, wie soll ich mir denn da bitte sicher sein, dass mein Paketfilter funktioniert? Weil nmap alles als closed meldet?
Ist in manchen Ländern IMHO sogar unter Strafe gestellt (portscans).
Quelle? Verfahren? Verurteilungen?
Und was, wenn es einen Fehler im Apache,FtpD oder Kernel gibt, ein Benutzer bekommt ne Shell und verschickt mal eben ein paar hunderttausend Mails, oder Ping't andere Rechner zu Tode, mit DEINER Ip! remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null. Das ist der schlimmste Fall, aber es gibt Gründe Server-Dienste unter Benutzeraccounts laufen zu lassen. Falls mal etwas passiert kann der Angreifer _nur_ im Sicherheitskontext des Benutzers unsinn machen.
Einen heilen Kernel vorausgesetzt. Ich möchte keine Schätzung abgeben, wieviele der öffentlich erreichbaren Linuxkisten noch anfällig für den ptrace-Exploit sind, aber wenige sind es mit Sicherheit nicht.
Ohne Firewall kommt man dann von dort aus aber auch nach draussen, mit Deiner Ip. Es gehört nur ein telnet dazu dem president@whitehouse.gov mal so richtig die Meinung zu sagen ;-)
Ich habe gerade auf der Maschine einen Service aufgemacht, richtig? Und was sollte mich jetzt daran hindern, von dem gerade übernommenen Port zu senden?
Das ist an und für sich noch harmlos, aber es ist mit einer Firewall sehr einfach zu sperren.
Nein, ist es nicht.
Wenn man seinen Rechner ins Internet stellt, sollte man JEDE Möglichkeit zur Absicherung nutzen und eine Firewall ist erstens von Hause aus dabei und zum anderen auch nicht soo schwierig zu konfigurieren. Und in vielen Fällen imo sinnlos. Und wenn es nur einen einzigen sinnvollen Fall gibt.......
Dann macht man es. Wenn es keinen Sinn macht, lässt man es. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert wrote:
Das halte ich für ein Gerücht. Was hast du denn für eine Anbindung, wenn da auf dem ext_iface Ip-Pakete mit einer privaten Quelle ankommen? Die werden üblicherweise vom Router deines Vertrauens schon verworfen.
war es t-online? ich kann mich nicht mehr errinnern. irgendein grösserer ISP routet solche pakete _innerhalb_ seines netzes. weiss ich aber nicht aus eigener erfahrung, sondern habe ich nur schon häufiger gelesen. micha
Am Dienstag, 17. Juni 2003 20:23 schrieb Michael Meyer:
Martin Borchert wrote:
Das halte ich für ein Gerücht. Was hast du denn für eine Anbindung, wenn da auf dem ext_iface Ip-Pakete mit einer privaten Quelle ankommen? Die werden üblicherweise vom Router deines Vertrauens schon verworfen. war es t-online? ich kann mich nicht mehr errinnern. irgendein grösserer ISP routet solche pakete _innerhalb_ seines netzes. weiss ich aber nicht aus eigener erfahrung, sondern habe ich nur schon häufiger gelesen.
Echt? Naja, RFC 1918 spricht von shall und should und are expected to. Also nichts wirklich zwingendes. Aber doch komplett sinnfrei. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 20:23 schrieb Michael Meyer:
Martin Borchert wrote:
Das halte ich für ein Gerücht. Was hast du denn für eine Anbindung, wenn da auf dem ext_iface Ip-Pakete mit einer privaten Quelle ankommen? Die werden üblicherweise vom Router deines Vertrauens schon verworfen. war es t-online? ich kann mich nicht mehr errinnern. irgendein grösserer ISP routet solche pakete _innerhalb_ seines netzes. weiss ich aber nicht aus eigener erfahrung, sondern habe ich nur schon häufiger gelesen.
Echt?
nein, sowas denke ich mir 'on the fly' aus. ;) im ernst: ja, soll es wirklich geben.
Naja, RFC 1918 spricht von shall und should und are expected to. Also nichts wirklich zwingendes. Aber doch komplett sinnfrei.
absolut! micha
Hallo zusammen, Am Dienstag, 17. Juni 2003 21:16 schrieb Michael Meyer:
Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 20:23 schrieb Michael Meyer:
Martin Borchert wrote:
Das halte ich für ein Gerücht. Was hast du denn für eine Anbindung, wenn da auf dem ext_iface Ip-Pakete mit einer privaten Quelle ankommen? Die werden üblicherweise vom Router deines Vertrauens schon verworfen.
war es t-online? ich kann mich nicht mehr errinnern. irgendein grösserer ISP routet solche pakete _innerhalb_ seines netzes. weiss ich aber nicht aus eigener erfahrung, sondern habe ich nur schon häufiger gelesen.
Echt?
nein, sowas denke ich mir 'on the fly' aus. ;)
im ernst: ja, soll es wirklich geben.
So siehts bei mir aus. T-DSL: firewall-20030614.gz:Jun 13 14:30:25 server kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=192.168.0.2 DST=62.226.2.111 LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=38718 PROTO=UDP SPT=3914 DPT=8272 LEN=20
Naja, RFC 1918 spricht von shall und should und are expected to. Also nichts wirklich zwingendes. Aber doch komplett sinnfrei.
absolut!
ACK!
micha
Viele Grüße Andreas
Andreas Winkelmann wrote:
Martin Borchert wrote:
Was ist schlimm an einem Portscan?
Was ist schlimm an einem fremden Typen, der alle paar Stunden an Deinem Haus vorbeistreift und kontrolliert ob alle Türen und Fenster richtig geschlossen sind... Nichts... Ist doch pure Freundlichkeit, Oder ?
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Portscan
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null.
Das ist der schlimmste Fall,
dummerweise ist das auf einem übernommenem system eher die regel.
aber es gibt Gründe Server-Dienste unter Benutzeraccounts laufen zu lassen. Falls mal etwas passiert kann der Angreifer _nur_ im Sicherheitskontext des Benutzers unsinn machen.
träum weiter. lokale root-exploits finden sich auf einem system, zu dem du zugang erlangt hast, oft genug. micha
On Tue, Jun 17, 2003 at 08:40:32PM +0200, Michael Meyer wrote:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Portscan
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null.
Das ist der schlimmste Fall,
dummerweise ist das auf einem übernommenem system eher die regel. Ich dachte es geht um einen Webserver. Auf diesem brauche ich keine dynamischen Module und auch das proc FS sollte nicht für jeden willi lesbar sein. In der Folge beisst sich der ptrace exploit die Zähne aus. Ich kann Deine Argumentation im übrigen nicht verstehen; Du scheinst Dich in etwas verbissen zu haben - dieses Szenario hat _nichts_ mit der Frage zu tun ob ein Paketfilter aktiv ist oder nicht.
Mit einem Paketfilter kann ich Portscans und Pings und vieles mehr verbieten. Ein elementarer Grundsatz bei Absicherung von Rechnern ist grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt wird. Dies gilt für laufende Programme natürlich ebenso wie für ein- und evtl. ausgehende Pakete. Abgesehen von den ICMP's: fragmentation-needed und Parameter Problem brauche ich auf einem Webserver (in der Regel) jedoch keine weiteren ICMP's - noch nicht mal Pings - zu erlauben. Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind? Selbstverständlich reicht ein Paketfilter nicht um einen "sicheren" Server zu erhalten. Selbstverständlich wird ein verantwortungsbewusster Admin _zusäztlich_ alle Dienste soweit möglich auf eine bestimmte IP-Adresse oder noch besser ausschließlich auf das lokale Interface festlegen und selbstverständlich wird ein verantwortungsbewusster Admin sämtliche Dienste soweit möglich nicht als root starten und obendrein chrooten und zumindest die root Prozesse auch noch mit Systrace zusätzlich einschränken. Vom regelmässigen einspielen von Sicherheitsupdates usw. usf. möchte ich garnicht erst sprechen. Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt. Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist??? Ich würde mir das nicht anmaßen. greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher wrote:
On Tue, Jun 17, 2003 at 08:40:32PM +0200, Michael Meyer wrote:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Portscan
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null.
Das ist der schlimmste Fall,
dummerweise ist das auf einem übernommenem system eher die regel. Ich dachte es geht um einen Webserver. Auf diesem brauche ich keine dynamischen Module und auch das proc FS sollte nicht für jeden willi lesbar sein.
ACK
In der Folge beisst sich der ptrace exploit die Zähne aus. Ich kann Deine Argumentation im übrigen nicht verstehen; Du scheinst Dich in etwas verbissen zu haben - dieses Szenario hat _nichts_ mit der Frage zu tun ob ein Paketfilter aktiv ist oder nicht.
ähm ... das hat sich nunmal so ergeben ...
Mit einem Paketfilter kann ich Portscans und Pings und vieles mehr verbieten.
und warum willst du das?
Ein elementarer Grundsatz bei Absicherung von Rechnern ist grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt wird. Dies gilt für laufende Programme natürlich ebenso wie für ein- und evtl. ausgehende Pakete.
eben.
Abgesehen von den ICMP's: fragmentation-needed und Parameter Problem brauche ich auf einem Webserver (in der Regel) jedoch keine weiteren ICMP's - noch nicht mal Pings - zu erlauben.
und warum sollte man nicht?
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft.
was sind wir froh :)[1]
Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind?
*ähm* warum hast du sie denn offen? weil du möchtest, dass sich jemand verbindet? warum sollte ich nicht per portscan schauen, was du so anbietest und das, was ich finde, dann auch mal besuchen? im erlaubten und von dir gewünschten rahmen natürlich. du setzt einen portscan mit einem angriff gleich. oder mit der vorbereitung zu einem. das ist quatsch.
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt.
warum?
Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist???
nein. wo habe ich das geschrieben? der begriff 'potenziell' sagt dir was? ich sprach von einem weiteren potenziellen risiko, das nicht eingegangen werden muss um einen webserver zu betreiben. das ist von der aussage etwas völlig anderes als das, was du da versuchst zu konstruieren. aber ja, ich werfe den 'entwicklern von iptables' vor, das sie menschen sind und somit die möglichkeit besteht, dass sie fehler machen. hast du nicht weiter oben geschrieben: ,---| | Ein elementarer Grundsatz bei Absicherung von Rechnern ist | grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt | wird `----| warum ist ein paketfilter, auf einem server, der ausschlisslich http anbietet, sinnvoll und vor allem, tatsächlich benötigt?
Ich würde mir das nicht anmaßen.
musst du ja auch nicht ... [1] smiley sponsored by FG micha
On Tue, Jun 17, 2003 at 10:19:23PM +0200, Michael Meyer wrote:
Michael Hilscher wrote: Mit einem Paketfilter kann ich Portscans und Pings und vieles mehr verbieten.
und warum willst du das?
Ein elementarer Grundsatz bei Absicherung von Rechnern ist grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt wird. Dies gilt für laufende Programme natürlich ebenso wie für ein- und evtl. ausgehende Pakete.
eben.
Abgesehen von den ICMP's: fragmentation-needed und Parameter Problem brauche ich auf einem Webserver (in der Regel) jedoch keine weiteren ICMP's - noch nicht mal Pings - zu erlauben.
und warum sollte man nicht? Ein elementarer Grundsatz bei Absicherung von ... (siehe Abatz 2!)
Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind?
*ähm* warum hast du sie denn offen? weil du möchtest, dass sich jemand verbindet? warum sollte ich nicht per portscan schauen, was du so anbietest und das, was ich finde, dann auch mal besuchen? im erlaubten und von dir gewünschten rahmen natürlich.
du setzt einen portscan mit einem angriff gleich. oder mit der vorbereitung zu einem. das ist quatsch. So? Warum bitte denn nicht? Machst Du einen Portscan um nachzusehen, ob ein Webserver läuft oder gibst Du nicht einfache http://ip-addi bzw. http://domain-addi.toplelveldomain in den Browser ein?
Nenn mir bitte einen Grund weshalb ein Portscan meines _Webservers_ von einer wildfremden Person legitim sein soll!
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt.
warum? Warum denn nicht? Wenn Du diskutieren willst, musst Du schon etwas mehr Input bringen als ein altkluges "warum weshalb wieso". Erklär mir doch bitte das Gegenteil, wenn Du es besser weist. Ich lerne gerne dazu.
hast du nicht weiter oben geschrieben:
,---| | Ein elementarer Grundsatz bei Absicherung von Rechnern ist | grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt | wird `----|
warum ist ein paketfilter, auf einem server, der ausschlisslich http anbietet, sinnvoll und vor allem, tatsächlich benötigt? Warum sollte ich nicht benötigte Pakete entgegennehmen und obendrein beantworten? Ein Paketfilter passt ins Sicherheitskonzept, da er hilft dem Grundsatz zu folgen. Er wiederspricht dem Grundsatz nicht.
Sicher sind auch die Entwickler von iptables nur Menschen. Aber mir ist weder bei iptables noch bei ipchains noch bei pf oder ipfw ein einziger Fall bekannt wo eine Sicherheitslücke es einem Angreifer gestattet hätte das System _dank_eines_fehlers_im_Paketfilter_ zu übernehmen. Falls tatsächlich eine derartige Sicherheitslücke auftreten sollte, ist die Firewall auch sofort zu deaktivieren. Im Gegensatz zu wichtigen Systemprogrammen fällt hier ein Abschalten wirklich leicht. Aber bis eine solche Sicherheitslücke (die doch sehr unwahrscheinlich ist) auftritt ist es definitiv besser mit als ohne Paketfilter zu arbeiten. Und bitte frage nicht schon wieder "wieso" - lies Absatz 2! greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher wrote:
Warum denn nicht? Wenn Du diskutieren willst, musst Du schon etwas mehr Input bringen als ein altkluges "warum weshalb wieso". Erklär mir doch bitte das Gegenteil, wenn Du es besser weist. Ich lerne gerne dazu.
und jetzt liesst du den thread, dann deine mail. und _dann_ kannst du es ja nochmal versuchen. ja? micha
Am Dienstag, 17. Juni 2003 21:38 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 08:40:32PM +0200, Michael Meyer wrote:
remote exploit im daemon -> ptrace-bug-exploit -> root-Zugriff, paketfilter abschalten. Und nu? Keine Firewall mehr da. Sicherheitsgewinn durch Paketfilter? Null. Das ist der schlimmste Fall, dummerweise ist das auf einem übernommenem system eher die regel. Ich dachte es geht um einen Webserver. Auf diesem brauche ich keine dynamischen Module und auch das proc FS sollte nicht für jeden willi lesbar sein. In der Folge beisst sich der ptrace exploit die Zähne aus.
Muss ja nicht immer ptrace sein. Nur weil seit langem nichts gefunden wurde, muss der Kernel ja nicht bugfrei sein. Der ptrace-bug wurde spätestens mit dem Kernel 2.2. im Januar 1999 eingeführt, der Bugfix kam mit 2.4.10 am 24.9.2001. Bummelig fast drei Jahre. Ich würde mich nicht darauf verlassen, dass es da nicht noch andere Sachen gibt. Und der monolithische Kernel an sich ist auch nicht besonders wertvoll, solange /dev/kmem existiert.
Mit einem Paketfilter kann ich Portscans und Pings und vieles mehr verbieten. Ein elementarer Grundsatz bei Absicherung von Rechnern ist grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt wird. Dies gilt für laufende Programme natürlich ebenso wie für ein- und evtl. ausgehende Pakete. Abgesehen von den ICMP's: fragmentation-needed und Parameter Problem brauche ich auf einem Webserver (in der Regel) jedoch keine weiteren ICMP's - noch nicht mal Pings - zu erlauben.
Das Problem ist aber, dass du zusätzliche Komponenten einsetzen musst, um etwas zu verbieten, was dir nicht schadet.
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind?
Warum wolltest du Ports offen haben, die keiner sehen soll?
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt.
Weil dreifach besser hält? Oder wegen des beruhigenden Gefühls in der Bauchgegend?
Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist??? Ich würde mir das nicht anmaßen.
Was hat denn iptables mit routing zu tun? Iptables implementiert einen Paketfilter. Mehr nicht. Es gibt genügend Szenarien, wo so ein Ding Sinn macht: Hauptsächlich da, wo Netze voneinander zu trennen sind. Das ist bei einem einfachen Webserver nicht der Fall, ergo ist ein Paketfilter dort zu nichts nütze. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote:
Mit einem Paketfilter kann ich Portscans und Pings und vieles mehr verbieten. Ein elementarer Grundsatz bei Absicherung von Rechnern ist grundsätzlich: erlaube nur was sinnvoll ist und tatsächlich benötigt wird. Dies gilt für laufende Programme natürlich ebenso wie für ein- und evtl. ausgehende Pakete. Abgesehen von den ICMP's: fragmentation-needed und Parameter Problem brauche ich auf einem Webserver (in der Regel) jedoch keine weiteren ICMP's - noch nicht mal Pings - zu erlauben.
Das Problem ist aber, dass du zusätzliche Komponenten einsetzen musst, um etwas zu verbieten, was dir nicht schadet. Nun, darüber lässt sich streiten. Es gibt durchaus Attacken die ICMP Pakete nutzen um ein DOS zu erreichen. Das muss garnicht das angestaubte POD sein - es gibt und wird immer neue Angriffsformen geben.
Ja es ist natürlich richtig, dass auch gedroppte Pakete eingehend traffic verursachen aber wenigsten verdoppelt (wenn nicht gar verdreifacht) sich der Verkehr durch serverseitige Antworten an mehr oder minder tatsächlich vorhandene IP-Adressen nicht.
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind?
Warum wolltest du Ports offen haben, die keiner sehen soll? Warum sollte ich wollen, dass jeder in kürzester Zeit weiss, was auf meinem Server erreichbar ist?
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt.
Weil dreifach besser hält? Oder wegen des beruhigenden Gefühls in der Bauchgegend? Ich habe mehr Angst vor einem Hardwareausfall als vor einem Angriff. Der Paketfilter ist nur ein kleiner Teil meines Sicherheitskonzepts ich würde jedoch nicht auf ihn verzichten wollen.
Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist??? Ich würde mir das nicht anmaßen.
Was hat denn iptables mit routing zu tun? Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
Iptables implementiert einen Paketfilter. Mehr nicht. Es gibt genügend Szenarien, wo so ein Ding Sinn macht: Hauptsächlich da, wo Netze voneinander zu trennen sind. Das ist bei einem einfachen Webserver nicht der Fall, ergo ist ein Paketfilter dort zu nichts nütze. Doch eben weil ich ungewünschte Pakte fallen lassen kann.
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher wrote:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote:
Warum wolltest du Ports offen haben, die keiner sehen soll? Warum sollte ich wollen, dass jeder in kürzester Zeit weiss, was auf meinem Server erreichbar ist?
du bemerkst deinen wiederspruch wirklich nicht?
Was hat denn iptables mit routing zu tun? Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
ja.
Iptables implementiert einen Paketfilter. Mehr nicht. Es gibt genügend Szenarien, wo so ein Ding Sinn macht: Hauptsächlich da, wo Netze voneinander zu trennen sind. Das ist bei einem einfachen Webserver nicht der Fall, ergo ist ein Paketfilter dort zu nichts nütze. Doch eben weil ich ungewünschte Pakte fallen lassen kann.
und das wären dann genau _welche_? micha
Am Dienstag, 17. Juni 2003 23:02 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote:
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind? Warum wolltest du Ports offen haben, die keiner sehen soll? Warum sollte ich wollen, dass jeder in kürzester Zeit weiss, was auf meinem Server erreichbar ist?
Blödsinn. Entweder bietest du einen Dienst an, dann kannst du die Pakete nicht wegfiltern, oder du bietest ihn nicht an, dann brauchst du keinen Paketfilter davor.
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt. Weil dreifach besser hält? Oder wegen des beruhigenden Gefühls in der Bauchgegend? Ich habe mehr Angst vor einem Hardwareausfall als vor einem Angriff. Der Paketfilter ist nur ein kleiner Teil meines Sicherheitskonzepts ich würde jedoch nicht auf ihn verzichten wollen.
Und genau warum nicht?
Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist??? Ich würde mir das nicht anmaßen. Was hat denn iptables mit routing zu tun? Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
Warum sollte es nicht gehen? Ging ja auch bevor es iptables gab. Iptables ist ein Paketfilter. Das hat mit routing nichts zu tun.
Iptables implementiert einen Paketfilter. Mehr nicht. Es gibt genügend Szenarien, wo so ein Ding Sinn macht: Hauptsächlich da, wo Netze voneinander zu trennen sind. Das ist bei einem einfachen Webserver nicht der Fall, ergo ist ein Paketfilter dort zu nichts nütze. Doch eben weil ich ungewünschte Pakte fallen lassen kann.
Das ist nicht so richtig schlüssig... Fallen lassen (drop) macht das Netz kaputt. Es stört mehr als es nutzt. Das ordnungsgemäße rejecten erledigt der Kernel, dafür braucht man keinen Paketfilter. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Tue, Jun 17, 2003 at 11:36:12PM +0200, Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 23:02 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote:
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind? Warum wolltest du Ports offen haben, die keiner sehen soll? Warum sollte ich wollen, dass jeder in kürzester Zeit weiss, was auf meinem Server erreichbar ist?
Blödsinn. Entweder bietest du einen Dienst an, dann kannst du die Pakete nicht wegfiltern, oder du bietest ihn nicht an, dann brauchst du keinen Paketfilter davor. Der Paketfilter ist sinnvoll weil er Angriffe auf Paketebene verhindern kann. Es ist wahrscheinlicher, dass ein ICMP Angriff oder Scan geblockt wird als dass es einem Angreifer gelingt eine hypothetisch vorhandene Sicherheitslücke im Paketfilter selbst auszunutzen.
Was ich bereits schrieb: es gibt keinen legitimen Grund einen Webserver zu scannen (ausser ich seinen eigenen). Warum sollte ich es einem Angreifer also vereinfachenn herauszufinden, dass er tatsächlich neben ssh, apache und evtl. pop/imap/smtp auch irgendwelche anderen Dienste von ausserhalb erreichen kann?
Aber zur eigentlichen Frage ob auf einem Webserver ein Paketfilter aktiviert werden soll, ist ganz klar "ja" zu sagen und zwar auch dann, wenn bereits eine Firewall davor hängt. Weil dreifach besser hält? Oder wegen des beruhigenden Gefühls in der Bauchgegend? Ich habe mehr Angst vor einem Hardwareausfall als vor einem Angriff. Der Paketfilter ist nur ein kleiner Teil meines Sicherheitskonzepts ich würde jedoch nicht auf ihn verzichten wollen.
Und genau warum nicht? Warum soll ich das eigentlich weiter ausführen? Habe ich meinen Standpunkt nicht schon dargelegt? Siehe oben und meine vergangenen Mails.
Oder willst Du den Entwicklern von iptables tatsächlich unterstellen, dass ihre Arbeit unnütz ist und eher neue Sicherheitslücken einbringt sowie lediglich für Masquerading und Routing zu gebrauchen ist??? Ich würde mir das nicht anmaßen. Was hat denn iptables mit routing zu tun? Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
Warum sollte es nicht gehen? Ging ja auch bevor es iptables gab. Iptables ist ein Paketfilter. Das hat mit routing nichts zu tun. Was verstehst Du unter routing? route add default gw ... ?? Ein router muss masquerading können, sonst kann er Anfragen von verschiedenen Clients aus dem lan nicht weiter- und zurückleiten. Zumindest wüsste ich nicht wie es ohne entsprechende iptables (oder ipchains) Regeln gehen sollte.
Iptables implementiert einen Paketfilter. Mehr nicht. Es gibt genügend Szenarien, wo so ein Ding Sinn macht: Hauptsächlich da, wo Netze voneinander zu trennen sind. Das ist bei einem einfachen Webserver nicht der Fall, ergo ist ein Paketfilter dort zu nichts nütze. Doch eben weil ich ungewünschte Pakte fallen lassen kann.
Das ist nicht so richtig schlüssig... Fallen lassen (drop) macht das Netz kaputt. Es stört mehr als es nutzt. Das ordnungsgemäße rejecten erledigt der Kernel, dafür braucht man keinen Paketfilter. Jo, wenn ich alles rejecten würde könnte ich einen Portscan nicht erschweren. Das einzige was man wirklich rejecten sollte sind Anfragen an Port 113 - die alte Unsitte vieler Clients hinter denen in der Regel auch keine böswillige Absicht steckt.
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Mittwoch, 18. Juni 2003 10:35 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 11:36:12PM +0200, Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 23:02 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote:
Tatsächlich ist es so, dass ein Portscan einem Angreifer nicht automatisch root Rechte verschafft. Aber es ist unstrittig, dass ein Portscan bei der Suche nach möglichen Angriffsflächen hilft. Warum sollte ich einem Angreifer es einfach machen, in Erfahrung zu bringen, welche Ports offen sind? Warum wolltest du Ports offen haben, die keiner sehen soll? Warum sollte ich wollen, dass jeder in kürzester Zeit weiss, was auf meinem Server erreichbar ist? Blödsinn. Entweder bietest du einen Dienst an, dann kannst du die Pakete nicht wegfiltern, oder du bietest ihn nicht an, dann brauchst du keinen Paketfilter davor. Der Paketfilter ist sinnvoll weil er Angriffe auf Paketebene verhindern kann. Es ist wahrscheinlicher, dass ein ICMP Angriff oder Scan geblockt wird als dass es einem Angreifer gelingt eine hypothetisch vorhandene Sicherheitslücke im Paketfilter selbst auszunutzen.
Ich klinke mich an dieser Stelle aus der Diskussion aus. Ich habe den Eindruck, dass du nicht verstehen willst, dass die das Blocken von ICMP oder Portscans keinen Sicherheitsgewinn bringt. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Wed, Jun 18, 2003 at 11:09:06AM +0200, Martin Borchert wrote:
Der Paketfilter ist sinnvoll weil er Angriffe auf Paketebene verhindern kann. Es ist wahrscheinlicher, dass ein ICMP Angriff oder Scan geblockt wird als dass es einem Angreifer gelingt eine hypothetisch vorhandene Sicherheitslücke im Paketfilter selbst auszunutzen.
Ich klinke mich an dieser Stelle aus der Diskussion aus. Ich habe den Eindruck, dass du nicht verstehen willst, dass die das Blocken von ICMP oder Portscans keinen Sicherheitsgewinn bringt. LOL. Ich kann Deine Meinung durchaus nachvollziehen, sehe aber wie erläutert durchaus einen Sicherheitsgewinn.
Schade nur, dass Du es nicht für nötig gehalten hast mir auf:
Was hat denn iptables mit routing zu tun? Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
Warum sollte es nicht gehen? Ging ja auch bevor es iptables gab. Iptables ist ein Paketfilter. Das hat mit routing nichts zu tun. Was verstehst Du unter routing? route add default gw ... ?? Ein router muss masquerading können, sonst kann er Anfragen von verschiedenen Clients aus dem lan nicht weiter- und zurückleiten. Zumindest wüsste ich nicht wie es ohne entsprechende iptables (oder ipchains) Regeln gehen sollte. zu antworten. Hätte mich ehrlich interessiert.
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Mittwoch, 18. Juni 2003 11:34 schrieb Michael Hilscher:
On Wed, Jun 18, 2003 at 11:09:06AM +0200, Martin Borchert wrote:
Schade nur, dass Du es nicht für nötig gehalten hast mir auf:
Was hat denn iptables mit routing zu tun? Was verstehst Du unter routing? route add default gw ... ??
Routingtabellen dürfen gerne auch etwas komplexer sein.
Ein router muss masquerading können, sonst kann er Anfragen von verschiedenen Clients aus dem lan nicht weiter- und zurückleiten. Zumindest wüsste ich nicht wie es ohne entsprechende iptables (oder ipchains) Regeln gehen sollte. zu antworten. Hätte mich ehrlich interessiert.
Network Address Translation/Masquerading kann eine Funktion eines Routers sein, muss es aber nicht. Die gleiche Funktion erfüllt (unter Umständen) ein sockd, was den Rechner, auf dem der läuft ja nun nicht zum Router macht. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Michael Hilscher wrote:
On Tue, Jun 17, 2003 at 11:36:12PM +0200, Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 23:02 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote: Was ich bereits schrieb: es gibt keinen legitimen Grund einen Webserver zu scannen (ausser ich seinen eigenen). Warum sollte ich es einem Angreifer also vereinfachenn herauszufinden, dass er tatsächlich neben ssh, apache und evtl. pop/imap/smtp auch irgendwelche anderen Dienste von ausserhalb erreichen kann?
wodurch erschwerst du es denn?
Ich habe mehr Angst vor einem Hardwareausfall als vor einem Angriff. Der Paketfilter ist nur ein kleiner Teil meines Sicherheitskonzepts ich würde jedoch nicht auf ihn verzichten wollen.
Und genau warum nicht? Warum soll ich das eigentlich weiter ausführen? Habe ich meinen Standpunkt nicht schon dargelegt?
nein.
Geht Routing denn auch ohne iptables (ich meine auf einem Linux Router und keiner Hardware Box mit alternativem Betriebssystem)?
Warum sollte es nicht gehen? Ging ja auch bevor es iptables gab. Iptables ist ein Paketfilter. Das hat mit routing nichts zu tun. Was verstehst Du unter routing? route add default gw ... ??
ich vermute das selbe wie ich. das routen von paketen.
Ein router muss masquerading können,
nein.
sonst kann er Anfragen von verschiedenen Clients aus dem lan nicht weiter- und zurückleiten.
falsch.
Zumindest wüsste ich nicht wie es ohne entsprechende iptables (oder ipchains) Regeln gehen sollte.
das ist schade ... aber ok: unter routen versteht man das weiterleiten von paketen zwischen verschiedenen netzen. du sprichst von masquerading. das ist etwas völlig anderes.
Das ist nicht so richtig schlüssig... Fallen lassen (drop) macht das Netz kaputt. Es stört mehr als es nutzt. Das ordnungsgemäße rejecten erledigt der Kernel, dafür braucht man keinen Paketfilter. Jo, wenn ich alles rejecten würde könnte ich einen Portscan nicht erschweren.
du erschwerst den portscan gleich nochmal wodurch? du glaubst,'drop' erschwert einen portscan? ich vermute du glaubst auch, dass du stealth bist, oder?
Das einzige was man wirklich rejecten sollte sind Anfragen an Port 113 - die alte Unsitte vieler Clients hinter denen in der Regel auch keine böswillige Absicht steckt.
du legst nicht viel wert auf funktionierendes tcp/ip, oder? micha
On Wed, Jun 18, 2003 at 11:47:41AM +0200, Michael Meyer wrote:
Michael Hilscher wrote:
On Tue, Jun 17, 2003 at 11:36:12PM +0200, Martin Borchert wrote:
Am Dienstag, 17. Juni 2003 23:02 schrieb Michael Hilscher:
On Tue, Jun 17, 2003 at 10:19:38PM +0200, Martin Borchert wrote: Was ich bereits schrieb: es gibt keinen legitimen Grund einen Webserver zu scannen (ausser ich seinen eigenen). Warum sollte ich es einem Angreifer also vereinfachenn herauszufinden, dass er tatsächlich neben ssh, apache und evtl. pop/imap/smtp auch irgendwelche anderen Dienste von ausserhalb erreichen kann?
wodurch erschwerst du es denn? Ohne Paketfilter kann ich meinen Server innerahlb weniger minuten vollständig scannen mit Paketfilter dauert es ewig (je nach genutzten Optionen und Scanner).
Es steht ausser frage, dass ein Paketfilter diverse Scans ganz verhindern und manche erschweren kann. Natürlich bleibt es weiterhin möglich einen Server trotz Paketfilter zu scannen. Dennoch sehe ich darin keinen Grund auf den Paketfilter zu verzichten. Das wäre ja als ob Du keine Sicherheitsupdates einspielst, da der Server doch ohnehin irgendeine noch nicht endeckte Sicherheitslücke besitzt, die ein Angreifer nutzen kann um root Rechte zu erhalten ...
Ich habe mehr Angst vor einem Hardwareausfall als vor einem Angriff. Der Paketfilter ist nur ein kleiner Teil meines Sicherheitskonzepts ich würde jedoch nicht auf ihn verzichten wollen.
Und genau warum nicht? Warum soll ich das eigentlich weiter ausführen? Habe ich meinen Standpunkt nicht schon dargelegt?
nein. Super Argumentation. Lies meine vorangeganenen eMails.
Fallen lassen (drop) macht das Netz kaputt. Es stört mehr als es nutzt. Das ordnungsgemäße rejecten erledigt der Kernel, dafür braucht man keinen Paketfilter. Jo, wenn ich alles rejecten würde könnte ich einen Portscan nicht erschweren.
du erschwerst den portscan gleich nochmal wodurch? du glaubst,'drop' erschwert einen portscan? ich vermute du glaubst auch, dass du stealth bist, oder? Probiere es doch mal selbst aus. Scanne Deinen Server mal ohne und danach mit einem Paketfilter der alles dropped anstelle reject.
Das einzige was man wirklich rejecten sollte sind Anfragen an Port 113 - die alte Unsitte vieler Clients hinter denen in der Regel auch keine böswillige Absicht steckt.
du legst nicht viel wert auf funktionierendes tcp/ip, oder? Alle wichtigen Pakete - auch die benötigten ICMP's sind bei mir freigegeben. Alle übrigen Anfragen die sich nicht an gewünschte Dienste wie http richten werden gedropped - völlig unabhängig davon ob überhaupt ein Dienst auf diesem Port läuft und ob dieser überhaupt nach aussen lauscht. Mein Server ist erreichbar und kümmert sich um alle legitimen Anfragen. Ich kontrolliere ein- und ausgehende Pakete; ich "zerstöre" tcp/ip nicht, indem unsinnige Pakete ignoriert werden.
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
On Wed, Jun 18, 2003 at 12:12:25PM +0200, Michael Hilscher wrote:
Ohne Paketfilter kann ich meinen Server innerahlb weniger minuten vollständig scannen mit Paketfilter dauert es ewig (je nach genutzten Optionen und Scanner).
Eher nicht. Jeder, der einen sinnvollen Scanner hat und ihn zu benutzen weiß, weiß auch, was ein parallel Scan ist und wie man ihn realisiert. Ich bin inzwischen dazu übergegangen, meine Firewalls mit 3:10 antworten zu lassen (ICMP administratively prohibited). Die Begründung ist klar: Einem kundigen Angreifer ist es egal, ob man Pakete droppt oder beantwortet, es hält ihn nicht auf. Dem unkundigen Angreifer wird signalisiert: "Hier ist eine Firewall" und er sucht sich ggf. ein leichteres Ziel. Dem debuggenden Administrator wird ebenfalls signalisiert: "Hier ist eine Firewall" und er weiß, daß er unter Umständen mit mir in Kontakt treten muß, wenn er ein Netzwerkproblem debuggen will. Was die Scans selber angeht: Ein Portscan macht nix kaputt. Wenn ich mit 3:10 antworte, ist er schneller vorbei und alle Beteiligten wissen Bescheid.
Es steht ausser frage, dass ein Paketfilter diverse Scans ganz verhindern und manche erschweren kann.
Ein abschließendes Wort noch, bevor ich den Thread wegscore: Eine Firewall macht auch auf einem einzelnen Host genauso viel Sinn oder Unsinn wie für ein Subnetz - so wie man einen einzelnen Host sicher konfigurieren kann, kann man ja auch ein einzelnes Netz hostweise sicher konfigurieren. Das ist auch nicht der Punkt. Eine Firewall ist ein Policy Enforcer. Das bedeutet, man schreibt noch einmal gesammelt und an einer Stelle den Sollzustand des Netzes auf (das ist der Policy-Teil) und läßt ihn durch die Firewall filtern und loggen (das ist der Enforcement-Teil) - parallel dazu konfiguriert man seine Kisten so, daß sie diesen Sollzustand möglichst auch ohne die Firewall erreichen. Im Gegensatz zu der hostweise sicheren konfiguration ist die Firewall-Konfiguration jedoch leichter zu validieren und evaluieren: ihre Ergebnisse werden zentral geloggt und können so zentral ausgewertet werden. Kristian
Am Dienstag, 17. Juni 2003 14:55 schrieb Thomas Worm:
Tach,
In letzter Zeit wurden viele DoS-Attacken auf 1&1-Server gestartet. Ich empfehl dir deswegen ne Firewall! Kannst du noch kurz anreißen, wie deine Firewall![1] eine DoS-Attacke verhindert? Durch abblocken, wie denn sonst?
Äh... von was für einem DoS reden wir hier? Crash exploit im Apache? Da blocke ich also den Traffic, der auf port 80 reinkommt? Leitung zupingen? Die Pakete müssen ohnehin über die Leitung, bis du sie abblocken kannst. SynFlood? Bleibt immer noch das nicht-triviale Unterscheiden zwischen gewolltem und nicht gewolltem Verkehr. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Tue, Jun 17, 2003 at 02:18:34PM +0200, Martin Borchert wrote:
sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen.
Ich weiß von einem Setup, bei dem ein Java Application Server sich weigert, über einen UNIX Domain Socket mit dem MySQL zu reden. Also schirmt der Paketfilter die 3306 nach draussen ab. In einem anderen Setup läuft ein imap/pop auf 143/110 und sslwrap auf 993/995. Der Paketfilter macht hier die 143/110 nach aussen zu.
Viel wichtiger ist es, nur die Services laufen zu lassen, die du benötigst und zu diesen jeweils als sicher[tm] eingestufte Versionen der Software einzusetzen.
Generell ist es sinnvoll, mehr als eine Verteidigungslinie aufzubauen. Das schützt zusätzlich gegen Konfigurationsfehler und Admindummheit. Kristian
Am Dienstag, 17. Juni 2003 14:59 schrieb Kristian Koehntopp:
On Tue, Jun 17, 2003 at 02:18:34PM +0200, Martin Borchert wrote:
sinnfrei. Überhaupt fällt mir kein vernünftiges Setup ein, bei dem es nötig wäre, einen _einzelnen_ Server mit einem Paketfilter zu versehen. Ich weiß von einem Setup, bei dem ein Java Application Server sich weigert, über einen UNIX Domain Socket mit dem MySQL zu reden. Also schirmt der Paketfilter die 3306 nach draussen ab.
Kaputte Software. Ok, das gleiche ist es, wenn sich ein daemon nicht an ein bestimmtes interface binden lassen will.
In einem anderen Setup läuft ein imap/pop auf 143/110 und sslwrap auf 993/995. Der Paketfilter macht hier die 143/110 nach aussen zu.
Gleiches wie oben, oder? Die eigentliche Verbindung ist doch inet->ext_iface:993->lo:143, also muss der imapd nicht auf ext_iface lauschen. Oder hab ich was wesentliches übersehen?
Viel wichtiger ist es, nur die Services laufen zu lassen, die du benötigst und zu diesen jeweils als sicher[tm] eingestufte Versionen der Software einzusetzen. Generell ist es sinnvoll, mehr als eine Verteidigungslinie aufzubauen. Das schützt zusätzlich gegen Konfigurationsfehler und Admindummheit.
Wichtiges Argument, hat aber den Nachteil, dass zusätzliche Software auch zusätzliche Angriffsfläche bietet. Und ich würde befürchten, dass sich der dumme Admin dann auf seinen (unter Umständen kaputten) Paketfilter verlässt. Und wo wir gerade bei Admindummheit sind: So richtig trivial ist ein Paketfilter imho auch mit fwbuilder nicht zusammenklickbar, wir reden also schon über ein wenig Sachverstand. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
On Tue, Jun 17, 2003 at 03:19:54PM +0200, Martin Borchert wrote:
Und wo wir gerade bei Admindummheit sind: So richtig trivial ist ein Paketfilter imho auch mit fwbuilder nicht zusammenklickbar, wir reden also schon über ein wenig Sachverstand.
Trivial verglichen mit was? Mit fwbuilder ist es schon so trivial wie es sein kann, ohne die Möglichkeiten einzuschränken. Noch simpler wird es nur, wenn man Annahmen über das Setup macht, wie SuSEFirewall2 es tut. Kristian
Am Dienstag, 17. Juni 2003 15:33 schrieb Kristian Koehntopp:
On Tue, Jun 17, 2003 at 03:19:54PM +0200, Martin Borchert wrote:
Und wo wir gerade bei Admindummheit sind: So richtig trivial ist ein Paketfilter imho auch mit fwbuilder nicht zusammenklickbar, wir reden also schon über ein wenig Sachverstand. Trivial verglichen mit was?
Mit SuSEFirewall[2], Filtereinstellungen in Windows >=2000
Mit fwbuilder ist es schon so trivial wie es sein kann, ohne die Möglichkeiten einzuschränken. Noch simpler wird es nur, wenn man Annahmen über das Setup macht, wie SuSEFirewall2 es tut.
Ich muss für fwbuilder eine ziemlich genaue Vorstellung davon haben, was ich machen will und wie sich was auswirkt, das heißt ich muss zumindest das Grundkonzept von tcp/ip verstanden haben. Ich wollte zum Ausdruck bringen, dass fwbuilder es nicht erlaubt, ohne Vorwissen einen standfesten Paketfilter zusammenzuklicken. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
[Dominik Thüriedl]:
morgen,
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich?
Was verstehst du unter "Firewall"? (Wegen der Alternativen) Nun, eine Menge Fragen. Hier noch ein paar Gedanken dazu: Prinzipiell ist es richtig, dass der apache nur auf den angegebenen Ports reagiert. Sicherlich wird er auch noch Sicherheitslücken haben, aber die werden nach ihrer Entdeckung i.d.R. relativ schnell gepatcht (man muss halt nur auf dem Laufenden bleiben). Ein Paketfilter muss auch diese Ports offen halten, sonst kommt ja nix beim apache an. Aber allein ein Paketfilter kann schon mehr (Stichwort: DoS-Attacken). Außerdem überlege, welche Dienste evtl noch auf dem Rechner laufen (ftp, ssh, mail, ..). Irgendwie musst du das Teil ja warten, sicher auch Daten uploaden. Vielleicht sollen das auch noch andere können. Da ergeben sich neue Gefahren (Stichwort: AntiVirenFilter). Eine Firewall (selbst nur ein einfacher Paketfilter) direkt auf dem Webserver ist viel besser als keine. Eine Firewall vor dem Webserver ist sicherlich noch besser (auf diesem Host sollten natürlich keinerlei Dienst angeboten werden außer ggf. Mailversand für Statusinformationen ins eigene Netz). Evtl. schützt 1&1 die vermieteten Server schon durch eine eigene Firewall (zumindest teilweise)? -- Gruß MaxX
Matthias Houdek wrote:
[Dominik Thüriedl]:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
was?
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
ok, gutes argument. scp?
ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich?
Was verstehst du unter "Firewall"? (Wegen der Alternativen)
Nun, eine Menge Fragen. Hier noch ein paar Gedanken dazu:
Prinzipiell ist es richtig, dass der apache nur auf den angegebenen Ports reagiert. Sicherlich wird er auch noch Sicherheitslücken haben, aber die werden nach ihrer Entdeckung i.d.R. relativ schnell gepatcht (man muss halt nur auf dem Laufenden bleiben).
ACK
Ein Paketfilter muss auch diese Ports offen halten, sonst kommt ja nix beim apache an.
was?
Aber allein ein Paketfilter kann schon mehr (Stichwort: DoS-Attacken).
irgendwer macht ein DoS auf deinen webserver. der paketfilter nutzt jetzt noch was?
Außerdem überlege, welche Dienste evtl noch auf dem Rechner laufen (ftp, ssh, mail, ..). Irgendwie musst du das Teil ja warten, sicher auch Daten uploaden.
scp?
Vielleicht sollen das auch noch andere können.
scp?
Da ergeben sich neue Gefahren (Stichwort: AntiVirenFilter).
für was?
Eine Firewall (selbst nur ein einfacher Paketfilter) direkt auf dem Webserver ist viel besser als keine.
warum? micha
[Michael Meyer]:
Matthias Houdek wrote:
[Dominik Thüriedl]:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
was?
Gut, wenn das Teil nichts weiter beherbergt und ich immer eine aktuelle Sicherung (Image) parat habe, um ihn schnell wieder fit zu machen.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
ok, gutes argument. scp?
Dafür muss ssh laufen. Bist du sicher, dass das immer nur auf die angegebenen Hostadressen reagiert? Eigentlich schon, aber was heißt "eigentlich", wenn es mir auf Sicherheit ankommt.
ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich?
Was verstehst du unter "Firewall"? (Wegen der Alternativen)
Nun, eine Menge Fragen. Hier noch ein paar Gedanken dazu:
Prinzipiell ist es richtig, dass der apache nur auf den angegebenen Ports reagiert. Sicherlich wird er auch noch Sicherheitslücken haben, aber die werden nach ihrer Entdeckung i.d.R. relativ schnell gepatcht (man muss halt nur auf dem Laufenden bleiben).
ACK
Ein Paketfilter muss auch diese Ports offen halten, sonst kommt ja nix beim apache an.
was?
Na nix, wenn der Paketfilter Port 80 blockt.
Aber allein ein Paketfilter kann schon mehr (Stichwort: DoS-Attacken).
irgendwer macht ein DoS auf deinen webserver. der paketfilter nutzt jetzt noch was?
Zumindest kann ich die Angreifer relativ leicht lokalisieren und für die Zukunft sperren (ggf. könnte man das in beschränktem Umfang vielleicht sogar (teil)automatisieren).
Außerdem überlege, welche Dienste evtl noch auf dem Rechner laufen (ftp, ssh, mail, ..). Irgendwie musst du das Teil ja warten, sicher auch Daten uploaden.
scp?
Siehe oben.
Vielleicht sollen das auch noch andere können.
scp?
FTP?
Da ergeben sich neue Gefahren (Stichwort: AntiVirenFilter).
für was?
Das, was reinkommt, wird erst mal gefiltert, bevor es wirklich das System erreicht.
Eine Firewall (selbst nur ein einfacher Paketfilter) direkt auf dem Webserver ist viel besser als keine.
warum?
Es beruhigt (wenn der Webserver und vor allem die Daten da drauf einem wichtig sind). -- Gruß MaxX
Matthias Houdek wrote:
[Michael Meyer]:
Matthias Houdek wrote:
[Dominik Thüriedl]:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
ok, gutes argument. scp?
Dafür muss ssh laufen. Bist du sicher, dass das immer nur auf die angegebenen Hostadressen reagiert? Eigentlich schon, aber was heißt "eigentlich", wenn es mir auf Sicherheit ankommt.
bist du sicher das dein paketfilter immer richtig reagiert? eigentlich schon ...
Ein Paketfilter muss auch diese Ports offen halten, sonst kommt ja nix beim apache an.
was?
Na nix, wenn der Paketfilter Port 80 blockt.
so wie du es geschrieben hattest, liest es sich für mich, als ob ich den paketfilter brauche, damit mein apache anfragen auf port 80 entgegenehmen kann. da musste ich einfach mit einem 'was?' nachfragen.
Aber allein ein Paketfilter kann schon mehr (Stichwort: DoS-Attacken).
irgendwer macht ein DoS auf deinen webserver. der paketfilter nutzt jetzt noch was?
Zumindest kann ich die Angreifer relativ leicht lokalisieren und für die Zukunft sperren
komm ... wer greift schon mit seiner adresse an? im zweifel kommt jedes paket von einer anderen IP. viel spass beim filtern.
(ggf. könnte man das in beschränktem Umfang vielleicht sogar (teil)automatisieren).
na klar ... portsentry z.b. kann das von hause aus.
Vielleicht sollen das auch noch andere können.
scp?
FTP?
dazu fällt mir dann nur ein: selber schuld! so was krankes wie ftp würde ich nicht mehr einsetzen.
Da ergeben sich neue Gefahren (Stichwort: AntiVirenFilter).
für was?
Das, was reinkommt, wird erst mal gefiltert, bevor es wirklich das System erreicht.
sind wir noch bei http und ssh?
Eine Firewall (selbst nur ein einfacher Paketfilter) direkt auf dem Webserver ist viel besser als keine.
warum?
Es beruhigt (wenn der Webserver und vor allem die Daten da drauf einem wichtig sind).
wenn aber doch nur der webserver erreichbar ist und keine weiteren dienste laufen, bleibt der webserver als erstes potentielles angriffsziel. da hilft dann auch kein paketfilter, ausser du blockst alle anfragen an den webserver. nur, warum hast du dann einen? micha
Am Dienstag, 17. Juni 2003 16:51 schrieb Michael Meyer:
Matthias Houdek wrote:
FTP? dazu fällt mir dann nur ein: selber schuld! so was krankes wie ftp würde ich nicht mehr einsetzen.
Stichwort Last. Große Dateien mit scp zu übertragen erfordert ein bisschen Hardware. Da verschiebt sich leicht der Flaschenhals von Netzwerk zu CPU. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
[Michael Meyer]:
Matthias Houdek wrote:
[Michael Meyer]:
Matthias Houdek wrote:
[Dominik Thüriedl]:
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
ok, gutes argument. scp?
Dafür muss ssh laufen. Bist du sicher, dass das immer nur auf die angegebenen Hostadressen reagiert? Eigentlich schon, aber was heißt "eigentlich", wenn es mir auf Sicherheit ankommt.
bist du sicher das dein paketfilter immer richtig reagiert? eigentlich schon ...
Ja, eigentlich schon. Und ich bin mir noch sicherer, dass nicht beide an der gleichen Stelle versagen.
Ein Paketfilter muss auch diese Ports offen halten, sonst kommt ja nix beim apache an.
was?
Na nix, wenn der Paketfilter Port 80 blockt.
so wie du es geschrieben hattest, liest es sich für mich, als ob ich den paketfilter brauche, damit mein apache anfragen auf port 80 entgegenehmen kann. da musste ich einfach mit einem 'was?' nachfragen.
So weit solltest du mich eigentlich kennen.
Aber allein ein Paketfilter kann schon mehr (Stichwort: DoS-Attacken).
irgendwer macht ein DoS auf deinen webserver. der paketfilter nutzt jetzt noch was?
Zumindest kann ich die Angreifer relativ leicht lokalisieren und für die Zukunft sperren
komm ... wer greift schon mit seiner adresse an? im zweifel kommt jedes paket von einer anderen IP. viel spass beim filtern.
Von DDoS war bisher noch nicht die Rede ;-)
(ggf. könnte man das in beschränktem Umfang vielleicht sogar (teil)automatisieren).
na klar ... portsentry z.b. kann das von hause aus.
Ach, du kennst sowas sogar. Und, ist das kein Tool einer Firewall?
Vielleicht sollen das auch noch andere können.
scp?
FTP?
dazu fällt mir dann nur ein: selber schuld! so was krankes wie ftp würde ich nicht mehr einsetzen.
Es ist aber für allgemeinen Up- und Download noch der Standard. Und auch über scp kann man dir noch alles mögliche unterjubeln. Ausnahme: nur du alleine spielst Daten auf die Kiste. Aber das war nicht die Voraussetzung.
Da ergeben sich neue Gefahren (Stichwort: AntiVirenFilter).
für was?
Das, was reinkommt, wird erst mal gefiltert, bevor es wirklich das System erreicht.
sind wir noch bei http und ssh?
Bei Upload auf den Rechner.
Eine Firewall (selbst nur ein einfacher Paketfilter) direkt auf dem Webserver ist viel besser als keine.
warum?
Es beruhigt (wenn der Webserver und vor allem die Daten da drauf einem wichtig sind).
wenn aber doch nur der webserver erreichbar ist und keine weiteren dienste laufen, bleibt der webserver als erstes potentielles angriffsziel. da hilft dann auch kein paketfilter, ausser du blockst alle anfragen an den webserver.
Die Frage ging nicht ausschließlich nach Paketfilter, sondern nach Firewall. Richtig dicht wäre das auch erst, wenn der Webserver in einer DMZ steht und nur über einen Proxy von außen erreichbar ist.
nur, warum hast du dann einen?
Gute Frage ;-) -- Gruß MaxX
Matthias Houdek wrote:
[Michael Meyer]:
Matthias Houdek wrote:
[Michael Meyer]:
ok, gutes argument. scp?
Dafür muss ssh laufen. Bist du sicher, dass das immer nur auf die angegebenen Hostadressen reagiert? Eigentlich schon, aber was heißt "eigentlich", wenn es mir auf Sicherheit ankommt.
bist du sicher das dein paketfilter immer richtig reagiert? eigentlich schon ...
Ja, eigentlich schon.
eben.
Und ich bin mir noch sicherer, dass nicht beide an der gleichen Stelle versagen.
das ist aber auch nur eine gutgemeinte warscheinlichkeitsrechnung, oder?
was?
Na nix, wenn der Paketfilter Port 80 blockt.
so wie du es geschrieben hattest, liest es sich für mich, als ob ich den paketfilter brauche, damit mein apache anfragen auf port 80 entgegenehmen kann. da musste ich einfach mit einem 'was?' nachfragen.
So weit solltest du mich eigentlich kennen.
eben drum mein sehr erstauntes 'was?'. aber ja, hast ja recht ... hätte ich ignorieren können. aber ... so weit solltest du mich eigentlich kennen. ;)
(ggf. könnte man das in beschränktem Umfang vielleicht sogar (teil)automatisieren).
na klar ... portsentry z.b. kann das von hause aus.
Ach, du kennst sowas sogar.
na klar ... du nicht?
Und, ist das kein Tool einer Firewall?
ja, vielleicht. man muss sich dann halt fragen, ob man einer closed-source-software vertraut. nur bisher ging es doch gar nicht um firewalls. ok, der op schreibt firewall. aber würdest du mit mir wetten wollen, dass er nicht in wirklichkeit paketfilter meint? ich an deiner stelle würde nicht wetten.
dazu fällt mir dann nur ein: selber schuld! so was krankes wie ftp würde ich nicht mehr einsetzen.
Es ist aber für allgemeinen Up- und Download noch der Standard.
wessen? meiner nicht.
Und auch über scp kann man dir noch alles mögliche unterjubeln.
ja, ok.
Ausnahme: nur du alleine spielst Daten auf die Kiste. Aber das war nicht die Voraussetzung.
was genau war denn die vorraussetzung? der kern der frage des op war doch: ,----| | kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der | apache genügend sicherheit? `----| wobei ich davon ausgehe, dass der OP mit 'firewall' einen paketfilter meint. daher meine antwort: nein, braucht er nicht.
Das, was reinkommt, wird erst mal gefiltert, bevor es wirklich das System erreicht.
sind wir noch bei http und ssh?
Bei Upload auf den Rechner.
ahh ... ich kann dir folgen. das kann wohl unter umständen sinn machen.
wenn aber doch nur der webserver erreichbar ist und keine weiteren dienste laufen, bleibt der webserver als erstes potentielles angriffsziel. da hilft dann auch kein paketfilter, ausser du blockst alle anfragen an den webserver.
Die Frage ging nicht ausschließlich nach Paketfilter, sondern nach Firewall.
ach ... Matthias, du bekommst hier doch auch immer mal wieder mit, wie firewall gerne definiert wird. diese allgemeine computer-bild-definition weicht doch von der deinen, und auch von der meinen, meilenweit ab. du kannst doch, mit an sicherheit grenzender warscheinlichkeit, davon ausgehen, dass für den OP eine firewall == paketfilter ist. IMHO zeigt die fragestellung dieses auch.
Richtig dicht wäre das auch erst, wenn der Webserver in einer DMZ steht und nur über einen Proxy von außen erreichbar ist.
'richtig dicht' wird wohl immer ein wunsch bleiben. aber ja, und so verstehe ich dich, dass ist schon die optimalere umsetzung.
nur, warum hast du dann einen?
Gute Frage ;-)
na immerhin _eine_. ;) micha
[Michael Meyer]:
Matthias Houdek wrote:
[Michael Meyer]:
Matthias Houdek wrote:
[Michael Meyer]:
ok, gutes argument. scp?
Dafür muss ssh laufen. Bist du sicher, dass das immer nur auf die angegebenen Hostadressen reagiert? Eigentlich schon, aber was heißt "eigentlich", wenn es mir auf Sicherheit ankommt.
bist du sicher das dein paketfilter immer richtig reagiert? eigentlich schon ...
Ja, eigentlich schon.
eben.
Und ich bin mir noch sicherer, dass nicht beide an der gleichen Stelle versagen.
das ist aber auch nur eine gutgemeinte warscheinlichkeitsrechnung, oder?
Asl Mathematiker liegt mir das ;-)
was?
Na nix, wenn der Paketfilter Port 80 blockt.
so wie du es geschrieben hattest, liest es sich für mich, als ob ich den paketfilter brauche, damit mein apache anfragen auf port 80 entgegenehmen kann. da musste ich einfach mit einem 'was?' nachfragen.
So weit solltest du mich eigentlich kennen.
eben drum mein sehr erstauntes 'was?'. aber ja, hast ja recht ... hätte ich ignorieren können. aber ... so weit solltest du mich eigentlich kennen. ;)
Stimmt auch wieder auffallend.
(ggf. könnte man das in beschränktem Umfang vielleicht sogar (teil)automatisieren).
na klar ... portsentry z.b. kann das von hause aus.
Ach, du kennst sowas sogar.
na klar ... du nicht?
Nicht praktisch, da bisher kein Bedarf (DSL ist hier Mangelware, und bei kurzzeitigen Einwahlverbindungen mit städnig wechselnder IP ist das egal).
Und, ist das kein Tool einer Firewall?
ja, vielleicht. man muss sich dann halt fragen, ob man einer closed-source-software vertraut.
nur bisher ging es doch gar nicht um firewalls. ok, der op schreibt firewall. aber würdest du mit mir wetten wollen, dass er nicht in wirklichkeit paketfilter meint? ich an deiner stelle würde nicht wetten.
Sogar ich hab meist Paketfilter geschrieben, obwohl ich eigentlich immer mehr im Auge dabei habe.
dazu fällt mir dann nur ein: selber schuld! so was krankes wie ftp würde ich nicht mehr einsetzen.
Es ist aber für allgemeinen Up- und Download noch der Standard.
wessen? meiner nicht.
Allgemein, im Internet. Hast du schon mal Dateien via scp aus dem Internet geladen? Und der Upload funxt meist über das gleiche Protokoll.
Und auch über scp kann man dir noch alles mögliche unterjubeln.
ja, ok.
Ausnahme: nur du alleine spielst Daten auf die Kiste. Aber das war nicht die Voraussetzung.
was genau war denn die vorraussetzung?
Ich schrieb von anderen, die mir was auf meinen Rechner schieben dürfen (hast du freundlicher Weise im Interesse des Traffics gelöscht ;-).
der kern der frage des op war doch:
,----|
| kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet | der apache genügend sicherheit?
`----|
wobei ich davon ausgehe, dass der OP mit 'firewall' einen paketfilter meint.
daher meine antwort: nein, braucht er nicht.
Wenn nur ein Indianer drauf tanzt und der vernünftig konfiguriert, gebe ich dir gerne Recht.
[...] Richtig dicht wäre das auch erst, wenn der Webserver in einer DMZ steht und nur über einen Proxy von außen erreichbar ist.
'richtig dicht' wird wohl immer ein wunsch bleiben. aber ja, und so verstehe ich dich, dass ist schon die optimalere umsetzung.
*SCNR* Von optimal gibt es keine Steigerung (wie auch schwanger oder tod) Aber du hast natürlich Recht: 'richtig dicht' ist immer noch zeihmlich offen. -- Gruß MaxX
On Tue, Jun 17, 2003 at 01:14:28PM +0200, Matthias Houdek wrote:
Evtl. schützt 1&1 die vermieteten Server schon durch eine eigene Firewall (zumindest teilweise)?
No. Es heißt nicht umsonst "Pure"tec. Die weisen außerdem in der Anleitung ausdrücklich darauf hin, daß man selber für die Security verantwortlich ist. Kristian
Hallo Matthias Am Dienstag, 17. Juni 2003 13:14 schrieb Matthias Houdek:
[Dominik Thüriedl]:
morgen,
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil? Diese 1&1-Rootserver haben nur eine Partition und die sollte man wohl nicht "ro" mounten, sonst gibts keine Logs, keine Mails, kein MySQL etc., oder sehe ich das falsch?
ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich?
Was verstehst du unter "Firewall"? (Wegen der Alternativen)
Nun, eine Menge Fragen. Hier noch ein paar Gedanken dazu:
Evtl. schützt 1&1 die vermieteten Server schon durch eine eigene Firewall (zumindest teilweise)? Nein, das tun sie leider ausdrücklich nicht. Da sollte man sich nicht in falscher Sicherheit wiegen.
CU Thorsten
[Thorsten Körner]:
Hallo Matthias
Am Dienstag, 17. Juni 2003 13:14 schrieb Matthias Houdek:
[Dominik Thüriedl]:
morgen,
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
Diese 1&1-Rootserver haben nur eine Partition und die sollte man wohl nicht "ro" mounten, sonst gibts keine Logs, keine Mails, kein MySQL etc., oder sehe ich das falsch?
Oups, das ist aber schwach.
ist es überhaupt ratsam eine firewall direkt auf einen webserver zu installieren? und wenn nicht: welche alternativen bieten sich?
Was verstehst du unter "Firewall"? (Wegen der Alternativen)
Nun, eine Menge Fragen. Hier noch ein paar Gedanken dazu:
Evtl. schützt 1&1 die vermieteten Server schon durch eine eigene Firewall (zumindest teilweise)?
Nein, das tun sie leider ausdrücklich nicht. Da sollte man sich nicht in falscher Sicherheit wiegen.
Naja, wäre wohl irgendwie auch schwierig. Oder sie müssten von jedem gehosteten Server die anzubietenden Dienste vorher abfragen. Der Aufwand wäre sicherlich ein wenig teurer ;-) -- Gruß MaxX
Hallo Matthias Am Dienstag, 17. Juni 2003 16:59 schrieb Matthias Houdek:
[Thorsten Körner]:
Hallo Matthias
Am Dienstag, 17. Juni 2003 13:14 schrieb Matthias Houdek:
[Dominik Thüriedl]:
morgen,
mein webserver ist direkt an das internet angeschlossen - also nicht hinter einer firewall.
Kann man machen, sollte man aber nicht.
kann/Sollte/MÜSSTE eine firewall installiert werden oder bietet der apache genügend sicherheit?
Läuft auf dem Webserver nur apache? Keine weitere Software? Alle Partitionen ro gemountet? Und wie pflegst _du_ die Daten auf dem Teil?
Diese 1&1-Rootserver haben nur eine Partition und die sollte man wohl nicht "ro" mounten, sonst gibts keine Logs, keine Mails, kein MySQL etc., oder sehe ich das falsch?
Oups, das ist aber schwach. Wie Kristian schon sagte:" PURE-tec" 8-) Obwohl meine aussage nicht so ganz richtig ist: Es gibt ausser "/" noch zwei Partitionen und zwar: /boot und swap mit jeweils 258.8MB, was allerdings wohl nichts daran ändert.
CU thorsten
participants (12)
-
Andreas Hergesell -
Andreas Winkelmann -
Dominik Thüriedl -
Kristian Koehntopp -
Martin Borchert -
Matthias Hentges -
Matthias Houdek -
Michael Hilscher -
Michael Meyer -
Peter Wiersig -
Thomas Worm -
Thorsten Körner