Rob,
Thanks for your reply.
I will try out the disable_evation_alerts enforce_state option today.
There is one more issue which i wanted to share -
1) When i change the telnet rule from "alert" to "drop" in snort_inline
rules, i'm unable to make any telnet connections to Honeypot. In the snort
rules, this is an "alert" rule and so it should allow inbound connections to
honeypot and alert rite? This is not happening.
So i guess if i change soemthing in the snort_inline, apparently snort gets
affected. Did anybody face this issue?Any common variables etc. bet. snort and
snort_inline causing this?
Snort_inline should just affect outbound conenctions rite?
Thanks
Nandhini
There may be a few things going on here...
1. By default, the honeywall only sends outbound traffic through
snort_inline if snort_inline is enabled. Does the flow plugin require
both sides of the communications in order to determine its thing? If
so, we may have to change the way the honeywall sends traffic through
snort_inline.
2. Telnet is one of those protocols that has very small packets;
therefore, the content you are searching for may reside within more
than one packet. Did you try adding the enforce_state option to the
stream4 preprocessor to the snort_inline.conf?
preprocessor stream4: disable_evation_alerts enforce_state
hmm.. number 1 may apply here as well.... does the stream4 plugin need
to see both sides to track?
You can test snort_inline with a very simply rule.
drop tcp $HOME_NET any -> $EXTERNAL_NET 23 (msg; "Dropping HOME_NET ->
EXTERNAL_NET traffic")
The project has not spent a lot of time trying to generate a good
snort_inline ruleset. You are more than welcome to start/document
research in this area. It would be a great help!
Hope some of this helps...
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now._______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall
