OPNsense Forum

International Forums => German - Deutsch => Topic started by: W0nderW0lf on October 06, 2020, 10:50:56 am

Title: Suricata - Block trotz disable und alarm
Post by: W0nderW0lf 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?
Title: Re: Suricata - Block trotz disable und alarm
Post by: chemlud on October 06, 2020, 11:12:24 am
Zeig doch noch das Log für die Alerts...

Title: Re: Suricata - Block trotz disable und alarm
Post by: W0nderW0lf 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.

Title: Re: Suricata - Block trotz disable und alarm
Post by: mimugmail on October 06, 2020, 12:34:21 pm
Dann mach doch eine User Rule mit Quell- und Ziel-IP wie im alert und action "pass".
Title: Re: Suricata - Block trotz disable und alarm
Post by: W0nderW0lf 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.
Title: Re: Suricata - Block trotz disable und alarm
Post by: mimugmail on October 06, 2020, 01:56:10 pm
Ich meinte eigentlich in IDS : Administration : User rules ... dort eine Regel erstellen.
Title: Re: Suricata - Block trotz disable und alarm
Post by: W0nderW0lf 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!