| 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: | 2 | Keywords: | 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
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. 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. 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). 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 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 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! 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. 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? 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? 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. *** Bug 10614 has been marked as a duplicate of this bug. *** 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) - ping - Sorry, I'm not using IPFire any more. Please keep working on this bug though. 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. :-( *** Bug 11532 has been marked as a duplicate of this bug. *** 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 I guess CLOSED DEFERRED is the right status here |