Wie richtig Einbrüche verhindern?

[guest24551]

Ich versuche es einfach mal hier .. nochmal ...

Zum besseren Verständnis bzgl. IP

      Internet
            :
            : Cable - Vodafone Germany
            :
      .-----+-----.
      |  Gateway  |  Fritz-Box Cable Router
      '-----+-----'
            |
        WAN | 192.168.2.65 Opnsense DHCP
            |
      .-----+------.
      |  OPNsense
      '-----+------'   
            |
        LAN | 192.168.1.1/24
            |
      .-----+------.
      | LAN-Client | Debian
      '-----+------'

Das Problem ist folgendes:

Meine Firewall wird pemanent gescannt angegriffen, bis die Angreifer irgendwann erfolg haben.

Siehe Log Suricata:

Code: [Select]

2020-07-13T14:46:01.939317+0200
2020-07-13T14:46:01.939317+0200
2831048 blocked WAN 54.235.136.99 443 192.168.2.65 7439 ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org)

Es dauert nicht lange, dann wird die Schwachstelle gefunden. Suricata hilft mir nicht, genauso wenig wie die Default Firewall rules. Es dauert immer ein paar Tage nach der Einrichtung, aber irgendwann wird dann per UDP ein haufen cryptischer Pakete von den Angreifern übertragen, die Suricata irgendwie infizieren.

Code: [Select]

2020-07-08T23:10:00 suricata[38610]: [100658] <Notice> -- all 3 packet processing threads, 4 management threads initialized, engine started.
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop smb any any -> $DC_SERVERS 445 (msg: "ATTACK AD [PTsecurity] Possible MS-RPRN abuse. Hash or Ticket theft"; flow: to_server, established, no_stream; content:"SMB"; offset: 5; depth: 3; content: "|05 00 00|"; distance: 0; content: "|41 00|"; distance: 19; within: 2; content: "|00 01 00 00|"; distance: 36; within: 4; content: "|5C 00 5C 00|"; fast_pattern; distance: 0; flowbits: isset, DCERPC.BIND.SPOOLSS; reference: url, posts.specterops.io/not-a-security-boundary-breaking-forest-trusts-cd125829518d; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; classtype: attempted-recon; sid: 10004153; rev: 1;)" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 273
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp !$DC_SERVERS any -> $DC_SERVERS 389 (msg: "ATTACK [PTsecurity] DCShadow: Fake DC Creation"; flow: established, to_server; content: "|68 84 00|"; content: "CN="; distance: 5; within: 3; content: "CN=Servers,CN="; distance: 0; content: ",CN=Sites,CN=Configuration,DC="; distance: 0; content: "objectClass"; distance: 0; content: "server"; distance: 0; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002559; rev: 2; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 215
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "ATTACK AD [PTsecurity] DCShadow Replication Attempt - DRSUAPI_REPLICA_ADD from non-DC"; flow: established, to_server, no_stream; content: "|05 00 00 03|"; depth: 4; content: "|05 00|"; distance: 18; within: 2; flowbits: isset, RPC.Bind.DRSUAPI; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002558; rev: 1; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 213
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "ATTACK AD [PTsecurity] DCShadow Replication Attempt"; flow: established, to_server; content: "|05 00 0B|"; depth: 3; content: "|35 42 51 E3 06 4B D1 11 AB 04 00 C0 4F C2 DC D2|"; distance: 0; flowbits: set, RPC.Bind.DRSUAPI; flowbits: noalert; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002557; rev: 2; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 211
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp $HOME_NET any -> $DC_SERVERS 88 (msg: "ATTACK [PTsecurity] Overpass the hash. Encryption downgrade activity to ARCFOUR-HMAC-MD5"; flow: no_stream, established, to_server; content: "|A1 03 02 01 05 A2 03 02 01 0A|"; offset: 12; depth: 10; content: "|A1 03 02 01 02|"; distance: 5; within: 6; content: "|A0 03 02 01 17|"; distance: 6; within: 6; content: "krbtgt"; distance: 0; xbits: set, Krb5.AsReq, track ip_src, expire: 10; classtype: attempted-user; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002228; rev: 1; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 171
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:05:51 suricata: [100658] <Warning> -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(317)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.
2020-07-08T23:05:51 suricata: [100526] <Notice> -- This is Suricata version 4.1.8 RELEASE
2020-07-08T23:05:51 suricata[83153]: [100201] <Notice> -- Stats for 'igb0+': pkts: 91822, drop: 5207 (5.67%), invalid chksum: 0
2020-07-08T23:05:51 suricata[83153]: [100201] <Notice> -- Stats for 'igb0': pkts: 142974, drop: 0 (0.00%), invalid chksum: 0
2020-07-08T23:05:50 suricata[83153]: [100201] <Notice> -- Signal Received. Stopping engine.
2020-07-08T22:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:28014
2020-07-08T22:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:44941
2020-07-08T22:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:43728
2020-07-08T22:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:51898
2020-07-08T22:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.21.213.140:443 -> 192.168.2.65:27449
2020-07-08T22:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.21.213.140:443 -> 192.168.2.65:29040
2020-07-08T22:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 184.73.165.106:443 -> 192.168.2.65:25054
2020-07-08T22:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 184.73.165.106:443 -> 192.168.2.65:55965
2020-07-08T22:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:9766
2020-07-08T22:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:63278
2020-07-08T22:06:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:24312
2020-07-08T22:06:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:8201
2020-07-08T21:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.251.25:443 -> 192.168.2.65:37805
2020-07-08T21:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.251.25:443 -> 192.168.2.65:10832
2020-07-08T21:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:42865
2020-07-08T21:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:51207
2020-07-08T21:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:13562
2020-07-08T21:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:33944
2020-07-08T21:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.255.253:443 -> 192.168.2.65:62216
2020-07-08T21:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.255.253:443 -> 192.168.2.65:57836
2020-07-08T21:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.221.234.156:443 -> 192.168.2.65:13134
2020-07-08T21:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.221.234.156:443 -> 192.168.2.65:3524

Mein Problem ist, dass ich nicht weiß wie ich das verhindern kann. Scheinbar versagen hier die Sicherheitsmechaniken von Opnsense.
Ich möchte Anfragen über OpenDNS filtern, aber alles was von außen kommt und nicht von OpenDNS ist, soll geblockt werden. Das ist die Theorie, aber ob die Praxis auch so funktioniert, weiß ich eben nicht. Ich finde leider keinen Ratgeber mit den man die Rules richtig anpassen kann, so dass Angriffe über gewisse Ports quasi unmöglich werden.

Hat jemand ähnliches erlebt, oder weiß wie man gewisse Angriffsvektoren mit Firewall Regeln richtig blockiert?

[chemlud]

Wenn du auf dem WAN keine allow rules hast, sitzt eine infizierte Kiste in deinem LAN (oder irgendwas fragt ipfy.org ab, warum auch immer), da kann auch die Firewall wenig machen, wenn du deine Clients nicht kontrolliert in's Netz lässt (oder eben garnicht).

Untersuch deine Clients und lass die arme Firewall in Frieden.

[mimugmail]

Port Forward für alle Dns Pakete aus dem LAN auf die OPN biegen, und dann Unbound sagen welche Dns Server er verwenden soll

[JeGr]

> Meine Firewall wird pemanent gescannt angegriffen, bis die Angreifer irgendwann erfolg haben.

Sagt wer? Logs? Alles was ich da sehe was ETPRO liefert ist "hallo da nutzt jemand ipify.org zum Abfragen deiner externen IP. Was hat das mit DNS Angriff zu tun?

> wird dann per UDP ein haufen cryptischer Pakete von den Angreifern übertragen, die Suricata irgendwie infizieren.

Sorry, aber nochmal: Ich sehe da gar keinen Angriff.
von unten nach oben sind das
- Ipify Zugriffe (kein Drama.
- Surricata wurde neu gestartet / reinitialisiert
- irgendwelche Variablen von Surricata nicht definiert, Warnings und Errors beim Start von Surricata.

Mehr seh ich da nicht.

> Mein Problem ist, dass ich nicht weiß wie ich das verhindern kann. Scheinbar versagen hier die Sicherheitsmechaniken von Opnsense.

Ich gehe eher von einem Verständnisproblem aus, ws wirklich ein "Angriff" ist und was einfach nur geloggt wird mit "ob das gewünscht ist oder nicht - musst du wissen - aber das passiert hier gerade". IDS/IPS lesen und verstehe ist eben leider wie vielfach suggeriert kein "Schalter an und gut", sondern ein Einlesen und Verstehen, was da geloggt wird und was das heißt. Trotzdem wird IDS/IPS immer wieder als Allheilmittel und SuperSecurity NGFW "genutzt" indem man einfach nur ein Ruleset reinschmeißt und wenn es Alarme wirft Panik bekommt Man muss auch verstehen und sich einlesen, WAS man da tut und loggt. Und ob es was ist, was man möchte - dann muss man die Regel eben ausmachen oder unterdrücken - oder man muss die Quelle finden und das eliminieren.

> Ich möchte Anfragen über OpenDNS filtern, aber alles was von außen kommt und nicht von OpenDNS ist, soll geblockt werden. Das ist die Theorie, aber ob die Praxis auch so funktioniert, weiß ich eben nicht. Ich finde leider keinen Ratgeber mit den man die Rules richtig anpassen kann, so dass Angriffe über gewisse Ports quasi unmöglich werden.

Dazu würde ich empfehlen erstmal generell OPNsense Dokus zu lesen, wie Regeln funktionieren und wo sie angelegt werden müssen. Da OPNsense wie jede gute Firewall Stateful arbeitet muss z.B. überhaupt nichts von extern geöffnet werden, weil das die Firewall selber macht - nämlich die Antworten auf Anfragen _von innen/LAN_ automatisch reinzulassen. Das ist Pflichtprogramm bei Stateful Filtering. Somit würde für deinen Wunsch schlicht und ergreifend genügen wenn du

a) alle DNS Abfragen intern auf die Firewall umleitest (wie @mimugmail schon schreibt) und
b) dem DNS Resolver / unbound sagst, er soll alles an OpenDNS weiterschicken. Also Forward Mode an und in in den Systemeinstellungen die beiden DNSe von OpenDNS hinterlegen. Fertig.

> Ich finde leider keinen Ratgeber mit den man die Rules richtig anpassen kann, so dass Angriffe über gewisse Ports quasi unmöglich werden.

Wozu auch, wie mehrfach schon gesagt: DEFAULT ist: block any any! Ist auf WAN / InterfaceXY nichts definiert wird automatisch alles geblockt. Und egal wo, jede neue Sense die man ans Netz bringt loggt erstmal einen riesen sch...großen Batzen Pakete auf dem WAN selbst wenn alles geblockt ist. Weil man es sieht. Im Gegensatz zu irgendwelchen FritzBoxen oder sonstigen SoHo Kram. Und dann sieht man auch, wie viel "Grundrauschen" man inzwischen im Netz hat. Der Großteil weiß gar nicht(!) dass DU jetzt da bist und auf der IP hörst. Weil der Großteil an Grundrauschen Bullshit ist. Irgendwelche Uralt Kisten, Malware und Botnetze, kaputte/ungepatchte Server etc. die einfach nur ihren Müll volle Kanne ins Netz kippen. Ab und an sieht man sogar mal wieder irgendwelche Uralt Windows Trojaner Versuche vorbeikommen. Dazwischen Portscans, irgendwelche halb-freundlichen Netzwerkscanner die ständig irgendwelche Adressbereiche abklappern etc etc. Grundrauschen mit Murks

Hoffe das machts verständlicher

[ole]

Hi,

ich habe ein ähnliches Setup mit Cable-Router, OPNsense etc. wie Du bzw. wie JeGr vorgeschlagen hat. Hier einmal wie ich vorgegangen bin:

- [OpenDNS](https://docs.opnsense.org/manual/opendns.html), Account anlegen, DNS Anfragen werden nach Deinen Angaben schon vor gefiltert (Porn etc. on/off obliegt Dir X-)
 Damit werden die entsprechenden Einträge in den DNS server unter System eingetragen, die nicht durch das DHCP WAN (also per Modem) überschrieben werden sollten, siehe Anhang
- [Unbound DNS](https://docs.opnsense.org/manual/unbound.html) einrichten, siehe Anhang (die Custom Settings ignoriere bitte)
- [HOWTO - Redirect all DNS Requests to Opnsense ](https://forum.opnsense.org/index.php?topic=9245.0)
- im WAN habe ich nun keine Regeln, wie gesagt: per default wird alles geblockt.

mache ich nun aus dem internen! Netz einen Scan auf meine externe IP:

Code: [Select]

sudo nmap -p22,53,80,443  xxxx.ddns.net
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-13 19:48 CEST
Nmap scan report for xxxx.ddns.net (AA.BB.CC.DD)
Host is up (0.00048s latency).
rDNS record for AA.BB.CC.DD: cool-aa-bb-cc-dd.provider.de

PORT    STATE    SERVICE
22/tcp  filtered ssh
53/tcp  open     domain
80/tcp  filtered http
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 1.37 seconds

so scheint zB. der Port 53 von außen offen zu sein. Machst Du aber mittels eines online Port Scanners (zB. http://www.dnstools.ch/port-scanner.html) einen Test auf Deine externe IP:53 (oder eben 80,443,...), so ist dieser geschlossen! Erfolgt kein Redirect werden viele DNS queries mit imo teilweise fragwürdigen IP/DNS Namen geloggt (so war es bei mir zumindest).

Die Profis hier können den Grund für obiges sicher besser erklären - ich denke aufgrund der bekannten/notwendigen Route zum Model/WAN und NAT reflection? klappt es über das interne Netzwerk so "einfach". Aus dem gleichen Grunde kommst Du auch via dem WAN auf das WebUI Deiner Fritzbox (bzw. Cable Modem).

Evtl. bringt das ja etwas Licht in Deine Sache?

[dsecure]

Hi,

ich habe ein ähnliches Setup mit Cable-Router, OPNsense etc. wie Du bzw. wie JeGr vorgeschlagen hat. Hier einmal wie ich vorgegangen bin:
[...]

Moin, deine Erklärung finde ich gut, ich hätte aber eine Frage, auf deinem letzten Bild, die Konfig von Unbound nehme ich an, was genau macht die Einstellung bei Custom Options bei dir?

Das mit der Port 53 Umleitung auf 127.0.0.1 funktioniert auch bei mir, als Default DNS habe ich mein Pi-Hole angegeben, zu welchem dann weiter gelietet wird, bist du mit open-dns soweit zufrieden und hast du da evtl. einen direkten Vergleich zu Pi-Hole?

Block Any bezieht sich bei euch (JeGr und ole) auf die WAN Schnittstelle oder hab ich da was überlesen? Bei LAN ist bei mir unteranderem als default zB. die anti aussperrregel und die NAT konfig drinnen, sollte so passen oder?

[guest24551]

So guten Morgen allerseits und danke für das Feedback.

Leider kann ich hier kein Paketcapture hochladen, weil das die erlaubte größe überschreitet.

Ich habe noch einen Teil vergessen zu erwähnen. Das mag ein kleiner Log auszug sein, aber das ist der Anfang von "etwas größerem".
IPIFY.ORG scannt in regelmäßigen 10 Minuten abständen.
Beim 1. Angriff hat man es geschafft mittels DNS-Rebind die GUI von meinem managed switch zu immitieren. Aufgefallen ist mir das erst durch falsche und geänderte DNS Einträge auf dem Switch die nicht von mir stammen. Also insofern darf ich schon etwas Panik schieben, wenn soetwas (mehrfach) durch meine Firewall dringt.

Wie ich auf DNS komme?

Aus Maltrail lese ich das so raus. (Dies ist der Stand nach dem letzten Angriff) (siehe Anhang)
Wenn es von innen kommen würde, würde dann nicht die LAN Adresse statt WAN als Ziel angegeben werden?


Bis auf das weiterleiten der DNS requests, habe ich alles ähnlich wie @Ole eingerichtet.

Ich habe mal die Zeitstempel in Suricata verglichen und mir ist aufgefallen, dass meine Linux Kiste zu der Zeit nicht in Betrieb war und es ist der einzige Client hinter der Firewall. Alles andere befindet sich im Fritzbox LAN. Aber selbst da, sind da bis auf 2 Smartphones und 1 eBook nix an.

[guest24551]

Ich habe nun nachträglich das Port Forwarding auf 53 eingerichtet. Alles andere hat soweit gepasst.

Um nochmal auf JeGr's kommentar zurück zu kommen. Die Dokumentation habe ich mir bereits mehrfach, aber noch nicht vollständig durchgelesen. Ich stoße auch oft vor vielen kleineren Problemen. Z.B. Kann ich keine GeoIP Aliase trotz der Einrichtung nach Doku abrufen, weil Opnsense scheinbar keinen gescheiten Handshake mit der URL "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&license_key=........ " hinbekommt.

DNS o. TLS habe ich ebenfalls schon eine Weile am laufen. Ich versuche momentan auch DNSSEC richtig einzurichten, allerdings bekomme ich zu z.B. Internet.nl immer noch keine Chain of Trust hin.

Ich bin noch im Lernprozess, aber ich entdecke ständig neue Features von Opnsense.

[micneu]

zu maxmind kannst du im forum suche, da gab es vor kurzem einen beitrag...

[JeGr]

> IPIFY.ORG scannt in regelmäßigen 10 Minuten abständen.

Ipify.org scannt nicht. Geh doch mal auf die Seite. https://www.ipify.org/ und schau dir an, WAS die eigentlich machen. Sie bieten lediglich einen Service an, dass du via API/programmatisch deine externe IP abfragen kannst. Nichts anderes wie http://checkip.dyndns.org nur eben für Entwickler zur Nutzung in Programmen und Tools. Warum sollten die also DICH angreifen?

> Beim 1. Angriff hat man es geschafft mittels DNS-Rebind die GUI von meinem managed switch zu immitieren. Aufgefallen ist mir das erst durch falsche und geänderte DNS Einträge auf dem Switch die nicht von mir stammen. Also insofern darf ich schon etwas Panik schieben, wenn soetwas (mehrfach) durch meine Firewall dringt.

Ich habe keine Ahnung was da wo wie vorher vorgefallen ist, aber das klingt einfach weird. Dein managed Switch macht DNS und hat geänderte DNS Einträge? Was hast du denn für Switche auf denen selbst DNS aktiv ist wenn du davor eine OPNsense hast die DNS macht? Verstehe ich nicht ganz. Zudem nimmst du nur an, dass irgendwas durch deine Firewall "drang" und deinen Switch verstellt hat. So richtig Sinn macht das für mich noch keinen, aber mag korrekt so passiert sein, das maße ich mir nicht an zu verstehen ohne Details zu kennen.

In deinem Screenshot unten wird auch Ipify an dem du dich etwas festbeißt wie ich finde auch lediglich als "IPInfo Suspicious" geflaggt, NICHT als Malware oder sonstwie bösartig. Da deine IP .2.65 aber lustige Sachen macht mit DNS und Malware Sachen aufruft laut deinem Screen, würde ich eher mal die interne IP .2.65 abklemmen und untersuchen, was darauf läuft und was für Mist die Kiste treibt. Klingt nämlich eher als hätte sich eine Kiste intern nen Trojaner oder Malware eingefangen und würde Blödsinn machen, als dass irgendjemand durch deine Firewall durchtunnelt Das würde auch erklären, was von der IP Ipify nutzt, wahrscheinlich eben eine Malware auf dem Rechner, die ihre externe IP rausfinden will um sich ggf. rauszutunneln oder Murks reinzuladen.

Zu GeoIP und Co hatte ja Mic schon geschrieben, dass das nicht mehr geht/ging liegt am neuen Licensing von MaxMind

[guest24551]

> IPIFY.ORG scannt in regelmäßigen 10 Minuten abständen.

Ipify.org scannt nicht. Geh doch mal auf die Seite. https://www.ipify.org/ und schau dir an, WAS die eigentlich machen. Sie bieten lediglich einen Service an, dass du via API/programmatisch deine externe IP abfragen kannst. Nichts anderes wie http://checkip.dyndns.org nur eben für Entwickler zur Nutzung in Programmen und Tools. Warum sollten die also DICH angreifen?

> Beim 1. Angriff hat man es geschafft mittels DNS-Rebind die GUI von meinem managed switch zu immitieren. Aufgefallen ist mir das erst durch falsche und geänderte DNS Einträge auf dem Switch die nicht von mir stammen. Also insofern darf ich schon etwas Panik schieben, wenn soetwas (mehrfach) durch meine Firewall dringt.

Ich habe keine Ahnung was da wo wie vorher vorgefallen ist, aber das klingt einfach weird. Dein managed Switch macht DNS und hat geänderte DNS Einträge? Was hast du denn für Switche auf denen selbst DNS aktiv ist wenn du davor eine OPNsense hast die DNS macht? Verstehe ich nicht ganz. Zudem nimmst du nur an, dass irgendwas durch deine Firewall "drang" und deinen Switch verstellt hat. So richtig Sinn macht das für mich noch keinen, aber mag korrekt so passiert sein, das maße ich mir nicht an zu verstehen ohne Details zu kennen.

In deinem Screenshot unten wird auch Ipify an dem du dich etwas festbeißt wie ich finde auch lediglich als "IPInfo Suspicious" geflaggt, NICHT als Malware oder sonstwie bösartig. Da deine IP .2.65 aber lustige Sachen macht mit DNS und Malware Sachen aufruft laut deinem Screen, würde ich eher mal die interne IP .2.65 abklemmen und untersuchen, was darauf läuft und was für Mist die Kiste treibt. Klingt nämlich eher als hätte sich eine Kiste intern nen Trojaner oder Malware eingefangen und würde Blödsinn machen, als dass irgendjemand durch deine Firewall durchtunnelt Das würde auch erklären, was von der IP Ipify nutzt, wahrscheinlich eben eine Malware auf dem Rechner, die ihre externe IP rausfinden will um sich ggf. rauszutunneln oder Murks reinzuladen.

Zu GeoIP und Co hatte ja Mic schon geschrieben, dass das nicht mehr geht/ging liegt am neuen Licensing von MaxMind

Scannen mag das falsche Wort gewesen sein. Ich habe bereits gesehen, dass sie lediglich die API bereitstellen, aber auffällig ist, dass die Meldungen bzgl. IPIFY aufhören, sobald scheinbar eingedrungen wurde. Ich habe das vor ein Paar Tagen mal live über das WAN Interface gecaptured und da habe ich das ganze dann im Detail beobachten können. Wie gesagt, der Capture ist zu groß um das hier zu attachen.

Das mit dem Switch ist nicht weird. Du kannst ihm einen Nameserver vorgeben und als das DNS-Rebinding aktiv war, wurde auf den DNS Server von der bösen Domäne gezielt. Mein Switch hatte vorher den Nameserver Example.com, der dann später Examplea.com hieß. Den Nameserver bekommt der Switch per DHCP von Opnsense übermittelt.

Ich hatte das WAN Interface mehrmals zum Test abgestöpselt und dabei die Interfaces beobachtet. LAN und WAN sind unauffällig. Maltrail meldet auch keine vorkommnisse über einen längeren Zeitraum hinweg. 2 Tage später wieder angeschlossen und das WAN fängt wieder an fleißig mit den Angreifern zu kommunizieren. Das ließ sich auch live im Maltrail mitverfolgen. Es wird erst dann auffällig, wenn ich WAN wieder anschließe.

Jemand versucht mittels dieser API Zugriff zu erhalten und sendet eine Art Kill signal an Suricata, dass ihn zu einem Neustart zwingt und infiziert diesen danach. Das klingt für mich echt weird, aber das ist eine Tatsache und keine Einbildung.

Nachdem scheinbar Opnsense nicht mehr auffhören wollte über WAN nach draußen zu kommunizieren, habe ich die Firewall neu aufgesetzt. Und hier bin ich jetzt, beobachte wie das ganze wieder von vorne Anfängt.

[guest24551]

Manchmal kann ich posts nachträglich nicht richtig editieren... Bekomme Meldung: No subject was filled in.
The message body was left empty.

Was ich noch sagen wollte. Nach der Änderung von Examplea.com auf Example.com, bekam ich von Opnsense eine DNS-Rebinding Warnung angezeigt. Ich solle auf die Oberfläche nur per IP zugreifen.
Es ließ sich auch in Maltrail eine Tor Adresse ausfindig machen: irgendeineTor.examplea.com.onion oder etwas dergleichen.
Ganz schön verrücktes Zeug ist passiert. Dabei habe verfolge ich lediglich die Opnsense dokumentation...

[guest24551]

Damit ihr mal meine Settings sehen könnt:

[guest24551]

Sorry für den Spam!
Hier noch ein wenig zu Unbound

[micneu]

@g4njawizard sei mir bitte nicht böse, deine art kommt mir vor wie so ein pubertierender schnösel (sorry, will dich nicht beleidigen).
fang doch langsam an, gefühlt willst du alles auf einmal (du hast ca. 3 Themen gleichzeitig am laufen).
kleiner tipp, fang doch nochmal von vorne an, und richte doch erstmal ein paar sinnvolle firewall regeln an.
nutze und verstehe das system. ich bin auf alle fälle kein profi und will dir hier Vorschriften machen.
du kannst dich gerne bei mir per PM melden.