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