pf-block: infiziertes Android Telefon?

F

fschaeffler

New Member
Ich habe versucht nach Details der Logs wie z.B. 'central/motorola-11-voice20000-1600-bpi.cm' zu googlen, aber ich hatte keinen einzige Treffer. So hier meine Frage. Könnte es sich hier um ein infiziertes Android Telefon handeln?

Was sagen mir diese logs eigentlich? Ausser der Tatsache, dass dieser Request geblockt wurde und immer noch mit einer Rate von 4 Request / Minute geblockt wird.

### Client:
IP: 192.168.<HIDDEN>.<HIDDEN>
MAC: cc:fa:00:a7:**:**
Name: android-dcd79d0cd<HIDDEN>


### Filter logs:
Feb 26 12:42:37 tmh-firewall pf: 00:00:02.823886 rule 5/0(match): block in on em0_vlan112: (tos 0x0, ttl 64, id 56167, offset 0, flags [DF], proto TCP (6), length 79)
Feb 26 12:42:37 tmh-firewall pf: 192.168.<HIDDEN>.<HIDDEN>.47438 > 173.194.44.31.443: Flags [P.], cksum 0xa8b1 (correct), ack 3479133114, win 264, options [nop,nop,TS val 1895616 ecr 571900440], length 27

Feb 26 12:42:27 tmh-firewall pf: 00:00:00.958737 rule 45/0(match): block in on re0: (tos 0x0, ttl 255, id 19360, offset 0, flags [none], proto UDP (17), length 456)
Feb 26 12:42:27 tmh-firewall pf: 10.220.112.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 428, hops 1, xid 0x1773e7ea, Flags [Broadcast]
Feb 26 12:42:27 tmh-firewall pf: Your-IP 10.220.123.137
Feb 26 12:42:27 tmh-firewall pf: Server-IP 195.234.128.44
Feb 26 12:42:27 tmh-firewall pf: Gateway-IP 10.220.112.1
Feb 26 12:42:27 tmh-firewall pf: Client-Ethernet-Address 00:14:e8:a6:61:aa
Feb 26 12:42:27 tmh-firewall pf: file "central/motorola-11-voice20000-1600-bpi.cm" [|bootp]
Feb 26 12:42:27 tmh-firewall pf: 00:00:00.095688 rule 5/0(match): block in on em0_vlan112: (tos 0x0, ttl 64, id 54655, offset 0, flags [DF], proto TCP (6), length 79)

Feb 26 12:54:20 tmh-firewall pf: 00:00:00.439478 rule 5/0(match): block in on em0_vlan112: (tos 0x0, ttl 64, id 49569, offset 0, flags [DF], proto TCP (6), length 603)
Feb 26 12:54:20 tmh-firewall pf: 192.168.<HIDDEN>.<HIDDEN>.32821 > 173.194.70.95.443: Flags [P.], ack 3906605826, win 408, options [nop,nop,TS val 1965844 ecr 1110537749], length 551
Feb 26 12:54:20 tmh-firewall pf: 00:00:00.413795 rule 3/0(match): block in on em0: (hlim 1, next-header UDP (17) payload length: 107) fe80::e524:c7e1:e886:dd29.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit
(xid=b52a0a (elapsed time 300) (client ID hwaddr/time type 1 time 411801340 000c29e45988) (IA_NA IAID:234884137 T1:0 T2:0) (Client FQDN) (vendor class) (option request DNS name DNS vendor-specific info Clie
nt FQDN))
Feb 26 12:54:20 tmh-firewall pf: 00:00:00.000031 rule 3/0(match): block in on bridge0: (hlim 1, next-header UDP (17) payload length: 107) fe80::e524:c7e1:e886:dd29.546 > ff02::1:2.547: [udp sum ok] dhcp6 sol
icit (xid=b52a0a (elapsed time 300) (client ID hwaddr/time type 1 time 411801340 000c29e45988) (IA_NA IAID:234884137 T1:0 T2:0) (Client FQDN) (vendor class) (option request DNS name DNS vendor-specific info
Client FQDN))
Feb 26 12:54:20 tmh-firewall pf: 00:00:00.000010 rule 3/0(match): block in on em0: (hlim 1, next-header UDP (17) payload length: 107) fe80::e524:c7e1:e886:dd29.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit
(xid=b52a0a (elapsed time 300) (client ID hwaddr/time type 1 time 411801340 000c29e45988) (IA_NA IAID:234884137 T1:0 T2:0) (Client FQDN) (vendor class) (option request DNS name DNS vendor-specific info Clie
nt FQDN))
 
dig -x 173.194.44.31 ergibt
muc03s07-in-f31.1e100.net.

1e100.net ist google. (gogol = 1e100)

und muc ist wahrscheinlich XMPP oder der Google Push Service.


EDIT: DAFUQ ?

Das sieht nach dem provisioning Netz für dein Kabelmodem aus. Nach DOCSIS Standard laden die Dinger ihre konfiguration va tftp. Dass die pakete bei deiner Firewall ankommen riecht komisch, da das modem die eigentlich filtern sollte.

dig -x 195.234.128.44 ---> tftp.cablesurf.de.
 
Das ist PXE was hier passiert. Wenn 10.220.112.1 keine lokale IP (also im LAN) ist, dann ist was kaputt mit Deinem Netz. Guck mal mit
Code: 
arp -a
Das Gerät sollte eine MAC-Adresse haben, wenn es in Deinem Netz ist und Broadcasts machen kann. Dann kannst Du den Übeltäter vielleicht identifizieren.

Wenn das ein Handy macht, dann ist es eindeutig böse. Aber es kann nur bestimmte Arten von Telefonen auf diese Art und Weise erreichen.

Edit:
Aja, das kann wirklich ein Update sein, welches von tftp.cablesurf.de verteilt wird. Aber so einen Kack macht man nicht. Das ist ja wirklich ein Weg, wie sich Viren verbreiten. Guck mal nach der oben erwähnten IP. Es scheint, dass der ISP sich fein in Dein Netz reingestellt hat, was ich sowieso für eine zwielichtige Geschichte halte.
 
Der Kabelanbieter schickt in seinem DHCP-Reply halt einen Filenamen mit. Na und?

Desweiteren sieht das so aus, als hätte der OP einfach keine öffentliche Adresse sondern der Anbieter macht CGN.
 
Die DHCP Server der Kabelanbieter stehen im 10er Netz und verteilen öffentliche IPs (zumindest bei mir bei unitymedia):
Code: 
Mar  5 09:16:04 router dhclient[8440]: DHCPREQUEST on re0 to 10.156.128.1 port 67
Mar  5 09:16:11 router last message repeated 2 times
Mar  5 09:16:15 router dhclient[8440]: DHCPREQUEST on re0 to 255.255.255.255 port 67
Mar  5 09:16:15 router dhclient[8440]: DHCPACK from 10.156.128.1 (1c:df:0f:02:2f:d9)
Mar  5 09:16:15 router dhclient[8440]: bound to 88.152.83.46 -- renewal in 1800 seconds
Hinzu kommt noch, dass der Server nicht auf unicast DHCPREQUESTS reagiert. Die Antwort auf meine Frage, was der Sch***s soll, war, ich solle mich an den Routerhersteller wenden oder bei Problemen des Modems mich nochmal melden.
 
Der ISP hat nichts im LAN zu fummeln. Das darf höchstens der Router. Der hat auch nicht einfach Dateinamen (zum PXE-Boot) zu senden, weil das komplett idiotisch ist.

Bin leider auch bei Unitymedia. Bin zwar am Anfang der Vertragslaufzeit, aber ich habe mich entschlossen zu kündigen. Der Support ist einfach unerträglich. Ich habe auch gebeten, dass sie Anycast bei 6to4-Adressen überprüfen sollen, weil die Kommunikation nicht klappt. Die haben mir auch gesagt, ich soll mich an den Hersteller der Hardware wenden. Es ist mir einfach lästig mich mit denen zu unterhalten. Ich konnte nach mehreren Wochen nicht einen kompetenten Menschen erreichen. Und ... es sieht so aus als ob sie mich vom Online-Support gesperrt haben.

Ich weiß nicht was ich davon halten soll. Der Router von Unitymedia ist komplett böse programmiert. So ein Verhalten toleriere ich nicht in meinem Netz, wie dieser von sich gibt. Zum ersten Mal habe ich gesehen, dass ein Provider das LAN hackt (im wahrsten Sinne des Wortes!) und ich habe kein Bock auf solche Spielchen.
 
Was schiebt ihr denn alle für einen Stress.
Das sieht einfach nur danach aus, als ob das Kabelmoden (nicht der Router) die Broadcast messages die für das provisioning des Modems genutzt werden in das lokale netz leakt.
Das ist bei DHCP Replies nicht gefärlich, weil die Clients sowieso die ganze Zeit fremde replies sehen.

@makenoob: Das ist das ganz normale DHCP für deine Gateway. So wird dieser (deinem Router, Dlink/fritzbox/selber gebastelt) die zugeteilte öffentliche IP mitgeteilt. Wie sonst soll das ablaufen?

@nakal: Wer hackt denn wie was ? Und welcher Router ? Die benutzen da Off-The-Shelf Plastikboxen für 15€, als ob die die jemals selbst konfiguriert haben. Ich habe da eine ARM Box mit debian stehen. Wer Seinen Rechner direkt an das Modem anschließt braucht sich nicht zu wundern.

Es sieht mir eher nach einem harmlosen gefrickel mit vlans und broadcast domains aus damit DHCP für den Router hinter dem Modem geht aus, als um etwas Böswilliges.
 
FreeBSDuser schrieb:
@makenoob: Das ist das ganz normale DHCP für deine Gateway. So wird dieser (deinem Router, Dlink/fritzbox/selber gebastelt) die zugeteilte öffentliche IP mitgeteilt. Wie sonst soll das ablaufen?
Zum Vergrößern anklicken....
DHCPREQUEST per Unicast direkt an den DHCP Server:
Code: 
Mar 5 09:16:04 router dhclient[8440]: DHCPREQUEST on re0 to 10.156.128.1 port 67
Mar 5 09:16:11 router last message repeated 2 times
Da kütt aber nix zurück. Erst wenn die Client wieder ein Broadcast sendet, antwortet der DHCP, der zuvor per Unicast angefragt wurde:
Code: 
Mar 5 09:16:15 router dhclient[8440]: DHCPREQUEST on re0 to 255.255.255.255 port 67
Mar 5 09:16:15 router dhclient[8440]: DHCPACK from 10.156.128.1 (1c:df:0f:02:2f:d9)
Mar 5 09:16:15 router dhclient[8440]: bound to 88.152.83.46 -- renewal in 1800 seconds
Was soll sowas? Abgesehen von CGN und DS-Lite ist für mich so eine Konfiguration kaputt. Abgesehen davon gibt's auch Zeiten, wo mir ARP Anfragen auf dem externen Interface aufgeschlagen sind. Wenn ich die beantwortet hätte, wär das sicher lustig geworden. Als Antwort vom Support wurde ich dann gefragt, ob das meinen Betrieb einschränkt...
 
Der Router von Unitymedia sichert ab, dass Du Dein Netz nicht durch einen weiteren Router teilen kannst. Dazu schickt er auch Layer 2 ARP/NDP um zu prüfen, ob Du sternenförmig dran hängst.

Sollte der Router "herausfinden" dass Du irgendwas versuchst mit Bridges oder Routen, dann hängt er den Port auf und kommuniziert gar nicht mehr Dir.

Das meine ich mit "böse". Und es ist durchaus eine gehackte Firmware, die sich nicht standardkonform verhält.
 
Das würde mich mal interessieren. Was genau macht der?

Dieses Vorgehen wäre doch etwas fehlgeleitet, denn die leute die komplexeres routing aufsetzen, wissen genug um solche Spielereien zu umgehen.

Ist das Verhalten irgendwo dokumentiert?
 
Wäre das Verhalten dokumentiert, dann hätte ich das überhaupt nicht geholt. Das Handbuch im Netz und auf der mitgelieferten DVD sugerriert, dass man sogar vollwertiges IPv4 von Unitymedia bekommt (DMZ und Portweiterleitung ist dort dokumentiert mit Abbildungen; beides funktioniert nicht und das DMZ-Menü verschwindet sogar komplett nach dem nächsten Firmware-Update).

Unitymedia sagt nur dazu, dass der Router nicht erlaubt, Stock-Router anzuschließen. Ich habe eine spezielle Art von NAT nun eingesetzt, um dem Router vorzugaukeln, dass nur ein Gerät angeschlossen ist. Bei Stock-Routern gibt es eine Standard-NAT und da "findet" der Router einen Weg, das herauszufinden und hängt auch den Port auf.
 
Hast du so eine Fritzbox mit multi-voip oder die einfache variante?

Ich verstehe nicht ganz was du meinst, ich glaube du nennst das Kabelmodem und den Router Router.

Ich habe keine Probleme mit meinem Setup bei Unitymedia. Ich hatte Motorola und Cisco Kabelmodems, beide Funkionieren gleich.
Es wird Tunnel aufgebaut, welcher über den Ethernet Port am Kabelmodem erreichbar ist, Darüber bekommt eine MAC Adresse die öffentliche IP via broadcast DHCP zugewiesen. Der host mit der MAC muss dann NAT machen um die anderen Rechner im Netz mit Internet zu versorgen.

Ich hatte schon alles mögliche am Kabelmodem hängen, Dockstar, Notebook, Desktop, D-Link usw. und bisher nie Probleme gehabt.

Das Kabelmodem mischt noch sein 192.168.100.0 Netz da mit rein, aber das ist ja zu erwarten.

Benutz mal bitte die richtigen Bezeichnungen wenn möglich mit Modellnamen, sonst verstehe ich nur Bahnhof.
 
nakal schrieb:
Ich habe eine spezielle Art von NAT nun eingesetzt, um dem Router vorzugaukeln, dass nur ein Gerät angeschlossen ist. Bei Stock-Routern gibt es eine Standard-NAT und da "findet" der Router einen Weg, das herauszufinden und hängt auch den Port auf.
Zum Vergrößern anklicken....

Details dazu? Was mir einfällt, wie man NAT entdecken kann: verschiedene Bereiche der Quellports aufgebauter Verbindungen und unterschiedliche TTLs. Beides kann man mit pf homogenisieren.
 
FreeBSDuser schrieb:
Hast du so eine Fritzbox mit multi-voip oder die einfache variante?
Zum Vergrößern anklicken....

Es geht um das Gerät TC-7200, welches Unitymedia den Neukunden aufdrückt. Fritzboxen gibt es nicht mehr.

FreeBSDuser schrieb:
Ich verstehe nicht ganz was du meinst, ich glaube du nennst das Kabelmodem und den Router Router.
Zum Vergrößern anklicken....

Weil das Modem nicht nur ein Modem ist, sondern auch ein Router.

FreeBSDuser schrieb:
Ich habe keine Probleme mit meinem Setup bei Unitymedia. Ich hatte Motorola und Cisco Kabelmodems, beide Funkionieren gleich.
Es wird Tunnel aufgebaut, welcher über den Ethernet Port am Kabelmodem erreichbar ist, Darüber bekommt eine MAC Adresse die öffentliche IP via broadcast DHCP zugewiesen. Der host mit der MAC muss dann NAT machen um die anderen Rechner im Netz mit Internet zu versorgen.
Zum Vergrößern anklicken....

Darf man ein anderes Kabelmodem anschließen? Ist es generell so? Da Unitymedia nur noch Dual Stack Lite vergibt, wirst Du wahrscheinlich DHCPv6 meinen, oder? Eine IPv4 gibt es ja nicht mehr. Die wird per NAT beim ISP herausgeleitet falls man eine Verbindung zu nicht-IPv6-Netzen möchte.

TCM schrieb:
Details dazu? Was mir einfällt, wie man NAT entdecken kann: verschiedene Bereiche der Quellports aufgebauter Verbindungen und unterschiedliche TTLs. Beides kann man mit pf homogenisieren.
Zum Vergrößern anklicken....

Der Router guckt selbst, ob er geNATet wird. Er kann sich ja genauso zum Gerät im Netz machen. Wenn man das Netz wo der Unitymedia-Router sitzt eingehend bei der NAT-Regel filtert, dann kann man erst NAT fahren. Das machen Stock-Router so nicht und funktionieren deswegen nicht.

Es ist auch total lästig mit dem blöden Teil, weil er nicht nur alles sperrt, sondern das Netz auch mit zufälligen ARP-Requests floodet, um andere Router außer Gefecht zu setzen. Das macht er dann, wenn er eine IP sieht, die nicht zu seinem festgelegten Netz gehört. /16er-Netz-Einstellung ist übrigens auf dem Router kaputt. Man kann nur /24 wählen und dann auch sehr gut aufpassen, weil es auch irgendwie buggy ist (meint irgendwie, dass man Überschneidungen bei DHCP hat etc... was natürlich nicht der Fall ist).
 
Zuletzt bearbeitet:
nakal schrieb:
Weil das Modem nicht nur ein Modem ist, sondern auch ein Router.
Zum Vergrößern anklicken....
Dann ist es ein Router mit integriertem Modem, also vorrangig ein Router.


Der Router guckt selbst, ob er geNATet wird. Er kann sich ja genauso zum Gerät im Netz machen. Wenn man das Netz wo der Unitymedia-Router sitzt eingehend bei der NAT-Regel filtert, dann kann man erst NAT fahren. Das machen Stock-Router so nicht und funktionieren deswegen nicht.
Zum Vergrößern anklicken....
Der Router wird doch nicht geNATed. Bei solchen Zwangskistchen klemmt man die ans Netz und _dahinter_ seinen eigenen Router. Wie die Kiste dann merken will, ob da ein Router oder ein einzelner Client dranhängt, erklär mir mal einer.

Es ist auch total lästig mit dem blöden Teil, weil er nicht nur alles sperrt, sondern das Netz auch mit zufälligen ARP-Requests floodet, um andere Router außer Gefecht zu setzen. Das macht er dann, wenn er eine IP sieht, die nicht zu seinem festgelegten Netz gehört.
Zum Vergrößern anklicken....

Klingt alles irrelevant, wenn man es wie o.g. macht.
 
TCM schrieb:
Der Router wird doch nicht geNATed. Bei solchen Zwangskistchen klemmt man die ans Netz und _dahinter_ seinen eigenen Router. Wie die Kiste dann merken will, ob da ein Router oder ein einzelner Client dranhängt, erklär mir mal einer.
Zum Vergrößern anklicken....

Das habe ich eben versucht zu erklären. Natürlich hängt man den eigenen Router vor das eigene Netz. Ich gebe Dir ein Beispiel zur Illustration:

Code: 
nat on $if_ext inet from any to $net_internet -> ($if_ext)

Beim obigen ist der UM-Router auch in der NAT und kann das austesten. Dann macht er voll den Terror und stört alle Geräte, die man im Netz hat.

Code: 
nat on $if_ext inet from ! ($if_ext) to $net_internet -> ($if_ext)

Bei dieser Variante wird der UM-Router ausgeschlossen. So habe ich das auch eingestellt. Ein feiner Unterschied, aber den die Stock-Router nicht so machen.
 
Aber hängt das komische UnityRouterModem denn in dem selben Netz wie deine Clients oder an dem zweiten NIC deiner PF Kiste.
Im letzteren Fall sollte das seltsame Verhalten des Upstream Netzwerks doch nichts ausmachen. Und verschachtelte NATs haben bei mir auch noch keine Probleme gemacht.


Ich habe noch pur IPv4, glücklicherweise mit einem Cisco EPC3208, das Kabelmodel verhält sich wie ein PointToPoint Tunnel.
 
Nein. Ich mache keine Bridge über alle 3 NICs (ich habe separate Netze, eins fürs UM-Router-Netz, eins für Ethernet und eins für WLAN, als Schutz, erkläre ich gleich unten). Dann bräuchte ich im Endeffekte kein NAT. Ich habe noch nicht herausgefunden, warum eine Brigde nicht klappt. Das mag der UM-Router nämlich auch nicht und macht das Netz ebenfalls kaputt. Interessanterweise macht eine hausgemachte Bridge denen das Geschäft kaputt mit den 30 Euro für die Freischaltung von WLAN im UM-Router.

Mir gefällt das ganze überhaupt nicht. Ich habe einen ehrlichen und kundenfreundlichen ISP erwartet. Aber jetzt muss ich mich vor dem UM-Router schützen. Wer so etwas dreckiges im Hausnetz macht, der macht wahrscheinlich noch mehr... wer weiß. Ich sehe meinen Selbstbaurouter nun als Plicht an, damit ich mich vor dem (wie schon eben gesagt) bösen UM-Router schütze. Deswegen habe ich auch auf eine Untersuchung warum Bridges technisch nicht klappen verzichtet.

Das erschien mir passend zum Thema... wir sind aber sehr abgewichen (sorry an den OP). Aber im Endeffekt sollte man sich vor ISPs gut schützen, wie Unitymedia hier deutlich zeigt.
 
Zuletzt bearbeitet:
Vielleicht ein Fall von:

Never ascribe to malice that which can be adequately explained by incompetence.
Zum Vergrößern anklicken....

Ich würde eher darauf tippen das die Plastikdose kacke ist.

Jedoch führen beide Varianten zu der gleichen Lösung.
Das ist bestimmt auch irgendwie ein schönes Lehrstück.

If you prepare for the NSA, you get protection from shoddy ISPs for free.
Ich hoffe wirklich das opportunistic encryption in HTTP/2 landet.
 
Das die Router-Firmware nur dumm programmiert ist, kann ich guten Gewissens ausschließen. Ich gehe immer unvoreingenommen an eine Sache dran. Sie ist eigentlich beides, dumm programmiert und boshaft zugleich.
 
TCM schrieb:
Die wichtige Frage bei Encryption ist, woher der Schlüssel kommt und wer ihn alles hat.
Zum Vergrößern anklicken....

Nein ist es nicht, Diffie hellmann ephemeral und gut. Danach kann nurnoch mitlesen wer auch MITM machen kann. Und es lässt sich einfacher bemerken. Es geht nicht um absolute sicherheit, sondern darum die kosten prohibitiv für massenhaftes sammeln zu machen. GGf kann man es ja in etwas langweiliges umbenennen wie "low level transport encoding" dann vertun sich die leute nicht.
 
Da stimme ich zu. Wobei es lässt sich auch sagen, dass Sicherheit sich in Kosten aufwiegen lässt, dieselbige zu umgehen. Absolute Sicherheit gibt es deswegen nicht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben