Michael,
----- "Michael Rash" <m...@cipherdyne.org> wrote:
> 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/
>
I guess my version of logging all traffic is what you have in the book. The
setup we have is effectively what you have documented.
This firewall, 1 of 6 sets is the only one that gets this aggressive (for what
of a better word) number of connection attempts. The other site we have run the
same configurations and do not see the same issue.
>
> > > > > 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.
>
>
The interface/ip address does not accept connections to port 443 hence the
attempts are logged.
A sample of the logs:
Mar 9 22:28:00 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=201.130.238.225
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=41943 DF PROTO=TCP
SPT=2186 DPT=443 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204056401010402)
Mar 9 22:28:01 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=75.36.127.219
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=2594 DF PROTO=TCP
SPT=2126 DPT=443 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (020405AC01010402)
Mar 9 22:28:01 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=217.216.65.172
DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=109 ID=10162 DF PROTO=TCP
SPT=1930 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 OPT
(020405B40103030201010402)
Mar 9 22:28:04 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=217.216.65.172
DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=109 ID=10215 DF PROTO=TCP
SPT=1930 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 OPT
(020405B40103030201010402)
Mar 9 22:28:07 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=75.36.127.219
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=2734 DF PROTO=TCP
SPT=2126 DPT=443 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (020405AC01010402)
Mar 9 22:28:09 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=190.71.102.47
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=46277 DF PROTO=TCP
SPT=52690 DPT=443 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (020405AC01010402)
Mar 9 22:28:10 fw2 kernel: DROP INVALID INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=75.36.127.219
DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=15426 DF PROTO=TCP
SPT=1989 DPT=443 WINDOW=0 RES=0x00 ACK RST URGP=0
Mar 9 22:28:10 fw2 kernel: DROP INPUT IN=bond0 OUT=
MAC=00:1b:21:3d:d7:d0:00:d0:01:b3:f4:00:08:00 SRC=217.216.65.172
DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=109 ID=10331 DF PROTO=TCP
SPT=1930 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 OPT
(020405B40103030201010402)
------------------------------------------------------------------------------
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
