Hallo, ich habe meine Firewall nun so angepasst, dass auch ausgehender Traffic (Chain OUTPUT) validiert wird. Aus diverse Gründen wird im Augenblick nur geloggt, es wird (noch) nichts geblockt. So bin ich nun auf Seltsamkeiten im Log gestoßen: Jul 26 09:34:49 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21332 DF PROTO=TCP SPT=32776 DPT=2703 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:35:54 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.6 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=256 DF PROTO=TCP SPT=32794 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:35:56 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.17 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28526 DF PROTO=TCP SPT=32800 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:42:41 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28526 DF PROTO=TCP SPT=32860 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:43:08 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=512 DF PROTO=TCP SPT=32872 DPT=2703 WINDOW=5808 RES=0x00 SYN URGP=0 Es wird versucht, den Port 2703 oder 7 bei den angegebenen DST-Adressen zu erreichen. Ein "telnet xyf.52.3.2 2703" zeigt interessantes... (Wäre es legal, da die komplette Zieladresse zu veröffentlichen?) Nun, das war der Hintergrund. Meine Frage ist nun: Wie kann ich herausfinden, welches Programm sich versucht zu connecten? Der Connect ist zu selten, dass ich ihn mit "netstat -an" o.ä. rausfinden könnte. Meine Idee wäre es, diese Zieladressen via NAT umzubiegen und lokal einen Dummy-Dienst dafür zu schreiben, der das Programm warten lässt. Dann könnte man sogar "netstat -an" einsetzen. Aufgrund des Misstrauens habe ich die Class-C-Adresse nun geblockt. Grüße, Tom
* On Sat, 26 Jul 2003 at 10:30 +0200, Thomas Preissler wrote:
ich habe meine Firewall nun so angepasst, dass auch ausgehender Traffic (Chain OUTPUT) validiert wird. Aus diverse Gründen wird im Augenblick nur geloggt, es wird (noch) nichts geblockt. [...] Es wird versucht, den Port 2703 oder 7 bei den angegebenen DST-Adressen zu erreichen. Ein "telnet xyf.52.3.2 2703" zeigt interessantes...
Ja, was zeigt es denn? Ein bisl was musst Du schon verraten.
(Wäre es legal, da die komplette Zieladresse zu veröffentlichen?)
Keine Ahnung, versuch einfach mit whois und host ein bischen mehr darüber rauszufinden. Wenn da wer heimtelefoniert muss sich ja rauskriegen lassen, wer der Empfänger ist. Und schneide Dir den Traffic, der da geht einfach mit tcpdump mit.
Nun, das war der Hintergrund. Meine Frage ist nun:
Wie kann ich herausfinden, welches Programm sich versucht zu connecten? Der Connect ist zu selten, dass ich ihn mit "netstat -an" o.ä. rausfinden könnte. Meine Idee wäre es, diese Zieladressen via NAT umzubiegen und lokal einen Dummy-Dienst dafür zu schreiben, der das Programm warten lässt. Dann könnte man sogar "netstat -an" einsetzen.
Hört sich plausibel an. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo Adalbert, * Adalbert schrieb am 26.07.2003:
* On Sat, 26 Jul 2003 at 10:30 +0200, Thomas Preissler wrote:
ich habe meine Firewall nun so angepasst, dass auch ausgehender Traffic (Chain OUTPUT) validiert wird. Aus diverse Gründen wird im Augenblick nur geloggt, es wird (noch) nichts geblockt. [...] Es wird versucht, den Port 2703 oder 7 bei den angegebenen DST-Adressen zu erreichen. Ein "telnet xyf.52.3.2 2703" zeigt interessantes...
Ja, was zeigt es denn? Ein bisl was musst Du schon verraten.
[root@zeus:~/firewall]$ telnet 216.52.3.2 2703 Trying 216.52.3.2... Connected to 216.52.3.2. Escape character is '^]'. sn=D&srl=124&ep4=7542-10&a=l&a=cg err=102 help err=100 ? err=100 h err=100 ^] telnet> q Connection closed.
(Wäre es legal, da die komplette Zieladresse zu veröffentlichen?)
Keine Ahnung, versuch einfach mit whois und host ein bischen mehr darüber rauszufinden. Wenn da wer heimtelefoniert muss sich ja rauskriegen lassen, wer der Empfänger ist.
Und schneide Dir den Traffic, der da geht einfach mit tcpdump mit.
Werde ich mal machen.
Nun, das war der Hintergrund. Meine Frage ist nun:
Wie kann ich herausfinden, welches Programm sich versucht zu connecten? Der Connect ist zu selten, dass ich ihn mit "netstat -an" o.ä. rausfinden könnte. Meine Idee wäre es, diese Zieladressen via NAT umzubiegen und lokal einen Dummy-Dienst dafür zu schreiben, der das Programm warten lässt. Dann könnte man sogar "netstat -an" einsetzen.
Hört sich plausibel an.
Grüße, Tom
* On Sat, 26 Jul 2003 at 12:15 +0200, Thomas Preissler wrote:
* Adalbert schrieb am 26.07.2003:
* On Sat, 26 Jul 2003 at 10:30 +0200, Thomas Preissler wrote:
ich habe meine Firewall nun so angepasst, dass auch ausgehender Traffic (Chain OUTPUT) validiert wird. Aus diverse Gründen wird im Augenblick nur geloggt, es wird (noch) nichts geblockt. [...] Es wird versucht, den Port 2703 oder 7 bei den angegebenen DST-Adressen zu erreichen. Ein "telnet xyf.52.3.2 2703" zeigt interessantes...
Ja, was zeigt es denn? Ein bisl was musst Du schon verraten.
[root@zeus:~/firewall]$ telnet 216.52.3.2 2703
Hast Du da irgendwas Spamfilterndes? adalbert@pepe:~ > host 216.52.3.2 2.3.52.216.IN-ADDR.ARPA domain name pointer agony.cloudmark.com adalbert@pepe:~ > lynx -source www.cloudmark.com|grep -i meta.*descr <meta name="description" content="Cloudmark: a company that stops spam before it costs you money. Cloudmark's groundbreaking, peer-to-peer (P2P) solution (initially Vipul's Razor) proven effective at fighting spam since 1998 and now called SpamNet, already delivers immediate spam relief to more than half a million people."> /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Am Samstag, 26. Juli 2003 10:30 schrieb Thomas Preissler:
Hallo,
ich habe meine Firewall nun so angepasst, dass auch ausgehender Traffic (Chain OUTPUT) validiert wird. Aus diverse Gründen wird im Augenblick nur geloggt, es wird (noch) nichts geblockt.
So bin ich nun auf Seltsamkeiten im Log gestoßen:
Jul 26 09:34:49 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21332 DF PROTO=TCP SPT=32776 DPT=2703 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:35:54 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.6 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=256 DF PROTO=TCP SPT=32794 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:35:56 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.17 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28526 DF PROTO=TCP SPT=32800 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:42:41 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28526 DF PROTO=TCP SPT=32860 DPT=7 WINDOW=5808 RES=0x00 SYN URGP=0 Jul 26 09:43:08 [kernel] OEXT PASSED: IN= OUT=ppp0 SRC=217.84.16.yxv DST=xyf.52.3.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=512 DF PROTO=TCP SPT=32872 DPT=2703 WINDOW=5808 RES=0x00 SYN URGP=0
Es wird versucht, den Port 2703 oder 7 bei den angegebenen DST-Adressen zu erreichen. Ein "telnet xyf.52.3.2 2703" zeigt interessantes... (Wäre es legal, da die komplette Zieladresse zu veröffentlichen?) Warum eigentlich nicht?
Nun, das war der Hintergrund. Meine Frage ist nun: Wie kann ich herausfinden, welches Programm sich versucht zu connecten?
markus@laptop:~> cat /etc/services |grep 2703 sms-chat 2703/tcp # SMS CHAT sms-chat 2703/udp # SMS CHAT Meinst du das? Gruß Markus
Hallo Markus, * Markus schrieb am 26.07.2003:
Am Samstag, 26. Juli 2003 10:30 schrieb Thomas Preissler:
[...]
markus@laptop:~> cat /etc/services |grep 2703 sms-chat 2703/tcp # SMS CHAT sms-chat 2703/udp # SMS CHAT
Meinst du das?
"getent services 2703" ist leer. Also kein "Standarddienst". Meine services auf meinem Gentoo-System hat diesen nicht eingetragen. Oder irgendwas mit SMS oder Chat läuft da bei mir nicht. Grüße, Tom
Hallo, nun habe ich rausgefunden, dass die Logeinträge mit dem Spam-Filter Vipul's Razor zu tun haben, denn bei aktivierter FW kann der sich nicht mehr connecten und spuckt Fehlermeldungen im procmail-Log raus. checkit: connect1: nextserver: Could not get valid info from Discovery Servers Danke, Tom
participants (3)
-
Adalbert Michelic -
Markus Hoppe -
Thomas Preissler