bei aktiviertem Intrusion Detection (suricata) nur 100 MBit bei 400er-Leitung?

Started by Marcel_75, March 14, 2018, 12:09:46 AM

Previous topic - Next topic
Print
Go Down Pages1 2
User actions
March 14, 2018, 12:09:46 AM
Hallo zusammen,

bin gerade durch Zufall darauf gestoßen, warum mein 400er-Kabelanschluss (PYUR) seit Wochen nur knapp 100 MBit statt der versprochenen "bis zu 400 MBit" liefert:

Es liegt am aktivierten Intrusion Detection (suricata)!

Aufgefallen ist es mir nur dadurch, dass der Zack-Speedtest von AVM direkt nach einem Neustart des Routers (AMD GX-416RA SOC mit 4 cores und SSD) für ca. 30 Sekunden stattliche ~360 MBit/s down schaffte - aber nur so lange, bis suricata (Intrusion Detection) aktiv wurde – dann fällt die Geschwindigkeit relativ zeitnah auf unter 100 MBit.

http://avm.de/nc/service/zack-der-speedtest-fuer-ihre-breitbandverbindung/

Wann suricata aktiv wird, kann man ja recht einfach im Dashboard sehen.

Nach dem Neustart von OPNsense war es bei mir schon immer so, dass sowohl der ntpd (Network Time Daemon) immer einige Zeit brauchte, bis er auch wirklich aktiv ist (grün statt rot) - und auch suricata benötigt eben einige Sekunden, bis es aktiv ist.

Und jetzt habe ich das mehrmals durchgespielt, es liegt defintiv am suricata:

Sobald ich es aktiviere, komme ich auf knapp 92 bis maximal 98 MBit/s beim Download.

Ist suricata dagegen deaktiviert, schafft der Anschluss problemlos, was PYUR verspricht – in meinem Fall also 396,159 MBit/s (49,520 MByte/s) down (gerade noch einmal getestet).

Die Frage ist für mich jetzt: Warum ist das so?

Suricata hatte ich auch schon mit meinem alten 120er-Anschluss genutzt, dort dann aber auch immer die knapp 120 MBit/s im Download erreicht – wie gesagt mit aktiviertem suricata.

Und seit der Umstellung auf den 400er-Anschluss kam ich nie über 100 MBit/s im Download, obwohl ich an den Einstellungen nichts geändert hatte (also sowohl beim Intrusion Detection als auch in anderen Bereichen).

Ich hatte das Modem tauschen lassen, sämtliche Netzwerk-Kabel geprüft, alle meine Switche etc. – und am Ende lag es scheinbar an irgend einer "verkorksten" Einstellung beim "Intrusion Detection"?

Bin gespannt, ob das anderen auch schon mal passiert ist?

Meine suricata-settings liefere ich gleich nach ...
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 12:17:57 AM #1 Last Edit: March 14, 2018, 12:20:58 AM by Marcel_75
Bei "Settings" ist das hier eingestellt:

Enabled: YES
IPS mode: YES (Hardware CRC, Hardware TSO und Hardware LRO sind wie empfohlen deaktiviert)
Promiscuous mode: NO
Enable sylog: NO
Pattern matcher: Aho-Corasick
Interfaces: WAN
Rotate log: Weekly
Save logs: 4

Und im Bereich "Download" sind folgende Filter aktiviert (drop):

abuse.ch/Dyre SSL IPBL   
abuse.ch/Feodo Tracker   
abuse.ch/SSL Fingerprint Blacklist   
abuse.ch/SSL IP Blacklist
ET open/botcc   
ET open/botcc.portgrouped   
ET open/ciarmy   
ET open/compromised
ET open/drop
ET open/dshield
ET open/emerging-activex

Vermutlich sind das einfach "zu viele" für ihn?

Oder liegt es an einer anderen (falschen) Einstellung?

Bei der CPU- und RAM-Auslastung war mir bisher aber nicht aufgefallen, dass da irgend etwas "am Limit" läuft.

Danke im Voraus für Eure Unterstützung!  :D
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 12:34:37 AM #2 Last Edit: March 14, 2018, 11:52:27 AM by Marcel_75
PS: Dank dieses Thread

https://forum.opnsense.org/index.php?topic=5165.0

habe ich jetzt mal folgende Drop-Filter deaktiviert:

abuse.ch/Dyre SSL IPBL
ET open/botcc   
ET open/botcc.portgrouped   
ET open/ciarmy   
ET open/compromised   
ET open/drop   
ET open/dshield   
ET open/emerging-activex

Aktiviert sind jetzt also nur noch:

abuse.ch/Feodo Tracker
abuse.ch/SSL Fingerprint Blacklist
abuse.ch/SSL IP Blacklist

So komme ich auch bei aktiviertem Suricata auf knapp 390 MBit/s down.

Könnt ihr eventuell Empfehlungen geben, was die sinnvollsten Einstellungen sind?

Alles "an" war ja scheinbar eher kontraproduktiv wie ich nun sehe ...  ;)

PS: Nein - Kommando zurück - ein zweiter Speedtest schaffte jetzt auch wieder nur 97 MBit/s down, verdammt.

Also lasse ich Suricata vorerst mal deaktiviert und warte ab, was ihr dazu sagt.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 08:34:55 AM #3
QuoteBin gespannt, ob das anderen auch schon mal passiert ist?
Natürlich!  ;)
QuoteDie Frage ist für mich jetzt: Warum ist das so?
Weil Du hier sicherlich an eine Hardwaregrenze kommst. Jedes Packet welches durchs Netz geht schau Suricata an.
Umsomehr Traffic, umso mehr muss suricata leisten. Wenn Dir mal die CPU Auslastung anschaust ist Suricata sicher auf Platz 1.
March 14, 2018, 10:46:38 AM #4 Last Edit: March 14, 2018, 01:26:03 PM by Marcel_75
Ok, verstehe - 400 MBit/s ist ja auch nicht gerade wenig, das kann ich durchaus nachvollziehen.

Meine CPU ist diese hier:

http://www.cpu-world.com/CPUs/Jaguar/AMD-G-Series%20GX-416RA%20-%20GE416RIBJ44HM.html

Steckt in diesem Router:

https://www.deciso.com/product-catalog/OPN20078B/

Und das Teil war auch nicht gerade günstig (ca. 750,- €):

http://varia-store.com/Ready-Systems/OPNSense/Deciso-Systems/Desktop-Solutions/OPNsense-OPN20078B-A10-Quad-Core-Desktop-SSD::28755.html

Hatte eigentlich gehofft, dass das ausreichen würde – aber scheinbar ist das dann doch zu schwachbrüstig, sobald man mehr als 100 MBit/s Durchsatz möchte bei aktiviertem IPS?

Allerdings habe ich auch schon im Netz gelesen, dass das selbst mit "dickeren" Systemen (Xeon?) ein Problem ist?

Man wird doch dafür nicht etwa so etwas hier benötigen (ca. 2.000,- €)?

http://varia-store.com/Ready-Systems/OPNSense/Deciso-Systems/Rack-Solutions/OPNsense-OPN19004R-Quad-Core-Gen3-SSD-Rack::28762.html

Meine Frage ist: Ab welcher Gerätekategorie wird das denn zuverlässig auch bei 400 MBit/s klappen?

Habt ihr da Erfahrungswerte?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 12:12:56 PM #5
Hatte übrigens auch mal Deciso angeschrieben wegen des Themas und möchte Euch die Antwort nicht vorenthalten:

As far as throughput considers, Suricata certainly takes a lot of CPU cycles as it needs to evaluate every package.
Depending on what else is running on the device, the number of active rules and how you test it the results will vary a lot.

On a clean system running the latest OPNsense version it can perform up to 327Mbps. The test conditions for the lab test involves a simulation with 150 simultaneous users and packages varying in size from 400-800 bytes send and 1K-8K receive, while having 21000 rules enabled but doing nothing else.

In practice while running other things and just one thread I would expect something between 100-200Mbps for speedtest.net.

For the kind of throughput that you are looking for and taking into account time consuming ip packages like Netflix streaming, you will need a much faster CPU.

Alternatively, you can put Suricata in IDS mode, that will only alert, but does not limit your available bandwidth that much.

Ok, es gibt also IPS (Intrusion Prevention System) und IDS (Intrusion Detection System), und wenn ich IDS statt IPS nutzen würde, wäre es wohl schneller? Aber dann wird auch nur noch gewarnt aber nichts mehr abgewehrt, verstehe ich das richtig?

Und mehr als 327 Mbps sind scheinbar sowieso nicht drin (zumindest nicht mit meiner Hardware)?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 02:13:28 PM #6
Hallo,

deine HW ist gar nicht so schlecht.  ;)
Ich hatte das gleiche Problem und auch einige Lösungsansätze in die Board gefunden.
Probier das mal:
https://forum.opnsense.org/index.php?topic=6855.0
Das ist auch eine gute Seite:
https://calomel.org/freebsd_network_tuning.html
Du kannst also gerade beim Netzwerk noch ein wenig tunen und mehr Performance rausholen.
Ich habe bei aktiviertem IDS/IPS auf eine 400er Leitung noch 360 - 380 Mbit.
Probier es aus.

Gruß
March 14, 2018, 02:54:38 PM #7
Danke Dir. Beim ersten Link kam ja leider auch nur raus, dass man den "Promiscuous mode" deaktivieren soll, was bei mir ja so ist.

Aber am Ende des Threads wird hierauf verlinkt:

https://forum.opnsense.org/index.php?topic=6590.0

Das scheint dann unter Umständen zu helfen, ich verstehe es aber leider nicht ...  :-\

Und wenn ich die Kommentare zu dem Thema allgemein richtig verstanden habe (und das würde sich auch mit meinen bisherigen Erfahrungen decken), existiert das Problem auch wieder erst seit dem Umstieg von der 17.x Serie auf die 18.x Serie?

Also, dass das IPS plötzlich so langsam ist bzw. die Verbindung dadurch so stark belastet wird?

Und auch Dein zweiter Link sieht spannend aus:

https://calomel.org/freebsd_network_tuning.html

Auch da soll ich ja Hardware-Treiber anpassen, eventuell den Kernel neu kompilieren etc. – das traue ich mir nicht zu, leider.

Aber eine einfachere Lösung gibt es wahrscheinlich gar nicht?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 03:01:53 PM #8
IPS und dummynet sind leider sehr treiber- und hardwarelastig. Ich hatte da auch ziemliche Probleme mit 10G Bereicht mit einer X710 Karte von Intel. Da hat dann die NIC im IPS Modus einfach den Dienst quittiert. Man könnte mal mit einer Compatibility List anfangen :D
March 14, 2018, 03:20:37 PM #9 Last Edit: March 14, 2018, 04:58:18 PM by Marcel_75
Habe jetzt mal versucht, dem zweiten Link zu folgen – folgendes habe ich gemacht:

https://calomel.org/freebsd_network_tuning.html

1) /boot/loader.conf

Habe /boot/loader.conf.local neu angelegt und befüllt wie empfohlen, denn in /boot/loader.conf gibt es folgenden Hinweis (da mein Router nur 4 GB RAM hat, habe ich die Zeile mit der vfs.zfs.dirty_data_max_max="12884901888" Angabe mal komplett auskommentiert):

Code Select
##############################################################
# This file was auto-generated using the rc.loader facility. #
# In order to deploy a custom change to this installation,   #
# please use /boot/loader.conf.local as it is not rewritten. #
##############################################################

Frage: Wie und wo sage ich dem System jetzt, dass es statt /boot/loader.conf zukünftig /boot/loader.conf.local benutzen soll?

2) Die Datei /etc/sysctl.conf enthält ja nur folgende, komplett auskommentierten Einträge:

Code Select
# $FreeBSD$
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

Habe dies ebenfalls um die empfohlenen Einträge ergänzt.

3) Als dritten Schritt soll man ja /etc/rc.conf anpassen, diese Datei finde ich bei mir aber nicht in /etc, sondern nur:

rc
rc.bsdextended
rc.conf.d
rc.d
rc.firewall
rc.initdiskless
rc.resume
rc.shutdown
rc.subr
rc.suspend

Frage: Was genau muss ich hier machen? Einfach /etc/rc.conf anlegen und entsprechend bestücken?

Noch kann ich das alles rückgängig machen, falls das alles "Blödsinn" ist.  ;D
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 03:27:42 PM #10
Hi,

Auch da soll ich ja Hardware-Treiber anpassen, eventuell den Kernel neu kompilieren etc. – das traue ich mir nicht zu, leider.

also das brauchst du nicht unbedingt...
Es ist eigentlich sehr gut beschrieben, welche Änderungen was bewirken und für was die Parameter stehen.
Du musst ja nicht alles 1:1 übernehmen. Hier ist auch viel "Try and Error" angesagt.
March 14, 2018, 04:30:02 PM #11 Last Edit: March 14, 2018, 04:37:15 PM by opnsense_user12123
Ich habe die selben Probleme und auch alles in der Anleitung befolgt.
Ich selber habe 100mbit down und konnte mit 3 aktiven Rules auf dem wan Interface die Leitung dann auch knapp mit 100mbit betreiben. Aber laut meinen Recherchen sollte man ids/ips auf wan und lan aktivieren was aber dann zum tot meines Netzes führen würde.
Stabile 100mbit waren faktisch aber auch nur am wan nicht möglich.
Hab's dann ganz deaktiviert und nun läuft wieder alles konstant.

IDS allein macht nicht so große Probleme. IPS aktiviert drückt aber ziemlich an der Substanz des Hardware.

Meine Hardware, die ich verwende, steht in der Fußzeile
March 14, 2018, 06:30:05 PM #12
Hallöchen,

Wenn /boot/loader.conf.local und /etc/rc.conf nicht da sind, dann können diese bedenkenlos angelegt werden. Sie werden von OPNsense nicht manipuliert.


Grüsse
Franco
March 14, 2018, 09:15:58 PM #13 Last Edit: March 14, 2018, 09:25:04 PM by Marcel_75
Oh je, ich war mal so mutig und habe einen Neustart gewagt (nachdem ich auch noch die /etc/rc.conf angelegt hatte), aber nun kommt das Gerät gar nicht mehr hoch (mounten des Laufwerks klappt nicht).

Das hier sehe per Terminal-Console:

Code Select
Mounting from zfs:zroot failed with error 5.

Loader variables:
  vfs.root.mountfrom=zfs:zroot

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:tank
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

Wenn ich mir dann per ? die Boot devices anzeigen lasse sehe ich dies:

Code Select
List of GEOM managed disk devices:
  gpt/swapfs ufs/OPNsense ufsid/5a02ff681dd474fc gpt/rootfs gpt/bootfs msdosfs/EFI ada0p4 ada0p3 ada0p2 ada0p1 ada0

Aber wie geht es jetzt weiter?

Im Idealfall würde ich das einfach wieder rückgängig machen wollen, sprich die Dateien /boot/loader.conf.local und /etc/rc.conf einfach wieder löschen und die /etc/sysctl.conf auch einfach wieder bereinigen.

Aber wie komme ich da jetzt ran?  :-\

Per ufs:/ufs/OPNsense komme ich da zwar erst einmal etwas weiter, aber scheinbar auch nur lesend bzw. bringt mich das auch nicht ans Ziel ...

Oh man bin ich ein Lamer ...  :'(
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
March 14, 2018, 09:24:19 PM #14
Würde OPNsense neuinstallieren und dann gleich wieder das letzte Backup rein (das Du ja sicherlich vor der Aktion noch erstellt und heruntergeladen hast.)

Damit solltest Du in ca. 20 Minuten wieder ein funktionierendes System haben.
Print
Go Up Pages1 2
User actions