mangle + TCP Flags

mangle + TCP Flags

[Jean-Marie]

Hello, can someone tell me if it is possible, thanks to the mangle table, to modify the flags of a TCP packet before it is routed.
I think to something like that:
iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
Thank you.

Re: mangle + TCP Flags

[Maciej Soltysiak]

Hi,

> I think to something like that:
> iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
There is no such module. It would be possible to do that.
If a module like this existed it would be a 
> Thank you.
> 
> 

Re: mangle + TCP Flags

[Maciej Soltysiak]

[Oops, sorry there for incomplete mail :)]
Hi,

> I think to something like that:
> iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
There is no such module. It would be possible to do that.
If a module like this existed it would be a great way to violate the
protocol
and cause antisocial behaviour of your tcp stack.

Anyway such a module is not difficult to write. So it is possible, but
nor the iptables package and the kernel, nor patch-o-matic
do not contain such a module.

Regards,
Maciej

Re: mangle + TCP Flags

[Antony Stone]

On Wednesday 10 December 2003 7:25 pm, Maciej Soltysiak wrote:

> [Oops, sorry there for incomplete mail :)]
> Hi,
>
> > I think to something like that:
> > iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
>
> There is no such module. It would be possible to do that.
> If a module like this existed it would be a great way to violate the
> protocol and cause antisocial behaviour of your tcp stack.

There are plenty of ways to do that already - I don't think one more would 
hurt....   :)

Enough people think that un-decrementing the TTL field, or DROPping packets 
without sending back RST or ICMP, is a bad enough violation of the protocol 
(both of these are easily possible with netfilter as it is).

Antony.

-- 
Perfection in design is achieved not when there is nothing left to add, but 
rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

                                                     Please reply to the list;
                                                           please don't CC me.

RE: mangle + TCP Flags

[bmcdowell]

Now that is a truly interesting question, if a bit off-topic.  What is the best way to handle recon?  Is it best to comply and hope your network looks un-interesting?  Is it best to try and make scanning as costly as possible (aka Tarpitting)?  Is it best to make everything appear open, thereby polluting the results of the scans?

Personally, I go for a mix of the latter two.  I'd like to make recon take absolutely forever AND return false information.  Particularly randomly false information - to make the prospect of rescanning unpalatable.

One down side is, I wind up making my network more 'interesting' than my neighbors.  I'm not quite sure if it is worth the extra interest...


Bob

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Thursday, December 11, 2003 9:44 AM
To: netfilter@lists.netfilter.org
Subject: Re: mangle + TCP Flags


On Thursday 11 December 2003 3:32 pm, Jean-Marie Orset wrote:

> > Well, you could just:
> > -p tcp -j REJECT --reject-with tcp-reset (uses tcp rst)
> > -p udp -j REJECT (uses icmp port-unreach)
> >That makes nmap say: ports closed.
>
> Yes, that's what I should do but My idea was to answer false SYN,ACK
> even if the ports are closed. In that way a scan would declare all my ports
> open but in reality, they would be closed.

Why is that better for security?

Antony.

-- 
G- GIT/E d- s+:--(-) a+ C++++$ UL++++$ P+(---)>++ L+++(++++)$ !E W(-) N(-) o? 
w-- O !M V+++(--) !PS !PE Y+ PGP+> t- tv@ b+++ DI++ D--- e++>+++ h++ r@? 5? 
!X- !R K--?

                                                     Please reply to the list;
                                                           please don't CC me.

Re: mangle + TCP Flags

[Maciej Soltysiak]

> Now that is a truly interesting question, if a bit off-topic.  What is the
best way to handle recon?
Recon is about getting info.
- If you do nothing, the scanning person gets: X amount of information
- If you use PSD, the scanning person might get weird results, and might get
uninterested, unless
he or she is determined to gather information about you. But noticing PSD
effects (if the person
is smart enough) may cause him to stop, because if someone is using PSD, he
surely is logging it.
And these logs are very easy to understand and to find.

- If you are tarpitting, the scanning person may be able to detect tarpitted
ports. In this case
the person gets X amount of information, as you would have done nothing.

My point is, that no matter what a scanning person does, my services that
are supposed to be
available to the world, and to him also, are supposed to be secure. At this
point we are talking
about application security. Like they say: Firewall is not magic. It just
decides who can see what
and when.

Network security is about actually differentiating between who can scan
what.
If someone is determined, he will finally get the ports you have open, no
matter what.

Regards,
Maciej

Re: mangle + TCP Flags

[Jean-Marie]

>If a module like this existed it would be a great way to violate the
>protocol and cause antisocial behaviour of your tcp stack.

Yes, I agree, but in any case there would be more efficient ways to
cause antisocial behaviour. In fact, in the beginning, my idea was to return a RST,ACK, for each SYN received on one of my closed ports, in order to make a scan tool belive that they are all open. (Perhaps it is useles but I  found the idea amusing.

>Anyway such a module is not difficult to write. So it is possible, but
>nor the iptables package and the kernel, nor patch-o-matic
>do not contain such a module.

I saw yesterday that Craig Shelley did provide such a module on the devel-list in june but I can't recover the tarball he sended in attachment.

Re: mangle + TCP Flags

[Maciej Soltysiak]

> cause antisocial behaviour. In fact, in the beginning, my idea was to
return a RST,ACK, for each SYN received > on one of my closed ports, in
order to make a scan tool belive that they are all open. (Perhaps it is
useles but I
> found the idea amusing.
Well, you could just:
-p tcp -j REJECT --reject-with tcp-reset (uses tcp rst)
-p udp -j REJECT (uses icmp port-unreach)

That makes nmap say: ports closed.

> I saw yesterday that Craig Shelley did provide such a module on the
devel-list
> in june but I can't recover the tarball he sended in attachment.
:-) Maybe you could try email him and ask for publishing it somewhere

Regards,
Maciej

Re: mangle + TCP Flags

[Damjan]

> >If a module like this existed it would be a great way to violate the
> >protocol and cause antisocial behaviour of your tcp stack.
> 
> Yes, I agree, but in any case there would be more efficient ways to
> cause antisocial behaviour. In fact, in the beginning, my idea was to return a RST,ACK, for each SYN received on one of my closed ports, in order to make a scan tool belive that they are all open. (Perhaps it is useles but I  found the idea amusing.

Maybe TARPIT is what you need?
Adds a TARPIT target to iptables, which captures and holds incoming TCP
connections using no local per-connection resources.  Connections are
accepted, but immediately switched to the persist state (0 byte window),
in which the remote side stops sending data and asks to continue every
60-240 seconds.  Attempts to close the connection are ignored, forcing the
remote side to time out the connection in 12-24 minutes.


-- 
Damjan Georgievski
jabberID: damjan@bagra.net.mk

Re: mangle + TCP Flags

[Jean-Marie Orset]

Le Thu, 11 Dec 2003 15:54:08 +0100
Damjan a écrit:


> Maybe TARPIT is what you need?
> Adds a TARPIT target to iptables, which captures and holds incoming > TCP
> connections using no local per-connection resources. Connections are
> accepted, but immediately switched to the persist state (0 byte > window),
> in which the remote side stops sending data and asks to continue every
> 60-240 seconds.  Attempts to close the connection are ignored, forcing > the
> remote side to time out the connection in 12-24 minutes.

Mhh, it seems very interesting. I will try it.

> -- 
> Damjan Georgievski
> jabberID: damjan@bagra.net.mk

Re: mangle + TCP Flags

[Jean-Marie Orset]

> Well, you could just:
> -p tcp -j REJECT --reject-with tcp-reset (uses tcp rst)
> -p udp -j REJECT (uses icmp port-unreach)
>That makes nmap say: ports closed.

Yes, that's what I should do but My idea was to answer false SYN,ACK
even if the ports are closed. In that way a scan would declare all my ports open but in reality, they would be closed.
But I recognize that it is a a little tortured idea.. ;-)

> I saw yesterday that Craig Shelley did provide such a module on the
devel-list
> in june but I can't recover the tarball he sended in attachment.
> :-) Maybe you could try email him and ask for publishing it somewhere

Yes it's done, but he seems to be in holliday :-)

Thank you

Re: mangle + TCP Flags

[Antony Stone]

On Thursday 11 December 2003 3:32 pm, Jean-Marie Orset wrote:

> > Well, you could just:
> > -p tcp -j REJECT --reject-with tcp-reset (uses tcp rst)
> > -p udp -j REJECT (uses icmp port-unreach)
> >That makes nmap say: ports closed.
>
> Yes, that's what I should do but My idea was to answer false SYN,ACK
> even if the ports are closed. In that way a scan would declare all my ports
> open but in reality, they would be closed.

Why is that better for security?

Antony.

-- 
G- GIT/E d- s+:--(-) a+ C++++$ UL++++$ P+(---)>++ L+++(++++)$ !E W(-) N(-) o? 
w-- O !M V+++(--) !PS !PE Y+ PGP+> t- tv@ b+++ DI++ D--- e++>+++ h++ r@? 5? 
!X- !R K--?

                                                     Please reply to the list;
                                                           please don't CC me.

Re: mangle + TCP Flags

[Jean-Marie Orset]

> Why is that better for security?

Well, I don't pretend that's better for security. In fact, it would be more difficult for a scanner to find a port really open among all other falsely open. If I drop or reject the SYN msg on those ports the scanner will deduce they are filtred or closed and it will see the real open ports. However, if it sees all the ports open, it has to test more accurately the ports for finding a real open one.

mangle + TCP Flags

[Jean-Marie]

Hello, can someone tell me if it is possible, thanks to the mangle table, to modify the flags of a TCP packet before it is routed.
I think to something like that:
iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
Thank you.

Re: mangle + TCP Flags

[Tom Marshall]

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

Yes, but I don't know of any TCPFLAG module.  You might have to write your
own.  I wrote one because I couldn't find one -- if you can find one, please
let me know.  ;-)

On Wed, Dec 10, 2003 at 11:08:49AM +0100, Jean-Marie wrote:
> Hello, can someone tell me if it is possible, thanks to the mangle table, to modify the flags of a TCP packet before it is routed.
> I think to something like that:
> iptables -t mangle -A INPUT -j TCPFLAG --set-flags FIN,URG
> Thank you.

-- 
"Copyright laws are only tolerated because they are not enforced against the
large number of petty offenders."
        -- Alastair Kelman, University of Cambridge, 1997

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]