Moin.
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht. Ich arbeite im Moment noch mit ipchains. Kann es sein, das ipchains das AIM-Protocol nicht versteht? Das Login auf login.icq.com:5190 funktioniert nur dann, wenn ich alles durchlasse. Das kann aber Sinn der Sache sein! Der Connect findet aber dennoch von 1023:65535(local) auf 5190(remote) statt. Die danach aufgebauten direkten Verbindungen laufen auch wieder über die Highports. Ich arbeite mit selbstdefinierten Chains. Die Standard-Policy der Input und Output Chains lautet DENY. Sobald ein Paket über eth0 kommt, springt er zur entsprechenden Chain (ETH0_IN/ETH0_OUT). Ich habe das deswegen so gewählt, weil hier noch andere Interfaces angeschlossen sind und ich ein klare Trennung haben will. Komischerweise wir trotz des DENY in Input und Output bspw. auf Pings geantwortet. Darum habe ich in jede User-Chain noch eine letzte Regel eingefügt, die alles verbietet. Dann wird nicht mehr auf Pings geanwortet, ICQ geht aber auch nicht mehr. Wie löst man das Problem?
MfG
Carsten
Hallo Carsten,
Once upon a time, I head Carsten Friede say:
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht.
Im ICQ gibt es IMHO einen Schalter, mit dem du dem Programm sagen kannst, dass er durch eine Firewall muss. Soweit ich weiß, versucht er die Verbindung dann über Port 443 aufzubauen, die als solche dann bestehen bleibt. Das sollte firewalltechnisch soweit machbar sein.
Knifflig wird es allerdings dann, wenn du noch Direct Client Connections willst, also Chat-Sessions oder Filetransfers.
Matthias
Matthias Sauppe wrote:
Hallo Carsten,
Once upon a time, I head Carsten Friede say:
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht.
Im ICQ gibt es IMHO einen Schalter, mit dem du dem Programm sagen kannst, dass er durch eine Firewall muss. Soweit ich weiß, versucht er die Verbindung dann über Port 443 aufzubauen, die als solche dann bestehen bleibt. Das sollte firewalltechnisch soweit machbar sein.
Ich hätte noch sagen sollen, daß ich ickle verwende. So wie es aussieht, muß ich generell den Aufbau ändern. Bei der Gelegenheit steige ich gleich auf iptables um.
Knifflig wird es allerdings dann, wenn du noch Direct Client Connections willst, also Chat-Sessions oder Filetransfers.
Ja, das wären dann noch recht angenehme Zusatzfeatures. Mal sehen.
Carsten
On Wed, Jan 14, 2004 at 08:19:11PM +0100, Carsten Friede wrote:
Moin.
Hi Carsten,
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht. Ich arbeite im Moment noch mit ipchains. Kann es sein, das ipchains das AIM-Protocol nicht versteht?
Ich kenne das ICQ-Protokoll nicht, aber kann es sein das es wie FTP oder IRC versucht einen zweiten Kanal zu öffnen? Für dieses Problem gibt es direkt ein FTP bzw. IRC Firewall-Modul, evtl. kannst du die verwenden bzw. abändern.
Ciao, Tobias
Tobias Koenig wrote:
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht. Ich arbeite im Moment noch mit ipchains. Kann es sein, das ipchains das AIM-Protocol nicht versteht?
Ich kenne das ICQ-Protokoll nicht, aber kann es sein das es wie FTP oder IRC versucht einen zweiten Kanal zu öffnen? Für dieses Problem gibt es direkt ein FTP bzw. IRC Firewall-Modul, evtl. kannst du die verwenden bzw. abändern.
Klingt interessant. Wie genau stellst Du dir das vor?
Carsten
am 15.01.2004, um 1:52:47 +0100 mailte Carsten Friede folgendes:
Ich kenne das ICQ-Protokoll nicht, aber kann es sein das es wie FTP oder IRC versucht einen zweiten Kanal zu öffnen? Für dieses Problem gibt es direkt ein FTP bzw. IRC Firewall-Modul, evtl. kannst du die verwenden bzw. abändern.
Klingt interessant. Wie genau stellst Du dir das vor?
Ich kenne IRC und so auch nicht, aber:
Damit iptables mit diesen Protokollen korrekt arbeiten kann, sind Helper-Module nötig. Der Grund ist, daß z.B. FTP 2 Kanäle öffnet: einen Daten- bzw. Kommunikationskanal und einen Datenkanal. Dabei wird bei FTP z.B. noch zwischen passiv und aktiv unterschieden, je nachdem, wer die Datenverbindung aufbaut.
Ein 'dummer' Portfilter würde in einem solchen Szenario eher hinderlich sein. Ein 'kluger' Portfilter untersucht nun nicht nur Quell- und Zieladresse, Port und IP-Protokoll, sondern auch noch den _Inhalt_ der Pakete. Bei FTP zum Bleistift muß er die Kontrollverbindung belauschen, um den dort ausgehandelten Port für die Datenverbindung rauszubekommen. Diese Verbindung gilt das als 'related' und kann gesondert behandet werden (-j ACCEPT).
Es gibt da etliche Helper-Module, schau mal unter http://netfilter.org
Andreas
On Thu, Jan 15, 2004 at 01:52:47AM +0100, Carsten Friede wrote:
Tobias Koenig wrote:
Hi Carsten,
Ich versuche gerade einen neuen Paketfilter zusammenzubasteln. Alles funktioniert soweit, nur das ICQ will nicht so recht. Ich arbeite im Moment noch mit ipchains. Kann es sein, das ipchains das AIM-Protocol nicht versteht?
Ich kenne das ICQ-Protokoll nicht, aber kann es sein das es wie FTP oder IRC versucht einen zweiten Kanal zu öffnen? Für dieses Problem gibt es direkt ein FTP bzw. IRC Firewall-Modul, evtl. kannst du die verwenden bzw. abändern.
Klingt interessant. Wie genau stellst Du dir das vor?
Ich hab mich nochmal schlau gemacht... für Kernel 2.2.X gab es ein solches Modul für ICQ, aber da das Protokoll so ugly ist, wurde es nicht auf 2.4 oder 2.6 portiert. Im Internet hatte ich irgendwo gelesen das man ICQ auch mittels Proxy (SOCKS) durch eine Firewall tunneln kann, evtl. hilft dir das weiter?
Ciao, Tobias
am 15.01.2004, um 10:24:55 +0100 mailte Tobias Koenig folgendes:
Ich hab mich nochmal schlau gemacht... für Kernel 2.2.X gab es ein solches Modul für ICQ, aber da das Protokoll so ugly ist, wurde es nicht auf 2.4 oder 2.6 portiert.
Schöne Übersetzung der Iptables-FAQ ;-) http://www.netfilter.org/documentation/FAQ/netfilter-faq-1.html#ss1.3
Im Internet hatte ich irgendwo gelesen das man ICQ auch mittels Proxy (SOCKS) durch eine Firewall tunneln kann, evtl. hilft dir das weiter?
Da der Fragesteller wohl noch ipchains nutzt:
http://www.licq.org/faq.html#3_10
Andreas, googelnd ;-)
Hallo Tobias,
[15.01.04 01:15] Tobias Koenig schrieb:
On Wed, Jan 14, 2004 at 08:19:11PM +0100, Carsten Friede wrote: Ich kenne das ICQ-Protokoll nicht, aber kann es sein das es wie FTP oder IRC versucht einen zweiten Kanal zu öffnen?
Das ICQ-Protokoll hat sich m.E. auch mehrfach verändert. Für die alten Protokollversionen gab es Kernelmodul, was auf dem Firewallrechner laufen mußte.
Man kann das aktuelle Protokoll aber auch über einen http, https oder socks-Proxy fahren und braucht dementsprechend keine Umkonfiguration an der Firewall/Proxy vorzunehmen.
Ich hab mir von sim-icq eigene Debian-Pakete gebaut, die auf drei verschiedenen Rechnern zum Einsatz kommen und bin recht zufrieden damit.
Bert
Am 15. Januar 2004 schrieb Bert Lange:
Das ICQ-Protokoll hat sich m.E. auch mehrfach verändert. Für die alten Protokollversionen gab es Kernelmodul, was auf dem Firewallrechner laufen mußte.
Man kann das aktuelle Protokoll aber auch über einen http, https oder socks-Proxy fahren und braucht dementsprechend keine Umkonfiguration an der Firewall/Proxy vorzunehmen.
Ich hab mir von sim-icq eigene Debian-Pakete gebaut, die auf drei verschiedenen Rechnern zum Einsatz kommen und bin recht zufrieden damit.
Ich würde mal noch Jabber in die Runde werfen, das ist open source und hat Gateways nach vielen proprietären IM-Systemen und geht natürlich auch leicht zu NATten.
Torsten
On 14.01.04 Carsten Friede (cfriede@wh12.tu-dresden.de) wrote:
Moin,
Darum habe ich in jede User-Chain noch eine letzte Regel eingefügt, die alles verbietet. Dann wird nicht mehr auf Pings geanwortet, ICQ geht aber auch nicht mehr. Wie löst man das Problem?
Ganz am Rande: Normalerweise ist es ganz böse[TM] nicht auf Pings zu antworten. Ist das bei Dir anders?
H.
Am Mit, 2004-01-14 um 20.19 schrieb Carsten Friede: Moin,
... Darum habe ich in jede User-Chain noch eine letzte Regel eingefügt, die alles verbietet. Dann wird nicht mehr auf Pings geanwortet, ICQ geht aber auch nicht mehr. Wie löst man das Problem? ...
Sollte die Regel die alles verbietet nicht am Anfang stehen?
Mfg Gerd
am 15.01.2004, um 9:29:08 +0100 mailte Gerd Goehler folgendes:
Darum habe ich in jede User-Chain noch eine letzte Regel eingefügt, die alles verbietet. Dann wird nicht mehr auf Pings geanwortet, ICQ geht aber auch nicht mehr. Wie löst man das Problem? ...
Sollte die Regel die alles verbietet nicht am Anfang stehen?
Nein, das verbuchselst Du mit der Policy. Die kann man auf DROP setzen (REJECT geht nicht als Policy), dann greift das für alles, was durchfällt.
Regeln werden dann aber der Reihe nach abgearbeitet. Verbietet man am Anfang alles, ist das für die Kommunikation, ähm, ungünstig.
Andreas
Hi,
also ICQ stellt bei mir kein Problem dar. Ich verwende iptables. Von drin lass ich alles raus und von draußen lass ich bloß die Ports blocken, auf welchen auch was drauf läuft. Damit lief ICQ schon problemlos. Für die Direktverbindung um Daten austauschen zu können hab ich folgende Regel drin: iptables -t nat -A PREROUTING -p tcp --dport <DestPort> -j DNAT --to <Ziel-IP> (Danke nochmal Chris) Die Regel wird mehrmals aufgerufen mit unterschiedlichen Destination Ports (ich hab mir 5 für ICQ eingerichtet) welche ich auch in licq konfiguriert habe. Läuft problemlos.
Gruß Tilo
Moin.
Dank erstmal für die ganzen Tips. Ich muß mich im Moment noch mit den Grundlagen von iptables vertraut machen. Anscheinend habe ich noch Veständnisprobleme mit dem Konzepten von netfilter. Trotzdem dank, ich werde sehen, was ich umsetzen kann.
MfG
Carsten
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Bert Lange -
Carsten Friede -
Gerd Goehler -
Hilmar Preusse -
Matthias Sauppe -
Tilo Wetzel -
Tobias Koenig -
Torsten Werner