Hallo,
ich habe gerade die Personal Firewall von der SuSE 7.2 installiert.
Leider funktioniert sie so gut, dass ich nur noch Mails abrufen, aber
keine Mails versenden, keine News abrufen und nicht mehr im Internet
surfen kann :-(
In /etc/rc.config.d/security.rc.config steht nur
REJECT_ALL_INCOMING_CONNECTIONS=yes
In /etc/rc.config ist START_FW auf "yes" gesetzt (obwohl dort etwas
davon steht, dass die Konfiguration ueber
/etc/rc.config.d/firewall.rc.config erfolgt).
Ein "ipchain -L" bringt:
Chain input (policy ACCEPT):
target prot opt source destination ports
devchain all ------ anywhere anywhere n/a
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
Chain rulchain (1 references):
target prot opt source destination ports
DENY udp ------ anywhere anywhere any -> domain
DENY udp ------ anywhere anywhere any -> 1082
ACCEPT udp ------ localhost anywhere domain -> any
DENY icmp ------ anywhere anywhere redirect
DENY udp ------ anywhere anywhere any -> any
REJECT tcp -y--l- anywhere anywhere any -> any
Chain devchain (1 references):
target prot opt source destination ports
rulchain all ------ anywhere anywhere n/a
Chain maschain (0 references):
Und zum Schluss noch ein Auszug aus /var/log/kernel:
Nov 6 22:47:19 localhost kernel: Packet log: rulchain REJECT ippp2
PROTO=6 217.
87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64351 F=0x4000 T=125 SYN
(#6)
Nov 6 22:47:22 localhost kernel: Packet log: rulchain REJECT ippp2
PROTO=6 217.
87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64577 F=0x4000 T=125 SYN
(#6)
Statt des bind laeuft hier uebrigens der dnrd (Version 2.10), Kernel ist
ein selbstgebauter 2.2.18.
Ist die Personal Firewall von Suse vielleicht doch nicht so geeignet,
um anderen Rechnern den Zugang auf den eigenen PC zu verbieten,
gleichzeitig aber selbst mit dem Stand-alone-PC noch ins Netz gehen zu
koennen?
Vielen Dank fuer Tips,
Heinz.
--
E-Mail: Heinz W. Pahlke
On Tue, 06 Nov 2001, "Heinz W. Pahlke" wrote:
Hallo,
ich habe gerade die Personal Firewall von der SuSE 7.2 installiert. Leider funktioniert sie so gut, dass ich nur noch Mails abrufen, aber keine Mails versenden, keine News abrufen und nicht mehr im Internet surfen kann :-(
In /etc/rc.config.d/security.rc.config steht nur REJECT_ALL_INCOMING_CONNECTIONS=yes
In /etc/rc.config ist START_FW auf "yes" gesetzt (obwohl dort etwas davon steht, dass die Konfiguration ueber /etc/rc.config.d/firewall.rc.config erfolgt). [...]
Du willst ganz sicher gehen und startest gleich zwei Firewalls ;). "START-FW" muss auf "no" gesetzt werden sonst startet zusätzlich zur Personal-firewall noch SuSEfirewall. Personal-firewall wird nur über "/etc/rc.config.d/security.rc.config" konfiguriert. Falls du noch masquerading benötigst, ist noch in "/etc/rc.config" "IP_FORWARD=yes" zu setzen. -ron
On 07-Nov-2001 Rolf Naef wrote:
On Tue, 06 Nov 2001, "Heinz W. Pahlke" wrote:
In /etc/rc.config ist START_FW auf "yes" gesetzt (obwohl dort etwas davon steht, dass die Konfiguration ueber /etc/rc.config.d/firewall.rc.config erfolgt). [...]
Du willst ganz sicher gehen und startest gleich zwei Firewalls ;).
Wollte ich eigentlich nicht :-)
"START-FW" muss auf "no" gesetzt werden sonst startet zusätzlich
Ich habe es aber natuerlich auch mit dieser Einstellung probiert, eben wegen des Kommentars in der rc.config. Bloss es ging trotzdem nicht :-( Heute morgen habe ich mich deshalb noch mal rangesetzt. Auf "no" gesetzt und getestet: Mail geht, Usenet geht, nur Surfen nicht :-(( Also die Firewall wieder deaktiviert. Mail geht, Usenet geht, nur Surfen nicht :-((( Und da fiel es mir wie Schuppen von den Augen :-)))))) Ich bin wie ueblich mit T-Online ins Netz gegangen und greife deshalb natuerlich auch auf den (regionalen) DNS-Server von T-Online zurueck. Also den DNS von Otello gewaehlt, die Firewall wieder aktiviert und - es funzt :-))))))))) Ich schreibe das hier nur so ausfuehrlich, weil wir erst kuerzlich eine Diskussion ueber die T-Online-DNS hatten.
konfiguriert. Falls du noch masquerading benötigst, ist noch in
Wenn ich das wuesste. Ich arbeite mich ja erst in das Thema ein. Da es
sich um einen Stand-alone-Rechner handelt, denke ich aber, dass es
ueberfluessig ist.
Vielen Dank und einen schoenen Tag,
Heinz.
--
E-Mail: Heinz W. Pahlke
"Heinz W. Pahlke"
Hallo, [...]
Und zum Schluss noch ein Auszug aus /var/log/kernel:
Nov 6 22:47:19 localhost kernel: Packet log: rulchain REJECT ippp2 PROTO=6 217. 87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64351 F=0x4000 T=125 SYN (#6) Nov 6 22:47:22 localhost kernel: Packet log: rulchain REJECT ippp2 PROTO=6 217. 87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64577 F=0x4000 T=125 SYN (#6)
Wieder ein Beweis, wie wichtig ein Paketfilter, auch für einen alleinstehenden PC, ist. Ich vermute, die Adresse 217.87.9.21 war die dir dynamisch zugeteilte Adresse, dann lautet die Meldung im Logfile Die Adresse 217.87.25.215 versucht ueber Port 1457 auf dem Device ippp2 zum lokalen http-Server eine aktive Verbindung (das SYN bit)durch das Protokoll TCP (PROTO=6) herzustellen, die Regelkette untersagt diese Verbindung, daher wurde sie zurückgewiesen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
On 07-Nov-2001 Dieter Kluenter wrote:
"Heinz W. Pahlke"
writes: Und zum Schluss noch ein Auszug aus /var/log/kernel:
Nov 6 22:47:19 localhost kernel: Packet log: rulchain REJECT ippp2 PROTO=6 217. 87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64351 F=0x4000 T=125 SYN (#6) Nov 6 22:47:22 localhost kernel: Packet log: rulchain REJECT ippp2 PROTO=6 217. 87.25.215:1457 217.87.9.21:80 L=48 S=0x00 I=64577 F=0x4000 T=125 SYN (#6)
Wieder ein Beweis, wie wichtig ein Paketfilter, auch für einen alleinstehenden PC, ist. Ich vermute, die Adresse 217.87.9.21 war die dir dynamisch zugeteilte Adresse, dann lautet die Meldung im Logfile
Die Adresse 217.87.25.215 versucht ueber Port 1457 auf dem Device ippp2 zum lokalen http-Server eine aktive Verbindung (das SYN bit)durch das Protokoll TCP (PROTO=6) herzustellen, die Regelkette untersagt diese Verbindung, daher wurde sie zurückgewiesen.
Kann es sein, dass es sich um eine Antwort auf eine DNS-Anfrage des
dnrd handelt?
Nachdem ich vorhin frohlockt habe, dass es jetzt liefe, musste ich
inzwischen feststellen, dass offenbar weiter keine Namen aufgeloest
werden koennen. Verbindungen kann ich nur zu Seiten herstellen, fuer
die der dnrd die IP-Nummer im Cache hat, fuer alle anderen sagt
wwwoffle "Cannot open the HTTP connection to www.fvw.de port 80; [Name
Lookup Non-Authoritive Answer Host not found]."
Langsam gewinne ich den Eindruck, dass es wohl doch sinnvoller ist,
sich systematisch selbst an die Paketfilterung ranzutasten anstatt auf
die Personal Firewall von Suse zu setzen.
Beste Gruesse,
Heinz.
--
E-Mail: Heinz W. Pahlke
Hallo Heinz
"Heinz W. Pahlke"
On 07-Nov-2001 Dieter Kluenter wrote:
"Heinz W. Pahlke"
writes: [...] Die Adresse 217.87.25.215 versucht ueber Port 1457 auf dem Device ippp2 zum lokalen http-Server eine aktive Verbindung (das SYN bit)durch das Protokoll TCP (PROTO=6) herzustellen, die Regelkette untersagt diese Verbindung, daher wurde sie zurückgewiesen. Kann es sein, dass es sich um eine Antwort auf eine DNS-Anfrage des dnrd handelt?
Nein, DNS-Antworten wuerden als PROTO=17 (udp)von Port 53 an Port (ueber 1024) gehen.
Nachdem ich vorhin frohlockt habe, dass es jetzt liefe, musste ich inzwischen feststellen, dass offenbar weiter keine Namen aufgeloest werden koennen. Verbindungen kann ich nur zu Seiten herstellen, fuer die der dnrd die IP-Nummer im Cache hat, fuer alle anderen sagt wwwoffle "Cannot open the HTTP connection to www.fvw.de port 80; [Name Lookup Non-Authoritive Answer Host not found]."
Du must schon das Protokoll udp und den Quellport 53 freigeben.
Langsam gewinne ich den Eindruck, dass es wohl doch sinnvoller ist, sich systematisch selbst an die Paketfilterung ranzutasten anstatt auf die Personal Firewall von Suse zu setzen.
die Firewall von SuSE ist schon OK, man muss nur wissen, was man macht. :-) -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo Dieter, On 07-Nov-2001 Dieter Kluenter wrote:
"Heinz W. Pahlke"
writes: On 07-Nov-2001 Dieter Kluenter wrote:
"Heinz W. Pahlke"
writes: [...] Die Adresse 217.87.25.215 versucht ueber Port 1457 auf dem Device ippp2 zum lokalen http-Server eine aktive Verbindung (das SYN bit)durch das Protokoll TCP (PROTO=6) herzustellen, die Regelkette untersagt diese Verbindung, daher wurde sie zurückgewiesen. Kann es sein, dass es sich um eine Antwort auf eine DNS-Anfrage des dnrd handelt?
Nein, DNS-Antworten wuerden als PROTO=17 (udp)von Port 53 an Port (ueber 1024) gehen.
Schade, dann wuesste ich wenigstens ein bisschen mehr.
Nachdem ich vorhin frohlockt habe, dass es jetzt liefe, musste ich inzwischen feststellen, dass offenbar weiter keine Namen aufgeloest werden koennen. Verbindungen kann ich nur zu Seiten herstellen, fuer die der dnrd die IP-Nummer im Cache hat, fuer alle anderen sagt wwwoffle "Cannot open the HTTP connection to www.fvw.de port 80; [Name Lookup Non-Authoritive Answer Host not found]."
Du must schon das Protokoll udp und den Quellport 53 freigeben.
Bloss solche manuellen Eingriffe sieht die Suse-Personal-Firewall nicht vor.
Langsam gewinne ich den Eindruck, dass es wohl doch sinnvoller ist, sich systematisch selbst an die Paketfilterung ranzutasten anstatt auf die Personal Firewall von Suse zu setzen.
die Firewall von SuSE ist schon OK, man muss nur wissen, was man macht. :-)
Warum sollen immer nur andere auf die Marketingsprueche von Suse
hereinfallen?
Irgendwo stand, die Personal Firewall sei die einfachste Methode, einen
Stand-alone-PC gegen alle Zugriffe von draußen abzuschirmen.
Da das natuerlich nur Sinn macht, wenn Mail, Usenet und Internet weiter
funktionieren (wenn ich ohnehin nicht ins Netz will, brauche ich auch
keine Firewall), war ich eben leicht so leichtglaeubig, den Einstieg in
die Paketfilterung von dieser Seite zu versuchen. So nach dem Muster:
Scripte ansehen, Zeile fuer Zeile nach ihrem Sinn untersuchen, eigene
Regeln schreiben.
Aber wenn es so herum nicht funktioniert, muss es eben anders herum
gehen. Zieglers "Linux Firewalls" liegt schon hier, ich muss es nur
noch durcharbeiten.
Beste Gruesse,
Heinz.
--
E-Mail: Heinz W. Pahlke
On Wed, 07 Nov 2001, "Heinz W. Pahlke" wrote:
[...] Nachdem ich vorhin frohlockt habe, dass es jetzt liefe, musste ich inzwischen feststellen, dass offenbar weiter keine Namen aufgeloest werden koennen. Verbindungen kann ich nur zu Seiten herstellen, fuer die der dnrd die IP-Nummer im Cache hat, fuer alle anderen sagt wwwoffle "Cannot open the HTTP connection to www.fvw.de port 80; [Name Lookup Non-Authoritive Answer Host not found]."
Das scheint eher ein Problem mit DNS/wwwoffle zu sein. - Geht die Namensauflösung wenn die firewall deaktiviert ist? - Was ist bei direkter Verbindung ins Netz (rcwwwoffle stop)? - Versuchs ohne dnrp. Trag die dns-ip deines providers direkt in /etc/resolv.conf ein. Falls der Nameserver dynamisch zugeteilt wird, ist ein restart von wwwoffle notwendig (zb. in ip-up.local), weil er den nameserver nur beim start einliest.
Langsam gewinne ich den Eindruck, dass es wohl doch sinnvoller ist, sich systematisch selbst an die Paketfilterung ranzutasten anstatt auf die Personal Firewall von Suse zu setzen.
Die Personal Firewall ist für einen standalone PC, ohne feste IP, der nicht täglich stundenlang im Netz hängt, durchaus brauchbar. Natürlich brauchts für Programme wie zb. speakfreely, eine besser konfigurierbare firewall. Jedenfalls ist es empfehlenswert tiefer in das Thema einzusteigen, und keinem fertigen script blind zu vertrauen. -ron
On Wed, 07 Nov 2001, Rolf Naef wrote:
On Wed, 07 Nov 2001, "Heinz W. Pahlke" wrote:
[...] Lookup Non-Authoritive Answer Host not found]."
Das scheint eher ein Problem mit DNS/wwwoffle zu sein.
- Geht die Namensauflösung wenn die firewall deaktiviert ist? - Was ist bei direkter Verbindung ins Netz (rcwwwoffle stop)?
Direct connection muss natürlich im Browser eingestellt werden, nicht mit "rcwwwoffle stop". -ron
On 07-Nov-2001 Rolf Naef wrote:
Das scheint eher ein Problem mit DNS/wwwoffle zu sein.
DNS ja, wwwoffle nein. Wie in einer anderen Mail geschrieben, fiel das Problem beim Mailen nur nicht auf, weil dnrd dann aus dem Cache aufloest. Ich habe es eben noch einmal getestet. Wenn der dnrd-Cache geleert ist, geht keinerlei Namensaufloesung mehr.
- Versuchs ohne dnrp. Trag die dns-ip deines providers direkt in /etc/resolv.conf ein. Falls der Nameserver dynamisch zugeteilt wird, ist ein restart von wwwoffle notwendig (zb. in ip-up.local), weil er den nameserver nur beim start einliest.
Ist hier leider etwas aufwendiger, weil historisch gewachsen die ganze Waehlerei usw. ueber diverse Scripte geht. Dass das Problem beim DNS liegt, ist eigentlich klar. Ich habe mir deshalb auch schon die Firewall-Scripts angesehen, aber noch steige ich noch nicht so richtig durch. Suse geht ja wohl vom bind aus.
Jedenfalls ist es empfehlenswert tiefer in das Thema einzusteigen, und keinem fertigen script blind zu vertrauen.
Deshalb setze ich heute abend auch hin und fange mal an, mich genauer
mit Paketfilterung zu beschaeftigen. C muss eben erst einmal wieder
warten.
Einen schoenen Abend,
Heinz.
--
E-Mail: Heinz W. Pahlke
participants (3)
-
Dieter Kluenter
-
Heinz W. Pahlke
-
Rolf Naef