Re: ipfilter traffic blocking and tcpdump snort etc
On Fri, 5 Dec 2003 00:24:12 + Jez Hancock [EMAIL PROTECTED] wrote: Hi, I've blocked a dozen or so addresses using ipfilter: block in quick on fxp0 from 208.186.60.116 to any block in quick on fxp0 from 216.230.149.11 to any etc but I still see a lot of traffic those hosts in trafshow, snort and other packet capturing utils. Why is this? Is there any alternative method of blocking access from certain hosts so that this traffic is not 'seen' by higher level /userland apps? As background, the blocked hosts were part of a denial of service attack which has been going on for a few hours now. The attack was aimed at port 80, although an odd artifact is that no httpd log entries were made for any of the hosts attempting to connect on port 80. A cursory nmap scan of a few of the hosts shows that all hosts had both port 25 and 80 open, but none of the hosts accepted connections on either of those ports. Any idea what kind of attack this could be? -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] You are probably seeing the supposedly blocked packets on the outside of network. Observe them on inside, i.e., on the interface not fxp0. What you are seeing are packets ipfilter is just about to handle. I don't understand your second question. Are you thinking about tcp wrapper, reset feature of snort, etc ? horio shoichi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter traffic blocking and tcpdump snort etc
Hi Horio, Cheers for reply. On Fri, Dec 05, 2003 at 07:33:49PM +0900, horio shoichi wrote: On Fri, 5 Dec 2003 00:24:12 + Jez Hancock [EMAIL PROTECTED] wrote: Hi, I've blocked a dozen or so addresses using ipfilter: block in quick on fxp0 from 208.186.60.116 to any block in quick on fxp0 from 216.230.149.11 to any etc but I still see a lot of traffic those hosts in trafshow, snort and other packet capturing utils. Why is this? You are probably seeing the supposedly blocked packets on the outside of network. Observe them on inside, i.e., on the interface not fxp0. Not sure what you mean here, what command would you issue via tcpdump or snort to do what you suggest? What you are seeing are packets ipfilter is just about to handle. Right - it's just I would have thought that ipfilter handled packets before they reached any traffic dumping utils. I see what you're getting at. Presumably snort for example uses the bpf driver via pcap(?) to capture network traffic... actually reading bpf(4) clears things up a little: Associated with each open instance of a bpf file is a user-settable packet filter. Whenever a packet is received by an interface, all file descriptors listening on that interface apply their filter. Each descriptor that accepts the packet receives its own copy. Is there any alternative method of blocking access from certain hosts so that this traffic is not 'seen' by higher level /userland apps? I don't understand your second question. Are you thinking about tcp wrapper, reset feature of snort, etc ? Let me rephrase that one :P I meant is there a method - for example such as adding some kind of routing via arp - so that packets are dropped on the floor even quicker than they would be via the firewall method? -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter traffic blocking and tcpdump snort etc
On Friday 05 December 2003 11:58, Jez Hancock wrote: Let me rephrase that one :P I meant is there a method - for example such as adding some kind of routing via arp - so that packets are dropped on the floor even quicker than they would be via the firewall method? You could bind the ip's to the loopback interface, but I think the firewall setup is quicker. -- Melvyn === FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #1: Thu Dec 4 12:47:31 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOAPM_NODEBUG i386 === pgp0.pgp Description: signature
Re: ipfilter traffic blocking and tcpdump snort etc
On Fri, Dec 05, 2003 at 01:10:16PM +0100, Melvyn Sopacua wrote: On Friday 05 December 2003 11:58, Jez Hancock wrote: Let me rephrase that one :P I meant is there a method - for example such as adding some kind of routing via arp - so that packets are dropped on the floor even quicker than they would be via the firewall method? You could bind the ip's to the loopback interface, but I think the firewall setup is quicker. Interesting(!) idea but kind of does the DOS'ers job for 'em! I'm really curious as to what type of attack it actually was. Right now I know: - it was aimed at a single address on port 80 - global apache errorlog was relatively quiet in the run up to the exhaustion of apache with only a small hint that a larger number of requests were being made: [Thu Dec 4 18:47:46 2003] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 146 total children [Thu Dec 4 18:47:47 2003] [error] server reached MaxClients setting, consider raising the MaxClients setting [Thu Dec 4 18:52:34 2003] [notice] child pid 91863 exit signal Segmentation fault (11) snip same error log line repeated around 4,500 times! [Fri Dec 5 00:13:04 2003] [notice] child pid 38280 exit signal Segmentation fault (11) [Fri Dec 5 01:35:52 2003] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 17 total children note the 5min gap between the server reaching the MaxClients setting and the server collapsing with no err log entries in between - no HTTP requests were logged by apache from any of the dozen or so attacking hosts - snort captured only SYN packets from the attacking hosts (I suppose this explains why no requests were logged by apache) - all the attacking hosts had both port 25 and 80 open, although none of those hosts accepted inbound connections to those ports Would appear someone had control over a few zombie hosts and was able to coordinate a distributed attack - thankfully it was only a dozen or so hosts :P -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfilter traffic blocking and tcpdump snort etc
Maybee an upgrade of apache would be a good start?. and have a look at mod_bandwidth http://www.cohprog.com/mod_bandwidth.html and mod_dosevasive http://www.nuclearelephant.com/projects/dosevasive/ . -david -Original Message- From: Jez Hancock [mailto:[EMAIL PROTECTED] Sent: Friday, 5 December 2003 23:41 To: [EMAIL PROTECTED] Subject: Re: ipfilter traffic blocking and tcpdump snort etc On Fri, Dec 05, 2003 at 01:10:16PM +0100, Melvyn Sopacua wrote: On Friday 05 December 2003 11:58, Jez Hancock wrote: Let me rephrase that one :P I meant is there a method - for example such as adding some kind of routing via arp - so that packets are dropped on the floor even quicker than they would be via the firewall method? You could bind the ip's to the loopback interface, but I think the firewall setup is quicker. Interesting(!) idea but kind of does the DOS'ers job for 'em! I'm really curious as to what type of attack it actually was. Right now I know: - it was aimed at a single address on port 80 - global apache errorlog was relatively quiet in the run up to the exhaustion of apache with only a small hint that a larger number of requests were being made: [Thu Dec 4 18:47:46 2003] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 146 total children [Thu Dec 4 18:47:47 2003] [error] server reached MaxClients setting, consider raising the MaxClients setting [Thu Dec 4 18:52:34 2003] [notice] child pid 91863 exit signal Segmentation fault (11) snip same error log line repeated around 4,500 times! [Fri Dec 5 00:13:04 2003] [notice] child pid 38280 exit signal Segmentation fault (11) [Fri Dec 5 01:35:52 2003] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 17 total children note the 5min gap between the server reaching the MaxClients setting and the server collapsing with no err log entries in between - no HTTP requests were logged by apache from any of the dozen or so attacking hosts - snort captured only SYN packets from the attacking hosts (I suppose this explains why no requests were logged by apache) - all the attacking hosts had both port 25 and 80 open, although none of those hosts accepted inbound connections to those ports Would appear someone had control over a few zombie hosts and was able to coordinate a distributed attack - thankfully it was only a dozen or so hosts :P -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter traffic blocking and tcpdump snort etc
On Sat, Dec 06, 2003 at 12:01:09AM +1100, David wrote: Maybee an upgrade of apache would be a good start?. and have a look at mod_bandwidth http://www.cohprog.com/mod_bandwidth.html and mod_dosevasive http://www.nuclearelephant.com/projects/dosevasive/ I upgrade manually using portupgrade where necessary every weekend after the weekly periodic run. Without doubt apache is up to date - unless any changes to the ports in the last few days :P Server: Apache/1.3.29 (Unix) mod_accounting/0.5 PHP/4.3.4 mod_perl/1.28 mod_throttle/3.1.2 Gets me that something as simple as a flood of packets can just cripple a service so easily given enough bandwidth (although adding ipf rules helped a lot). I've not actually checked out mod_bandwidth, I use mod_throttle - fwiw, it's not great for multiple vhosts :( - should check that out, thanks. mod_dosevasive sounds even more interesting. Heading toward that link now... Very interesting, particularly this feature: The blacklist can/should be configured to talk to your network's firewalls and/or routers to push the attack out to the front lines, but this is not required. This is something I could do with for Exim as well :P Not sure that it would have helped last night actually - no hits were actually registered by apache during the attack from any of the attacking hosts. As I said in another post, all the packets I captured from the attacking hosts with snort during the packet attack only had the SYN flag set - it appeared to be the sheer volume of these packets to port 80 that was causing apache child procs to die rapidly in succession. The hardest part over the few hours the attack lasted was working out from the snort logs which _bad_ hosts I'd already blocked with ipf, which hosts were legit and which hosts I still had to block - over time more hosts joined in the attack. The last 20mins or so consisted of a flood from a single host I'd missed in my blocking spree! Fun and games :=P -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter traffic blocking and tcpdump snort etc
On Fri, 5 Dec 2003 10:58:39 + Jez Hancock [EMAIL PROTECTED] wrote: Hi Horio, Cheers for reply. On Fri, Dec 05, 2003 at 07:33:49PM +0900, horio shoichi wrote: On Fri, 5 Dec 2003 00:24:12 + Jez Hancock [EMAIL PROTECTED] wrote: Hi, I've blocked a dozen or so addresses using ipfilter: block in quick on fxp0 from 208.186.60.116 to any block in quick on fxp0 from 216.230.149.11 to any etc but I still see a lot of traffic those hosts in trafshow, snort and other packet capturing utils. Why is this? You are probably seeing the supposedly blocked packets on the outside of network. Observe them on inside, i.e., on the interface not fxp0. Not sure what you mean here, what command would you issue via tcpdump or snort to do what you suggest? Um, that's my bad assumption ! I thought your box is a filtering router, and has at least two interfaces. What you are seeing are packets ipfilter is just about to handle. Right - it's just I would have thought that ipfilter handled packets before they reached any traffic dumping utils. I see what you're getting at. Presumably snort for example uses the bpf driver via pcap(?) to capture network traffic... actually reading bpf(4) clears things up a little: Associated with each open instance of a bpf file is a user-settable packet filter. Whenever a packet is received by an interface, all file descriptors listening on that interface apply their filter. Each descriptor that accepts the packet receives its own copy. The log keyword on blocking rules would have helped... Is there any alternative method of blocking access from certain hosts so that this traffic is not 'seen' by higher level /userland apps? I don't understand your second question. Are you thinking about tcp wrapper, reset feature of snort, etc ? Let me rephrase that one :P I meant is there a method - for example such as adding some kind of routing via arp - so that packets are dropped on the floor even quicker than they would be via the firewall method? In my observation, packet filters are the quickest since blocked packets die in ip_input(), below which is where ethernet interrupt handlers are laid out. horio shoichi -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter traffic blocking and tcpdump snort etc
Hi, I've blocked a dozen or so addresses using ipfilter: block in quick on fxp0 from 208.186.60.116 to any block in quick on fxp0 from 216.230.149.11 to any etc but I still see a lot of traffic those hosts in trafshow, snort and other packet capturing utils. Why is this? Is there any alternative method of blocking access from certain hosts so that this traffic is not 'seen' by higher level /userland apps? As background, the blocked hosts were part of a denial of service attack which has been going on for a few hours now. The attack was aimed at port 80, although an odd artifact is that no httpd log entries were made for any of the hosts attempting to connect on port 80. A cursory nmap scan of a few of the hosts shows that all hosts had both port 25 and 80 open, but none of the hosts accepted connections on either of those ports. Any idea what kind of attack this could be? -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
