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