FW: block + kill connections

FW: block + kill connections

[Michael D. Berger]

Now thw wrong list.  Damm!
Mike
--
Michael D. Berger
m.d.berger@ieee.org 

> -----Original Message-----
> From: Michael D. Berger [mailto:m.d.berger@ieee.org] 
> Sent: Sunday, January 08, 2006 5:59 PM
> To: Redhat-List
> Subject: FW: block + kill connections
> 
> 
> My apology.  Inadvertantly send to the individual rather than 
> the list.
> Some list managers think that this is good.  I do not.
> Mike.
> --
> Michael D. Berger
> m.d.berger@ieee.org 
> 
> > -----Original Message-----
> > From: Michael D. Berger [mailto:m.d.berger@ieee.org] 
> > Sent: Sunday, January 08, 2006 5:47 PM
> > To: '/dev/rob0'
> > Subject: RE: block + kill connections
> > 
> > 
> > [...]
> > > On Sunday 2006-January-08 16:04, Robert Nichols wrote:
> > > > > iptables -I INPUT -s 1.2.3.4 -j DROP
> > > 
> > > > That will prevent communication by blocking any further incoming
> > > > packets, but won't do anything to tear down the connection.  See
> > > 
> > > Actually it would drop anything with a source address of 
> > > 1.2.3.4 which 
> > > happens to hit the filter INPUT chain, regardless of protocol 
> > > or state. 
> > > Perhaps the issue is as I suggested, the packets are 
> > hitting FORWARD, 
> > > or simply that a blocked connection has not yet timed out of 
> > > conntrack 
> > > or netstat listings.
> > > -- 
> > >     mail to this address is discarded unless "/dev/rob0"
> > >     or "not-spam" is in Subject: header
> > > 
> > > 
> > 
> > I have the same problem.  I DROP in the INPUT chain, but the 
> > connection
> > stays up and receives more junk.
> > 
> > There is no confusion with the FORWARD chain.  I have 
> > :FORWARD DROP [0:0],
> > and that is it.  I do not forward anything.
> > 
> > I like the suggestion in a previous post:
> > 
> >    iptables -I INPUT -s 1.2.3.4 -p tcp --tcp-flags ! FIN,RST 
> > NONE -j REJECT 
> >    --reject-with tcp-reset
> > 
> > however, I DROP from a libipq daemon, and REJECT  does not 
> > appear to be an
> > option. I could accomplish it if I could set the MARK from 
> > the daemon, but
> > this is not possible in the version I have, although it is 
> > possible in later
> > versions.
> > 
> > I await admonition by those more knowledgeable than I.
> > 
> > Mike.
> > --
> > Michael D. Berger
> > m.d.berger@ieee.org 
> > 
> > 
> 

Re: FW: block + kill connections

[/dev/rob0]

On Sunday 2006-January-08 17:01, Michael D. Berger wrote:
> > > I have the same problem.  I DROP in the INPUT chain, but
> > > the connection stays up

Likely so, insofar as your local process knows, as explained in my 
corrected reply to Bob Nichols. But ...

> > > and receives more junk. 

No, not if you used a rule as the OP did, with -I to put it at the top 
of INPUT rules. If a packet matches the first DROP rule, that's where 
it stops. If a --state RELATED,ESTABLISHED -j ACCEPT rule precedes the 
DROP, yes, but that's a different issue.

> > > I await admonition by those more knowledgeable than I.

Does it make sense now?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

RE: FW: block + kill connections

[Michael D. Berger]

> On Sunday 2006-January-08 17:01, Michael D. Berger wrote:
> > > > I have the same problem.  I DROP in the INPUT chain, but
> > > > the connection stays up
> 
> Likely so, insofar as your local process knows, as explained in my 
> corrected reply to Bob Nichols. But ...
> 
> > > > and receives more junk. 
> 
> No, not if you used a rule as the OP did, with -I to put it 
> at the top 
> of INPUT rules. If a packet matches the first DROP rule, that's where 
> it stops. If a --state RELATED,ESTABLISHED -j ACCEPT rule 
> precedes the 
> DROP, yes, but that's a different issue.
> 
> > > > I await admonition by those more knowledgeable than I.
> 
> Does it make sense now?

[...]

It does make sense in theory, but not in practice.  Below is an excerpt
from the results of an iptables-save (with numbers zeroed).  As you can
see, the QUEUE preceeds any ACCEPT except for -i lo.  The extra DROP is
my paranoia in case QUEUE doesn't work.  The OUTPUT chain blocks some
output that previous communications indicated should not be there. I
note that when I say that there are packets in both directions after
the DROP I have confirmed this with tethereal, which I have running in
the background.  Perhaps there are some timing issues that have not
been mentioned?

:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:MDB-IN - [0:0]
[0:0] -A INPUT -j MDB-IN
[0:0] -A OUTPUT -j MDB-OUT
[0:0] -A MDB-IN -i lo -j ACCEPT
[0:0] -A MDB-IN -p tcp -m tcp --dport 80 -j QUEUE
[0:0] -A MDB-IN -p tcp -m tcp --dport 80 -j DROP
[0:0] -A MDB-IN -m state --state RELATED,ESTABLISHED -j ACCEPT

Mike.
--
Michael D. Berger
m.d.berger@ieee.org