11
Telekom Abuse Mitteilung - Open DNS-Resolver - Mikrotik RB750GL 5.24 - Malware?
Hallo zusammen!
Habe leider ein Problem mit dem rosa Riesen.
Die Telekom hat mir eine Abuse Mitteilung (Hacking DoS DNS Resolver)geschickt und ich solle das abstellen, sonst würde mein Anschluss deaktiviert.
Leider kann ich das nicht reproduzieren, wenn ich die von der TK empfohlenen DNS Resolver Tests ausführe, sind die immer negativ.
http://www.thinkbroadband.com/tools/dnscheck.html od.
http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl
Ich habe meine Clients bereits zig mal gescannt, es kommt nichts dabei rum, nicht einmal ein Verdacht.
Verwendete ScanSoftware (jeweils aktuellste Version):
- Sophos Endpoint Security and Control
- McAfee Stinger
- Sophos Virus Removal Tool
- Malwarebytes
- Sophos Mobile Security
- OTL
Einzig in meinem Router ( Mikrotik RB750GL 5.24) finde ich folgende Verbindungen die mir nicht klar sind, es sollten doch alle irgendwie mit meinem LAN (192.168.200.0/24) zu tun haben?
Ich habe das nun mal so der TK geschrieben und warte mal ab was die sagen, nur würde ich gerne den Hintergrund bzw. das Zustandekommen dieser ersten drei Verb. verstehen.
Kann mir evtl. jemand dazu Hilfestellung leisten?
Danke im Voraus.
Edit: hier noch meine Firewallregeln in dem MT.
NAT:
0 chain=srcnat action=masquerade src-address=192.168.200.0/24
out-interface=pppoe-out1
Filter:
3 ;;; Accept established connections
chain=input action=accept connection-state=established
4 ;;; Accept related connections
chain=input action=accept connection-state=related
5 ;;; Drop Open-DNS-Resolver (wegen der TK nun sicherheitshalber eingefügt, wurde vorher aber auch gefiltert.)
chain=input action=drop protocol=udp in-interface=pppoe-out1 dst-port=53
6 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid
7 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2
8 ;;; Drop excess pings
chain=input action=drop protocol=icmp
9 ;;; From our LAN
chain=input action=accept src-address=192.168.200.0/24
in-interface=ether2
14 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"
15 ;;; Drop everything else
chain=input action=drop
Habe leider ein Problem mit dem rosa Riesen.
Die Telekom hat mir eine Abuse Mitteilung (Hacking DoS DNS Resolver)geschickt und ich solle das abstellen, sonst würde mein Anschluss deaktiviert.
Leider kann ich das nicht reproduzieren, wenn ich die von der TK empfohlenen DNS Resolver Tests ausführe, sind die immer negativ.
http://www.thinkbroadband.com/tools/dnscheck.html od.
http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl
Ich habe meine Clients bereits zig mal gescannt, es kommt nichts dabei rum, nicht einmal ein Verdacht.
Verwendete ScanSoftware (jeweils aktuellste Version):
- Sophos Endpoint Security and Control
- McAfee Stinger
- Sophos Virus Removal Tool
- Malwarebytes
- Sophos Mobile Security
- OTL
Einzig in meinem Router ( Mikrotik RB750GL 5.24) finde ich folgende Verbindungen die mir nicht klar sind, es sollten doch alle irgendwie mit meinem LAN (192.168.200.0/24) zu tun haben?
Ich habe das nun mal so der TK geschrieben und warte mal ab was die sagen, nur würde ich gerne den Hintergrund bzw. das Zustandekommen dieser ersten drei Verb. verstehen.
Kann mir evtl. jemand dazu Hilfestellung leisten?
Danke im Voraus.
Edit: hier noch meine Firewallregeln in dem MT.
NAT:
0 chain=srcnat action=masquerade src-address=192.168.200.0/24
out-interface=pppoe-out1
Filter:
3 ;;; Accept established connections
chain=input action=accept connection-state=established
4 ;;; Accept related connections
chain=input action=accept connection-state=related
5 ;;; Drop Open-DNS-Resolver (wegen der TK nun sicherheitshalber eingefügt, wurde vorher aber auch gefiltert.)
chain=input action=drop protocol=udp in-interface=pppoe-out1 dst-port=53
6 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid
7 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2
8 ;;; Drop excess pings
chain=input action=drop protocol=icmp
9 ;;; From our LAN
chain=input action=accept src-address=192.168.200.0/24
in-interface=ether2
14 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"
15 ;;; Drop everything else
chain=input action=drop
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 203147
Url: https://administrator.de/contentid/203147
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
11 Kommentare
Neuester Kommentar
Die erste Adresse ist von Google:
NetRange: 173.194.0.0 - 173.194.255.255
CIDR: 173.194.0.0/16
OriginAS: AS15169
NetName: GOOGLE
OrgName: Google Inc.
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Die 2te von Facebook Irland:
inetnum: 31.13.64.0 - 31.13.127.255
netname: IE-FACEBOOK-20110418
descr: Facebook Ireland Ltd
country: IE
source: RIPE # Filtered
org-name: Facebook Ireland Ltd
org-type: LIR
address: Facebook Ireland Ltd
und die 3te von Softlayer Texas:
NetRange: 50.22.0.0 - 50.23.255.255
CIDR: 50.22.0.0/15
OriginAS: AS36351
NetName: SOFTLAYER-4-9
NetType: Direct Allocation
Comment: 3 Bars for Life!
OrgName: SoftLayer Technologies Inc.
OrgId: SOFTL
Address: 4849 Alpha Rd.
City: Dallas
StateProv: TX
Die beiden letzten sind HTTPS Connctions. Vermutlich Robots oder sowas...
NetRange: 173.194.0.0 - 173.194.255.255
CIDR: 173.194.0.0/16
OriginAS: AS15169
NetName: GOOGLE
OrgName: Google Inc.
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Die 2te von Facebook Irland:
inetnum: 31.13.64.0 - 31.13.127.255
netname: IE-FACEBOOK-20110418
descr: Facebook Ireland Ltd
country: IE
source: RIPE # Filtered
org-name: Facebook Ireland Ltd
org-type: LIR
address: Facebook Ireland Ltd
und die 3te von Softlayer Texas:
NetRange: 50.22.0.0 - 50.23.255.255
CIDR: 50.22.0.0/15
OriginAS: AS36351
NetName: SOFTLAYER-4-9
NetType: Direct Allocation
Comment: 3 Bars for Life!
OrgName: SoftLayer Technologies Inc.
OrgId: SOFTL
Address: 4849 Alpha Rd.
City: Dallas
StateProv: TX
Die beiden letzten sind HTTPS Connctions. Vermutlich Robots oder sowas...
Nabend,
wenn Dein Lan aus 192.168.200.0/24 Adressen besteht stellt sich für mich die Frage woher denn die Source Adressen
herkommen die alle nichts mit Deinem IP-Adressraum zu tun haben ?
Die Destination 217.237.151.205:53 sind DNS anfragen ausgehend von der 92.233.48.156:diverser Ports
Beide IP Adressräume sind von der Telekom.
Solution: Wer aus eurem Netz verbindet sich von der 92.233.48.156 nach -> 217.237.205.205 ??
Die kannst Du ja erstmals auf der Firewall sperren.
Gruss
wenn Dein Lan aus 192.168.200.0/24 Adressen besteht stellt sich für mich die Frage woher denn die Source Adressen
herkommen die alle nichts mit Deinem IP-Adressraum zu tun haben ?
Die Destination 217.237.151.205:53 sind DNS anfragen ausgehend von der 92.233.48.156:diverser Ports
Beide IP Adressräume sind von der Telekom.
Solution: Wer aus eurem Netz verbindet sich von der 92.233.48.156 nach -> 217.237.205.205 ??
Die kannst Du ja erstmals auf der Firewall sperren.
Gruss
Genau Alchimedes, das fragte ich mich auch, wie kommt eine Verbindung aus diesem Adressraum zustande?
Wie kann denn eine Adresse 10.131.164.227 sich mit Google und Facebook etc. verbinden, wenn die Firewall kein input von außen durchlässt und kein forward von innen das aus meinem IP Kreis anfragt?
Das checke ich nicht.
Die 92.233.48.156 ist meine WAN IP der Telekom, die verbindet sich mit dem TK DNS 217.237.205.205! Das ist ja so ok... durch das NAT.
Wie kann ich denn ermitteln woher diese 10er IP kommt?
Wie kann denn eine Adresse 10.131.164.227 sich mit Google und Facebook etc. verbinden, wenn die Firewall kein input von außen durchlässt und kein forward von innen das aus meinem IP Kreis anfragt?
Das checke ich nicht.
Die 92.233.48.156 ist meine WAN IP der Telekom, die verbindet sich mit dem TK DNS 217.237.205.205! Das ist ja so ok... durch das NAT.
Wie kann ich denn ermitteln woher diese 10er IP kommt?
Hallo ,
sobald eine Verbindung von Innen nach außen steht "stateful" steht Sie.
Weil, wie solltest Du sonst von Innen das Internet erreichen?
Der 10 Adressraum ist auch ein privater Adressraum. Also vieleicht WLAN ?
Sonst direkt auf der Firewall sperren.. irgendwer wird sich schon beschweren.
Ansonsten hat aqui mich noch auf eine Idee gebracht: Die Timeouts und die UDP Connections
Timeout alle bei 5.34 Protokoll 17 ?
Und die src 192.168.100.253:5678 -> dest 255.255.255.255:5678
Das heisst hier wird von der 192. ins Internet nen UDP Broadcast veranstaltet.
hier die Solution: http://forum.mikrotik.com/viewtopic.php?f=2&t=19812
Gruss
sobald eine Verbindung von Innen nach außen steht "stateful" steht Sie.
Weil, wie solltest Du sonst von Innen das Internet erreichen?
Der 10 Adressraum ist auch ein privater Adressraum. Also vieleicht WLAN ?
Sonst direkt auf der Firewall sperren.. irgendwer wird sich schon beschweren.
Ansonsten hat aqui mich noch auf eine Idee gebracht: Die Timeouts und die UDP Connections
Timeout alle bei 5.34 Protokoll 17 ?
Und die src 192.168.100.253:5678 -> dest 255.255.255.255:5678
Das heisst hier wird von der 192. ins Internet nen UDP Broadcast veranstaltet.
hier die Solution: http://forum.mikrotik.com/viewtopic.php?f=2&t=19812
Gruss
Grundsätzlich sind wir bisher auch nicht schlecht damit gefahren einfach generell die Kommunikation (übers NAT) auf Port 53 (TCP,UDP) zu sperren. Direkt dabei wird auch die direkte Kommunikation auf Port 25 TCP blockiert.
Zum einen hilft es infizierte Rechner zu finden, bei denen irgendein Trojaner die DNS-Einstellungen manipuliert hat (denn der kommt nicht mehr raus und irgendwer schreit dann) - zum anderen weiß man dann wo man bei solchen Meldungen suchen muss, denn ein Client kommt ja dann eigentlich nicht infrage.
Was die 10er-IP angeht:
Das passiert mit manchen Mobiltelefonen oder Tablets manchmal: Nämlich dann wenn sie parallel mit dem UMTS-Netz verbunden sind und die DNS-Server des Mobilfunkanbieters fragen wollen. Dagegen hilft (wenn die Mikrotiks das können) die Unicast-Reverse-Path-Verification einzuschalten, dann prüft der Router ob er für die Quelladresse der Datenpakete auf dem Ingress-Interface auch eine passende Route zurück kennt.
Wenn du möchtest kannst du mir per PM ja mal deine öffentliche IP zukommen lassen, ich würde dann mal NMAP drübergucken lassen (dem ich mehr vertraue als irgendwelchen Webseiten)
Vielleicht ist ja wirklich der DNS-Server des Mikrotik weltweit offen, antwortet aber nur mit SERVFAIL oder so - was für Reflector-Angriffe vollkommen ausreichend ist.
Was natürlich bei verbindungslosen Protokollen wie UDP fast immer passieren kann ist, dass jemand einfach deine zu diesem Zeitpunkt verwendete IP gespoofed hat und die Telekom selbst nur einen Abuse-Report von Dritten erhalten hat.
Zum einen hilft es infizierte Rechner zu finden, bei denen irgendein Trojaner die DNS-Einstellungen manipuliert hat (denn der kommt nicht mehr raus und irgendwer schreit dann) - zum anderen weiß man dann wo man bei solchen Meldungen suchen muss, denn ein Client kommt ja dann eigentlich nicht infrage.
Was die 10er-IP angeht:
Das passiert mit manchen Mobiltelefonen oder Tablets manchmal: Nämlich dann wenn sie parallel mit dem UMTS-Netz verbunden sind und die DNS-Server des Mobilfunkanbieters fragen wollen. Dagegen hilft (wenn die Mikrotiks das können) die Unicast-Reverse-Path-Verification einzuschalten, dann prüft der Router ob er für die Quelladresse der Datenpakete auf dem Ingress-Interface auch eine passende Route zurück kennt.
Wenn du möchtest kannst du mir per PM ja mal deine öffentliche IP zukommen lassen, ich würde dann mal NMAP drübergucken lassen (dem ich mehr vertraue als irgendwelchen Webseiten)
Vielleicht ist ja wirklich der DNS-Server des Mikrotik weltweit offen, antwortet aber nur mit SERVFAIL oder so - was für Reflector-Angriffe vollkommen ausreichend ist.
Was natürlich bei verbindungslosen Protokollen wie UDP fast immer passieren kann ist, dass jemand einfach deine zu diesem Zeitpunkt verwendete IP gespoofed hat und die Telekom selbst nur einen Abuse-Report von Dritten erhalten hat.
Hi Maxi, du hast eine PM. Danke schonmal.
Das mit den Phones kann sein, ich habe 3 hier im WLAN. Ein Unicast Reverse Path Forwarding (URPF) haben die Mikrotik noch nicht, steht unter MikroTik RouterOS/Feature Requests im Mikrotik Wiki.
Das mit den Phones kann sein, ich habe 3 hier im WLAN. Ein Unicast Reverse Path Forwarding (URPF) haben die Mikrotik noch nicht, steht unter MikroTik RouterOS/Feature Requests im Mikrotik Wiki.
Hi Alchimedes,
die :5678 Neighbors Geschichte habe ich abgestellt.
Danke für den Link.
Was kann ich mit dne Timeouts noch machen?
die :5678 Neighbors Geschichte habe ich abgestellt.
Danke für den Link.
Was kann ich mit dne Timeouts noch machen?
Hi tom1234,
habe gerade mal ein bisschen rumgescannt, aber der Router ist dichter als ein Hippie auf einem Reggae-Festival
Auch explizit an die IP gerichtete DNS-Anfragen sind absolut unbeantwortet geblieben.
Ich würde mal sagen: Da muss die DTAG ein bisschen konkreter werden und vielleicht auch erläutern woher sie diese Info haben?
habe gerade mal ein bisschen rumgescannt, aber der Router ist dichter als ein Hippie auf einem Reggae-Festival
Auch explizit an die IP gerichtete DNS-Anfragen sind absolut unbeantwortet geblieben.
Ich würde mal sagen: Da muss die DTAG ein bisschen konkreter werden und vielleicht auch erläutern woher sie diese Info haben?
Wenn das alle deine Regeln sind hast du komplett den forward-Chain vergessen und Router OS ist ein Router, d.h. es routet - von überall nach überall.
RP Filtering gibt es ab Version 6.
http://wiki.mikrotik.com/wiki/Manual:IP/Settings
Ein Unicast Reverse Path Forwarding (URPF) haben die Mikrotik noch nicht,
RP Filtering gibt es ab Version 6.
http://wiki.mikrotik.com/wiki/Manual:IP/Settings
Danke Dog, du hast recht, ich habe mal folgendes zugefügt...
0 ;;; Accept established connections
chain=input action=accept connection-state=established
1 ;;; Accept established connections
chain=forward action=accept connection-state=established
2 ;;; Accept related connections
chain=input action=accept connection-state=related
3 ;;; Accept related connections
chain=forward action=accept connection-state=related
4 ;;; Drop Open-DNS-Resolver
chain=input action=drop protocol=udp in-interface=pppoe-out1 dst-port=53
5 ;;; Drop Open-DNS-Resolver
chain=input action=drop protocol=tcp in-interface=pppoe-out1 dst-port=53
6 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid
7 ;;; Drop invalid connections
chain=forward action=drop connection-state=invalid
8 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2
9 ;;; Drop excess pings
chain=input action=drop protocol=icmp
10 ;;; From our LAN
chain=input action=accept src-address=192.168.100.0/24
in-interface=ether2
11 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"
12 ;;; Drop everything else
chain=input action=drop
Und ich schaue mir die Version 6 einmal an.
Gruß
0 ;;; Accept established connections
chain=input action=accept connection-state=established
1 ;;; Accept established connections
chain=forward action=accept connection-state=established
2 ;;; Accept related connections
chain=input action=accept connection-state=related
3 ;;; Accept related connections
chain=forward action=accept connection-state=related
4 ;;; Drop Open-DNS-Resolver
chain=input action=drop protocol=udp in-interface=pppoe-out1 dst-port=53
5 ;;; Drop Open-DNS-Resolver
chain=input action=drop protocol=tcp in-interface=pppoe-out1 dst-port=53
6 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid
7 ;;; Drop invalid connections
chain=forward action=drop connection-state=invalid
8 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2
9 ;;; Drop excess pings
chain=input action=drop protocol=icmp
10 ;;; From our LAN
chain=input action=accept src-address=192.168.100.0/24
in-interface=ether2
11 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"
12 ;;; Drop everything else
chain=input action=drop
Und ich schaue mir die Version 6 einmal an.
Gruß
Zitat von @LordGurke:
Was natürlich bei verbindungslosen Protokollen wie UDP fast immer passieren kann ist, dass jemand einfach deine zu diesem
Zeitpunkt verwendete IP gespoofed hat und die Telekom selbst nur einen Abuse-Report von Dritten erhalten hat.
Was natürlich bei verbindungslosen Protokollen wie UDP fast immer passieren kann ist, dass jemand einfach deine zu diesem
Zeitpunkt verwendete IP gespoofed hat und die Telekom selbst nur einen Abuse-Report von Dritten erhalten hat.
Das wird es vermutlich sein, die letzte Antwort von der TK ist etwas, naja...
Sehr geehrter Herr XXXXX,
für Ihr umsichtiges Eingreifen und das in uns gesetzte Vertrauen bedanken wir uns herzlich.
Ob das Problem vollständig beseitigt wurde, können wir nicht sagen. Denn eine Prüfung eines Anschlusses bzw. Internetzugangs, ob darüber Spam-Mails versendet werden oder wurden, oder ob sonstige Virenaktivitäten vorliegen, ist uns nicht möglich. Eine solche Prüfung setzte voraus, dass wir den gesamten Datenverkehr eines Internetzugangs überwachen und protokollieren könnten. Dies wäre jedoch rechtswidrig.
Wir als Mitarbeiter der Abuse-Abteilung kennen grundsätzlich nur zwei Zustände bezüglich eines Internetzugangs:
• Es treffen Beschwerden ein.
• Es treffen keine Beschwerden ein.
Ersteres beweist nichts, sondern ist nur ein positives Indiz, während Letzteres zwar beweiskräftig, aber natürlich negativ ist.
Sofern weiterhin keine Beschwerden mehr bei uns eingehen, werden wir den Vorgang schließen. Sollten wir erneut Beschwerden erhalten, werden wir Sie per E-Mail an Ihr t-online.de-Postfach informieren.
Bitte schicken Sie uns keine Dateianhänge, da wir sie aus Sicherheitsgründen nicht öffnen können.
Als Abuse-Abteilung haben wir naturgemäß fast minütlich mit Viren der allerneuesten Art zu tun, die von Virenscannern noch gar nicht erkannt werden. Die Sicherheitsvorkehrungen und Laborbedingungen in unserer Abteilung sind ganz sicher auch im Interesse aller Kunden, mit denen wir Schriftwechsel führen. Wir bitten um Ihr Verständnis.
Mit freundlichen Grüßen
