Michael, 


----- "Michael Rash" <m...@cipherdyne.org> wrote: 
> On Mar 05, 2010, Rodney McKee wrote: 
> 
> > William, 
> > 
> > Certainly agree with enabling the option. 
> 
> What is the output of the following command: 
> 
> # psad -S |grep "scan sources" 

Total scan sources: 4183 

Checked this against all the other firewalls and found 
Total scan sources: 5867 
and 
Total scan sources: 4480 

with nothing like the memory usage that the swapping one does. I guess the 
question is, whats considered high. 

> 
> ? If the number is extremely high - which in itself is made possible by 
> enabling 
> ENABLE_PERSISTENCE and if your firewall logs a lot of source IP's - then psad 
> could use a lot of memory. The reason is that perl itself needs the memory to 
> track the IP's along with the associated scan data. In general though, 
> through 
> proper tuning of your firewall and assuming your system is not relentlessly 
> scanned by millions of source IP's, psad should not consume a huge amount of 
> memory. 
> 
> Either way, I think William's idea of disabling ENABLE_PERSISTENCE is 
> spot-on. 
> If this does not fix the problem, then there is potentially a bug somewhere, 
> and 
> it is even possible that this bug is in perl itself. (psad has exposed bugs 
> in 
> perl before - particularly in an older version w.r.t. a certain combination 
> of 
> iptables log data with the regex's psad uses to parse this data.) 
> 
> > Problem is this is our quietest network. My concern is that this could be a 
> > small memory leak or that something is not being handled correctly in the 
> > process. 
> 
> That's interesting. I think the number of scan sources is going to be a 
> strong 
> indicator. 
> 
> > I'm just wonder if the condition mentioned in my recent email with LOTS of 
> > traffic on a particular address over a period of time from multiple sources 
> > could be causing an issue. In a 10hour period I have 30844 logged attempts. 
> 
> If the 30844 attempts were from distinct source IP's, then this could be an 
> issue. How is your iptables policy tuned? What traffic is being logged? I 
> suspect that 30844 attempts in 10 hours are not just scans - more likely 
> "normal" traffic is being logged too. 

We log everything. 
The 30844 in 10 hours are just to the IP address in question, if it was not for 
that address, all would be quiet. The ip address is actually only used for 
out-bound snat and has no access being forwarded inbound. All the attempts are 
port 443. 

> 
> > Does auto_dl apply to dst addresses? If so I suspect an entry their might 
> > help or naturally just don't log in iptables. Yes, these are my options but 
> > their would appear to be an issue with psad consuming memory, would like to 
> > find out what could be the root cause and maybe help improve psad as it is 
> > proving to be an awesome tool. 
> 
> Thanks, glad you like psad. auto_dl applies to source IP's. 
> 
> 
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
psad-discuss mailing list
psad-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/psad-discuss

Reply via email to