Reset conntrack...

Reset conntrack...

[Sven Anders]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

Is it possible to reset the conntrack list or set any entry to the state NEW to force
a recheck against new filter rules?

The problem is:

~  If I set the (new) filtering rules with the target DROP, I want old
~  (existing) connections to be dropped immediatly.
~  The global rule '--state RELATED,ESTABLISHED' I set would still allow them...

Regards
~ Sven

- --
~ Sven Anders <anders@anduras.de>

~ ANDURAS service solutions AG
~ Innstraße 71 - 94036 Passau - Germany
~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h
QzBcNjCwn8da+HnPIaGjH+M=
=cVzY
-----END PGP SIGNATURE-----

RE: Reset conntrack...

[Richard]

> 
> Hello!
> 
> Is it possible to reset the conntrack list or set any entry to the state
> NEW to force
> a recheck against new filter rules?
> 
> The problem is:
> 
> ~  If I set the (new) filtering rules with the target DROP, I want old
> ~  (existing) connections to be dropped immediatly.
> ~  The global rule '--state RELATED,ESTABLISHED' I set would still allow
> them...
> 
I am in the process to write a TARGET which sets the conntrack expire value.
I am not sure if you set it to zero will immediately drop the connection.
But at least you can set it to 1 and let it drop in 1 second.

https://lists.netfilter.org/pipermail/netfilter-devel/2004-December/017582.h
tml

Richard

Re: Reset conntrack...

[Patrick Schaaf]

> Is it possible to reset the conntrack list or set any entry to the state 
> NEW to force a recheck against new filter rules?
> ~  If I set the (new) filtering rules with the target DROP, I want old
> ~  (existing) connections to be dropped immediatly.

Consider using REJECT. This has two advantages: it gives the end
systems you are now blocking a chance at state cleanup (instead of
needlessly wasting memory and CPU resources on a connection that you
now elect to forbit). But, the greater advantage: the packets that
the end systems exchange in response to the connection teardown,
are JUST what you need to get rid of their conntracks.

Of course, one could do what you requested. Maybe even without coding.
I wouldn't know. Maybe others.

best regards
  Patrick

Re: Reset conntrack...

[Sven Anders]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Schaaf wrote:
|>Is it possible to reset the conntrack list or set any entry to the state
|>NEW to force a recheck against new filter rules?
|>~  If I set the (new) filtering rules with the target DROP, I want old
|>~  (existing) connections to be dropped immediatly.
|
|
| Consider using REJECT. This has two advantages: it gives the end
| systems you are now blocking a chance at state cleanup (instead of
| needlessly wasting memory and CPU resources on a connection that you
| now elect to forbit). But, the greater advantage: the packets that
| the end systems exchange in response to the connection teardown,
| are JUST what you need to get rid of their conntracks.

This is not exactly what I'm meant...

Consider the following scenario:

~ 1. Set firewall rules
~     with:
~      a) ACCEPT on all --state RELATED,ESTABLISHED
~      b) with ACCEPT on ports 22 and 80

~ 2. Remote client creates connection through the firewall
~     on the port 80 (CONNTRACK state is: NEW)
~     It will be allowed due to the ACCEPT policy...

~ 3. Server answers and connection CONNTRACK state will be changed
~    to ESTABLISHED

~ 4. Set new firewall rules:
~      Changed b) to only allow port 22

~ 5. The connection to port 80 will continue to exists, because
~    it CONNTRACK state did not change and we have rule a)...

Possible solutions:

~ 1) Recheck all CONNTRACK entries against the new firewall rules.

~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
~     NEW, to force the recheck.

Is there any way to accomplish this?

Regards
~ Sven

- --
~ Sven Anders <anders@anduras.de>

~ ANDURAS service solutions AG
~ Innstraße 71 - 94036 Passau - Germany
~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBsEnF5lKZ7Feg4EcRAuGSAJ9CcGazy29uLg3OYVyf86UZHDZ8dwCdF7do
ufAoHMfOh0O7qe+s3jYbwQI=
=5R7c
-----END PGP SIGNATURE-----

Re: Reset conntrack...

[Yutaka Kondo]

Hello

I made littile change in file  ip_conntrack_standalone.c

This made, if you write IP address(in_addr_t format) to
 /proc/net/ip_conntrack, any contrack with SRC address
is written address are forced timeout/removed.

I think, this is useful for linux firewall with IDS(such as snort).

Sorry, I put many debug change to this file for my understand,
thus I cannnot post as diff/patch format.

YKND

add those 2 functions
-----------------------
/* YKND    Remove conntrack entry, if src ip address match as contrack */
static inline int
match_remove_srcip_conntrack(ulong in, struct ip_conntrack *conntrack)
{
 if( in == conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip){
  del_timer(&conntrack->timeout);   /* Delete from Timeout */
  conntrack->timeout.function((unsigned long)conntrack);
 }
 return 0;
}

/* YKND      write entry "proc/net/ip_conntrack" */
/*           Walk arround conntrack list and call remove entry */
static int
ip_conntrack_user_remove(struct file *file, const char *buffer,
    unsigned long count, void *data)
{
 unsigned int i;
 ulong in;
 if(count != sizeof(int)){
  printk("Write size error \n");
  return count;
 }

 in = *(ulong *)buffer;
 /* DEBUG */
// printk("Address=%u.%u.%u.%u was removed from conntrack \n", NIPQUAD(in));

 READ_LOCK(&ip_conntrack_lock);

 /* Traverse hash; print originals then reply. */
 for (i = 0; i < ip_conntrack_htable_size; i++) {
  const struct list_head * head = &ip_conntrack_hash[i];
  do {
   head = head->next;
   if (head == &ip_conntrack_hash[i]) {
    head = NULL;
    break;
   }
   if(head == NULL){
    break;
   }
  } while (!match_remove_srcip_conntrack(in, ((struct 
ip_conntrack_tuple_hash *)head)->ctrack));
 }
 READ_UNLOCK(&ip_conntrack_lock);
 return count;
}
-----------------------

and put 1 line in, function static int init_or_cleanup(int init)

-----------------------
 proc->write_proc = ip_conntrack_user_remove;

-----------------------

----- Original Message ----- 
From: "Sven Anders" <anders@anduras.de>
To: <netfilter-devel@lists.netfilter.org>
Sent: Friday, December 03, 2004 7:09 AM
Subject: Reset conntrack...


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> Is it possible to reset the conntrack list or set any entry to the state 
> NEW to force
> a recheck against new filter rules?
>
> The problem is:
>
> ~  If I set the (new) filtering rules with the target DROP, I want old
> ~  (existing) connections to be dropped immediatly.
> ~  The global rule '--state RELATED,ESTABLISHED' I set would still allow 
> them...
>
> Regards
> ~ Sven
>
> - --
> ~ Sven Anders <anders@anduras.de>
>
> ~ ANDURAS service solutions AG
> ~ Innstraße 71 - 94036 Passau - Germany
> ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 
> 50-55
>
> Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 
> 6032
> Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
> Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h
> QzBcNjCwn8da+HnPIaGjH+M=
> =cVzY
> -----END PGP SIGNATURE-----
> 

Re: Reset conntrack...

[Ferry Huberts]

This is great!
I've been looking for this for a while now.

But can the write to the proc entry please be in ascii format i.s.o. binary?



I use dynamically configured rules for peers that use DHCP: when a peer
address changes the old conntrack is in the way and needs to be removed. I
use a somewhat dirty trick for this that has more side effects than I want
so this solution appeals to me very much!

The trick (I use ESP traffic):
  # clear the connection tracking timeout for ESP traffic (generic)
  echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout \
        2> /dev/null

  delete-old-rules
  add-new-rules

  # set the connection tracking timeout for ESP traffic (generic)
  sleep 1
  echo $connectiontracking_esp_timeout \
         > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout \
        2> /dev/null



--
Ferry Huberts

> Hello
>
> I made littile change in file  ip_conntrack_standalone.c
>
> This made, if you write IP address(in_addr_t format) to
>  /proc/net/ip_conntrack, any contrack with SRC address
> is written address are forced timeout/removed.
>
> I think, this is useful for linux firewall with IDS(such as snort).
>
> Sorry, I put many debug change to this file for my understand,
> thus I cannnot post as diff/patch format.
>
> YKND
>
> add those 2 functions
> -----------------------
> /* YKND    Remove conntrack entry, if src ip address match as contrack */
> static inline int
> match_remove_srcip_conntrack(ulong in, struct ip_conntrack *conntrack)
> {
>  if( in == conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip){
>   del_timer(&conntrack->timeout);   /* Delete from Timeout */
>   conntrack->timeout.function((unsigned long)conntrack);
>  }
>  return 0;
> }
>
> /* YKND      write entry "proc/net/ip_conntrack" */
> /*           Walk arround conntrack list and call remove entry */
> static int
> ip_conntrack_user_remove(struct file *file, const char *buffer,
>     unsigned long count, void *data)
> {
>  unsigned int i;
>  ulong in;
>  if(count != sizeof(int)){
>   printk("Write size error \n");
>   return count;
>  }
>
>  in = *(ulong *)buffer;
>  /* DEBUG */
> // printk("Address=%u.%u.%u.%u was removed from conntrack \n",
> NIPQUAD(in));
>
>  READ_LOCK(&ip_conntrack_lock);
>
>  /* Traverse hash; print originals then reply. */
>  for (i = 0; i < ip_conntrack_htable_size; i++) {
>   const struct list_head * head = &ip_conntrack_hash[i];
>   do {
>    head = head->next;
>    if (head == &ip_conntrack_hash[i]) {
>     head = NULL;
>     break;
>    }
>    if(head == NULL){
>     break;
>    }
>   } while (!match_remove_srcip_conntrack(in, ((struct
> ip_conntrack_tuple_hash *)head)->ctrack));
>  }
>  READ_UNLOCK(&ip_conntrack_lock);
>  return count;
> }
> -----------------------
>
> and put 1 line in, function static int init_or_cleanup(int init)
>
> -----------------------
>  proc->write_proc = ip_conntrack_user_remove;
>
> -----------------------
>
> ----- Original Message -----
> From: "Sven Anders" <anders@anduras.de>
> To: <netfilter-devel@lists.netfilter.org>
> Sent: Friday, December 03, 2004 7:09 AM
> Subject: Reset conntrack...
>
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello!
>>
>> Is it possible to reset the conntrack list or set any entry to the state
>> NEW to force
>> a recheck against new filter rules?
>>
>> The problem is:
>>
>> ~  If I set the (new) filtering rules with the target DROP, I want old
>> ~  (existing) connections to be dropped immediatly.
>> ~  The global rule '--state RELATED,ESTABLISHED' I set would still allow
>> them...
>>
>> Regards
>> ~ Sven
>>
>> - --
>> ~ Sven Anders <anders@anduras.de>
>>
>> ~ ANDURAS service solutions AG
>> ~ Innstraße 71 - 94036 Passau - Germany
>> ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90
>> 50-55
>>
>> Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB
>> 6032
>> Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
>> Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.5 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h
>> QzBcNjCwn8da+HnPIaGjH+M=
>> =cVzY
>> -----END PGP SIGNATURE-----
>>
>
>
>

Re: Reset conntrack...

[Phil Oester]

On Fri, Dec 03, 2004 at 12:11:01PM +0100, Sven Anders wrote:
> Possible solutions:
> 
> ~ 1) Recheck all CONNTRACK entries against the new firewall rules.
> 
> ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
> ~     NEW, to force the recheck.
> 
> Is there any way to accomplish this?

Make iptables modular, and unload/reload the conntrack module everytime
you change your rules.  Not pretty, but without hacking the code, the
only way to achieve your objective.

Phil

Re: Reset conntrack...

[Carl-Daniel Hailfinger]

Sven Anders schrieb:
> Patrick Schaaf wrote:
> |>Is it possible to reset the conntrack list or set any entry to the state
> |>NEW to force a recheck against new filter rules?
> |>~  If I set the (new) filtering rules with the target DROP, I want old
> |>~  (existing) connections to be dropped immediatly.
> |
> |
> | Consider using REJECT. This has two advantages: it gives the end
> | systems you are now blocking a chance at state cleanup (instead of
> | needlessly wasting memory and CPU resources on a connection that you
> | now elect to forbit). But, the greater advantage: the packets that
> | the end systems exchange in response to the connection teardown,
> | are JUST what you need to get rid of their conntracks.
> 
> This is not exactly what I'm meant...
> 
> Consider the following scenario:
> 
> ~ 1. Set firewall rules
> ~     with:
> ~      a) ACCEPT on all --state RELATED,ESTABLISHED
> ~      b) with ACCEPT on ports 22 and 80
> 
> ~ 2. Remote client creates connection through the firewall
> ~     on the port 80 (CONNTRACK state is: NEW)
> ~     It will be allowed due to the ACCEPT policy...
> 
> ~ 3. Server answers and connection CONNTRACK state will be changed
> ~    to ESTABLISHED
> 
> ~ 4. Set new firewall rules:
> ~      Changed b) to only allow port 22
> 
> ~ 5. The connection to port 80 will continue to exists, because
> ~    it CONNTRACK state did not change and we have rule a)...
> 
> Possible solutions:
> 
> ~ 1) Recheck all CONNTRACK entries against the new firewall rules.
> 
> ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
> ~     NEW, to force the recheck.

Why so complicated? Insert a rule which rejects connections to port 80
before rule a). That way any packet coming to you on port 80 will cause
a reset, tearing down the connection and the problem is solved. The only
disadvantage is that your machine may continue sending data until it
requires an ack of the remote side to continue. That ack will then cause
teardown, too. If that is not good enough, consider adding a reject
rule for source port 80 in your OUTPUT table.
This will cause any connection which is now forbidden to be teared down
once either side wants to send any data.


> Is there any way to accomplish this?

Yes. (Well, it forces you to add an explicit REJECT rule for every
ACCEPT rule you remove, but that is less complicated than patching the
kernel.)


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: Reset conntrack...

[Henrik Nordstrom]

On Thu, 2 Dec 2004, Sven Anders wrote:

> Is it possible to reset the conntrack list or set any entry to the state 
> NEW to force a recheck against new filter rules?

You can use CONNMARK for a similar kind of test instead of looking for 
NEW.

Regards
Henrik

Re: Reset conntrack...

[Henrik Nordstrom]

On Fri, 3 Dec 2004, Sven Anders wrote:

> ~ 1) Recheck all CONNTRACK entries against the new firewall rules.
>
> ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
> ~     NEW, to force the recheck.

Setting it to NEW won't help you as this discards the current conntrack 
entry, and if the next packet is return traffic or on an related 
connection your ruleset will get very upset.

> Is there any way to accomplish this?

There is three ways

a) The simple "CONFIRMED" patch posted by a collegue of mine little more 
than a year ago (see archives).

b) Use CONNMARK as a ruleset counter instead of looking for state 
ESTABLISHED,RELATED. Mark accepted traffic with a specific CONNMARK and 
then look for this mark rather than the state.

Note that in both cases special care is needed to make sure you look at 
traffic or addresses in the "original" direction. See the conntrack match. 
Also beware of related connections such as the data channel of FTP 
connection etc.

Regards
Henrik

Re: Reset conntrack...

[Sven Anders]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl-Daniel Hailfinger wrote:
| Sven Anders schrieb:
|
|>Patrick Schaaf wrote:
|>|>Is it possible to reset the conntrack list or set any entry to the state
|>|>NEW to force a recheck against new filter rules?
|>|>~  If I set the (new) filtering rules with the target DROP, I want old
|>|>~  (existing) connections to be dropped immediatly.
|>|
|>|
|>| Consider using REJECT. This has two advantages: it gives the end
|>| systems you are now blocking a chance at state cleanup (instead of
|>| needlessly wasting memory and CPU resources on a connection that you
|>| now elect to forbit). But, the greater advantage: the packets that
|>| the end systems exchange in response to the connection teardown,
|>| are JUST what you need to get rid of their conntracks.
|>
|>This is not exactly what I'm meant...
|>
|>Consider the following scenario:
|>
|>~ 1. Set firewall rules
|>~     with:
|>~      a) ACCEPT on all --state RELATED,ESTABLISHED
|>~      b) with ACCEPT on ports 22 and 80
|>
|>~ 2. Remote client creates connection through the firewall
|>~     on the port 80 (CONNTRACK state is: NEW)
|>~     It will be allowed due to the ACCEPT policy...
|>
|>~ 3. Server answers and connection CONNTRACK state will be changed
|>~    to ESTABLISHED
|>
|>~ 4. Set new firewall rules:
|>~      Changed b) to only allow port 22
|>
|>~ 5. The connection to port 80 will continue to exists, because
|>~    it CONNTRACK state did not change and we have rule a)...
|>
|>Possible solutions:
|>
|>~ 1) Recheck all CONNTRACK entries against the new firewall rules.
|>
|>~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
|>~     NEW, to force the recheck.
|
|
| Why so complicated? Insert a rule which rejects connections to port 80
| before rule a). That way any packet coming to you on port 80 will cause
| a reset, tearing down the connection and the problem is solved. The only
| disadvantage is that your machine may continue sending data until it
| requires an ack of the remote side to continue. That ack will then cause
| teardown, too. If that is not good enough, consider adding a reject
| rule for source port 80 in your OUTPUT table.
| This will cause any connection which is now forbidden to be teared down
| once either side wants to send any data.

The rules will be set by an (normal) user. So I cannot assume the user to
understand why he should insert this rule too...
Automatically generating this rule is complicated too, because this
rule could conflict with some other rule...

|>Is there any way to accomplish this?
|
| Yes. (Well, it forces you to add an explicit REJECT rule for every
| ACCEPT rule you remove, but that is less complicated than patching the
| kernel.)

Regards
~ Sven

- --
~ Sven Anders <anders@anduras.de>

~ ANDURAS service solutions AG
~ Innstraße 71 - 94036 Passau - Germany
~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBtuN45lKZ7Feg4EcRAoZ/AJ9W37rM1Sf9F/8sScUbsokItmItRwCeMUr2
++4zWG66gUGeIA0Rn25X/WI=
=F92r
-----END PGP SIGNATURE-----

Re: Reset conntrack...

[Henrik Nordstrom]

On Wed, 8 Dec 2004, Sven Anders wrote:

> |>Possible solutions:
> |>
> |>~ 1) Recheck all CONNTRACK entries against the new firewall rules.
> |>
> |>~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to
> |>~     NEW, to force the recheck.


Implemented years ago by a collegue of mine:

https://lists.netfilter.org/pipermail/netfilter-devel/2003-August/012109.html
[or alternate archive location where MIME processing actually works...]
http://marc.theaimsgroup.com/?l=netfilter-devel&m=105975103717126&w=2

Needs some trivial adjustments for current ip_conntrack versions..

Regards
Herik