(Solved)Snort custom rules doubt?

periko

Hi, reading info from snort I can see that the custom rules are the last one that play.

I trying to find out how to block 1 user to access some openappID rules but allow others.

I disable in the rules tab the rule example: youtube.

Latter I add a custom rule and copy that rule but change $HOME_NET to a specific IP address from my local network, blocking just "DST".

I start snort, the IP that I want to block try to access the site youtube but no luck, snort start showing the IPs from youtube in the blocked tab.

But if a different IP address try to access youtube and dns return the same blocking address, it won't allow this user to access that site.

I trying to figure out how to manage this case.

I have read different pages but need to understand how to attack this scenario.

Using pf 2.4.4_p2, any help will be appreciated, thanks.

bmeeks

This is not going to work because of the way blocking is implemented with Snort on pfSense. Snort uses a FreeBSD system call to have the pf firewall create an IP-based rule that blocks access. That rule will contain either the SRC, DST or BOTH IP addresses from the packet that triggered Snort. Once that block is in place, it stays until removed by the user, by the cron job task (if enabled on the GLOBAL SETTINGS tab) or by a firewall reboot.

So when Snort blocks a "non-authorized" client from accessing YouTube, it is going to put the YouTube CDN address that client used in the firewall rule. The next LAN client that tries to access YouTube is likely to be given the same CDN IP address, so that client even if "authorized" on the Snort side will still be blocked by the pf firewall rule put in place when the "unauthorized" client attempted to contact YouTube.

To do what you want, you will need an inline IPS. Suricata can do that, but unfortunately Suricata does not support OpenAppID rules. With an inline IPS solution, traffic is dropped by the IPS (not blocked by firewall rules) and thus can be dynamic whereby one client is blocked from access while another client is permitted. Both can be talking to the same IP address.

I have a long-term plan to implement an inline IPS version of Snort on pfSense.

Edit: I think I may have been the one to suggest in another thread you try this approach, but I must admit I did not think it through all the way at the time. Due to the use of semi-permanent firewall rules used for the Snort blocking mechanism, you don't have nearly as much selective control as is needed to implement what you desire.

periko

@bmeeks I really appreciated your explanation, this help me understand more how snort can be implement in a environment and the limits and most important, explain customers.

Related to reports, does pfsense have something?

Thanks for your great help.

bmeeks

@periko said in Snort custom rules doubt?:

Related to reports, does pfsense have something?

No, there is nothing directly for pfSense. Many folks route Snort messages to syslog and then send their pfSense logs over to a third-party solution such as Gray Log or some of the ELK stack products. You can Google the terms "Gray Log pfSense" and "ELK pfSense" to get links to some suggestions and tutorials.

You can also use Barnyard2, but beware that package has not seen any updates for nearly 6 years and has issues with current versions of MySQL. I would not recommend using the Barnyard2 route. I would check the box on the INTERFACE SETTINGS tab in Snort to send system alerts to the pfSense system log and then route the pfSense log to a third-party log aggregator product.

periko

@bmeeks thanks for your great help!!!