Jason Pfingstmann wrote:
> First off, thanks to those who replied re: Happy Medium (linux/windows
> co-existance), I guess an A/B switcher is the way to go for now. ;)
> 
> I have been trying to track down a memory leak our server has had for the
> last few days.  It started Friday when the server would crash (more
> accurately the kernel would kick out user-space programs because of 100%
> memory usage - 1 GB physical and 1.9 GB swap -- overkill, but this was an
> LTSP server at one point) every 2 hours or so.  I figured out this weekend
> that the problem is only present when the network is up and our iptables
> nat script is run.  I then used iptraf to figure out what systems might be
> causing problems and found that 2 systems were sending out ICMP packets. 
> One was infected with the Welchia worm which has been taken care of and
> the other didn't find any viruses (Using Norton with latest definitions). 
> I am trying to pin-point this problem, and am thinking about just blocking
> all ICMP packets that are outbound over NAT as a temporary fix.  I'm not
> going to be in the office until Wednesday and need to get this up and
> running tomorrow morning if possible.  Here is what my iptraf monitor
> shows:
> ICMP echo req (92 bytes) from 192.168.0.146 to 192.166.55.110 on eth0 ICMP
> echo req (92 bytes) from 208.186.160.162 to 192.166.55.110 on eth1
> 
> It repeats this one right after another, with various different
> destinations, all in the 192.x.x.x network.

Those addresses aren't private space addresses. You have packets going 
out to the net it looks like to me. I would be curious to find out which 
programs are pinging the net...

> 
> I have tried various commands such as iptables -A INPUT -p ICMP -i eth0 -j
> DROP, but none have blocked this.  Am I missing something obvious?

Try inserting this command before the others in your scripts... 
unfortunately, iptables doesn't have (last I checked) a working -C flag. 
   If you are not using a script, try doing iptables -I INPUT 1 -p ICMP 
-i eth0 -j DROP (or REJECT). This insert the drop rule as the first rule 
in the INPUT chain. Rule placement is extremely important, if you placed 
this line *after* you accept the packet using another rule this one will 
be by-passed.

HTH
Patrick

> 
> Thanks.
> 
> Jason Pfingstmann
> 
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss