Shorewall users: I got a problem in my company where one (infected) laptop attached to the network and cause the following problem: At the PC hosting squid and shorewall: # netstat -na tcp 0 1352 192.168.1.1:3128 192.168.1.207:2464 LAST_ACK tcp 0 1350 192.168.1.1:3128 192.168.1.207:4000 LAST_ACK tcp 0 1356 192.168.1.1:3128 192.168.1.207:1696 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:1440 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:4992 LAST_ACK tcp 0 1350 192.168.1.1:3128 192.168.1.207:2944 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:2432 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:1664 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:1152 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:4960 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:2400 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:1632 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:1120 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:4928 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:2624 LAST_ACK tcp 0 1356 192.168.1.1:3128 192.168.1.207:2368 LAST_ACK tcp 0 1356 192.168.1.1:3128 192.168.1.207:1600 LAST_ACK tcp 0 1352 192.168.1.1:3128 192.168.1.207:4896 LAST_ACK tcp 0 1350 192.168.1.1:3128 192.168.1.207:2592 LAST_ACK tcp 0 1354 192.168.1.1:3128 192.168.1.207:1056 LAST_ACK And this list is very very long. I believe this is like a sync flood? It tried to go to the internet, and since it generated lots of communication, the ports where the Squid uses to connect to other hosts were all used up. As the result, squid is overloaded, and no one can browse the internet. Any rule to prevent this from happening? (i.e. check if the packet is incomplete packet?) NOTE: Machine runs linux mandrake 9.2 Shorewall 1.4.7 Squid and firewall on the same machine Policy: loc net ACCEPT ULOG fw net ACCEPT ULOG fw loc ACCEPT ULOG net all DROP ULOG all all DROP ULOG loc vpn ACCEPT ULOG vpn loc ACCEPT ULOG Thanks for your help. Lito
Lito Kusnadi wrote:> > Any rule to prevent this from happening? (i.e. check if the packet is > incomplete packet?)I would try adding rate-limiting to your loc->proxy rule(s). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Is there any way to detect if it is an incomplete/malicious packet and apply the rate limit to it? -----Original Message----- From: shorewall-users-bounces@lists.shorewall.net [mailto:shorewall-users-bounces@lists.shorewall.net] On Behalf Of Tom Eastep Sent: Thursday, 27 May 2004 1:56 PM To: Mailing List for Shorewall Users Subject: Re: [Shorewall-users] Prevent attack from LAN? Lito Kusnadi wrote:> > Any rule to prevent this from happening? (i.e. check if the packet is > incomplete packet?)I would try adding rate-limiting to your loc->proxy rule(s). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net _______________________________________________ Shorewall-users mailing list Post: Shorewall-users@lists.shorewall.net Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users Support: http://www.shorewall.net/support.htm FAQ: http://www.shorewall.net/FAQ.htm
----- Original Message ----- From: "Lito Kusnadi"> Is there any way to detect if it is an incomplete/malicious packet and > apply the rate limit to it?I''m curious as well Lito. But I''m also looking for other ways to go about the problem. Rate limiting I think is just the most intuitive and is why Tom mentioned this. Rate limiting is fairly effective but its a bandaid to a bigger problem I feel. I''m in the middle of a research and development stage of how to deal with exactly the same type of scenario. The scenario being when the internal anti-virus server measures fail for what ever reason.. to contain a virus/worm. Or a Roadwarrior brings in the same on his/her laptop.. I''m pretty new to this though. Snort seems to be the best that I''ve looked at for looking for such anomalies.. But then again I''m new to this type of proaction.. Joshua Banks