Sensei on OPNsense - Application based filtering

[patcsy88]

No it was a fresh install!

Running "ps awxu | grep elastic | grep -v grep" shows the following output:-

elasticsearch 18938  30.9 61.1 3897508 2528480  -  I    04:09       6:49.91 /usr/local/openjdk8/bin/java -Xms2g -Xmx2g -XX:+UseConc

"cat /usr/local/libexec/elasticsearch/config/jvm.options | grep 512" gives me

-Xms512m
-Xmx512m

I restarted ElasticSearch via the UI.

Is there a default setting it is picking up instead of from usr/local/libexec/elasticsearch/config/jvm.options?

[mb]

Hi @alelnr, service should be restored as of today. This was due to a BGP configuration problem . Sorry for the inconvenience.

@patcsy88, that should be the file elasticsearch is getting the settings from. Let's try to reproduce the issue here. I'll update you.

[spetrillo]

Is Sensei available from the plugins section or do we need to do a CLI install? I would very much like to try it out.

[mb]

Is Sensei available from the plugins section or do we need to do a CLI install? I would very much like to try it out.

Hi @spetrillo,

Thanks for your interest in Sensei. You'll need to install it from OPNsense CLI.

Please see here:

https://guide.sunnyvalley.io/sensei/getting-started/prepare-your-firewall
https://guide.sunnyvalley.io/sensei/getting-started/setup

[spetrillo]

Thanks @mb.

What does Sensei replace?

[mb]

Hi @spetrillo,

OPNsense is already a great firewall. Nothing to replace indeed.

Sensei is augmenting the firewall with commercial grade next generation features like:

• Application Control
• Cloud Threat Intelligence
• Best-in-segment network analytics and reporting (amongst UTM products)
• Web Security & Filtering
• Cloud Application Control
• Encrypted threats protection

And yet many to come...

It integrates in such a way that it makes it possible for you to continue to use all of the existing OPNsense functionality.

[spetrillo]

@mb does Sensei augment what Suricata brings to the table or are they aimed at totally different things. It seems to me there is overlap and I am trying to understand if I should use one or the other or both.

[ruffy91]

They do different things but they overlap a bit.

Both do Deep Packet Inspection but with other targets.
Suricata is only an engine, you have to select the rules yourself to reach your target.
You can use abuse.ch SSL Blacklist to block known bad Certificates or ET Pro Trojan Rules to block and detect network traffic from trojans and many more. It's there to defend against known exploits, vulnerabilities and threats mostly. You can enhance it yourself by adding the right rules.

Sensei classifies Traffic into application + web categories and allows you to specify what to block.
For example block File-Upload/Sharing sites to enforce the policy that employees have to use your in-house file sharing system etc. which would be very hard to do using suricata.
As addition they provide a blacklist of sites they see spreading malware.

So I see it like this: Block known threats using suricata and use Sensei for defense-in-depth by disabling apps you do not need or do not want in your network.

Also sensei has usable reporting, suricata just shows alerts, sensei shows relations and also what is happening in your network even if it's not an alert.

Gesendet von meinem MI 9 mit Tapatalk

[spetrillo]

I would agree on what Suricata shows. I am actually trying to find some kind of front end that visualizes the Suricata data. Working with Elastic Search right to see where it can get me.

[mb]

Is there a default setting it is picking up instead of from usr/local/libexec/elasticsearch/config/jvm.options?

Hi @patcsy88, it turns out that the correct jvm.options path should be:

Code Select Expand

/usr/local/lib/elasticsearch/config/jvm.options

Fix is also included in 0.8.0.rc2. Many thanks for bringing this into our attention.

[JohnDoe17]

@mb

Looks like this issue wasn't completely resolved afterall...

Code Select Expand


User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
FreeBSD 11.2-RELEASE-p10-HBSD  5e5adf26fc3(stable/19.1) amd64
OPNsense 19.1.8 dff8692b8
Plugins os-arp-scan-1.1 os-ftp-proxy-1.0_1 os-sensei-0.8.0.rc1 os-sensei-updater-0.8.0_21 os-vmware-1.5
Time Tue, 04 Jun 2019 11:05:35 -0500
OpenSSL 1.0.2r  26 Feb 2019
PHP 7.2.18
PHP Errors:
[04-Jun-2019 11:02:51 America/Chicago] Exception: Cannot connect to 127.0.0.1 on port 4343 in /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Telnet.class.php:111
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Telnet.class.php(75): OPNsense\Sensei\Telnet->connect()
#1 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php(155): OPNsense\Sensei\Telnet->__construct('127.0.0.1', 4343, 1, '', 0.5)
#2 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php(138): OPNsense\Sensei\Sensei->runTelnetCommands('127.0.0.1', 4343, 'ballyhoo#Recons...', Array, Array)
#3 /usr/local/opnsense/mvc/app/controllers/OPNsense/Sensei/Api/EngineController.php(93): OPNsense\Sensei\Sensei->runCLI(Array, 'ballyhoo#Recons...')
#4 [internal function]: OPNsense\Sensei\Api\EngineController->cliAction()
#5 [internal function]: Phalcon\Dispatcher->callActionMethod(Object(OPNsense\Sensei\Api\EngineController), 'cliAction', Array)
#6 [internal function]: Phalcon\Dispatcher->dispatch()
#7 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#8 {main}
[04-Jun-2019 11:03:24 America/Chicago] Exception: Cannot connect to 127.0.0.1 on port 4343 in /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Telnet.class.php:111
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Telnet.class.php(75): OPNsense\Sensei\Telnet->connect()
#1 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php(155): OPNsense\Sensei\Telnet->__construct('127.0.0.1', 4343, 1, '', 0.5)
#2 /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php(138): OPNsense\Sensei\Sensei->runTelnetCommands('127.0.0.1', 4343, 'ballyhoo#Recons...', Array, Array)
#3 /usr/local/opnsense/mvc/app/controllers/OPNsense/Sensei/Api/EngineController.php(93): OPNsense\Sensei\Sensei->runCLI(Array, 'ballyhoo#Recons...')
#4 [internal function]: OPNsense\Sensei\Api\EngineController->cliAction()
#5 [internal function]: Phalcon\Dispatcher->callActionMethod(Object(OPNsense\Sensei\Api\EngineController), 'cliAction', Array)
#6 [internal function]: Phalcon\Dispatcher->dispatch()
#7 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#8 {main}


[mb]

@JohnDoe17, got it, thanks for the update.

[BeNe]

Hello Murat,

one question. The problem with the VLAN Interfaces should be fixed since two versions what i saw.
I'm on 0.8.0.rc1 and still have the same problem as in version 0.8.0.beta4.

Problem was described here in this topic -> https://forum.opnsense.org/index.php?topic=9521.msg55463#msg55463
Should this case also be fixed with the current version ?

Thank you!

[mb]

Hi @BeNe,

Yes, you should be able to protect your VLAN interfaces now. You have two options:

1. If you add the VLAN parent interface to the protected interfaces list, then you should be all set. Sensei processes all VLANs as well as the untagged packets for that interface.

2. If you want to add vlan child interfaces one by one, you should also be able to do that provided that you do not add the parent interface at the same time. (due to a netmap issue). We also have a check in the UI for that.

I've heard from people running both of the options fine, though option number #1 should be more preferable performance-wise. Since in that mode we're using the netmap mode natively for a variety of interfaces (em, igb etc).

[BeNe]

@mb Thank you for your answer.

If i add the VLAN parent interface to the protected interfaces list, all VLAN child are unable to connect to the OPNsense anymore. I can see entries in the Firewall Live-Log, that all packets are denied.
If i stop the Sensei Packet Engine everything works fine again and there are no more denied packets.

Is there something i can debug ?
Thanks