On Mar 07, 2010, Rodney McKee wrote:

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

Ok.

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

Generally, psad assumes that packets associated with traffic that you don't
want to block is not logged.  So, if you allow any SSL traffic, then it is
not logged.  If you don't want to allow, say, SMTP traffic, then your iptables
policy would have a default LOG and DROP stance for this.  And, because you
block connections from being established, you don't end up logging a huge
number of data packets.  You could modify this stance to say, log all SYN
packets to port 443, but you certainly don't want to log every data and/or
ACK packet either way.

Even with this stance, psad will still pick up log messages that are
generated by fwsnort (if you decide to deploy it).  The key difference is
that log messages from fwsnort are only generated when a real attack (or
signature match at least) is found at the application layer.

You can find an example iptables policy script that builds a policy consistent
with this here:

http://www.cipherdyne.org/LinuxFirewalls/ch01/


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

What are the specifics of the packets being logged?  Are SSL connections
actually being established?  If ACK's are being logged, I think you will
need to tune your iptables policy.

--Mike

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