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