This is for the latest roo release
(http://www.honeynet.org/tools/cdrom/roo/iso/test/roo-1.3.hw-b1.iso)?
Hflow does a few things, one of them is to put the data from argus,
sebek, p0f, and snort into the db. So in order to see if hflow is
working properly, you have to look at the db (walleye_0_3).
snort alerts are put in the ids table.
argus flows are put in the argus table.
p0f is in os.
sebek is in (process, process_tree, sys_socket, sys_read, and a few
others)
Walleye simply reads the data from the db. So more than likely
something is happening between hflow and the db. I made a quick
modification to the mysql configuration because starting with 5.x
versions, the mysql client library no longer automatically reconnects
after timeout. So I made the timeout equivalent to a year so that
connections to the db would not timeout. This seemed to make mine work.
I am pretty sure the rule update bug you mention below is fixed in
1.3. The reason the alerts do not show after you update the rules is
similar to this ticket that was submitted. The update script needs to
be fixed so that when you implement the new ruleset, it also loads the
new signature ids into the db. (https://projects.honeynet.org/honeywall/ticket/2
).
Are you probing the honeypot with traffic that would raise alerts, and
is the attack system on a different network than your honeypot?
Thanks in advance,
Rob
On Feb 23, 2008, at 3:49 AM, [EMAIL PROTECTED] wrote:
Hi,
I can confirm that the issue also appears in the latest release of
roo-1.2 after updating the honeywall with "yum update".
root-files-8.1-1.1.1
roo-base-6-17.hw
hflowd-1.0-42
snort 2.6.1.4 (Build 54)
Running IDS/IPS processes:
root 9174 0.0 7.9 204032 163660 ? Ss 03:14 0:04
snort-inline -D -c /etc/snort_inline/snort_inline.conf -Q -l /var/
log/snort_inline/20080223 -t /var/log/snort_inline
snort 9549 0.6 70.9 1538748 1468900 ? Ss 03:22 2:47
snort-plain -D -c /etc/snort/snort.conf -i eth1 -l /var/log/snort/
20080223 -u snort -t /var/log/snort -N (host ( xxx.xxx.xxx.xxx or
xxx.xxx.xxx.xxx ))
Alerts are captured in /var/log/snort but are not displayed in
Walleye - hflowd seems to be working fine, and connections are
correctly logged to /var/log/pcap
I also think that I've discovered a bug when updating the ruleset
with Oinkmaster and trying to restart Snort: While updating, the
CURRENT snapshot is downloaded. However, the definitions for UDP
rules are not working with version 2.6. This is due to the flow:
statement.
Example:
alert udp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC udp
port 0 traffic"; flow:to_server; reference:bugtraq,576;
reference:cve,1999-0675; reference:nessus,10074; classtype:misc-
activity; sid:525; rev:10;)
A correct definition for 2.6 would be:
alert udp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC udp
port 0 traffic"; reference:bugtraq,576; reference:cve,1999-0675;
reference:nessus,10074; classtype:misc-activity; sid:525; rev:9;)
Using the CURRENT snapshot, Snort will not be able to restart, and
alerts will not be captured. Anyone who can confirm this behavior,
too?
Possible log entries in /var/log/messages:
FATAL ERROR: /etc/snort/rules/bad-traffic.rules(28): Cannot check
flow connection for non-TCP traffic
*** SOLUTION ***
To fix this issue, I simply edited /hw/sbin/hwruleupdate and changed
the following line from
http://www.snort.org/pub-bin/oinkmaster.cgi/${HwOINKCODE}/rules/
snortrules-snapshot-CURRENT.tar.gz
to
http://www.snort.org/pub-bin/oinkmaster.cgi/${HwOINKCODE}/rules/
snortrules-snapshot-2.6.tar.gz
After that, I was able to restart Snort, and now, alerts are being
written to /var/log/snort - but are not displayed in Walleye.
Is this maybe due to a permission problem? Because my latest
snort_fast and snort_full files are owned by root. I would greatly
appreciate any hints concerning this issue.
Best Regards,
Snort
From: rvmcmil at gmail.com> To: honeywall at public.honeynet.org
Subject: Re: [Honeywall] Would like to bring this ticket to the
public list...
Date: Sat, 9 Feb 2008 11:08:26 -0600
Ok... finally back home.
Nothing ever appears? Or does it appear when the honeywall is first
started and then stops updating?
I am currently in the process of upgrading from hflow to hflow2 so
this might fix the problem. Need a bit of time to rip out hflow and
all its management pieces and put in hflow2. Hope to have either a
new iso or rpms you can update soon.
Sorry for the delay...
Rob
On Feb 8, 2008, at 9:01 AM, M Lists wrote:
I've only had this problem with 1.3...
With regards to this issue, I am seeing the same thing.
Snort is picking up traffic, pcaps are saved, nothing appearing in
the
walleye interface. 0 traffic.
_______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall
_______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall
