On Mar 05, 2010, Rodney McKee wrote:

> 
> 
> 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. 

Interesting.  A "high" number in this case would be in the hundreds of thousands
of sources.  Low thousands should not be an issue.

Which version of perl are you running and on which Linux distro?

> > ? 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. 

So your iptables policy is configured to essentially log every packet?  If
so, then there are going to be an awful lot of non-malicious traffic logged.
Is this necessary?

> > 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. 

If every packet is logged then there will be a log of data that is not
useful to psad - particularly if it is SSL data.  Even if you are running
fwsnort for full application layer inspection, things will go blind after
the certs are transferred.  Or, is there something that just happens to
be using port 443 that is not speaking SSL?

--Mike

> > > 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


------------------------------------------------------------------------------
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