Messages

121

German - Deutsch / Re: Nach Upgrade auf 21.1 Error Updating Repositories

« on: January 29, 2021, 07:29:31 am »

Moin Franco,
Das heißt dann also, ich muss mich noch ne weile gedulden? Mir ist nur ein Dorn im Auge das die Plugins (verwaist) sind ^^...

Aber wenns nur daran liegt, ist's ja nur halb so wild.

122

German - Deutsch / Nach Upgrade auf 21.1 Error Updating Repositories

« on: January 29, 2021, 07:17:18 am »

Guten Morgen allerseits.

Seit dem gestrigen Upgrade von 20.7.8 auf 21.1 lassen sich keine Updates mehr überprüfen. Alle Plugins bleiben auf (verwaist)
Wenn ich nach Aktualisierungen Prüfe erhalte ich folgende Meldung.

Code: [Select]

Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
pkg-static: https://updates.sunnyvalley.io/opnsense/FreeBSD:12:amd64/21.1/LibreSSL/latest/meta.txz: Not Found
repository SunnyValley has no meta file, using default settings
pkg-static: https://updates.sunnyvalley.io/opnsense/FreeBSD:12:amd64/21.1/LibreSSL/latest/packagesite.txz: Not Found
Unable to update repository SunnyValley
Error updating repositories!
A firmware update is currently in progress.
Wenn ich andere Server auswähle, erhalte ich trotzdem die gleiche Meldung.

"Konnte das Repository auf dem ausgewählten Spiegelserver nicht finden."

Ist da was bekannt?

123

German - Deutsch / Re: Suricata - Block trotz disable und alarm

« on: October 06, 2020, 02:24:00 pm »

Aah, das hatte ich noch nie ausprobiert. Das es die Ecke gibt, hatte ich auch ganz vergessen. Muss ich testen. Danke für den Hinweis!

124

German - Deutsch / Re: Suricata - Block trotz disable und alarm

« on: October 06, 2020, 01:28:27 pm »

Auf den Gedanken bin ich auch schon gekommen, weil während der Installation der solange in der Schleife hing, bis der service eine Verbindung zum besagten Ziel aufbauen konnte.

Besagte Regel: siehe Anhang

Wenn der den HTTP request verschickt, wartet der bis code=200 erscheint. Im Log sieht das dann so aus.

Code: [Select]

[ INFO ] Updating asix ax88179 driver for kernel 5.4.51-v7+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-10-05 18:56:26--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... connected.
HTTP request sent, awaiting response... 200 OK
Length: 42895 (42K)
Saving to: ‘/tmp/ax88179_178a.ko’

     0K .......... .......... .......... .........             93%  365K=0.1s

2020-10-05 19:11:26 (365 KB/s) - Read error at byte 40296/42895 (Connection timed out). Retrying.

--2020-10-05 19:11:27--  (try: 2)  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 42895 (42K), 2599 (2.5K) remaining
Saving to: ‘/tmp/ax88179_178a.ko’

     0K ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,. .         100% 46.7M=0s

2020-10-05 19:11:28 (46.7 MB/s) - ‘/tmp/ax88179_178a.ko’ saved [42895/42895]

[ INFO ] Installing driver...
removed '/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko'
'/tmp/ax88179_178a.ko' -> '/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko'
[ INFO ] Running depmod...
[ INFO ] Cleaning up...
removed '/tmp/ax88179_178a.ko'
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.51-v7l+ /boot/kernel7l.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.51-v7l+ /boot/kernel7l.img
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.51-v8+ /boot/kernel8.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.51-v8+ /boot/kernel8.img
/etc/kernel/postinst.d/dietpi-USBridgeSig:
[ INFO ] Updating asix ax88179 driver for kernel 5.4.51-v8+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-10-05 19:11:28--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v8+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... connected.
HTTP request sent, awaiting response... 200 OK
Length: 66800 (65K)
Saving to: ‘/tmp/ax88179_178a.ko’

     0K .......... .......... .......... .........



Timeout, server ncloud not responding.
Und ab da hängt sich dann das ganze system auf und bleibt unerreichbar selbst nach einem neustart. Es funktioniert nur, wenn ich die Installation über den ISP modem starte. Das ist aber keine dauerhafte Lösung.

125

German - Deutsch / Re: Suricata - Block trotz disable und alarm

« on: October 06, 2020, 11:28:46 am »

Im Suricata.log steht leider nichts über diese Meldung.

Ich habe nur diese 2 Meldungen in den Alarmmeldungen stehen.

126

German - Deutsch / Suricata - Block trotz disable und alarm

« on: October 06, 2020, 10:50:56 am »

Moin moin,

ich kämpfe momentan damit, dass suricata die Rules nicht richtig anwendet.
Ich habe das Problem, dass "Dietpi" (RPi Betriebssystem) nicht in der Lage dazu ist, eine Firmware trotz Erlaubnis ordentlich runterzuladen. Bei der Einrichtung von dem Raspberry stürzt es regelmäßig an der gleichen stelle ab, weil Suricata den Download jener Treiber blockt.
Über jenes Problem habe ich schon mit dem Entwickler gesprochen. Leider kann dieser mir keine richtige Lösung anbieten.
Nichts desto trotz wundert mich, dass Suricata trotz der Regel "Alarm" statt Block, trotzdem blockiert:
Ich habe Suricata neugestartet. Ich habe Suricata-update gemacht und auch die Firewall neugestartet, aber es nützt nichts. Die Regel ist deaktiviert und auf Alarm gestellt und trotzdem wird die Firmware zerhackstückelt.

Woran kann das liegen?

127

German - Deutsch / Re: IPv6-Adressen und Firewall-Log

« on: September 28, 2020, 09:34:29 pm »

Ich glaube es geht darum die Adresse einfacher zuordnen zu können, ohne ständig das Menü, oder Gerät zu wechseln.
Ich verwende atm kein IPv6, aber du müsstest doch einen hostname lookup über die Firewall logs machen können?
Da sich IPv6 Adressen kaum einer merken kann, außer die haben irgendwelche coolen Adressen wie: dead:beef:4dad, solltest du dich am DNS orientieren. Die solltest du auflösen können und kannst die somit leichter in der Firewall identifizieren.

128

German - Deutsch / Re: INFO: Suricata/OPNsense Webinar

« on: September 28, 2020, 09:28:05 pm »

Kann nicht verkehrt sein. Danke fürs verlinken!

129

German - Deutsch / Re: Suricata blockt ohne Eintrag

« on: September 28, 2020, 09:25:10 pm »

Es muss kein generelles Problem sein. Bei mir lief es vom sprung von 20.1 auf 20.7 nicht mehr richtig. Es kann sich immer um Einzelfälle handeln.

130

German - Deutsch / Re: dhcpd6 Probleme nach Interface Reset

« on: September 26, 2020, 11:18:58 pm »

Vergiss das wan_script von mir...
probier das mal:

als Cron
service dhcp6c restart

131

German - Deutsch / Re: dhcpd6 Probleme nach Interface Reset

« on: September 26, 2020, 10:58:44 pm »

Welches Interface wird zurückgesetzt? WAN?

Ich bin noch relativ neu im OPNsense Bereich, aber wenn du mal guckst, es gibt folgende Datei:

/var/etc/dhcp6c_wan_script.sh
Vielleicht hilft es diese über einen Cronjob anzustoßen?

Ich verwende im Moment kein IPv6 mehr, aber vielleicht hilft dir das weiter.

Desweiteren haben die Herrschaften in dem Forum ähnliche Probleme wie du. https://forum.netgate.com/topic/115578/nach-periodic-reset-keine-neu-ipv6-adresse
Vielleicht kann dir das ebenfalls bei deinem Problem helfen.

Das mit den Zeitsprüngen im Log kann ich mir auch nicht erklären. Das scheint nicht immer so zu sein. Eventuell hängt sich das beim wieder öffnen auf. Beim 1. öffnen des Logs hatte ich das Problem nicht. Mir kommt es aber so vor, dass die editoren auf OPNSense nicht sauber laufen. Wenn ich über ssh "vi" verwende, geht das besser als über die konsole.

132

German - Deutsch / Re: Suricata blockt ohne Eintrag

« on: September 24, 2020, 10:24:08 am »

Hiho,
Suricata ist ein Thema für sich. Ich habe auch schon unterschiedliche Erfahrung damit gemacht. Mir ist aufgefallen, dass manche Update- oder Wiederherstellungs-Prozesse nicht richtig sauber durchlaufen.
Ich hatte zum einem das Problem, dass ich manche Spiele nicht zocken konnte, weil Suricata über den Block jener Dienste geschwiegen hat. Und ich meine mit schweigen tatsächlich, es wurde rein gar nichts geloggt. Ich habe mich dumm und dämlich gesucht. Es gab keine Meldung.
2. Problem war dass Suricata über einen längeren Zeitraum nichts geloggt hat.
Natürlich habe ich mehrfach die rules gecheckt und genau die die eigentlich hätten loggen solle, taten es nicht.

Weil ich Opnsense nicht komplett neuinstallieren wollte, habe ich folgendes probiert:
WAN Kabel zur Sicherheit gezogen, Suricata über das Dashboard disabled und dann über die Opnsense Pakete reinstalliert. Anschließend OPNsense neugestartet. Nachdem hochfahren den Dienst wieder aktiviert und alle Rules neu heruntergeladen.
Ohne Erfolg.

Gleiches prozedere, nur diesmal habe ich über das Terminal "suricata-update" gestartet. LEider auch ohne Erfolg.

Das Einzige das wirklich geholfen hat war, Backup von OPNsense machen und neuinstallieren. Nur so hat Suricata wieder normal funktioniert.

Es ist also nicht unbedingt ein konfigurationsfehler von dir. Es kommt scheinbar durchaus vor, dass Suricata ab einem gewissen Punkt nicht mehr Ordnugnsgemäß funktioniert, obwohl das in den Logs nicht richtig ersichtlich wird. Ob es an den Intel NIC's liegt, weiß ich nicht... ich habe auch welche. Würde mich interessieren, ob die probleme verursachen.

133

German - Deutsch / Re: Sehr langsames Internet über OPNsense

« on: September 18, 2020, 08:35:19 am »

Schlechter Vergleich dazu @W0nderW0lf: Du lässt dir erst ne Straßenanbindung an die Schnellstraße bauen (dein INet Zugang), setzt dich dann draußen hin und schaust zu wieviel Verkehr und böse Buben sich da auf der AB tummeln (oder zumindest auf deinem Streckenabschnitt des Providers). Die biegen nicht mal zu dir ab (weil kein offener Port) und wenn ist es nur der Postbote (bpsw. VPN frei), aber was da draußen an Idioten rumfährt! Mein Gott!

Manchmal ist "zuschauen" eben auch sinnlose Panik bekommen vor nichts und wieder nichts Internet "Grundrauschen" hast du heute an jedem Anschluß und wird auch nicht weniger. Nur sehen es die meisten Leute nicht, weil ihre 0815 Box das eben nicht zeigt - ansonsten würden die ja alle durchdrehen ^^

Witziger vergleich.. ^^ Aber meine vorhergehende Frage wurde damit noch immer nicht beantwortet. Deswegen werde ich das nun ähnlich darstellen wie du. Wenn ich sehe dass auf der Autobahn die apokalypse ausgebrochen ist und mich dazu entscheide die Jalousie runter zu fahren und meine Ohren in die Schublade zu legen, wie bekomme ich dann mit, wenn ein Dämon die Haustür auf macht?
Ich frage ganz dumm, weil mir vorgestern was merkwürdiges passiert ist, dass das DNS in meinem Netzwerk angriff. Ursache dafür war, dass ich nicht die alte config von vor meiner Neuinstallation wiederhergestellt habe, sondern meine Firewall quasi von Grund auf neu konfiguriert habe mit fast den gleichen Regeln.
Am Abend ist dann folgendes passiert:

Windows hochgefahren, bei der Anmeldung schon gewundert, dass kein Netzwerk angeblich vorhanden ist. Beim Testen hatte ich aber normal internet. Parallel dazu hatte ich meine Linux Kiste eingeschaltet und konnte nicht über ssh auf OPNsense zugreifen. In den Logs von Unbound hatte ich dann gesehen, dass mein Windows eine Domain "uk.com" innerhalb unbounds registriert hat.
Leider habe ich das Log nicht vollständig gebackupt...

Kurzer Einblick ->

2020-09-16T21:47:32   suricata[66437]   [Drop] [1:2029994:1] ET INFO Suspicious NULL DNS Request [Classification: Misc activity] [Priority: 3] {UDP} 192.168.5.3:45800 -> 192.168.5.1:53
2020-09-16T21:47:32   suricata[66437]   {"timestamp": "2020-09-16T21:47:32.448494+0200", "flow_id": 1781564980910062, "in_iface": "igb0^", "event_type": "alert", "src_ip": "192.168.5.3", "src_port": 45800, "dest_ip": "192.168.5.1", "dest_port": 53, "proto": "UDP", "alert": {"action": "blocked", "gid": 1, "signature_id": 2029994, "rev": 1, "signature": "ET INFO Suspicious NULL DNS Request", "category": "Misc activity", "severity": 3, "metadata": {"updated_at": ["2020_04_22"], "signature_severity": ["Informational"], "deployment": ["Perimeter"], "created_at": ["2020_04_22"], "attack_target": ["DNS_Server"], "affected_product": ["Windows_XP_Vista_7_8_10_Server_32_64_Bit"]}}, "dns": {"query": [{"type": "query", "id": 24554, "rrname": "_probe.uk.net", "rrtype": "NULL", "tx_id": 0}]}, "app_proto": "dns", "flow": {"pkts_toserver": 1, "pkts_toclient": 0, "bytes_toserver": 84, "bytes_toclient": 0, "start": "2020-09-16T21:47:32.448494+0200"}}

020-09-16T21:32:11   suricata[20011]   [Drop] [1:2019512:3] ET POLICY Possible IP Check api.ipify.org [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 146.112.61.104:443 -> 192.168.178.22:47162
2020-09-16T21:32:11   suricata[20011]   {"timestamp": "2020-09-16T21:32:11.803272+0200", "flow_id": 1838494712009307, "in_iface": "igb0", "event_type": "alert", "src_ip": "146.112.61.104", "src_port": 443, "dest_ip": "192.168.178.22", "dest_port": 47162, "proto": "TCP", "tx_id": 0, "alert": {"action": "blocked", "gid": 1, "signature_id": 2019512, "rev": 3, "signature": "ET POLICY Possible IP Check api.ipify.org", "category": "Potential Corporate Privacy Violation", "severity": 1, "metadata": {"updated_at": ["2020_08_20"], "created_at": ["2014_10_27"]}}, "tls": {"subject": "C=US, ST=California, L=San Francisco, O=OpenDNS, Inc., CN=api.ipify.org", "issuerdn": "O=Cisco, CN=Cisco Umbrella Secondary SubCA fra-SG", "serial": "5F:62:62:D8", "fingerprint": "99:aa:65:c1:36:10:0b:cb:30:60:6a:e0:5d:da:ad:45:30:b1:57:ea", "sni": "api.ipify.org", "version": "TLS 1.2", "notbefore": "2020-09-14T19:02:18", "notafter": "2020-09-19T19:02:18", "ja3": {"hash": "49e76101e93ff7ad65a47925a25c2cff", "string": "771,4866-4867-4865-49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47-255,0-11-10-22-23-13-43-45-51-21,29-23-30-25-24,0-1-2"}, "ja3s": {"hash": "4408e3e8f843eb342875319a6e015e93", "string": "771,157,0-65281"}}, "app_proto": "tls", "flow": {"pkts_toserver": 4, "pkts_toclient": 5, "bytes_toserver": 789, "bytes_toclient": 3595, "start": "2020-09-16T21:32:11.725595+0200"}}
2020-09-16T21:27:04   suricata[20011]   [Drop] [1:2012692:6] ET POLICY Microsoft user-agent automated process response to automated request [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 92.123.229.216:80 -> 192.168.178.22:50617
2020-09-16T21:27:04   suricata[20011]   {"timestamp": "2020-09-16T21:27:04.016188+0200", "flow_id": 67067642884544, "in_iface": "igb0", "event_type": "alert", "src_ip": "92.123.229.216", "src_port": 80, "dest_ip": "192.168.178.22", "dest_port": 50617, "proto": "TCP", "alert": {"action": "blocked", "gid": 1, "signature_id": 2012692, "rev": 6, "signature": "ET POLICY Microsoft user-agent automated process response to automated request", "category": "A Network Trojan was Detected", "severity": 1, "metadata": {"updated_at": ["2011_04_19"], "created_at": ["2011_04_19"]}}, "http": {"hostname": "www.microsoft.com", "url": "/", "http_user_agent": "Microsoft Windows Network Diagnostics", "http_content_type": "text/html", "http_method": "GET", "protocol": "HTTP/1.1", "status": 200, "length": 1020}, "app_proto": "http", "flow": {"pkts_toserver": 3, "pkts_toclient": 3, "bytes_toserver": 292, "bytes_toclient": 1474, "start": "2020-09-16T21:27:03.963008+0200"}}

Unbound

(192.168.5.3 ist der Linux Client der die neue böse Domain auflöst)

2020-09-16T22:08:06   unbound[18654]   [18654:2] info: resolving _probe.uk.uk. A IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: validate(nxdomain): sec_status_insecure
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: validated DNSKEY uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: query response was ANSWER
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: reply from <.> 1.0.0.1#853
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: response for uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: 192.168.5.3 uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: 192.168.5.3 uk. DS IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: validate(nxdomain): sec_status_insecure
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: validated DNSKEY uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: query response was ANSWER
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: reply from <.> 1.1.1.1#853
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: response for uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: resolving uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: validated DS uk. DS IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: query response was NXDOMAIN ANSWER
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: reply from <.> 1.0.0.1#853
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: response for _probe.uk.uk. AAAA IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: resolving uk. DNSKEY IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: validated DS uk. DS IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: query response was NXDOMAIN ANSWER
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: reply from <.> 1.1.1.1#853
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: response for _probe.uk.uk. A IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: resolving _probe.uk.uk. A IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: resolving _probe.uk.uk. AAAA IN
2020-09-16T22:08:06   unbound[18654]   [18654:3] info: 192.168.5.3 _probe.uk.uk. A IN
2020-09-16T22:08:06   unbound[18654]   [18654:2] info: 192.168.5.3 _probe.uk.uk. AAAA IN

2 Fehler sind mir bei meiner configuration aufgefallen.
1. Durch das wiederherstellen von ausschließlich unbound DNS über ein Backup, wird nur die Allgemeine Konfiguration wiederhergestellt und nicht die zusätzlichen Einstellungen wie Blacklists mit URL's, sowie Verschiedenes > DoT Server.
2. Habe ich bei meiner DNS Portweiterleitung ein entscheidendes Detail vergessen: TCP/UDP zu setzen statt nur TCP

Lösung war 1. Windows Client vom Netz trennen und 2. OPNsense platt machen und alte config wiederherstellen.
Und da frage ich mich halt ... wäre ich ohne Suricata trotzdem besser dran gewesen?

134

German - Deutsch / Re: Sehr langsames Internet über OPNsense

« on: September 15, 2020, 11:31:32 am »

Dann kann ich aber nix mehr zocken 

135

German - Deutsch / Re: Sehr langsames Internet über OPNsense

« on: September 15, 2020, 10:40:52 am »

Wenn du keine Dienste auf dem WAN anbietest (Ports offen) und keine sinnlosen FW-Regeln auf dem WAN hast, die dir Löcher reissen, ist IDS/IPS auf dem WAN nicht wirklich eine Notwendigkeit. Oder brauchst du die ganzen (Fehl-)Alarme um dich täglich zu gruseln, wie böse doch die Welt da draussen ist? ;-)

Wenn deine Win-10 Rechner anfangen Malware aus dem Netz zu holen solltest du das auch auf dem entsprechenden LAN-Interface mit IDS/IPS finden...

Ich habe keine Ports nach draußen offen. Sollte Suricata oder Sensei, aber auch nicht machen, oder?
Ich verwende Sensei z.B. gerne um mich dieser ganzen fiesen Ad's zu entledigen die man mit dem Windows Defender jetzt nicht wirklich los wird. Generell möchte ich die Kommunikation von Windows einschränken. Z.B. macht Windows im Hintergrund ständig zeug ohne meine Erlaubnis, wie z.B. nach Android Geräten suchen, oder telemetrie an Microsoft übermitteln. Wie ich sowas sinnvoll in Firewall Regeln verpacke, weiß ich leider auch nicht so richtig.
Ich frage mich auch, wie würde ich denn einen Einbrecher erkennen, wenn IPS/IDS nicht mehr im Dienst wären? Die Firewall verfolgt ja nur strikt ihre Regeln, gibt aber keine Meldungen, wenn eingebrochen wurde und merken tut man das doch auch erst dann wenn es bereits zu spät ist?
Ich habe die Firewall zwar schon eine Weile, aber ich befinde mich noch immer im Anfangsstadium des Lernprozesses.