Moin.
Ich bin immer noch bei dem Problem mit dem Nutzen von FTP.
Das Szenario sieht wie folgt aus: Ein Rechnerpool soll Zugriff auf's I-Net kriegen, allerdings nur die Dienste DNS,HTTP,HTTPS und FTP(passive) nutzen können. Auf dem Gateway möchte ich noch eine Reihe weiterer Dienste (Mail, ICQ, usw.)haben, die von diesem Rechner aus für den daran Arbeitenden nutzbar sind.
Ich habe folgende Regeln jetzt drin:
$IPT -A INPUT -p tcp -i eth0 --sport 21 --dport 1024: ! --syn -j ACCEPT $IPT -A OUTPUT -p tcp -o eth0 --sport 1024: -j ACCEPT
$IPT -A INPUT -p tcp -i eth0 --sport 1024: --dport 1024: ! --syn -j\ ACCEPT $IPT -A OUTPUT -p tcp -o eth0 --sport 1024: --dport 1024: -j ACCEPT
Soweit so gut. Nur werden dann z.B. solche Regeln obsolete, die den Login beim ICQ-Server (Port 5190) explizit regeln. Diese Regeln kann ich mir dann sparen. :-( Wie kann man das Lösen?
Ich habe gedacht, daß mir da das stateful filtering weiterhilft. Also habe ich eine "states"-Chain erstellt, in welche gleich am Anfang von INPUT und FORWARD aus verzweigt wird.
$IPT -A states -m state --state ESTABLISHED,RELATED -j RETURN $IPT -A states -m state --state NEW,INVALED -j LOG $IPT -A states -m state --state NEW,INVALED -j REJECT --reject-with\ tcp-reset
Danach geht aber gar nichts mehr. :-(
Carsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi | Ich habe gedacht, daß mir da das stateful filtering weiterhilft. Also | habe ich eine "states"-Chain erstellt, in welche gleich am Anfang von | INPUT und FORWARD aus verzweigt wird. | | $IPT -A states -m state --state ESTABLISHED,RELATED -j RETURN | $IPT -A states -m state --state NEW,INVALED -j LOG | $IPT -A states -m state --state NEW,INVALED -j REJECT --reject-with\ | tcp-reset
es gibt keinen Zustand INVALED das muss INVALID heissen.
Mfg Sven
- -- Sven Klemm sven@elektro-klemm.de GnuPG: 0x71084F86 | 1319 F0DF B317 91F0 E48E 1957 7AF9 604C 7108 4F86
Sven Klemm wrote:
es gibt keinen Zustand INVALED das muss INVALID heissen.
Hab's korrigiert, funktioniert aber nach wie vor nicht.
Carsten
Carsten Friede wrote:
Hallo,
Das Szenario sieht wie folgt aus: Ein Rechnerpool soll Zugriff auf's I-Net kriegen, allerdings nur die Dienste DNS,HTTP,HTTPS und FTP(passive) nutzen können. Auf dem Gateway möchte ich noch eine Reihe
weiterer Dienste (Mail, ICQ, usw.)haben, die von diesem Rechner aus für den daran Arbeitenden nutzbar sind.
Was spricht eigentlich dagegen, auf der Kiste Proxy-Server für alles zu installieren? ICQ läuft über HTTP-Proxy, FTP-Downloads sollten die meisten Proxies auch beherrschen.
Mail könntest du auch über ein Portforwarding auf einzelne Mailserver realisieren (wenn die Nutzer sowieso nur drei, vier Mailserver nutzen).
Soweit so gut. Nur werden dann z.B. solche Regeln obsolete, die den Login beim ICQ-Server (Port 5190) explizit regeln. Diese Regeln kann ich mir dann sparen. :-( Wie kann man das Lösen?
Kein Ahnung, aber zu ICQ selbst:
client --( ich will login )--> icq-login-server <--( name & passwd? )-- --( name & passwd: )--> <--( ok, korrekt. )-- ( deine Session ) ( wartet auf ) ( m1231icq.com ) ( auf dich )
client --( will session )--> m1231.icq.com ...
Wenn du es per Firewall regeln willst, dann musst du auch Verbindungen auf ne Menge anderer Kisten *.icq.com oder *.mirabilis.com ermöglichen, nicht nur login.icq.com .
mfg, Fabian
Fabian Hänsel wrote:
Was spricht eigentlich dagegen, auf der Kiste Proxy-Server für alles zu installieren? ICQ läuft über HTTP-Proxy, FTP-Downloads sollten die meisten Proxies auch beherrschen.
Performance ;-) Die Hütte ist schon so nicht die Schnellste, da habe ich keine Lust mir noch so 'ne Bremse einzubauen.
Mail könntest du auch über ein Portforwarding auf einzelne Mailserver realisieren (wenn die Nutzer sowieso nur drei, vier Mailserver nutzen).
Mail ist nur für mich auf der Kiste. :-) Ich habe nur einen Account, denn ich von da aus abrufe.
Kein Ahnung, aber zu ICQ selbst:
client --( ich will login )--> icq-login-server <--( name & passwd? )-- --( name & passwd: )--> <--( ok, korrekt. )-- ( deine Session ) ( wartet auf ) ( m1231icq.com ) ( auf dich )
client --( will session )--> m1231.icq.com ...
Wenn du es per Firewall regeln willst, dann musst du auch Verbindungen auf ne Menge anderer Kisten *.icq.com oder *.mirabilis.com ermöglichen, nicht nur login.icq.com .
Das geht schon so. Ich verbiete im Client direkte Verbindungen, und lasse alles über den Server laufen (Port 5190) das habe ih schon getestet. Nur, wie schon gesagt, sobal ich passives FTP habe, kann ich mir den Krempel sparen.
Carsten
On Sat, Jun 05, 2004 at 03:01:39PM +0200, Carsten Friede wrote:
Fabian Hänsel wrote:
Was spricht eigentlich dagegen, auf der Kiste Proxy-Server für alles zu installieren? ICQ läuft über HTTP-Proxy, FTP-Downloads sollten die meisten Proxies auch beherrschen.
Performance ;-) Die Hütte ist schon so nicht die Schnellste, da habe ich keine Lust mir noch so 'ne Bremse einzubauen.
Daß Proxy-Server bremsen müssen, ist eine urban legend. Wenn du nicht gerade mit >100MBit am Internet angebunden bist, dann bringen zumindest webcaches typischerweise Geschwindigkeitsvorteile.
Wenn du es per Firewall regeln willst, dann musst du auch Verbindungen auf ne Menge anderer Kisten *.icq.com oder *.mirabilis.com ermöglichen, nicht nur login.icq.com .
Das geht schon so. Ich verbiete im Client direkte Verbindungen, und lasse alles über den Server laufen (Port 5190) das habe ih schon getestet. Nur, wie schon gesagt, sobal ich passives FTP habe, kann ich mir den Krempel sparen.
Ja. Oder du nimmst einfach einen ftp proxy. FTP ist mist, ein Proxy ist die einzig vernünftige Möglichkeit, um das zu firewallen.
am Sat, dem 05.06.2004, um 14:00:53 +0200 mailte Carsten Friede folgendes:
Ich habe gedacht, daß mir da das stateful filtering weiterhilft. Also habe ich eine "states"-Chain erstellt, in welche gleich am Anfang von INPUT und FORWARD aus verzweigt wird.
$IPT -A states -m state --state ESTABLISHED,RELATED -j RETURN
Warum RETURN? Tausch das mal gegen ACCEPT.
Für ftp gibt es Helper-Module, sind die geladen? Für Conn-tracking brauchst Du auch ein Modul, damit es geht.
Andreas
Andreas Kretschmer wrote:
$IPT -A states -m state --state ESTABLISHED,RELATED -j RETURN
Warum RETURN? Tausch das mal gegen ACCEPT.
Das RETURN sagt, daß das Paket, weil es ja gültig ist wieder zurück in die INPUT-Chain geht und dort mit den vorhandenen Regeln verglichen wird.
Für ftp gibt es Helper-Module, sind die geladen? Für Conn-tracking brauchst Du auch ein Modul, damit es geht.
Okay. Was machen diese Module? Machen sie es möglich, das die high-port Verbindung nur dann gemacht wird, wenn schon der Kontrollkanal aufgebaut wurde? Denn dann und nur dann sollen die hohen Ports offen sein. Ansonsten soll Sense sein, und nur die Dienste auf den hohen Ports operieren, die explizit gestattet sind.
Carsten
am Sat, dem 05.06.2004, um 14:54:56 +0200 mailte Carsten Friede folgendes:
Andreas Kretschmer wrote:
$IPT -A states -m state --state ESTABLISHED,RELATED -j RETURN
Warum RETURN? Tausch das mal gegen ACCEPT.
Das RETURN sagt, daß das Paket, weil es ja gültig ist wieder zurück in die INPUT-Chain geht und dort mit den vorhandenen Regeln verglichen wird.
Schon klar, aber es gehört ja ganz offensichtlich zu einer gewollten Verbindung. Schon deswegen sehe ich keine Notwendigkeit, es noch irgendwie weiter zu untersuchen. Oder?
Für ftp gibt es Helper-Module, sind die geladen? Für Conn-tracking brauchst Du auch ein Modul, damit es geht.
Okay. Was machen diese Module? Machen sie es möglich, das die high-port Verbindung nur dann gemacht wird, wenn schon der Kontrollkanal aufgebaut wurde?
Ja.
Denn dann und nur dann sollen die hohen Ports offen sein. Ansonsten soll Sense sein, und nur die Dienste auf den hohen Ports operieren, die explizit gestattet sind.
Das FTP-Modul schnüffelt den Kommandokanal mit und weiß so, welche Ports mit genutzt werden. Ich kann auf Arbeit an einem genatten Rechner sowohl passives als auch aktives FTP machen. Dazu sind auf dem Gateway 3 Module geladen, ich schrieb das aber IMHO auch schon mal in dieser Liste.
Andreas
Andreas Kretschmer wrote:
Denn dann und nur dann sollen die hohen Ports offen sein. Ansonsten soll Sense sein, und nur die Dienste auf den hohen Ports operieren, die explizit gestattet sind.
Das FTP-Modul schnüffelt den Kommandokanal mit und weiß so, welche Ports mit genutzt werden. Ich kann auf Arbeit an einem genatten Rechner sowohl passives als auch aktives FTP machen. Dazu sind auf dem Gateway 3 Module geladen, ich schrieb das aber IMHO auch schon mal in dieser Liste.
Ja, das hattest du. Mich würde aber interessieren, welche Regeln du für das FTP in welchen Chains verwendest.
Carsten
Carsten Friede schrieb:
Andreas Kretschmer wrote:
Denn dann und nur dann sollen die hohen Ports offen sein. Ansonsten soll Sense sein, und nur die Dienste auf den hohen Ports operieren, die explizit gestattet sind.
Das FTP-Modul schnüffelt den Kommandokanal mit und weiß so, welche Ports mit genutzt werden. Ich kann auf Arbeit an einem genatten Rechner sowohl passives als auch aktives FTP machen. Dazu sind auf dem Gateway 3 Module geladen, ich schrieb das aber IMHO auch schon mal in dieser Liste.
Ja, das hattest du. Mich würde aber interessieren, welche Regeln du für das FTP in welchen Chains verwendest.
Reicht es nicht aus, in der "nat" Tabelle in der chain POSTROUTING einfach den Port 21 zu mit dem Ziel SNAT bzw. MASQUERADE einzufuegen? IMHO kuemmern sich dann ip_nat_ftp (und ip_conntrack_ftp, falls stateful filtering benutzt wird) um das Masquerading der DATA Verbindung. Danach sollte eigentlich nur die FORWARD Chain ggf praepariert werden um beidseitige Verbindung fuer Zielports 21 und 1024+ zu erlauben.
-Dimitri
Dimitri Puzin wrote:
Reicht es nicht aus, in der "nat" Tabelle in der chain POSTROUTING einfach den Port 21 zu mit dem Ziel SNAT bzw. MASQUERADE einzufuegen? IMHO kuemmern sich dann ip_nat_ftp (und ip_conntrack_ftp, falls stateful filtering benutzt wird) um das Masquerading der DATA Verbindung. Danach sollte eigentlich nur die FORWARD Chain ggf praepariert werden um beidseitige Verbindung fuer Zielports 21 und 1024+ zu erlauben.
Okay, mal einen Gang zurück. Erstmal nur so, daß für einen Rechner (Firewall) selbst FTP(passiv) verfügbar sein soll. Mit dem stateful filtering läuft das soweit auch, bis auf die Tatsache. daß ich damit ICQ "inklusive" kriege. Das kotzt mich ehrlich gesagt an. Wenn ich sage, daß ich hohe Ports von meinem Rechner zu anderen Rechnern erlaube, dabei SYN blocke kann ich passives FTP machen und gleichzeitig auch ICQ. Nur ist das Mist, wenn ich nur eins von beiden, nämlich FTP, dauerhaft und ICQ nur dann freigeschaltet, wenn ich das sage und danach den Client starte. Ich hatte mir schon überlegt die Sache an die IPs der ICQ-Server zu binden. Aber das war auch nicht erfolgreich.
Was ich mit dem stateful filtering will, ist das nach einem connect auf einen entfernten Port 21 die Datenverbindung selber kommt. Wenn ich aber in die INPUT-Chain bzw. OUTPUT-Chain reinschreiben muß "Erlaube alles von hohen Ports ohne SYN-Bit zu den lokalen hohen Ports.", dann ist das für'n Eimer, denn dann mache ich ja auch den Weg frei für andere Dienste, die ich gar nicht will.
Ich will explizit anweisen "Wenn jetzt FTP auf 21, dann mach' zu dieser, und nur dieser IP auch eine Verbindung von und zu hohen Ports. Ansonsten nicht! Und wenn ich ICQ haben will, dann mach' solch eine Verbindung nur zu den ICQ-Servern. Ende."
So ungefähr stelle ich mir das vor.
Carsten
Hi Carsten,
ich gehe jetzt mal davon aus, dass Du NAT machen willst. Dazu habe ich folgende Konfig:
# Dieses erlaubt eingehende Verbindungen, aber nur wenn diese zu einer bereits hergestellen Verbundung von LOKAL (also mein Router) gehoeren. iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -m state --state RELATED,ESTABLISHED -j ACCEPT
# Diese erlauben Masquerading von Ports 21 und 5190 (ICQ) aus meinem Netz ueber diesen Router. Du kannst weitere, DNS, HTTP(S) hier hinzufuegen. iptables -t nat -A POSTROUTING -s $MYNETWORK -d $ALL -o $EXT_IFACE -p tcp -m tcp --dport 21 -j MASQUERADE iptables -t nat -A POSTROUTING -s $MYNETWORK -d $ALL -o $EXT_IFACE -p tcp -m tcp --dport 5190 -j MASQUERADE
# Alle anderen Chains sind ACCEPT und leer, im einfachsten Fall. ip_nat_ftp und ip_conntrack_ftp sind geladen.
Ist das Deine Wunschkonfig?
-Dimitri
Dimitri Puzin wrote:
Hi Carsten,
ich gehe jetzt mal davon aus, dass Du NAT machen willst. Dazu habe ich folgende Konfig:
# Dieses erlaubt eingehende Verbindungen, aber nur wenn diese zu einer bereits hergestellen Verbundung von LOKAL (also mein Router) gehoeren. iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -m state --state RELATED,ESTABLISHED -j ACCEPT
# Diese erlauben Masquerading von Ports 21 und 5190 (ICQ) aus meinem Netz ueber diesen Router. Du kannst weitere, DNS, HTTP(S) hier hinzufuegen. iptables -t nat -A POSTROUTING -s $MYNETWORK -d $ALL -o $EXT_IFACE -p tcp -m tcp --dport 21 -j MASQUERADE iptables -t nat -A POSTROUTING -s $MYNETWORK -d $ALL -o $EXT_IFACE -p tcp -m tcp --dport 5190 -j MASQUERADE
# Alle anderen Chains sind ACCEPT und leer, im einfachsten Fall. ip_nat_ftp und ip_conntrack_ftp sind geladen.
Ist das Deine Wunschkonfig?
Naja, nicht so ganz. Aber ich habe mich jetzt die Sache mit dem FTP-Proxy angesehen. Das scheint ganz gut zu sein. ICQ ist zwar bockig, habe das jetzt aber per Schalter für das Skript gelöst. Das Problem bei ICQ ist weniger das Einloggen, als vielmehr das Holen der Session. Der Login-Server schickt irgendwann sein FIN und schließt die Verbindung, und danach, müßte theoretisch Verbindung zum Session-Server auf einem hohen Port aufgenommen werden. Wie gesagt, ich schalte jetzt dieses Feature bei Bedarf über eine Option des Skriptes zu.
Carsten
Carsten Friede schrieb:
Dimitri Puzin wrote:
Ist das Deine Wunschkonfig?
Naja, nicht so ganz. Aber ich habe mich jetzt die Sache mit dem FTP-Proxy angesehen. Das scheint ganz gut zu sein. ICQ ist zwar bockig, habe das jetzt aber per Schalter für das Skript gelöst. Das Problem bei ICQ ist weniger das Einloggen, als vielmehr das Holen der Session. Der Login-Server schickt irgendwann sein FIN und schließt die Verbindung, und danach, müßte theoretisch Verbindung zum Session-Server auf einem hohen Port aufgenommen werden. Wie gesagt, ich schalte jetzt dieses Feature bei Bedarf über eine Option des Skriptes zu.
Also ich habe Socks 5 Proxy laufen (Debian Package: dante-server). Das funkt super mit ICQ und FTP (Hauptsaechlich wegen Website Uploads) laesst sich damit auch realisieren. Unter M$ habe ich WS FTP Pro 7. Ich verwende cachenden DNS Server und auch E-Mail wird durch diese Box gesendet/empfangen. Dann noch Squid Proxy fuer HTTP(S) und einfaches FTP (Downloads von den FTP Servern im Internet). Da enfallen die Regeln in der NAT Tabelle bei mir komplett. Ausserdem unterstuetzen viele Anwendungen einen Socks Proxy.
-Dimitri
Dimitri Puzin wrote:
Also ich habe Socks 5 Proxy laufen (Debian Package: dante-server). Das funkt super mit ICQ und FTP (Hauptsaechlich wegen Website Uploads) laesst sich damit auch realisieren. Unter M$ habe ich WS FTP Pro 7. Ich verwende cachenden DNS Server und auch E-Mail wird durch diese Box gesendet/empfangen. Dann noch Squid Proxy fuer HTTP(S) und einfaches FTP (Downloads von den FTP Servern im Internet). Da enfallen die Regeln in der NAT Tabelle bei mir komplett. Ausserdem unterstuetzen viele Anwendungen einen Socks Proxy.
Wie firewallst Du dann den SOCKS-Server? Wie sehen die Regeln dazu aus(speziell ICQ und FTP)? Daß man dann kein NAT mehr braucht, ist schon ganz gut, dadurch vereinfacht sich vieles.
Carsten
Carsten Friede schrieb:
Dimitri Puzin wrote:
Also ich habe Socks 5 Proxy laufen [...]
Wie firewallst Du dann den SOCKS-Server? Wie sehen die Regeln dazu aus(speziell ICQ und FTP)? Daß man dann kein NAT mehr braucht, ist schon ganz gut, dadurch vereinfacht sich vieles.
Also, der SOCKS-Server ist ein lokales Prozess, weshalb nur die INPUT und OUTPUT Ketten relevant sind. Ich verbiete alles in der INPUT Kette, was vom externen Interface kommt. Nur ESTABLISHED, RELATED Pakete sind erlaubt, da keiner zu meinem SOCKS Server eine Verbindung aufbauen soll. OUTPUT Kette ist ACCEPT und leer, da hier nur lokal generierte Pakete durchgehen. FORWARD ist ebenfalls ACCEPT und leer. Die ist nicht relevant, da kein Routing stattfindet. Das ist alles, was NETFILTER betrifft. Der Rest erfolgt in der Konfiguration in der danted.conf.
Hier mein Regelsatz: # Antworten auf ICMP erlauben iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p icmp -m icmp -j ACCEPT # IDENT Anfragen von IRC et al abweisen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable # eingehende Pkt erlauben, die zu lokal aufgebauten Verbindungen gehoeren iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -m state --state RELATED,ESTABLISHED -j ACCEPT # der Rest loggen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -j LOG --log-prefix "DROP IN PKT: " --log-level 7 # und verwerfen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -j DROP
ICQ, FTP und der Rest, der SOCKS benutzt, muss nicht explizit in der Firewallkonfig beachtet werden, da der Proxy sich darum kuemmert. Er nimmt Verbindungen aus deinem LAN am Port 1080/tcp an. (also INPUT Kette vom LAN Interface, port 1080/tcp) In den Paeckchen steht, mit was sich der Client gern verbinden will. Der Server macht die Verbindung fuer den Client (OUTPUT Kette, von 1024+ zum Remote-Dienst Port) und forwardet dann die Antworten vom Remote-Server zu deinem Client (Intern, nix mit iptables), in SOCKS Paeckchen eingebettet.
Alles klar?
-Dimitri
Dimitri Puzin wrote:
Also, der SOCKS-Server ist ein lokales Prozess, weshalb nur die INPUT und OUTPUT Ketten relevant sind. Ich verbiete alles in der INPUT Kette, was vom externen Interface kommt. Nur ESTABLISHED, RELATED Pakete sind erlaubt, da keiner zu meinem SOCKS Server eine Verbindung aufbauen soll. OUTPUT Kette ist ACCEPT und leer, da hier nur lokal generierte Pakete durchgehen. FORWARD ist ebenfalls ACCEPT und leer. Die ist nicht relevant, da kein Routing stattfindet. Das ist alles, was NETFILTER betrifft. Der Rest erfolgt in der Konfiguration in der danted.conf.
Hier mein Regelsatz: # Antworten auf ICMP erlauben iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p icmp -m icmp -j ACCEPT # IDENT Anfragen von IRC et al abweisen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable # eingehende Pkt erlauben, die zu lokal aufgebauten Verbindungen gehoeren iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -m state --state RELATED,ESTABLISHED -j ACCEPT # der Rest loggen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -j LOG --log-prefix "DROP IN PKT: " --log-level 7 # und verwerfen iptables -A INPUT -i $EXT_IFACE -d $EXT_IP -j DROP
ICQ, FTP und der Rest, der SOCKS benutzt, muss nicht explizit in der Firewallkonfig beachtet werden, da der Proxy sich darum kuemmert. Er nimmt Verbindungen aus deinem LAN am Port 1080/tcp an. (also INPUT Kette vom LAN Interface, port 1080/tcp) In den Paeckchen steht, mit was sich der Client gern verbinden will. Der Server macht die Verbindung fuer den Client (OUTPUT Kette, von 1024+ zum Remote-Dienst Port) und forwardet dann die Antworten vom Remote-Server zu deinem Client (Intern, nix mit iptables), in SOCKS Paeckchen eingebettet.
Alles klar?
Ja, denke schon. Danke.
Carsten
Hi.
* Dimitri Puzin tristan-777@t-online.de [2004-06-06 11:39 +0200]:
Also, der SOCKS-Server ist ein lokales Prozess, weshalb nur die INPUT und OUTPUT Ketten relevant sind. Ich verbiete alles in der INPUT Kette, was vom externen Interface kommt. Nur ESTABLISHED, RELATED Pakete sind erlaubt, da keiner zu meinem SOCKS Server eine Verbindung aufbauen soll.
Das könnte Probleme geben, falls Du direkte ICQ-Verbindungen haben willst, bei denen die Nachrichten nicht über die ICQ-Server laufen.
Die Nachrichten werden als UDP-Pakete verschickt und der Rechner auf dem der SOCKS-Proxy läuft sollte sie in dem Fall nicht nur verschicken sondern auch annehmen können.
Stefan
Stefan Moch schrieb:
Hi.
- Dimitri Puzin tristan-777@t-online.de [2004-06-06 11:39 +0200]:
Also, der SOCKS-Server ist ein lokales Prozess, weshalb nur die INPUT und OUTPUT Ketten relevant sind. Ich verbiete alles in der INPUT Kette, was vom externen Interface kommt. Nur ESTABLISHED, RELATED Pakete sind erlaubt, da keiner zu meinem SOCKS Server eine Verbindung aufbauen soll.
Das könnte Probleme geben, falls Du direkte ICQ-Verbindungen haben willst, bei denen die Nachrichten nicht über die ICQ-Server laufen.
Die Nachrichten werden als UDP-Pakete verschickt und der Rechner auf dem der SOCKS-Proxy läuft sollte sie in dem Fall nicht nur verschicken sondern auch annehmen können.
Stefan
Hi Stefan,
das Problem ist bei mir nicht aufgetreten, da der SOCKS 5 Server auch mit UDP umgehen kann, im Gegensatz zu SOCKS 4. Problematisch ist nur der Fall, wo der Initiator sich im Internet befindet und an einen Host hinter dem Proxy/NAT-Firewall etwas senden will. Hier kommt man ohne Portforwarding/DNAT nicht aus, was die Sache weder einfacher noch sicherer macht. AFAIK ist das aber ein generelles Problem, wenn man NAT benutzt. Man koennte jetzt meinen, wenn man eingehende Verbindungen zum SOCKS Proxy erlaubt, sich der Sachverhalt aendern wird, doch es ist nicht der Fall. Im Gegenteil, stellt dieses Vorgehen ein reales Sicherheitsrisiko dar.
-Dimitri
Hi Dimitri,
* Dimitri Puzin tristan-777@t-online.de [2004-06-06 15:00 +0200]:
das Problem ist bei mir nicht aufgetreten, da der SOCKS 5 Server auch mit UDP umgehen kann, im Gegensatz zu SOCKS 4. Problematisch ist nur der Fall, wo der Initiator sich im Internet befindet und an einen Host hinter dem Proxy/NAT-Firewall etwas senden will.
so wie ich die Sache mit UDP verstanden habe ist keine der beiden Seiten ein Initiator, wie man ihn von TCP kennt, da die Pakete verbindungslos ausgetauscht werden.
Kommt halt darauf an, was man machen will. Wenn der SOCKS-Proxy die ICQ-UPD-Pakete senden und empfangen soll, müssen sie auch zu ihm gelangen können, wenn er das nicht soll, besteht das Problem ja nicht.
Stefan
On Sun, Jun 06, 2004 at 07:29:24AM +0200, Carsten Friede wrote:
Wie firewallst Du dann den SOCKS-Server? Wie sehen die Regeln dazu aus(speziell ICQ und FTP)?
Wenn du deine Proxys / SOCKS-Server ordentlich konfiguriert hast, brauchst du keine Firewall mehr, das ist ja das gute. Auf der SOCKS/Proxy-Maschine ist dann natürlich IP-forwarding aus.
On Sat, 05 Jun 2004 15:15:37 +0200, Andreas Kretschmer wrote:
Das FTP-Modul schnüffelt den Kommandokanal mit und weiß so, welche Ports mit genutzt werden. Ich kann auf Arbeit an einem genatten Rechner sowohl passives als auch aktives FTP machen. Dazu sind auf dem Gateway 3 Module geladen, ich schrieb das aber IMHO auch schon mal in dieser Liste.
Aktives FTP ist so krank, daß man es IMO ohne zwingenden Grund nicht mehr unterstützen muß.
Reinhard
am 09.06.2004, um 13:11:56 +0200 mailte Reinhard Foerster folgendes:
On Sat, 05 Jun 2004 15:15:37 +0200, Andreas Kretschmer wrote:
Das FTP-Modul schnüffelt den Kommandokanal mit und weiß so, welche Ports mit genutzt werden. Ich kann auf Arbeit an einem genatten Rechner sowohl passives als auch aktives FTP machen. Dazu sind auf dem Gateway 3 Module geladen, ich schrieb das aber IMHO auch schon mal in dieser Liste.
Aktives FTP ist so krank, daß man es IMO ohne zwingenden Grund nicht mehr unterstützen muß.
ACK. Ich wollte das auch nicht propagieren, sondern nur darlegen, daß es funktioniert.
PS.: lange nix von Dir gehört...
Andreas
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Andreas Kretschmer -
Carsten Friede -
Fabian Hänsel -
Reinhard Foerster -
Stefan Moch -
Stefan Seyfried -
Sven Klemm -
tristan-777＠t-online.de