----- "Michael Rash" <m...@cipherdyne.org> wrote: 
> 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? 
> 

RHEL5.4 and perl version 5.8.8 



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

Yes their is a lot of internet noise, some we actually do not log, I suspect 
more could be excluded. Is their any information available of what not to log 
then? 


> > > 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? 
> 
> 
Their is no service listening on the ip that is being hit with the 443 traffic, 
it's like it was a previously address that is still being accessed. 
I've not yet deployed fwsnort at this stage but it's certainly on the list. 


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