Hallo,
mußte mich gerade etwas intensiver mit der personal-firewall meiner SuSi 7.2 herumschlagen, da die Antworten vom Timeserver einfach ausgefiltert werden ...
Dabei habe ich etwas (jedenfalls für meine ungeschulten Augen) komisches entdeckt: Mit viel Aufwand werden alle udp Ports die mit laufenden Prozessen (netstat -nl) mit DENY geschlossen.
for p in <alle offenen udp ports>; do $ipchains -I $rulechain -p udp -d 0/0 $p -j DENY done
Dann werden die Nameserver explizit geöffnet (domain -> any).
Und dann werden alle udp Pakete generell verboten $ipchains -A $rulechain -p udp -j DENY
Wenn sowieso alle udp Pakete geblockt werden, ist es da nicht sinnlos die einzelnen offenen Ports zuzumachen???
Uwe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 19 November 2001 02:16, Uwe Koloska wrote:
Hallo,
mußte mich gerade etwas intensiver mit der personal-firewall meiner SuSi 7.2 herumschlagen, da die Antworten vom Timeserver einfach ausgefiltert werden ...
Dabei habe ich etwas (jedenfalls für meine ungeschulten Augen) komisches entdeckt: Mit viel Aufwand werden alle udp Ports die mit laufenden Prozessen (netstat -nl) mit DENY geschlossen.
for p in <alle offenen udp ports>; do $ipchains -I $rulechain -p udp -d 0/0 $p -j DENY done
Dann werden die Nameserver explizit geöffnet (domain -> any).
Und dann werden alle udp Pakete generell verboten $ipchains -A $rulechain -p udp -j DENY
Wenn sowieso alle udp Pakete geblockt werden, ist es da nicht sinnlos die einzelnen offenen Ports zuzumachen???
voellig korrekt. Jetzt kommt mein Standardtipp fuer alle Firewall-Anfaenger:
1. schmeiss die beiden SuSE-Firewalls weg! 2. nimm Dir ein Blatt Papier und entwirf die Regeln fuer INPUT selber (von unten nach oben): 1) schliesse alles auf UDP aus 2) schliesse alle auf TCP aus => Verbindungsaufbau von innen soll meistens gestattet sein, also so bauen, dass nur --syn -Pakete von aussen verboten sind (SYN ist das erste Handshakepaket) 3) bohre weitere Loecher in UDP rein: a) DNS-Antworten sind erlaubt, also erlaube Port 53 von aussen b) ?? 4) bohre Loecher in TCP rein a) wenn Du von aussen per ssh ran willst oeffne Port 22 b) wenn Du Freunden Zugriff auf HTTP(S) geben willst oeffne Port 80 (443) c) etc. 3. lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen Leute, die nicht alles duerfen 4. falls Routing noetig ist bau Dir eine Forward-Chain und passende NAT-Table...
Im Anhang ist meine kommentierte IPTables-Config (kann mit iptables-restore gelesen werden, NAT ist dort noch nicht richtig drin).
Konrad
- -- BOFH excuse #17:
fat electrons in the lines
On Mon, Nov 19, 2001 at 06:18:20AM +0100, Konrad Rosenbaum wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- bohre weitere Loecher in UDP rein: a) DNS-Antworten sind erlaubt, also erlaube Port 53 von aussen b) ??
- bohre Loecher in TCP rein a) wenn Du von aussen per ssh ran willst oeffne Port 22 b) wenn Du Freunden Zugriff auf HTTP(S) geben willst oeffne Port 80 (443) c) etc.
Und ganz wichtig: Lass TCP port 53 offen, weil AFAIK alle grossen DNS-Antworten darüber laufen.
Konrad
cu, Ulf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 19 November 2001 20:13, Ulf Lorenz wrote:
On Mon, Nov 19, 2001 at 06:18:20AM +0100, Konrad Rosenbaum wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- bohre weitere Loecher in UDP rein: a) DNS-Antworten sind erlaubt, also erlaube Port 53 von aussen b) ??
- bohre Loecher in TCP rein a) wenn Du von aussen per ssh ran willst oeffne Port 22 b) wenn Du Freunden Zugriff auf HTTP(S) geben willst oeffne Port 80
(443) c) etc.
Und ganz wichtig: Lass TCP port 53 offen, weil AFAIK alle grossen DNS-Antworten darüber laufen.
waere mir neu.
Wie auch immer, es wird nur der remote Port 53 gebraucht und der kommt durch, wenn mit --syn gefiltert wird. Wuerdest Du den lokalen offen lassen waere das eine Zugangsmoeglichkeit zu Deinem lokalen DNS-server, was ja kaum gewollt sein kann.
Konrad
- -- BOFH excuse #87:
Password is too complex to decrypt
Hallo,
On Mon, Nov 19, 2001 at 09:51:49PM +0100, Konrad Rosenbaum wrote:
- bohre Loecher in TCP rein a) wenn Du von aussen per ssh ran willst oeffne Port 22 b) wenn Du Freunden Zugriff auf HTTP(S) geben willst oeffne Port 80
(443) c) etc.
Und ganz wichtig: Lass TCP port 53 offen, weil AFAIK alle grossen DNS-Antworten darüber laufen.
waere mir neu.
Wie auch immer, es wird nur der remote Port 53 gebraucht und der kommt durch, wenn mit --syn gefiltert wird. Wuerdest Du den lokalen offen lassen waere das eine Zugangsmoeglichkeit zu Deinem lokalen DNS-server, was ja kaum gewollt sein kann.
Wenn ich das mit DNS ueber TCP richtig verstanden habe, wird immer erst per UDP versucht, eine Namensaufloesung zu erreichen. Wenn der Antwortende der Meinung ist, die Antwort waere zu gross fuer ein UDP-Packet, schickt er eine entsprechende Fehlermeldung zurueck. Daraufhin oeffnet der Fragende eine TCP-Verbindung und schickt die Anfrage ueber diese und die Antwort kommt darauf zurueck. Solange Du also von aussen keine DNS-Anfragen ermoeglichen willst, brauchst Du auf 53 keine TCP-Verbindungen zu erlauben, Hauptsache die eigene Maschine kann nach aussen telefonieren.
Holger
Konrad Rosenbaum wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen Leute, die
nicht alles duerfen
Das funktioniert aber nur wenn der Name des Mitarbeiters als IP-Adresse aufgelöst werden kann. ;-)
- falls Routing noetig ist bau Dir eine Forward-Chain und passende
NAT-Table...
Die zugehörige FORWARD-Regel(n) überlasse ich dir, sie sind den INPUT-Regeln ähnlich.
Der spezielle (und meist benötigte) Fall Masquerading:
iptables -t nat -A POSTROUTING -o ippp0 -j MASQUERADE
Evtl. wirst Du das Interface noch anpassen müssen. Wie der Name 'POSTROUTING' schon sagt, wird das am Ende ausgeführt kurz bevor das Paket den Rechner verläßt.
dazu noch, damit der Kernel dyn. IP-Adressen bearbeiten kann:
echo 1 > /proc/sys/net/ipv4/ip_dynaddr echo 1 > /proc/sys/net/ipv4/ip_forward
Rico
Am Dienstag, dem 20. November 2001 um 13:26:40, schrieb Rico Koerner:
Konrad Rosenbaum wrote:
- lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen
Leute, die nicht alles duerfen
Das funktioniert aber nur wenn der Name des Mitarbeiters als IP-Adresse aufgelöst werden kann. ;-)
Ich erlaube mir, erneut aus manual pages zu zitieren:
--uid-owner userid Matches if the packet was created by a process with the given effective user id.
Torsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 20 November 2001 22:51, Torsten Werner wrote:
Am Dienstag, dem 20. November 2001 um 13:26:40, schrieb Rico Koerner:
Konrad Rosenbaum wrote:
- lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen
Leute, die nicht alles duerfen
Das funktioniert aber nur wenn der Name des Mitarbeiters als IP-Adresse aufgelöst werden kann. ;-)
Ich erlaube mir, erneut aus manual pages zu zitieren:
--uid-owner userid Matches if the packet was created by a process with the given effective user id.
Was wiederum total sinnlos ist, wenn der Prozess auf einem anderen Rechner laeuft... ;-)
Konrad
- -- Never shown Star Trek episodes #5: Picard: "Ok, and what does that little red light at this noisy machine mean?" Geordy: "It's the coffee automata, Captain."
Am Dienstag, dem 20. November 2001 um 23:50:54, schrieb Konrad Rosenbaum:
On Tuesday 20 November 2001 22:51, Torsten Werner wrote:
Am Dienstag, dem 20. November 2001 um 13:26:40, schrieb Rico Koerner:
Konrad Rosenbaum wrote:
- lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen
Leute, die nicht alles duerfen
Das funktioniert aber nur wenn der Name des Mitarbeiters als IP-Adresse aufgelöst werden kann. ;-)
Ich erlaube mir, erneut aus manual pages zu zitieren:
--uid-owner userid Matches if the packet was created by a process with the given effective user id.
Was wiederum total sinnlos ist, wenn der Prozess auf einem anderen Rechner laeuft... ;-)
Haben jetzt alle eine Leseschwaeche? Du selbst (siehe oben) schriebst aber ueber die OUTPUT chain! Also nix mit 'anderem Rechner'.
Bisschen viel zitiert, aber das muss hier sein.
Torsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 21 November 2001 10:51, Torsten Werner wrote:
Am Dienstag, dem 20. November 2001 um 23:50:54, schrieb Konrad
Rosenbaum:
On Tuesday 20 November 2001 22:51, Torsten Werner wrote:
Am Dienstag, dem 20. November 2001 um 13:26:40, schrieb Rico
Koerner:
Konrad Rosenbaum wrote:
- lasse die OUTPUT Chain in Ruhe, es sei denn es gibt drinnen
Leute, die nicht alles duerfen
Das funktioniert aber nur wenn der Name des Mitarbeiters als IP-Adresse aufgelöst werden kann. ;-)
Ich erlaube mir, erneut aus manual pages zu zitieren:
--uid-owner userid Matches if the packet was created by a process with the given effective user id.
Was wiederum total sinnlos ist, wenn der Prozess auf einem anderen Rechner laeuft... ;-)
Haben jetzt alle eine Leseschwaeche? Du selbst (siehe oben) schriebst aber ueber die OUTPUT chain! Also nix mit 'anderem Rechner'.
Bisschen viel zitiert, aber das muss hier sein.
Ups, mit IPChains verwechselt!
Konrad
- -- BOFH excuse #255:
Standing room only on the bus.
Uwe Koloska wrote:
Hallo,
mußte mich gerade etwas intensiver mit der personal-firewall meiner SuSi 7.2 herumschlagen, da die Antworten vom Timeserver einfach ausgefiltert werden ...
Dabei habe ich etwas (jedenfalls für meine ungeschulten Augen) komisches entdeckt: Mit viel Aufwand werden alle udp Ports die mit laufenden Prozessen (netstat -nl) mit DENY geschlossen.
for p in <alle offenen udp ports>; do $ipchains -I $rulechain -p udp -d 0/0 $p -j DENY done
Jeder einzeln? Das halte ich für Schwachsinn. So schlimm war's ja nicht mal bei 7.0 Ich denke, daß das etwas anders ist. Warum ist das eigentlich ein '-I' und kein '-A' ?
Dann werden die Nameserver explizit geöffnet (domain -> any).
Das wäre nutzlos. Was einmal abgelehnt wurde kann nicht wieder akzeptiert werden, da es diese Regel nie erreichen würde.
Und dann werden alle udp Pakete generell verboten $ipchains -A $rulechain -p udp -j DENY
Das ist prinzipiell wieder richtig, alles was übrigbleibt wird abgelehnt.
Wenn sowieso alle udp Pakete geblockt werden, ist es da nicht sinnlos die einzelnen offenen Ports zuzumachen???
Es wäre sinnlos. Ich denke du hast den ersten Part falsch interpretiert.
lug-dd@mailman.schlittermann.de
-
Holger Dietze -
konrad.rosenbaum＠t-online.de -
Rico Koerner -
Torsten Werner -
Ulf Lorenz -
Uwe Koloska