@peridian:
Doh! Figured it out.
@bmeeks:
In this case, the bad IP (the source IP in this alert) was blocked so no further communication can happen there.
You would think, however looking at the logs I realised that squid was operating on that interface in transparent mode. snort was generating the block for the external IP, but squid was returning a cached copy of the content, which made it look to the client like the connection had still worked.
@bmeeks:
If so, you will need to define a custom PASS LIST, uncheck the option to include local networks, then manually assign the list to the VLAN interface (or the LAN interface) and restart Snort.
Excellent, thank you for that, it achieved exactly the result I was looking for. I don't know how I ever got snort to produce blocks originally if I didn't know to do this, but it is now behaving as expected, and with squid still enabled on the interface.
Thank you for all your help, it's very much appreciated.
Regards,
Rob.
Glad you got it figured out. Unless you are worried about your internal VLAN hosts being a source of and spreading some malware, I don't understand why you want their IP addresses blocked at the firewall as well. Simply blocking the other end of the offending traffic stream is protection enough for the victim host. I'm assuming you are running this in a home setup. As an example, assume your PC browses to a web site and some rogue ad content on the site causes Snort to fire an alert and insert a block. If you let it block both the bad web site AND your own PC's address, then you can find yourself locked out of the firewall (at least from your PC). Isn't it sufficient that just the far-end rogue source or destination be blocked?
Bill
