Hallo,
vielleicht kann mir jemand weiterhelfen.
In meiner Firma kommen neben einem NT-Fileserver mehrere Windows 98-Clients zum Zuge. Seit einigen Monaten verrichtet Debian-Linux als Firewall in Verbindung mit dem Proxy-Server Squid gute Dienste.
Obwohl die Client-Rechner (Windows 98) mit der IP-Adresse 10.0.0.2 und 10.0.0.242 vollen FTP-Zugriff haben sollten, bekomme ich mit FTP-Programmen wie PSFtp 1.3 Free keine Verbindung zum Webspace-Provider. Benutze ich indes den Windows Commander 5 von Christian Ghisler kann ich zwar Dateien schreiben und überschreiben - löschen von bereits vorhandenen Dateien und Ordner sowie das Neuanlagen von Ordnern scheitert indes. Überdies verweigert mir das Extranet der Jugendsozialarbeit.de den Zugriff mit der Fehlermeldung "Proxy meldet, dass eine nicht autorisierte/unzulässige Verbindungsanfrage gesendet wurde".
Mit "ipchain -L" habe ich mir alle Regeln auflisten lassen und dabei folgendes Ergebnis bekommen:
Chain input (policy ACCEPT):
target prot opt source destination ports
ACCEPT tcp ------ anywhere 213-168-0-0-ppp.noe.estpak.ee/16 any -> ssh
ACCEPT udp ------ anywhere 213-168-0-0-ppp.noe.estpak.ee/16 any -> 1024:65535
ACCEPT tcp ------ anywhere 213-168-0-0-ppp.noe.estpak.ee/16 any -> 1024:65535
ACCEPT tcp ------ anywhere 213-168-0-0-ppp.noe.estpak.ee/16 any -> smtp
ACCEPT icmp ------ anywhere 213-168-0-0-ppp.noe.estpak.ee/16 any -> any
DENY all ----l- anywhere anywhere n/a
Chain forward (policy ACCEPT):
target prot opt source destination ports
MASQ all ------ 10.0.0.242 anywhere n/a
MASQ all ------ 10.0.0.2 anywhere n/a
DENY udp ------ anywhere anywhere any -> any
Chain output (policy ACCEPT):
Auch die Ausgabe, die ich mit "ipchains-save > zu_schreibende_Datei" erhalte, hält nichts Auffälliges bereit:
:input ACCEPT
:forward ACCEPT
:output ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 213.168.0.0/255.255.0.0 22:22 -i ppp0 -p 6 -j ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 213.168.0.0/255.255.0.0 1024:65535 -i ppp0 -p 17 -j ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 213.168.0.0/255.255.0.0 1024:65535 -i ppp0 -p 6 -j ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 213.168.0.0/255.255.0.0 25:25 -i ppp0 -p 6 -j ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 213.168.0.0/255.255.0.0 -i ppp0 -p 1 -j ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ppp0 -j DENY -l
-A forward -s 10.0.0.242/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j MASQ
-A forward -s 10.0.0.2/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j MASQ
-A forward -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -p 17 -j DENY
Ich hoffe, mir kann jemand bei diesem Problem unter die Arme greifen. Denn die Firma, die uns die Firewall einrichtete, scheint auch keine Lösung parat zu haben.
Nur am Rande: Gibt es eine Möglichkeit, ein Skript oder ein Tool zur Formulierung von Firewall-Regeln einzusetzen?
Für Eure Mühe danke ich.
Gruß
-- Gerald Rathjen
Bundesarbeitsgemeinschaft Jugendsozialarbeit e.V.
Gerald Rathjen
Hohe Str. 73
53175 Bonn
Telefon: (0228) 9596819
Email: gerald.rathjen@bagjaw.de
Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
-
ratte
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
*WICHTIG*
Wenn "ipchains -(n)L" auf der maschine, worauf eine *Firma*, wofuer ihr *Geld* bezahlt habt, bzw. auch nur *Vertrauen* entgegenbringt, obiges Ergebnis bringt, dann:
-->> sofort Vertraege kuendigen, mit Androhung auf Schadensersatzklage!!!
Was die da als Packetfilter installiert haben, ist schlimmer als laecherlich, am besten schaltest du sofort offline!!!
Ein kleiner Backenschlag fuer dich selbst auch, falls die IPs echt sind. Jedes script-kiddie kann nun euer Netz untersuchen und einbrechen.
Nochmal, sofort offline gehen, sonst boese Falle!!!
ratte
Wenn "ipchains -(n)L" auf der maschine, worauf eine *Firma*, wofuer ihr *Geld* bezahlt habt, bzw. auch nur *Vertrauen* entgegenbringt, obiges Ergebnis bringt, dann:
-->> sofort Vertraege kuendigen, mit Androhung auf Schadensersatzklage!!!
Was die da als Packetfilter installiert haben, ist schlimmer als laecherlich, am besten schaltest du sofort offline!!!
Ein kleiner Backenschlag fuer dich selbst auch, falls die IPs echt sind. Jedes script-kiddie kann nun euer Netz untersuchen und einbrechen.
Nochmal, sofort offline gehen, sonst boese Falle!!!
ratte
-
Gerald Rathjen
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
Hallo Sascha,
danke für Deine Antwort.
Deinen Rat, sofort Offline zu gehen und die Verträge mit der Firma kündigen, kann ich alleine nicht entscheiden. Nur soviel: auch wenn ich keine Erfahrung mit der Formulierung von ipchains-Regeln unter Debian-Linux habe - auf mich wirkt das Regelwerk nicht durchdacht.
Du verschweigst nur aber, was Dir an dieser Einstellung im Konkreten mißfällt. Ich vermute die Zeilen "A input -s 0.0.0.0/0.0.0.0 ..." und "-A forward -s 10.0.0.242/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j MASQ" nachfolgend!
Was würdest Du mir, außer sofort offline zu gehen, raten? Ich möchte wenigstens herausfinden, welche Regeln die Firma festgelegt bzw. ob sie in irgend einem Startskript weitere Regeln definiert haben. Ändere ich eine Regel und starte den Rechner anschließend neu, existiert die Regel nicht mehr.
Meine Lehre ist - traue nur Dir selbst.
Gruß
-- Gerald Rathjen
danke für Deine Antwort.
Deinen Rat, sofort Offline zu gehen und die Verträge mit der Firma kündigen, kann ich alleine nicht entscheiden. Nur soviel: auch wenn ich keine Erfahrung mit der Formulierung von ipchains-Regeln unter Debian-Linux habe - auf mich wirkt das Regelwerk nicht durchdacht.
Du verschweigst nur aber, was Dir an dieser Einstellung im Konkreten mißfällt. Ich vermute die Zeilen "A input -s 0.0.0.0/0.0.0.0 ..." und "-A forward -s 10.0.0.242/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j MASQ" nachfolgend!
Was würdest Du mir, außer sofort offline zu gehen, raten? Ich möchte wenigstens herausfinden, welche Regeln die Firma festgelegt bzw. ob sie in irgend einem Startskript weitere Regeln definiert haben. Ändere ich eine Regel und starte den Rechner anschließend neu, existiert die Regel nicht mehr.
Meine Lehre ist - traue nur Dir selbst.
Gruß
-- Gerald Rathjen
-
nano
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
Hi Gerald,
die Regeln müssen in irgend einem Startskript stehen.
Schau mal unter /etc/init.d nach ob da sowas wie firewall, filter oder ähnliches zu finden ist.
Eventuell wirst du auch in /etc direkt fündig.
Ipchains wird allgemein durch sukkzessives setzten der einzelnen Regeln über Aufrufe des Kommandos
/sbin/ipchains mit den entsprechenden Parametern konfiguriert.
Das kann man entweder von Hand machen (wenn man unbedingt will <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">) oder man packt alles z.B. in ein Shell-Skript.
Viel Erfolg beim Suchen nach dem Skript,
nano
die Regeln müssen in irgend einem Startskript stehen.
Schau mal unter /etc/init.d nach ob da sowas wie firewall, filter oder ähnliches zu finden ist.
Eventuell wirst du auch in /etc direkt fündig.
Ipchains wird allgemein durch sukkzessives setzten der einzelnen Regeln über Aufrufe des Kommandos
/sbin/ipchains mit den entsprechenden Parametern konfiguriert.
Das kann man entweder von Hand machen (wenn man unbedingt will <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">) oder man packt alles z.B. in ein Shell-Skript.
Viel Erfolg beim Suchen nach dem Skript,
nano
-
nano
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
ach ja,
schau doch mal ob in den log files ein Hinweis zu finden ist.
Gruß,
nano
schau doch mal ob in den log files ein Hinweis zu finden ist.
Gruß,
nano
-
Gerald Rathjen
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
Hi Nano,
vielen Dank für Deinen Hinweis.
Die Suche nach einem firewall- oder filter-Skript blieb ergebnislos. Wenn ich die Log-Datei /var/log/messages in einem Editor betrachte, bekomme ich folgende Anzeige:
....
Jul 18 12:26:32 fw1 kernel: MII transceiver found at address 24, status 782d.
Jul 18 12:26:32 fw1 kernel: Enabling bus-master transmits and whole-frame receives.
Jul 18 12:26:32 fw1 kernel: eth0: Initial media type Autonegotiate.
Jul 18 12:26:32 fw1 kernel: eth0: MII #24 status 786d, link partner capability 45e1, setting full-duplex.
Jul 18 12:26:32 fw1 kernel: eth1: Initial media type Autonegotiate.
Jul 18 12:26:32 fw1 kernel: eth1: MII #24 status 782d, link partner capability 0021, setting half-duplex.
Jul 18 12:26:32 fw1 kernel: CSLIP: code copyright 1989 Regents of the University of California
Jul 18 12:26:32 fw1 kernel: PPP: version 2.3.7 (demand dialling)
Jul 18 12:26:32 fw1 kernel: PPP line discipline registered.
Jul 18 12:26:32 fw1 kernel: registered device ppp0
Jul 18 12:26:32 fw1 pppd[164]: pppd 2.4.1 started by root, uid 0
Jul 18 12:26:32 fw1 pppd[164]: Serial connection established.
Jul 18 12:26:32 fw1 pppd[164]: Using interface ppp0
Jul 18 12:26:32 fw1 pppd[164]: Connect: ppp0 <--> /dev/pts/0
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: ez-ipupdate Version 3.0.11b5, Copyright (C) 1998-2001 Angus Mackay.
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: /usr/sbin/ez-ipupdate started for interface ppp0 host fw-bagjaw.dyndns.org using server members.dyndns.org and service dyndns
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: (fw-bagjaw.dyndns.org) unable to resolve interface ppp0
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: ez-ipupdate Version 3.0.11b5, Copyright (C) 1998-2001 Angus Mackay.
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: /usr/sbin/ez-ipupdate started for interface ppp0 host fw-bagjaw.dyndns.org using server members.dyndns.org and service dyndns
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: (fw-bagjaw.dyndns.org) unable to resolve interface ppp0
Jul 18 12:26:34 fw1 kernel: device ppp0 entered promiscuous mode
Jul 18 12:26:37 fw1 kernel: device ppp0 left promiscuous mode
Jul 18 12:26:38 fw1 squid[202]: Squid Parent: child process 205 started
Jul 18 12:26:39 fw1 kernel: PPP BSD Compression module registered
Jul 18 12:26:39 fw1 kernel: PPP Deflate Compression module registered
Jul 18 12:26:40 fw1 pppd[164]: local IP address 195.14.201.213
Jul 18 12:26:40 fw1 pppd[164]: remote IP address 195.14.200.1
Jul 18 12:27:04 fw1 /usr/sbin/ez-ipupdate[178]: successful update for ppp0->195.14.201.213 (fw-bagjaw.dyndns.org)
Jul 18 12:27:07 fw1 /usr/sbin/ez-ipupdate[176]: members.dyndns.org says that your IP address has not changed since the last update
Jul 18 12:27:07 fw1 /usr/sbin/ez-ipupdate[176]: successful update for ppp0->195.14.201.213 (fw-bagjaw.dyndns.org)
Jul 18 12:28:02 fw1 mc: /dev/gpmctl: Connection refused
Jul 18 12:28:50 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56728 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:54 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56729 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:55 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=40 S=0x00 I=56730 F=0x4000 T=61 (#6)
Jul 18 12:34:13 fw1 mc: /dev/gpmctl: Connection refused
Jul 18 12:35:38 fw1 mc: /dev/gpmctl: Connection refused
Aus diesen Zeilen zu entnehmen, welches Skript die Firewall-Regeln initialisiert, ist mir nicht möglich. Vielleicht hast Du oder ein anderer eine Idee. In den Verzeichnissen /etc/rc.d oder /etc exisitert keine Datei mit den Bezeichnungen "filter" oder "firewall". Mit Midnight Commander durforschte ich die gesamte root- und usr-Partition nach Dateien, die ipchains-Regeln beinhalten könnten. Die Suche blieb aber ergebnislos!
Für Eure Hilfe bin ich dankbar und wünsche Euch viel Spass mit Linux.
Gruß
-- Gerald Rathjen
vielen Dank für Deinen Hinweis.
Die Suche nach einem firewall- oder filter-Skript blieb ergebnislos. Wenn ich die Log-Datei /var/log/messages in einem Editor betrachte, bekomme ich folgende Anzeige:
....
Jul 18 12:26:32 fw1 kernel: MII transceiver found at address 24, status 782d.
Jul 18 12:26:32 fw1 kernel: Enabling bus-master transmits and whole-frame receives.
Jul 18 12:26:32 fw1 kernel: eth0: Initial media type Autonegotiate.
Jul 18 12:26:32 fw1 kernel: eth0: MII #24 status 786d, link partner capability 45e1, setting full-duplex.
Jul 18 12:26:32 fw1 kernel: eth1: Initial media type Autonegotiate.
Jul 18 12:26:32 fw1 kernel: eth1: MII #24 status 782d, link partner capability 0021, setting half-duplex.
Jul 18 12:26:32 fw1 kernel: CSLIP: code copyright 1989 Regents of the University of California
Jul 18 12:26:32 fw1 kernel: PPP: version 2.3.7 (demand dialling)
Jul 18 12:26:32 fw1 kernel: PPP line discipline registered.
Jul 18 12:26:32 fw1 kernel: registered device ppp0
Jul 18 12:26:32 fw1 pppd[164]: pppd 2.4.1 started by root, uid 0
Jul 18 12:26:32 fw1 pppd[164]: Serial connection established.
Jul 18 12:26:32 fw1 pppd[164]: Using interface ppp0
Jul 18 12:26:32 fw1 pppd[164]: Connect: ppp0 <--> /dev/pts/0
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: ez-ipupdate Version 3.0.11b5, Copyright (C) 1998-2001 Angus Mackay.
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: /usr/sbin/ez-ipupdate started for interface ppp0 host fw-bagjaw.dyndns.org using server members.dyndns.org and service dyndns
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[176]: (fw-bagjaw.dyndns.org) unable to resolve interface ppp0
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: ez-ipupdate Version 3.0.11b5, Copyright (C) 1998-2001 Angus Mackay.
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: /usr/sbin/ez-ipupdate started for interface ppp0 host fw-bagjaw.dyndns.org using server members.dyndns.org and service dyndns
Jul 18 12:26:33 fw1 /usr/sbin/ez-ipupdate[178]: (fw-bagjaw.dyndns.org) unable to resolve interface ppp0
Jul 18 12:26:34 fw1 kernel: device ppp0 entered promiscuous mode
Jul 18 12:26:37 fw1 kernel: device ppp0 left promiscuous mode
Jul 18 12:26:38 fw1 squid[202]: Squid Parent: child process 205 started
Jul 18 12:26:39 fw1 kernel: PPP BSD Compression module registered
Jul 18 12:26:39 fw1 kernel: PPP Deflate Compression module registered
Jul 18 12:26:40 fw1 pppd[164]: local IP address 195.14.201.213
Jul 18 12:26:40 fw1 pppd[164]: remote IP address 195.14.200.1
Jul 18 12:27:04 fw1 /usr/sbin/ez-ipupdate[178]: successful update for ppp0->195.14.201.213 (fw-bagjaw.dyndns.org)
Jul 18 12:27:07 fw1 /usr/sbin/ez-ipupdate[176]: members.dyndns.org says that your IP address has not changed since the last update
Jul 18 12:27:07 fw1 /usr/sbin/ez-ipupdate[176]: successful update for ppp0->195.14.201.213 (fw-bagjaw.dyndns.org)
Jul 18 12:28:02 fw1 mc: /dev/gpmctl: Connection refused
Jul 18 12:28:50 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56728 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:54 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56729 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:55 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=40 S=0x00 I=56730 F=0x4000 T=61 (#6)
Jul 18 12:34:13 fw1 mc: /dev/gpmctl: Connection refused
Jul 18 12:35:38 fw1 mc: /dev/gpmctl: Connection refused
Aus diesen Zeilen zu entnehmen, welches Skript die Firewall-Regeln initialisiert, ist mir nicht möglich. Vielleicht hast Du oder ein anderer eine Idee. In den Verzeichnissen /etc/rc.d oder /etc exisitert keine Datei mit den Bezeichnungen "filter" oder "firewall". Mit Midnight Commander durforschte ich die gesamte root- und usr-Partition nach Dateien, die ipchains-Regeln beinhalten könnten. Die Suche blieb aber ergebnislos!
Für Eure Hilfe bin ich dankbar und wünsche Euch viel Spass mit Linux.
Gruß
-- Gerald Rathjen
-
nano
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
Hi,
möglicherweise ist das das Problem:
Jul 18 12:28:50 fw1 kernel: Packet log: input <b>DENY</b> ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:<b>113</b> L=48 S=0x00 I=56728 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:54 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56729 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:55 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=40 S=0x00 I=56730 F=0x4000 T=61 (#6)
Mein Paketfilter läßt Anfragen an Port 113 durch.
Dieser Port ist für den Dienst auth reserviert (-> /etc/services), über den der FTP-Server versucht die Anfrage zu autentifizieren.
Bei mir läuft der Dienst nicht, daß heißt die Anfrage des Servers läut ins Leere, und erbekommt als Antwort, daß er auf keine Reaktion warten soll. Wird die Anfrage aber geblockt, so weiß der Server nicht, daß keine Antwort kommen wird und er wartet ... bis er möglicherweise die Verbindung einfach abbricht.
Anstelle die Pakete passieren zu lassen, kannst du auch mal versuchen, sie zu rejecten. Möglicherweise klappt das auch.
Aprospos Skript: wurde die Firewall bei euch einmal eingerichtet und der Rechner seither nicht mehr gebootet (ist natürlich eigentlich der Idealzustand <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">). Dann haben die die Regeln tatsächlich nacheinander von Hand eingetippt?
Du kannst aber die Ausgabe von ipchains-save (kannte ich gar nicht! wieder was gelernt <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">) in ein Skript umwandeln, daß genau den momentanen Zustand wieder herstellt.
Viel Erfolg,
nano
möglicherweise ist das das Problem:
Jul 18 12:28:50 fw1 kernel: Packet log: input <b>DENY</b> ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:<b>113</b> L=48 S=0x00 I=56728 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:54 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=48 S=0x00 I=56729 F=0x4000 T=61 SYN (#6)
Jul 18 12:28:55 fw1 kernel: Packet log: input DENY ppp0 PROTO=6 194.8.194.112:35829 195.14.201.213:113 L=40 S=0x00 I=56730 F=0x4000 T=61 (#6)
Mein Paketfilter läßt Anfragen an Port 113 durch.
Dieser Port ist für den Dienst auth reserviert (-> /etc/services), über den der FTP-Server versucht die Anfrage zu autentifizieren.
Bei mir läuft der Dienst nicht, daß heißt die Anfrage des Servers läut ins Leere, und erbekommt als Antwort, daß er auf keine Reaktion warten soll. Wird die Anfrage aber geblockt, so weiß der Server nicht, daß keine Antwort kommen wird und er wartet ... bis er möglicherweise die Verbindung einfach abbricht.
Anstelle die Pakete passieren zu lassen, kannst du auch mal versuchen, sie zu rejecten. Möglicherweise klappt das auch.
Aprospos Skript: wurde die Firewall bei euch einmal eingerichtet und der Rechner seither nicht mehr gebootet (ist natürlich eigentlich der Idealzustand <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">). Dann haben die die Regeln tatsächlich nacheinander von Hand eingetippt?
Du kannst aber die Ausgabe von ipchains-save (kannte ich gar nicht! wieder was gelernt <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">) in ein Skript umwandeln, daß genau den momentanen Zustand wieder herstellt.
Viel Erfolg,
nano
-
ratte
Re: Mit bestehenden ipchain-Regeln kein Zugriff auf entfernte FTP-Server
Hi,
gestern war schon spät, nun zu den Einzelheiten.
die ipchains rules sind keine firewall, sondern enablen lediglich
- input connect fuer ssh, hohe ports und mail versenden fuer das lockele netz 213.168.0.0/16 von ueberall
- Network Address Translation
einzige Einrichtung von Sicherheit sind die verbleibenden deny rules, jedoch gibt es keine Kontrolle darueber, welche Protokolle erlaubt sind und welche nicht.
AFAIK ist das input rule set unvollstaendig, schliesslich gibt es keinen dazugehoerigen ruleset fuer output. Vermutlich sind die policies fuer input, forward und deny alle auf ACCEEPT gesetzt.
Zwar bin ich auch kein Fachmann, aber soviel kann ich schon dazu sagen:
Diese rules dienen zum Online gehen fuer die Rechner im lokalen Netz, die diesen Rechner als gateway eingetragen haben. Ausserdem darf jeder ssh logins versuchen, mail versenden versuchen, die gesamten hohen ports scannen fuer alle Rechner des Netzes 213.168.0.0/16 und böse dinge damit tun...
Das ist bestimmt nicht das, was deine Firma will, oder?
Auf jeden Fall muss eine fremde Firewall eingekauft werden, oder ein Admin dafuer eingestellt oder fortgebildet werden.
Nun zu deinem eigentlichen Problem.
Die beiden Rechner, die ftp mit dem einen oder anderen Programm betreiben wollen, werden vollstaendig maskiert, alle Ports sind erlaubt und werden weitergereicht. Deshalb ist mir nicht ersichtlich woran es hapert.
Da hilft nur das logfile beobachten:
mach mal ein `tail -f /var/log/messages /var/log/syslog > filename` wenn einer auf Ansage die ftp Programme ausfuehrt.
Sollte der gateway Ports sprerren, findest du kernel messages diesbezueglich.
um das verantwortliche Script zu lokalisieren, wuerde ich alle Verzeichnisse unterhalb von / ausser /dev und /proc mit `grep -ril ipchains` durchsuchen und in ein file schreiben. Das ist zwar wenig intelligent, strengt filesystem und CPU sehr an, aber schadet auch nicht. Also zb. `grep -ril ipchains /etc >> filename` usw.
Wenn die Liste komplett ist, kannst du vermutlich das gesuchte File am Namen erkennen, sonst musst du dir alle Treffer mal ansehen.
ratte
gestern war schon spät, nun zu den Einzelheiten.
die ipchains rules sind keine firewall, sondern enablen lediglich
- input connect fuer ssh, hohe ports und mail versenden fuer das lockele netz 213.168.0.0/16 von ueberall
- Network Address Translation
einzige Einrichtung von Sicherheit sind die verbleibenden deny rules, jedoch gibt es keine Kontrolle darueber, welche Protokolle erlaubt sind und welche nicht.
AFAIK ist das input rule set unvollstaendig, schliesslich gibt es keinen dazugehoerigen ruleset fuer output. Vermutlich sind die policies fuer input, forward und deny alle auf ACCEEPT gesetzt.
Zwar bin ich auch kein Fachmann, aber soviel kann ich schon dazu sagen:
Diese rules dienen zum Online gehen fuer die Rechner im lokalen Netz, die diesen Rechner als gateway eingetragen haben. Ausserdem darf jeder ssh logins versuchen, mail versenden versuchen, die gesamten hohen ports scannen fuer alle Rechner des Netzes 213.168.0.0/16 und böse dinge damit tun...
Das ist bestimmt nicht das, was deine Firma will, oder?
Auf jeden Fall muss eine fremde Firewall eingekauft werden, oder ein Admin dafuer eingestellt oder fortgebildet werden.
Nun zu deinem eigentlichen Problem.
Die beiden Rechner, die ftp mit dem einen oder anderen Programm betreiben wollen, werden vollstaendig maskiert, alle Ports sind erlaubt und werden weitergereicht. Deshalb ist mir nicht ersichtlich woran es hapert.
Da hilft nur das logfile beobachten:
mach mal ein `tail -f /var/log/messages /var/log/syslog > filename` wenn einer auf Ansage die ftp Programme ausfuehrt.
Sollte der gateway Ports sprerren, findest du kernel messages diesbezueglich.
um das verantwortliche Script zu lokalisieren, wuerde ich alle Verzeichnisse unterhalb von / ausser /dev und /proc mit `grep -ril ipchains` durchsuchen und in ein file schreiben. Das ist zwar wenig intelligent, strengt filesystem und CPU sehr an, aber schadet auch nicht. Also zb. `grep -ril ipchains /etc >> filename` usw.
Wenn die Liste komplett ist, kannst du vermutlich das gesuchte File am Namen erkennen, sonst musst du dir alle Treffer mal ansehen.
ratte