[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sentry
Subject:    Re: [Abacus] Portsentry and IP Filter
From:       "Sanjeev B.S." <sanjeev () mbu ! iisc ! ernet ! in>
Date:       2001-10-31 13:46:17
[Download RAW message or body]

I agree that IPChains blocks packets before they reach portsentry, but
would like to share my experience which is puzzling. It seems to indicate
'some penetration' through IPchains. (This is to say that I am not an
expert but need some correction very badly. ;-)

I configured ipchains in the following way (in the same order).
1) Default ACCEPT for input and output and DENY for forward.
2) Then, on port-by-port account I allowed some hosts to connect.
   (Eg. Accept port 22 to some machine and '! -y' from that machine.)
3) Deny all other inputs. (This nullifies the policy of default ACCEPT.)

Then I did nmap scan from other machine, etc. Tried SSH too through some 
other machines and so on. Everything seemed as expected.

But occasionally I would get some portsentry warnings, telling some port 
is getting probed. (I think all UDP only, I am not sure. Ports are 
usually 137, 138, 80, etc.)

So, IPchains working, Portsentry coexisting!?

I am using Redhat 7.1 (2.4.9-6). I would be thankful to anyone who replies 
to this and helps me getout of this 'problem'. (There are too many UDP 
scans, principally because of Nimda, I think. So it's irritating.)

Thanks very much for your patience and any help.
-Sanjeev

On Tue, 30 Oct 2001, Nate Campi wrote:

On Tue, Oct 30, 2001 at 01:05:39PM +0000, marvin wrote:
> 
> Silly question time.
> 
> Portsentry works great but when I added IP Filter it was blocking the junk
> BEFORE portsentry could see it.
> 
> How do I make Portsentry monitor BEFORE the IP Filter.

This comes up every so often, usually about linux and ip(chains|tables).

The kernel blocks the packets before a user-space app like portsentry
can see the packets. You have a couple options:

1) use ipfilter to allow packets to some ports you watch with
   portsentry, and catch the connections that way

2) continue blocking everything with ipfilter, and keep portsentry up
   and running in case (for some reason) ipfilter gets it's rules
   cleared or it's kernel module can't load, etc, etc. It's defense in
   depth, a backup for when ipfilter isn't there.

[prev in list] [next in list] [prev in thread] [next in thread]