Fw: How to remove Established Connection

Fw: How to remove Established Connection

[HareRam]

Seems to be tehre is no answer below mentioned
----- Original Message ----- 
From: "HareRam" <hareram@sol.net.in>
To: <netfilter@lists.netfilter.org>
Sent: Wednesday, October 09, 2002 9:43 PM
Subject: How to remove Established Connection


> Hi all Guru
> 
> how can i remove Dynamically ESTABLISHED connection
> for the perticular IP address or MAC address, on fly
> thanks for the advanced help
> 
> hare
> 
> 
> 

Re: Fw: How to remove Established Connection

[Antony Stone]

On Friday 11 October 2002 6:28 am, HareRam wrote:

> Seems to be tehre is no answer below mentioned

You are correct.   There is no mechanism to do what you want.

Antony.

> ----- Original Message -----
> From: "HareRam" <hareram@sol.net.in>
> To: <netfilter@lists.netfilter.org>
> Sent: Wednesday, October 09, 2002 9:43 PM
> Subject: How to remove Established Connection
>
> > Hi all Guru
> >
> > how can i remove Dynamically ESTABLISHED connection
> > for the perticular IP address or MAC address, on fly
> > thanks for the advanced help
> >
> > hare

-- 

Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Nobel Prizewinner in Physics

Re: Fw: How to remove Established Connection

[HareRam]

then ? how do i remove my establish client, when we do some accounting
when he logged out, he should not get any browsing, as well as he should be
removed from internet
how can i achieve

please guide me alternative method to achieve this

hare
----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.samba.org>
Sent: Friday, October 11, 2002 1:19 PM
Subject: Re: Fw: How to remove Established Connection


> On Friday 11 October 2002 6:28 am, HareRam wrote:
>
> > Seems to be tehre is no answer below mentioned
>
> You are correct.   There is no mechanism to do what you want.
>
> Antony.
>
> > ----- Original Message -----
> > From: "HareRam" <hareram@sol.net.in>
> > To: <netfilter@lists.netfilter.org>
> > Sent: Wednesday, October 09, 2002 9:43 PM
> > Subject: How to remove Established Connection
> >
> > > Hi all Guru
> > >
> > > how can i remove Dynamically ESTABLISHED connection
> > > for the perticular IP address or MAC address, on fly
> > > thanks for the advanced help
> > >
> > > hare
>
> --
>
> Anything that improbable is effectively impossible.
>
>  - Murray Gell-Mann, Nobel Prizewinner in Physics
>
>

Re: Fw: How to remove Established Connection

[Michael]

HareRam wrote:

>then ? how do i remove my establish client, when we do some accounting
>when he logged out, he should not get any browsing, as well as he should be
>removed from internet
>how can i achieve
>
>please guide me alternative method to achieve this
>

You remove the rule that accepts the established connection.

I have a specific rule for each host that is forwarded through firewall. 
If I want to allow the host, I add the rule in FORWARD chain:

ACCEPT     all  --  *      eth0    <ip_of_host>        
0.0.0.0/0          state RELATED,ESTABLISHED

When I want to stop them I just remove the rule. Even if the established 
entry appears and lingers in /proc/net/ip_conntrack, it can't go anywhere.
At least that's how it seems to work for me... Am I wrong??

Cheers,
Michael

Re: Fw: How to remove Established Connection

[HareRam]

thanks

let me try and get back to you
any more help required
iam doing now
thanks to you and Antony also

hare
----- Original Message -----
From: "Michael" <mutk@iprimus.com.au>
To: <netfilter@lists.samba.org>
Sent: Friday, October 11, 2002 2:45 PM
Subject: Re: Fw: How to remove Established Connection


> HareRam wrote:
>
> >then ? how do i remove my establish client, when we do some accounting
> >when he logged out, he should not get any browsing, as well as he should
be
> >removed from internet
> >how can i achieve
> >
> >please guide me alternative method to achieve this
> >
>
> You remove the rule that accepts the established connection.
>
> I have a specific rule for each host that is forwarded through firewall.
> If I want to allow the host, I add the rule in FORWARD chain:
>
> ACCEPT     all  --  *      eth0    <ip_of_host>
> 0.0.0.0/0          state RELATED,ESTABLISHED
>
> When I want to stop them I just remove the rule. Even if the established
> entry appears and lingers in /proc/net/ip_conntrack, it can't go anywhere.
> At least that's how it seems to work for me... Am I wrong??
>
> Cheers,
> Michael
>
>
>

Re: Fw: How to remove Established Connection

[Antony Stone]

On Friday 11 October 2002 10:15 am, Michael wrote:

> HareRam wrote:
> >then ? how do i remove my establish client, when we do some accounting
> >when he logged out, he should not get any browsing, as well as he should
> > be removed from internet
> >how can i achieve
> >
> >please guide me alternative method to achieve this
>
> You remove the rule that accepts the established connection.
>
> I have a specific rule for each host that is forwarded through firewall.
> If I want to allow the host, I add the rule in FORWARD chain:
>
> ACCEPT     all  --  *      eth0    <ip_of_host>
> 0.0.0.0/0          state RELATED,ESTABLISHED
>
> When I want to stop them I just remove the rule. Even if the established
> entry appears and lingers in /proc/net/ip_conntrack, it can't go anywhere.
> At least that's how it seems to work for me... Am I wrong??

Depending on how many established connections you want to cut off, compared 
to how many new connections you want to allow, it could be easier to do this 
the other way around:

have a standard rule:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
in your FORWARD chain, and then insert a rule *before* this one to 
specifically block the IP you want to disconnect:
iptables -I FORWARD -s a.b.c.d -j REJECT

This will then make sure that packets from that address do not get as far as 
the ESTABLISHED, RELATED rule, and therefore are no longer allowed through 
the machine.

Antony.

-- 

KDE 3.0.3 contains an important fix for handling SSL certificates.  Users of 
Internet Explorer, which suffers from the same problem but which
does not yet have a fix available, are also encouraged to switch to KDE 3.0.3.

http://www.kde.org/announcements/announce-3.0.3.html

Re: Fw: How to remove Established Connection

[HareRam]

Hi all
thanks its working using my own methods,
but idea is lot of people, especially Mr Antony's

what is the Recomended DROP or REJECT
just now my Rule is work with DROP

but i saw now here REJECT
which one is powerfull to use to disable connections of Forward

thanks
hare
----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.samba.org>
Sent: Friday, October 11, 2002 6:00 PM
Subject: Re: Fw: How to remove Established Connection


> On Friday 11 October 2002 10:15 am, Michael wrote:
>
> > HareRam wrote:
> > >then ? how do i remove my establish client, when we do some accounting
> > >when he logged out, he should not get any browsing, as well as he
should
> > > be removed from internet
> > >how can i achieve
> > >
> > >please guide me alternative method to achieve this
> >
> > You remove the rule that accepts the established connection.
> >
> > I have a specific rule for each host that is forwarded through firewall.
> > If I want to allow the host, I add the rule in FORWARD chain:
> >
> > ACCEPT     all  --  *      eth0    <ip_of_host>
> > 0.0.0.0/0          state RELATED,ESTABLISHED
> >
> > When I want to stop them I just remove the rule. Even if the established
> > entry appears and lingers in /proc/net/ip_conntrack, it can't go
anywhere.
> > At least that's how it seems to work for me... Am I wrong??
>
> Depending on how many established connections you want to cut off,
compared
> to how many new connections you want to allow, it could be easier to do
this
> the other way around:
>
> have a standard rule:
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> in your FORWARD chain, and then insert a rule *before* this one to
> specifically block the IP you want to disconnect:
> iptables -I FORWARD -s a.b.c.d -j REJECT
>
> This will then make sure that packets from that address do not get as far
as
> the ESTABLISHED, RELATED rule, and therefore are no longer allowed through
> the machine.
>
> Antony.
>
> --
>
> KDE 3.0.3 contains an important fix for handling SSL certificates.  Users
of
> Internet Explorer, which suffers from the same problem but which
> does not yet have a fix available, are also encouraged to switch to KDE
3.0.3.
>
> http://www.kde.org/announcements/announce-3.0.3.html
>
>

DROP or REJECT

[HareRam]

Hi all

REJECT action tells tables to send back an ICMP message indicating that
you're REJECTing the packet.
DROPing will just DROP with no further action.

What is the Bandwidth will  use, if i keep on sending ICMP on big network
saying that
packets are REJECT.

which one i have to USE, recomendation will be more helpful

hare

Re: Fw: How to remove Established Connection

[Antony Stone]

On Friday 11 October 2002 3:03 pm, HareRam wrote:

> Hi all
> thanks its working using my own methods,
> but idea is lot of people, especially Mr Antony's
>
> what is the Recomended DROP or REJECT
> just now my Rule is work with DROP
>
> but i saw now here REJECT
> which one is powerfull to use to disable connections of Forward

I recommend you use REJECT for internal clients (people who you want to be 
nice to, and who you don't want to get excessive delays when they try to do 
something your firewall rules don't allow).

I recommend you use DROP for external connections (people who you don't want 
to be nice to, you don't want to give any information to, and who you don't 
care whether their client hangs for 60 seconds instead of immediately saying 
"connection refused").

Antony.

-- 

This is not a rehearsal.
This is Real Life.

DROP or REJECT

[Peter Marshall]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Which is better (to drop or reject packets)?  I am asking more specifically for connections from the internet to my external firewall.

My second question is if I have a DNS in my DMZ (contains only ip's in my dmz.  internal boxes use this as their DNS.  This DNS falls back to my ISP), do I have to allow both TCP and UDP connections on port 53 ?  Can I not just have UDP, or does it use both ? 

Thank you.




Peter Marshall, BCS
Projects Division, CARIS 
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception) 
</html>

[-- Attachment #2: Type: text/html, Size: 1346 bytes --]

Re: DROP or REJECT

[Frank Gruellich]

* Peter Marshall <peter.marshall@caris.com> 11. May 04:
> Which is better (to drop or reject packets)?  I am asking more
> specifically for connections from the internet to my external
> firewall.

REJECT is something more polite and suits to common standards.  However,
if your box is flooded with SYNs and your connection is disturbed you
maybe should start DROPing packets.

> My second question is if I have a DNS in my DMZ (contains only ip's in
> my dmz.  internal boxes use this as their DNS.  This DNS falls back to
> my ISP), do I have to allow both TCP and UDP connections on port 53 ?
> Can I not just have UDP, or does it use both ? 

Both.  HTH,
 regards, Frank.
-- 
Sigmentation fault

Re: DROP or REJECT

[Chris Brenton]

On Tue, 2004-05-11 at 09:45, Peter Marshall wrote:
> Which is better (to drop or reject packets)?  I am asking more
> specifically for connections from the internet to my external
> firewall.

Depends. I like rejecting with host-unreachables as it makes it look
like you do not have a firewall. It also has the ability to shut down
certain scanning tools before they can find exposed ports.

Some worry this could be a potential DoS situation. If you are worried
about this you can combine it with rate limiting.

> My second question is if I have a DNS in my DMZ (contains only ip's in
> my dmz.  internal boxes use this as their DNS.  This DNS falls back to
> my ISP), do I have to allow both TCP and UDP connections on port 53 ? 
> Can I not just have UDP, or does it use both ? 

Again, it depends. Queries use UDP/53 _unless_ the answer exceeds a 512
byte packet size. If it does, the connection can switch over to TCP/53. 

So, outbound you need TCP and UDP. Inbound to your DNS server, it
depends if you answers will exceed this maximum. If not, you only need
to permit UDP/53 from the Internet in general, and TCP/53 only from
servers (if any) that are acting as secondaries.

HTH,
Chris

Re: DROP or REJECT

[Frank Gruellich]

* Chris Brenton <cbrenton@chrisbrenton.org> 11. May 04:
> I like rejecting with host-unreachables as it makes it look like you
> do not have a firewall.

I hope you do this only in the FORWARD chain, don't you?

Just curious,
 regards, Frank.
-- 
Sigmentation fault

Re: DROP or REJECT

[Marc Haber]

On Tue, May 11, 2004 at 01:16:03PM -0400, Chris Brenton wrote:
> Depends. I like rejecting with host-unreachables as it makes it look
> like you do not have a firewall.

NACK. If I weren't there, the host unreachable would have the source
address of the upstream router, and not my own one. To be truly
invisible, you'd need to fake the upstream router's IP address, which
is (a) not easy to get hold of, (b) most probably not appreciated
by your upstream, and (c) some hosts will completely cease
communication with you which is not always the intended behavior.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: DROP or REJECT

[Chris Brenton]

On Tue, 2004-05-11 at 14:17, Frank Gruellich wrote:
>
> * Chris Brenton <cbrenton@chrisbrenton.org> 11. May 04:
> > I like rejecting with host-unreachables as it makes it look like you
> > do not have a firewall.
> 
> I hope you do this only in the FORWARD chain, don't you?

Yup. Host unreachables originating from the host that is suppose to be
unreachable don't have quite the same effect. ;-)

C

Re: DROP or REJECT

[Chris Brenton]

On Tue, 2004-05-11 at 14:38, Marc Haber wrote:
>
> On Tue, May 11, 2004 at 01:16:03PM -0400, Chris Brenton wrote:
> > Depends. I like rejecting with host-unreachables as it makes it look
> > like you do not have a firewall.
> 
> NACK. If I weren't there, the host unreachable would have the source
> address of the upstream router, and not my own one.

I didn't say "not there", I said "look like there is no firewall". The
type 3 code 1 mimics the response of a typical router.

>  To be truly
> invisible, you'd need to fake the upstream router's IP address,

Not going to work. Firewalk will quickly identify there is a hop on the
wire that is not accounted for. Thus I don't bother shooting for
invisible, just a little bit of decoying and deception. ;-)

HTH,
Chris