Earl,
I think they are related as once snort or whatever prog causes all the
memory to be used up and the box goes into dipping in swap by this time
WALLEYE UI doesn't even see a normal scan.
Its almost like the honeywall is as good as crashed state. At this
point if you even ran TCPDUMP on the bridged interface, you will see
that TCPDUMP starts missing packets.
-Parvinder Bhasin
Earl wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think this was a case of "snort using up all available memory"
and doesn't have anything to do with the data issue (correct me if
I'm wrong).
I can remember somewhere around snort 2.6.0 when I had mem troubles
similar to this. After research I ended up manually setting the
directive:
config detection: search-method <method>
Where method can be any of:
ac
ac-std
ac-bnfa
acs
ac-banded
ac-sparsebands
lowmem
In general, as I recall, the order these choices are in more/less
go from Higher performance memory hog (top) to slightly lower
performance (still ok for smaller nets) memory efficient settings.
I think I had good results with "acs". so, in your snort.conf and
snort_inline.conf you might want to try adding:
config detection: search-method lowmem
Then restart and see if it helps. If so, then you might want to do
some research on the other methods to see if it would be worth
moving up the resource ladder (unless lowmem just works)
Earl
On Tue, 23 Oct 2007 14:51:49 -0400 Rob McMillen <[EMAIL PROTECTED]>
wrote:
Anyone else on the list seeing the same issue?
Anyone else not seeing it?
I've been running my honeywall in vmware for a bit now with a
virtual
honeypot, and the issue I had was related to the connection being
close to the db from hflow and sebek. Increasing the wait_timeout
to
a year fixed that on my side.
This one is a tricky one. The problem is that snort and
snort_inline
already use a lot of memory to load the rules and do the stream
reassembly stuff.
Do your pcap files increase in size over time by any chance?
Hflow populates the db which walleye uses for data display. It
loops
through the following files; parses the data; and puts it in the
db:
1. Argus pipe
2. Sebek pipe
3. /var/log/snort/snort_unified
4. /var/log/snort_inline/snort_inline_unified
The argus pipe is where the flows in the UI come from (once they
are
dumped to the db). The alerts for snort come from the unified
files.
When you notice lack of updated data in the UI, can you do a
netstat
-an | grep mysql and see if you see three entries? One should be
the
mysql unix socket listening and the other two should be sebek and
hflow scripts connected to the unix socket.
This is what mine looks like
[EMAIL PROTECTED] ~]# netstat -an | grep mysql
unix 2 [ ACC ] STREAM LISTENING 5628
/var/lib/mysql/mysql.sock
unix 3 [ ] STREAM CONNECTED 6863
/var/lib/mysql/mysql.sock
unix 3 [ ] STREAM CONNECTED 6859
/var/lib/mysql/mysql.sock
Before, when I noticed the lack of data in the UI, only the
Listening
one was there.
Sorry this is not a here is how you fix it email... trying to
identify
the problem you are seeing. Would be much easier if I could cause
it
on my system. Wonder if this is because I have it in vmware?
Rob
On 10/23/07, Parvinder Bhasin <[EMAIL PROTECTED]> wrote:
Earl,
Its roo 1.2 hw-1. Its stock version. I did a brand new install
on the
honeywall. No updates to snort rules etc or any updates. Within
half an
hour memory had jumped from 400mb to around 900mb. Traffic is
at
minimum almost nothing actually.
-Parvinder Bhasin
_______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Charset: UTF8
Version: Hush 2.5
wkYEARECAAYFAkcd2H4ACgkQk7+e+4lPSm2VDACglLyG09bnq4p1e2U/QNzH1N8mkJsA
niCbvgMNneKTPqiuiVh/445OtxMe
=L6Ov
-----END PGP SIGNATURE-----
_______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall
_______________________________________________
Honeywall mailing list
[email protected]
https://public.honeynet.org/mailman/listinfo/honeywall