Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suricata IPS does not seem to drop #1664

Closed
chiel1980 opened this issue May 30, 2017 · 10 comments
Closed

Suricata IPS does not seem to drop #1664

chiel1980 opened this issue May 30, 2017 · 10 comments

Comments

@chiel1980
Copy link

Hi!
I am trying OPNSense:
OPNsense 17.1.7-amd64
FreeBSD 11.0-RELEASE-p10
OpenSSL 1.0.2k 26 Jan 2017

On an APU2C4 with Suricata enabled, IPS enabled, promiscious enabled, interface; WAN,new rules installed and enabled ET-scan and more.
I also changed the rules from alert to drop.
No matter how hard I try: I don't see any blocks in my alerts tab using nmap -sS/nmap -sT against the WAN interface from a VPS to my OPNsense box.
I also noticed that I see no alerts at all, only STREAM alerts but no drops (I also expect Dshield and Comrpomised alerts from chinese ip adressess but no alerts at all).

My questions:

  1. am I missing something to trigger the alerts?
  2. I did the the eicar download before with the OPNsense test rules but no other rules are triggered
  3. I have a VLAN interface connected to igb0 and use hardware offloading, all other hard offloading is disabled (by default) should I disable the VLAN interface? I also use port forwarding for SSH, HTTP & HTTPS can this cause issues?

I haven't experienced this with PFsense with suricata and/or snort.

Any pointers would be more then welcome :)

@chiel1980
Copy link
Author

Also opted here; https://forum.opnsense.org/index.php?topic=5261.0 but did not get a very clear answer from the helping hand ;)
If it is related to $HOME_NET and $WAN_NET variables not filled in correctly; how can I achieve this via the GUI and if this has to be changed by hand on the filesystem, how is it restored after an upgrade?

@AdSchellevis
Copy link
Member

@chiel1980 please try the test rule first and check if eicar blocks, our homenet is correctly configured. see also https://forum.opnsense.org/index.php?topic=4711.msg21016#msg21016

@chiel1980
Copy link
Author

Hi Ad, I enabled the plugin, download & update and try to test it from a box behind my firewall/IPS:

beheerder@NAS:~$ wget 'http://www.eicar.org/download/eicar.com.txt'
--2017-05-30 12:38:34--  http://www.eicar.org/download/eicar.com.txt
Resolving www.eicar.org... 213.211.198.62
Connecting to www.eicar.org|213.211.198.62|:80... connected.
HTTP request sent, awaiting response...

And yes it triggers an alert:

Alert details
Timestamp
	2017-05-30T12:38:34.731644+0200 	
Alert
	OPNsense test eicar virus 	
Alert action / sid
	7999999 	
Source IP
	213.211.198.62 	
Destination IP
	178.84.120.149 	
Source port
	80 	
Destination port
	64276

But still no other alerts are triggered (like dshield, port scans, etc):

eicar-download

and my search for scans:
no-scans-detected

What else can I try?

@AdSchellevis
Copy link
Member

Like I explained in the forum thread, a lot of the rules trigger when coming from the external network and go to the home network (192.168.0.0/16,10.0.0.0/8,172.16.0.0/12).
Suricata shouldn't be very noisy normally.
If one rule functions, they all should.

@chiel1980
Copy link
Author

Hi Ad, thanks for your reply.

I tested that with nmap and get no results, I also enabled the dshield, feodore, etc. no alerts.

Is there any way I can troubleshoot this and can you show me an example of your own setup with a nmap from the outside against your WAN interface and that it triggers an alert? I simply can not reproduce alerts by just settings some options in the GUI.
Just trying to get it to work and the 'If one rule functions, they all should.' might be true but since it does not work on my box I want to troubleshoot it.

@chiel1980
Copy link
Author

I checked the suricata.log in /var/log and for example I see:

30/5/2017 -- 12:36:16 - <Error> - [ERRCODE: SC_ERR_UNKNOWN_PROTOCOL(124)] - protocol "t" cannot be used in a signature.  Either detection
for this protocol supported yet OR detection has been disabled for protocol through the yaml option app-layer.protocols.t.detection-enable
d

Not sure if that can be the culprit?

@AdSchellevis
Copy link
Member

you can add your wan network manually to HOME_NET (/usr/local/etc/suricata/suricata.yaml ) and restart suricata (service suricata restart) then test again.
Enabling suricata on your LAN interface and forwarding all traffic to a machine in your local network should also work.

Please inspect the rules you want to match first (they're not that difficult the read) and fabricate traffic that matches that.

@chiel1980
Copy link
Author

Adding the WAN interface to $HOME_NET does trigger alerts (like port scans).
Since I have ZIggo/Vodafone with a dynamic ip, how can I ensure that this behaviour stays this way? Does adding the LAN interface also have the same effect?

@chiel1980
Copy link
Author

I've added my LAN and GUEST interfaces and that seems to get some more alerts and blocks (especially for my port forwarded hosts).
I am happy :)
If you want, I could help writing some documentation so these questions can be prevented in the future? (seeing as I am not the only one with these questions ;) )

@AdSchellevis
Copy link
Member

If you can spare some time to improve the documentation on this subject, that would be great. We're using Sphinx (http://www.sphinx-doc.org/en/stable/index.html) for our documentation (https://docs.opnsense.org/manual/), but any other documentation format is ok too.

Please send your contribution to project@opnsense.org, and we'll try to incorporate it asap.

The best thing is probably to add a section about (basic) setup, as far as I see that's missing from our documentation at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants