OPNsense Forum

English Forums => Development and Code Review => Topic started by: Supermule on July 03, 2015, 11:25:55 am

Title: Suricata
Post by: Supermule on July 03, 2015, 11:25:55 am
Alerts look like this. (see attached picture).

No blocks on IDS and very few ways to customize Suricata as of now.

Small issue is not beeing able to hace "select all" option when selecting rules to enable.
Title: Re: Suricata
Post by: Supermule on July 03, 2015, 12:20:52 pm
More. How to make it remember seetings in the GUI?

Instead of 7 I want ALL items listed.

Hitting APPLY doesnt help.
Title: Re: Suricata
Post by: lucifercipher on July 05, 2015, 10:32:53 pm
Indeed its an IDS not an IPS. The IPS ( Intrusion Prevention System ) component blocks the offending IP address/user when the alert is generated by the Suricata IPS. If you look at the basis of OPNSense then its supposed to be a firewall first then components to follow. Things will take some times for the project to mature. Don't you worry  :)
Title: Re: Suricata
Post by: franco on July 06, 2015, 09:05:09 am
Brian, you seem to have managed to find issues already. It looks like no rules are being applied, that would explain the empty log info screen. I'll be on Skype today to take a look. :)

We are going to need a lot more feedback regarding desired (and missing essential) configuration options. We've put in the bare minimum, which targets a novice user, but certainly not professional standards.

And, indeed, making it IPS instead of IDS was considered, but we've wanted to keep the steps small (and IDS is already a large step for us). Some time down the road for 15.7 we'll bring in IPS functionality when I have confirmed it is working for the development versions.
Title: Re: Suricata
Post by: lucifercipher on July 06, 2015, 11:05:14 am
I will look into the IPS component starting now Franco. Since I am doing hourly builds across 2 different machines, i can test things pretty quickly.
Title: Re: Suricata
Post by: Supermule on July 06, 2015, 12:14:01 pm
Thats super guys!

A kill all states option and a drop down menu for hours to clear blocked hosts would also be awesome.

And then a whitelist/pass option for whitelisted IP's as well.

Maybe a portscan feature detection in Suricata as well combined with country ip lists?
Title: Re: Suricata
Post by: lucifercipher on July 06, 2015, 09:33:26 pm
Franco,

Even the guardian component needs ipfw to work (http://www.chaotic.org/guardian/guardian-1.7.tar.gz) . Its basically designed for snort but i can make it work with suricata . The only issue is using ipfw . I am now building OPNSense with ipfw for testing. Will report in few hours.
Title: Re: Suricata
Post by: Supermule on July 06, 2015, 09:44:46 pm
 FreeBSD platform is a great platform for firewalls. As far as i know, FreeBSD has 3 firewall apllication for building a great firewall : IPFW, PF and IPF. hmmmm, i only will explain the IPFW and PF firewall. IPF and PF is almost same.

    IPFW : FreeBSD’s primary firewall is called IPFW (Internet Protocol Firewall). IPFW is composed of two parts: a kernel-level packet filter engine and a userland utility for controlling firewall functionality. IPFW has been part of FreeBSD since FreeBSD 2.0. IPFW went through a major overhaul as part of FreeBSD 5 development. This “new” IPFW became known as IPFW2. However, for the sake of sanity, we will refer to IPFW2 simply as IPFW.

    PF : OpenBSD utilizes a firewall mechanism called PF (packet filter). Like FreeBSD’s IPFW, PF is made up of a kernel-level packet filter and a userland utility for control of the firewall functionality. Unlike FreeBSD, PF is exposed via a device node, /dev/pf. PF is a newcomer to the OpenBSD world. Before using PF, OpenBSD utilized a firewall called IPFilter. I dont know why IPFilter removed from OpenBSD. maybe a licensce trouble. The end result was that IPFilter was removed from OpenBSD. PF was created to fill the void left by IPFilter. PF has been designed from day one to integrate cleanly into OpenBSD, and as such, is very usable and flexible.

The Differences
There are big differences between IPFW and PF. If you had ever using both IPFW and PF, you will find the differences. IPFW is list-based while PF is much more object oriented. PF configuration is broken into many parts, but IPFW generally a shell scripts with rules processed in order. but, both firewall supports statefull and stateless processing of connection.

In IPFW, the first rule in a ruleset that matches a packet “wins.” That means, if a ruleset has a rule to allow traffic to port 80 before a rule that denies all traffic, the packet destined to port 80 will be allowed. In PF, the exact opposite is true; the last rule that matches “wins.” In the same example, the packet to port 80 would be denied by the firewall. If you really need to have a packet match a rule and then be processed in PF, you can use the quick keyword to force the issue. (you can read my blog about PF)
In IPFW, denied packets are logged through the syslog facility. In PF, denied packets are logged to a special interface called pflog0. This interface is actually a BPF (Berkeley Packet Filter) interface that allows utilities like tcpdump to sniff logged packets directly. This feature can be used by IDS engines and monitoring tools to analyze the firewall’s activity without having to interact or affect the firewall processing.

PF implements Network Address Translation (NAT) and Quality of Service (QoS) directly into the firewall. In IPFW, these features are provided by other programs. In general, there is no functional difference. The integration in PF makes administration a bit easier as all configuration is done in one file.
PF performs more aggressive optimization than IPFW. In PF, large lists of rules are compressed into a table (of course you must read the PF manual first). So while the configuration file for PF may still have list-like properties, the core processing engine of PF treats the rules more efficient. This ultimately results in a tree data-structure for the rules making even huge rulesets rapidly searchable.
PF also has the capability to reassembly and normalizing fragmented packets before sending them through the firewall. This prevents fragmentation attacks behind the firewall. This is a great feature of PF, as it prevents other applications on the firewall (like an IDS sensor) from having to deal with fragments.
Seems that PF is a weapon weapon for building a firewall. If you need the flexibility and scalability, use PF. However, for smaller-scale deployments, such as a small or home office, IFPW’s simple interface and simple administration may be your choice.

https://cipitunk.wordpress.com/2007/07/07/ipfw-vs-pf/

Personally I like the pf implementation so far. I havent tried ipfw so cannot say anything useful about it.