I'm wondering why Bro is so quiet. So I tried tcpdump with Bro's filter ...
[root@rhyolite rreitz]# /usr/sbin/tcpdump -i eth2 '((((((((((((((((((((((port 111) or (port smtp)) or (port ftp)) or (port smtp)) or (icmp)) or (tcp[2:2] > 32770 and tcp[2:2] < 32901 and tcp[0:2] != 80 and tcp[0:2] != 22 and tcp[0:2] != 139)) or ((ip[6:2] & 0x3fff != 0) and tcp)) or (port 111)) or (tcp dst port 80 or tcp dst port 8080 or tcp dst port 8000)) or (tcp src port 80 or tcp src port 8080 or tcp src port 8000)) or (port 6666)) or (port 512 or port 513 or port 515)) or (tcp port 80 or tcp port 8080 or tcp port 8000 or tcp port 8001)) or (port telnet or tcp port 513)) or (port telnet)) or (port 53)) or ((src net 131.225.0.0/16 or src net 198.124.212.0/24 or src net 198.124.213.0/24) and (dst port 135 or dst port 137 or dst port 139 or dst port 445))) or (tcp[13] & 7 != 0)) or (port ftp)) or (port 6667)) or (port 143)) or (udp port 69)) or (port 161 or port 162)'
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
....
Killing after ~10 seconds ...
166 packets captured
249098 packets received by filter
248721 packets dropped by kernel
Do I read this as the kernel dropped the packets since they failed the Bro filter, or is the kernel just dropping packets because it's Tuesday?
I see in the email list advice like ...
"That all boils down to this certainly looking like a problem with the
packet filter itself rather than Bro."
I'm using ...
[root@rhyolite rreitz]# cat /etc/redhat-release
Scientific Linux Fermi LTS release 4.4 (Wilson)
This is Fermilab's release of RedHat Enterprise 4, update 4.
[root@rhyolite rreitz]# rpm -qa | egrep pcap
libpcap-0.8.3-10.RHEL4
Bro is 1.2.1 - not using the built-in libpcap.
[root@rhyolite bro-1.2.1]# tail /etc/sysctl.conf
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
net.core.rmem_max = 16777216
[root@rhyolite bro-1.2.1]# /sbin/sysctl net.core.rmem_max
net.core.rmem_max = 131071
At this point, I remembered Jason Lee's advice to tune the Linux kernel. He suggested this link
http://www.net.t-labs.tu-berlin.de/research/bpcs/
So I did ...
[root@rhyolite bro-1.2.1]# cat /proc/sys/net/core/rmem_default
110592
[root@rhyolite bro-1.2.1]# echo 33554432 > /proc/sys/net/core/rmem_default
[root@rhyolite bro-1.2.1]# echo 33554432 > /proc/sys/net/core/rmem_max
[root@rhyolite bro-1.2.1]# echo 10000 > /proc/sys/net/core/netdev_max_backlog
[root@rhyolite bro-1.2.1]# /sbin/sysctl net.core.rmem_max
net.core.rmem_max = 33554432
OK, this looks like progress. I tried the same tcpdump as above. Now I see ...
121 packets captured
149216 packets received by filter
121673 packets dropped by kernel
Before the 'tune', the kernel was dropping 99.8%. After the tune, it's dropping 81.5%. Not much better. No fair to suggest I drop Linux for FreeBSD!
Suggestions?
Thanks,
Randy Reitz
Computer Security Team