International Forums > German - Deutsch
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: ---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)
--- End code ---
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: ---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
--- End code ---
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: ---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
--- End code ---
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?
Navigation
[0] Message Index
[#] Next page
Go to full version