Bug 10273

Summary: Snort is not configured properly to capture anything on green0
Product: IPFire Reporter: Eugene Sokolov <eugene.sokolov>
Component: ---Assignee: Stefan Schantl <stefan.schantl>
Status: CLOSED DEFERRED QA Contact: Peter Müller <peter.mueller>
Severity: Major Usability    
Priority: - Unknown - CC: ipfire, lucifercipher, michael.tremer, peter.mueller, stefan.schantl
Version: 2Keywords: Security
Hardware: all   
OS: All   
See Also: https://bugzilla.ipfire.org/show_bug.cgi?id=11532
Bug Depends on:    
Bug Blocks: 11532, 11542    

Description Eugene Sokolov 2012-12-23 06:48:48 UTC
Hi,

I'm running 2.11 core65 x86 version.

IDS is configured to monitor Red and Green with Guardian set to Red.

I see alerts happening on Red interface, mostly inbound attacks, but something going inside out like sweeping http requests to a lot of destinations, and I want to investigate this. However, all I see is my public IP and rete IPs in the Internet.

Problem is, IDS does not show any alerts from Green. I believe I know why - Snort likes to see at least one IP address belonging to the interface, which is the case with Red - it originates and terminates all the traffic on the outside. However, that's not the case on Green - Green address is never source or destination of the IP packets passing through the firewall.

I have accidentally captured only one that proves it:

Date:   12/20 17:54:32    Name:   ET P2P BitTorrent DHT ping request
Priority:   1    Type:   Potential Corporate Privacy Violation
IP info:    A.B.C.1:1024 -> A.B.C.11:64413
References:   http://doc.emergingthreats.net/bin/view/Main/2008581
http://wiki.theory.org/BitTorrentDraftDHTProtocol
   SID:    2008581

In this case, Bittorrent on .11 has communicated with Green IP which is the default gateway for it, don't know why. But only in this case Green has produced an alert.

I'd like to run IDS on Green and Green only, it makes much more sense to run IDS 'inside' the firewall, but in this case Snort must be configured for 'promiscuous' capturing on Layer 3 (not to be confused with promiscuous L2 packet capturing by tcpdump or Wireshark).
Comment 1 Arne.F 2013-02-14 20:01:49 UTC
I do not understand what you mean. Have you patches or examples for the configuration files.

It is not possible to detect traffic that are not flow trough the IPFire if you have only a green network. Promicuios capturing is not possible in a switched network except you faking the arp or overload the switch mac tables.
Comment 2 Stefan Schantl 2013-10-12 21:45:14 UTC
Hello Eugene,

are there any new news about your issue ? The current IPFire 2 version is Core 73, does your problem still happen ?

Please provide an answer, otherwise we'll close this bug.
Comment 3 Eugene Sokolov 2013-10-14 01:10:40 UTC
Stefan,

Let me explain problem once again.

The IDS on IPFire, based on Snort, is catching events on Red interface but fail to catch them on Green. If the port is open, and there's an exchange between internal resource and destination in Internet,p I should be receiving two duplicate events, one on Red and one on Green, right? But it does not happen.

I believe the reason is that Snort is monitoring only the traffic that has either source or destination of the respective interface it's looking at. In case of Red, that's always true - IP packet has Red IP either as destination for incoming traffic, or source for outgoing. In case of Green it NEVER happens - all packets are transient from elsewhere in the internal subnet to Internet destinations or vice versa. Only once I saw something registering on Green, and it was when I accidentally enabled P2P rule and my bittorrent has hit the default gateway as destination by reason unknown - that's when I realized what was wrong.

So what I propose is to check the logic of the Snort working on Green - it shall look into all packets (and apparently it does not), not only the ones that have Green IP as source or destination. That would allow me to disable Red Snort completely. What's the point of doing it outside on Red? Most ports are closed on outer perimeter anyways. And monitoring on Green gives me information what private IPs are involved - this is what I don't see when IDS enabled on Red.

Does what I say make any sense? I'm strong with network transport but a noob in IDS.

Oh and I'm on the latest build now (72).
Comment 4 Stefan Schantl 2014-05-16 22:03:56 UTC
Hello Eugene,

I've pushed a possible fix into my git repositry.

http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=5cf4df2b5f7a2c2ad783c7c3c69fa6e2d0be90dd
Comment 5 Eugene Sokolov 2014-09-14 01:13:36 UTC
I'm now on 2.15.82, and still the IDS on Green does not work.

1. When I'm enabling it on Red and Green together, I see somehttp://upgrades.freepbxdistro.org/stable/ threats registered like, for example SipVicious hits on UDP/5060:

Date:	09/13 18:33:20	Name:	ET SCAN Sipvicious Scan
Priority:	2	Type:	Attempted Information Leak
IP info:	31.3.230.170:5082 -> xx.xx.xx.xx:5060
References:	http://doc.emergingthreats.net/2008578
http://blog.sipvicious.org
SID:	2008578

Where xx.xx.xx.xx is my external address.

I have UDP/5060 open and translated to internal IP address of my FreePBX home station. So I would expect to see another log entry for Green with same source IP and port and yy.yy.yy.yy:5060 destination where yy.yy.yy.yy is the internal IP of the FreePBX.

If I'm turning off the Red leaving only Green, I see nothing at all in my log.

So it seems your fix either wasn't added in the release or doesn't work.

Eugene
Comment 6 dnl 2014-10-31 11:50:05 UTC
I've only just become aware of this problem, but suspected Snort wasn't working correctly on anything other than the Red interface as I wasn't able to deliberately trigger any alerts.

I highly suspect that this problem also occurs with snort on a Blue network.  
So, please don't forget to make whatever fixes you do for the Blue network also.

Thanks!
Comment 7 Lucifer Cipher 2015-10-12 10:14:40 UTC
This is an isolated type of incident but the more serious ones are Snort not working on at all on any IP or Interface except Red. The additional IP aliases added for additional servers is useless as you wouldn't want your applications being falsely defended by Snort. 

Core 93 still doesn't address the issue. This is serious specially if you have 8 installations which are supposed to defend the web applications and fail to do so.
Comment 8 Eugene Sokolov 2017-06-28 04:36:00 UTC
After a long while I'm back to IPFire. And it seems it still does not work on GREEN. Can somebody look at it to fix it finally?
Comment 9 Peter Müller 2017-10-23 23:03:04 UTC
Is this still unresolved?

Since I assume this is has some impact on network security, I would have a closer look at it if it is still relevant.

By the way: Does anybody know where (and if) traffic coming from IPsec N2N connections passes the IDS?
Comment 10 dnl 2017-10-28 12:06:52 UTC
Hello Peter,

I have had this problem, but gave up on using Snort in IPFire anywhere but on my external (RED) interface.

I'll turn it back on again and run some common port scans and the like against my router from the inside to see if it detects them.
Comment 11 Peter Müller 2017-11-08 16:10:49 UTC
*** Bug 10614 has been marked as a duplicate of this bug. ***
Comment 12 Peter Müller 2017-11-08 16:16:05 UTC
Apparently this was not fixed. We definitely need to have a look at it.

(Currently working on these snort issues, see https://wiki.ipfire.org/devel/telco/2017-11-06)
Comment 13 Peter Müller 2018-02-06 20:21:29 UTC
- ping -
Comment 14 Eugene Sokolov 2018-02-06 23:10:34 UTC
Sorry, I'm not using IPFire any more. Please keep working on this bug though.
Comment 15 Peter Müller 2018-07-11 18:25:30 UTC
Simply setting $HOME_NET to "any" causes Snort (with ET ruleset) to crash:

FATAL ERROR: /etc/snort/rules/emerging-dns.rules(95) !any is not allowed: ![$SMTP_SERVERS,$DNS_SERVERS]

However, since only the firewall IP addresses (and not the complete /24 or whatever networks) are listed in /etc/snort/vars, some rules applying on outgoing traffic will not trigger. This is security relevant indeed. :-(
Comment 16 Peter Müller 2018-07-11 18:47:10 UTC
*** Bug 11532 has been marked as a duplicate of this bug. ***
Comment 17 Stefan Schantl 2019-03-05 19:06:47 UTC
Suricata is working in inline mode so all INPUT, OUTPUT and FORWARDED traffic will be delegated and scanned.

Also the ruleset is adjusted to match in both directions.

See:

https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=7c3b7cdcca852e4f5e5ee46b5291b8ba522535ec
Comment 18 Michael Tremer 2019-03-06 10:18:25 UTC
I guess CLOSED DEFERRED is the right status here