iptables and INVALID packet filtering.

[Daniel Curtis]

Hi

I would only ask about iptables (1.4.14-3.1) rule, which is responsible for
filtering INVALID packets. If I decide to use this rule;

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

That's an example. By using this rule, iptables will also check tcp and udp
protocols or should I use something like;

iptables -A INPUT -p tcp (...)
iptables -A INPUT -p udp (...)

Which solution/rule is correct and it is better to implement?

Best regards.

[David Dejaeghere]

*>> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP *

Should be fine if you want to drop any INVALID packers both tcp, udp

Kind Regards,

David

Post by Daniel Curtis
Hi
I would only ask about iptables (1.4.14-3.1) rule, which is responsible
for filtering INVALID packets. If I decide to use this rule;

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

That's an example. By using this rule, iptables will also check tcp and
udp protocols or should I use something like;

iptables -A INPUT -p tcp (...)
iptables -A INPUT -p udp (...)

Which solution/rule is correct and it is better to implement?
Best regards.

[Daniel Curtis]

Hi David.

Should be fine? So, you are not 100 percent sure? Okay, just
kidding (but who knows?) ;-)

Listen David, I have one more question regarding to antispoof.
As we know, typical rule can look, more or less, this way;

iptables -A INPUT -s 0.0.0.0/8 -j DROP etc.

But recently I came across on pretty strange rule also for
antispoof. This rule, concerns 'nat' table and PREROUTING chain;

iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP

So, what do you think? Using PREROUTING chain is good for
antispoof or it is better to use rule mentioned above (INPUT chain)?

[David Dejaeghere]

Hi Daniel,

I said "should" because i am unsure of your intensions.

Regarding your anti-spoof rules. What are you intentions?
I have not seen your first line before but I would be able to give you
better advice if i know exactly what you are trying to prevent.
Same goes for your question with INPUT vs PREROUTING.

Rules in the INPUT chain are ment to filter traffic going to the host
itself where the PREROUTING chain is to filter traffic being routed through
your host.

How familiar are you with iptables?

Regards,

David

Post by Daniel Curtis
Hi David.
Should be fine? So, you are not 100 percent sure? Okay, just
kidding (but who knows?) ;-)
Listen David, I have one more question regarding to antispoof.
As we know, typical rule can look, more or less, this way;

iptables -A INPUT -s 0.0.0.0/8 -j DROP etc.

But recently I came across on pretty strange rule also for
antispoof. This rule, concerns 'nat' table and PREROUTING chain;

iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP

So, what do you think? Using PREROUTING chain is good for
antispoof or it is better to use rule mentioned above (INPUT chain)?

[David Dejaeghere]

My information about PREROUTING vs INPUT is not correct. I was talking
about the FORWARD chain...
Sorry to confuse you.

PREROUTING is meant for rules that need to be applied before a routing
decision is made like the nat table.
So based on what you are trying to accomplish. If you want to apply anti
spoofing measures that fit in the PREROUTING chain then it makes most sense
to put them there.
Local ip ranges on public interfaces can be stopped in PREROUTING before it
hits the INPUT or FORWARD chain.

Regards,

David

Post by David Dejaeghere
Hi Daniel,
I said "should" because i am unsure of your intensions.
Regarding your anti-spoof rules. What are you intentions?
I have not seen your first line before but I would be able to give you
better advice if i know exactly what you are trying to prevent.
Same goes for your question with INPUT vs PREROUTING.
Rules in the INPUT chain are ment to filter traffic going to the host
itself where the PREROUTING chain is to filter traffic being routed through
your host.
How familiar are you with iptables?
Regards,
David

Post by Daniel Curtis
Hi David.
Should be fine? So, you are not 100 percent sure? Okay, just
kidding (but who knows?) ;-)
Listen David, I have one more question regarding to antispoof.
As we know, typical rule can look, more or less, this way;

iptables -A INPUT -s 0.0.0.0/8 -j DROP etc.

But recently I came across on pretty strange rule also for
antispoof. This rule, concerns 'nat' table and PREROUTING chain;

iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP

So, what do you think? Using PREROUTING chain is good for
antispoof or it is better to use rule mentioned above (INPUT chain)?

[Daniel Curtis]

H
i

My intentions are very simple. Firstly, I would like to
drop all INVALID packets - for INPUT and OUTPUT chains.
That's the reason why I've asked, which rule is better to use.

I would like to create pretty good protection for a typical
computer - without any services etc. For now, it is only
for testing purposes. In the future, this computer will be
using for more ambitious things.

What are my intentions according to antispoof? Hmm... simple -
block spoofing? Of, course I can do it with e.g. rp_filter, right
(I mean /proc/sys/net/ipv4/*/rp_filter settings)?

So, when it comes to these two questions; INVALID and spoofing -
according to you, which solution is best, good? Frankly, you already
answered to question about INVALID packet filtering and
suggested, that the first rule is okay. So what about antispoof?

My knowledge of iptables is not good, but I started to use iptables
a couple of weeks ago. Previously, I've used a OpenBSD firewall
so-called pf.

[David Dejaeghere]

Hi Daniel,

If you try to protect a host itself and block all invalid packets then the
first rule is the way to go.
Regarding spoofing, you have all kinds of spoofing but i assume you are
talking about IP address spoofing. You might want to block packets claiming
to come from your local network or from your host itself on interfaces not
connected to that network.

http://www.cyberciti.biz/tips/linux-iptables-8-how-to-avoid-spoofing-and-bad-addresses-attack.html

I find the above link usefull to give you more details on how to block bad
address attacks.

But there might be a whole lot more that you want to look into.

the rp_filter is another way to tackle these kind of packets.

Kind Regards,

David

Post by Daniel Curtis
H
i
My intentions are very simple. Firstly, I would like to
drop all INVALID packets - for INPUT and OUTPUT chains.
That's the reason why I've asked, which rule is better to use.
I would like to create pretty good protection for a typical
computer - without any services etc. For now, it is only
for testing purposes. In the future, this computer will be
using for more ambitious things.
What are my intentions according to antispoof? Hmm... simple -
block spoofing? Of, course I can do it with e.g. rp_filter, right
(I mean /proc/sys/net/ipv4/*/rp_filter settings)?
So, when it comes to these two questions; INVALID and spoofing -
according to you, which solution is best, good? Frankly, you already
answered to question about INVALID packet filtering and
suggested, that the first rule is okay. So what about antispoof?
My knowledge of iptables is not good, but I started to use iptables
a couple of weeks ago. Previously, I've used a OpenBSD firewall
so-called pf.

[Daniel Curtis]

Hi David;

Thank you and sorry, because I forgot to mention, that I talked
about IP address spoofing protection. Sorry again. So, it seems,
that I'm in the right direction if it's about filtering; INVALID and
spoofing. For now, I will be using;

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

...rule for INVALID packets and this one for antispoof protection;

iptables -A INPUT -s 10.0.0.0/8 -j DROP etc.

Thank you for that link. It is a really interesting website. iptables
is becoming more and more interesting, but pf firewall has a much
simpler syntax, but there is UFW; it seems to be a good project.

Thank you again, David. My doubts on iptables have been solved.

Best regards.

[Pascal Hambourg]

Hello,

Post by Daniel Curtis
I would only ask about iptables (1.4.14-3.1) rule, which is responsible for
filtering INVALID packets. If I decide to use this rule;

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Be aware that INVALID packets here means "packets in the INVALID state
with respect to connection tracking". It has nothing to do with, e.g.,
malformed packets.

Post by Daniel Curtis
That's an example. By using this rule, iptables will also check tcp and udp
protocols or should I use something like;

This rule applies to all protocols. That does not mean that connection
tracking can handle correctly all protocols. AFAIK, UDP packets cannot
be in the INVALID state (as there is no real stateful connection in UDP).

Post by Daniel Curtis
But recently I came across on pretty strange rule also for
antispoof. This rule, concerns 'nat' table and PREROUTING chain;

iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP

So, what do you think? Using PREROUTING chain is good for
antispoof or it is better to use rule mentioned above (INPUT chain)?

My opinion is that the chains of the nat table are not intended for, and
should not be used for filtering. They see only the first packet of a
new connection, i.e. in the NEW state, but not the other packets. If you
want to drop packets in a PREROUTING chain, use the mangle table instead.

[Matthew Babcock]

Post by Pascal Hambourg
Hello,

Post by Daniel Curtis
I would only ask about iptables (1.4.14-3.1) rule, which is responsible for
filtering INVALID packets. If I decide to use this rule;

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Be aware that INVALID packets here means "packets in the INVALID state
with respect to connection tracking". It has nothing to do with, e.g.,
malformed packets.

If the tcp flags are illegitimate, it will catch it such as an Xmas scan

Post by Pascal Hambourg

Post by Daniel Curtis
That's an example. By using this rule, iptables will also check tcp and udp
protocols or should I use something like;

This rule applies to all protocols. That does not mean that connection
tracking can handle correctly all protocols. AFAIK, UDP packets cannot
be in the INVALID state (as there is no real stateful connection in UDP).

So that is not exactly correct. One example is ICMP messages in response to UDP (or other) packets.

Post by Pascal Hambourg

Post by Daniel Curtis
But recently I came across on pretty strange rule also for
antispoof. This rule, concerns 'nat' table and PREROUTING chain;

iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP

So, what do you think? Using PREROUTING chain is good for
antispoof or it is better to use rule mentioned above (INPUT chain)?

My opinion is that the chains of the nat table are not intended for, and
should not be used for filtering. They see only the first packet of a
new connection, i.e. in the NEW state, but not the other packets. If you
want to drop packets in a PREROUTING chain, use the mangle table instead.

This is not exactly true either. For instance, the FORWARD chain. In fact, I believe that is why the FORWARD chain exists.

Post by Pascal Hambourg
--

[Matthew Babcock]

Hi Matthew
How can I use Reverse Path filtering in the kernel? You
mean this option, right?; /proc/sys/net/ipv4/conf/*/rp_filter

Yes, this is what I am referring to. I would double check the documentation to see if there are other settings to switch for RP filtering.

Sorry, but I do not understand how to drop "out of state"
packets with the INVALID rules.

Like you had before
-A INPUT -conntrac....

I know iptables -A INPUT -m state --state INVALID -j DROP works well. And it does pick out invalid (aka out of state) UDP packets. DNS is one additional example.

Apr 5 17:18:18 t4 kernel: [13107.296065] INVALID OUT: IN=
OUT=eth0 SRC=192.168.5.200 DST=173.194.44.32 LEN=446
TOS=0x00 PREC=0x00 TTL=64 ID=36621 DF PROTO=TCP
SPT=59041 DPT=443 WINDOW=14600 RES=0x00 ACK PSH
FIN URGP=0
Apr 5 15:29:40 t4 kernel: [ 6589.698710] INVALID IN: IN=eth0
OUT= MAC=mac_address_ SRC=173.194.44.32 DST=192.168.5.200
LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=40504 PROTO=TCP
SPT=443 DPT=56236 WINDOW=0 RES=0x00 RST URGP=0
and so on... Is there something wrong, strange?

Maybe, maybe not.

[Daniel Curtis]

Hi Pascal

If it does not matter, I will leave it as is. I mean rule with
conntrack state module instead of state. Okay, thank you
for the answer.

Best regards.

[Pascal Hambourg]

Post by Matthew Babcock
I know iptables -A INPUT -m state --state INVALID -j DROP works well.
And it does pick out invalid (aka out of state) UDP packets. DNS is one
additional example.

AFAIK, UDP packets cannot be in the INVALID state. Can you provide an
example of a UDP DNS packet in the INVALID state ?

[Matthew Babcock]

Please excuse the delayed response.

To answer your question, no I cannot, yet.

However, I can demonstrate iptables following what the "state" be on UDP
packets using DNS.

Example, add this to your firewall and resolve a FQDN.

"iptables -I INPUT 1 -p udp -m state --state ESTABLISHED -j LOG
--log-prefix 'DNS-In-Established '"
"iptables -I OUTPUT 1 -p udp -m state --state NEW -j LOG --log-prefix
'DNS-Out-New '"

You should see as I do, that the UDP DNS request are logged under the
state NEW, and that the response was logged under the state ESTABLISHED.

I consider this, iptables differentiating between "New" and
"Established" UDP "connections", reason to extrapolate that iptables can
follow state in UDP packets such as flagging on "Invalid" or out of
state UDP packets.

I aim to try and create an "Invalid" UDP state packet. I will follow up
if I try regardless of the outcome.

Post by Pascal Hambourg

Post by Matthew Babcock
I know iptables -A INPUT -m state --state INVALID -j DROP works well.
And it does pick out invalid (aka out of state) UDP packets. DNS is one
additional example.

AFAIK, UDP packets cannot be in the INVALID state. Can you provide an
example of a UDP DNS packet in the INVALID state ?

[Pascal Hambourg]

Hello,

Post by Matthew Babcock
Please excuse the delayed response.

No problem.

Post by Matthew Babcock
To answer your question, no I cannot, yet.
However, I can demonstrate iptables following what the "state" be on UDP
packets using DNS.

[...]

Post by Matthew Babcock
You should see as I do, that the UDP DNS request are logged under the
state NEW, and that the response was logged under the state ESTABLISHED.

Nothing new here. UDP possible states are :
- NEW for a datagram creating a new connection or belonging to a
"connection" which has seen traffic only in one direction ;
- ESTABLISHED for a datagram belonging to a "connection" which has seen
traffic in both directions ;
- RELATED when a conntrack helper expects a UDP datagram related to an
existing connection (e.g. TFTP or SIP).

Note that this is not specific to UDP, conntrack does the same with all
connectionless protocols.

Post by Matthew Babcock
I consider this, iptables differentiating between "New" and
"Established" UDP "connections", reason to extrapolate that iptables can
follow state in UDP packets such as flagging on "Invalid" or out of
state UDP packets.

UDP is connectionless by nature, so how would you define the INVALID
state of a UDP datagram ?

Post by Matthew Babcock
I aim to try and create an "Invalid" UDP state packet. I will follow up
if I try regardless of the outcome.

Good luck. I meant it.

[Matthew Babcock]

Post by Pascal Hambourg
Hello,

Post by Matthew Babcock
Please excuse the delayed response.

No problem.

Post by Matthew Babcock
To answer your question, no I cannot, yet.
However, I can demonstrate iptables following what the "state" be on UDP
packets using DNS.

[...]

Post by Matthew Babcock
You should see as I do, that the UDP DNS request are logged under the
state NEW, and that the response was logged under the state ESTABLISHED.

- NEW for a datagram creating a new connection or belonging to a
"connection" which has seen traffic only in one direction ;
- ESTABLISHED for a datagram belonging to a "connection" which has seen
traffic in both directions ;
- RELATED when a conntrack helper expects a UDP datagram related to an
existing connection (e.g. TFTP or SIP).

Much of that is my point. I am not sure why you make the statement
specific to UDP while omitting the "INVALID" state.

Post by Pascal Hambourg
Note that this is not specific to UDP, conntrack does the same with all
connectionless protocols.

Yes! I was aware, but thank you for point that out.

Post by Pascal Hambourg

Post by Matthew Babcock
I consider this, iptables differentiating between "New" and
"Established" UDP "connections", reason to extrapolate that iptables can
follow state in UDP packets such as flagging on "Invalid" or out of
state UDP packets.

UDP is connectionless by nature, so how would you define the INVALID
state of a UDP datagram ?

Yes, I am sure we all know UDP is a "connectionless" protocol, but as I
said in the email you are responding to, and as you cited yourself, NEW,
ESTABLISHED and RELATED states can be applied to UDP and ICMP and likely
other connectionless protocols. What you are saying is a large part of
my point.

iptables can determine, based on some criteria, what "state" a
connectionless protocol is in.

So, this is happening one of two? possible ways. One is very
rudimentary, the other is super plausible and I expect it is not beyond
the developers of iptables. The former being, just matching based on
source ip and port, destination ip and port, only information from the
packet headers, and timeframe. The other option I consider super
plausible, is as I eluded to previously, is looking past the packets
header into the application layer.

Post by Pascal Hambourg

Post by Matthew Babcock
I aim to try and create an "Invalid" UDP state packet. I will follow up
if I try regardless of the outcome.

Good luck. I meant it.

Thank you. I have not read the source code, it may well not work.
However, I feel my point is still valid that iptables could be(come) an
application aware firewall, even if just with rudimentary connectionless
protocols such as DNS or ICMP, much like you just pointed out.

As I conceptualized previously and am now elaborating on, there are
several application layer protocols that have their own "state", yet are
transported over unreliable transport protocols.

Example #1, DNS requests.
DNS packets have Transaction IDs. See the RFC rfc1035
"This identifier is copied the corresponding reply and can be used by
the requester to match up replies to outstanding queries."

So, an "established" DNS connection over UDP is *determined most
accurately through the layer 7 protocol*, matching the transaction IDs
in the absence of TCP Flags.

As I write this, I realize that the specific example above, iptables
determining state based on transaction IDs as well as direction of the
communication would go very far in flushing out DNS Cache Poising
attempts. Not preventing successful ones perhaps, but making them
clearly obvious as you would see a bunch of "INVALID" DNS responses.


Example #2, ICMP Pings.
I believe the standard for ICMP ping messages states that a ICMP ECHO
Response, is only created in response to an incoming ICMP Echo Request.

It seems to me that if iptables looked a bit beyond the headers (my
suggested premise) it could easily flag a unsolicited ICMP Echo response
as an INVALID state packet. Much as it would an unsolicited SYN ACK
packet.

[Pascal Hambourg]

Post by Matthew Babcock

Post by Pascal Hambourg
Hello,

Post by Matthew Babcock
Please excuse the delayed response.

No problem.

Post by Matthew Babcock
To answer your question, no I cannot, yet.
However, I can demonstrate iptables following what the "state" be on UDP
packets using DNS.

[...]

Post by Matthew Babcock
You should see as I do, that the UDP DNS request are logged under the
state NEW, and that the response was logged under the state ESTABLISHED.

- NEW for a datagram creating a new connection or belonging to a
"connection" which has seen traffic only in one direction ;
- ESTABLISHED for a datagram belonging to a "connection" which has seen
traffic in both directions ;
- RELATED when a conntrack helper expects a UDP datagram related to an
existing connection (e.g. TFTP or SIP).

Much of that is my point. I am not sure why you make the statement
specific to UDP while omitting the "INVALID" state.

Because I am describing how the general UDP connection tracking behaves.
AFAIK, it does not use the INVALID state because, as you mention, this
state does not make sense until the connection tracking looks beyond the
IP and UDP headers.

Post by Matthew Babcock
iptables can determine, based on some criteria, what "state" a
connectionless protocol is in.

Actually the state is not determined by iptables but by the connection
tracking (aka conntrack), an other part of netfilter. iptables is just
the filtering and mangling part of netfilter.

Post by Matthew Babcock
As I conceptualized previously and am now elaborating on, there are
several application layer protocols that have their own "state", yet are
transported over unreliable transport protocols.
Example #1, DNS requests.
DNS packets have Transaction IDs. See the RFC rfc1035
"This identifier is copied the corresponding reply and can be used by
the requester to match up replies to outstanding queries."
So, an "established" DNS connection over UDP is *determined most
accurately through the layer 7 protocol*, matching the transaction IDs
in the absence of TCP Flags.

I guess that a protocol-specific conntrack helper could do this. Not
sure it is desirable.

Post by Matthew Babcock
Example #2, ICMP Pings.
I believe the standard for ICMP ping messages states that a ICMP ECHO
Response, is only created in response to an incoming ICMP Echo Request.
It seems to me that if iptables looked a bit beyond the headers (my
suggested premise) it could easily flag a unsolicited ICMP Echo response
as an INVALID state packet.

Conntrack already does this. But ICMP has a special status : although is
is carried over IP, it is part of the IP protocol at the network layer,
it is not an application or transport layer protocol.

[Daniel Curtis]

Hi

So, it is better to use state module instead of conntrack,
when it comes to filter INVALID packets or it does not
matter, which module will be in use? What is your
opinion on this?
I'm wondering why there is so much entries about INVALID
packets in log files. Frankly, after - let say - 6, 7 hour of
computer use, there are about 40-50 logged events. Maybe
more. I don't know if it is something wrong.

I know, that in e.g. iptables v1.4.16.3, state module is obsolete.
But this is just an example;

$ ... INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
WARNING: The state match is obsolete. Use conntrack instead.

This module was available in iptables v1.4.13. Of course,
if I remember correctly.

Best regards Matthew.

[Pascal Hambourg]

Post by Daniel Curtis
So, it is better to use state module instead of conntrack,
when it comes to filter INVALID packets or it does not
matter, which module will be in use? What is your
opinion on this?

It does not matter. The conntrack match has more options, but
"-m conntrack --ctstate INVALID" does exactly the same as "-m state
--state INVALID". The connection tracking is not performed by either
module, their purpose is just to match the state of the packet, not to
decide what state the packet is in.

Post by Daniel Curtis
I know, that in e.g. iptables v1.4.16.3, state module is obsolete.

[...]

Post by Daniel Curtis
WARNING: The state match is obsolete. Use conntrack instead.

No, the state match is not obsolete any more. The developpers of
iptables have finally decided that it would not be deprecated and would
be aliased by the conntrack module instead, so you can safely ignore
this warning.

[Matthew Babcock]

1) it depends on you are calling "invalid"
2) same as above

I suggest you start by using Reverse Path filtering in the kernel, not in iptables, and drop "out of state" packets with the INVALID rules.

What is in your logs?

Hi Matthew and Pascal;
So, what should I do to take care of INVALID packets? What is
"the best" method? I mentioned, that this system is for testing
purposes now, but in log files (e.g. kern.log, syslog) I see a lot
of INVALID packets logged - for both input and output connections.
Best regards.

[Daniel Curtis]

Hi Matthew

How can I use Reverse Path filtering in the kernel? You
mean this option, right?; /proc/sys/net/ipv4/conf/*/rp_filter

Sorry, but I do not understand how to drop "out of state"
packets with the INVALID rules.

My logs:

Apr 5 17:18:18 t4 kernel: [13107.296065] INVALID OUT: IN=
OUT=eth0 SRC=192.168.5.200 DST=173.194.44.32 LEN=446
TOS=0x00 PREC=0x00 TTL=64 ID=36621 DF PROTO=TCP
SPT=59041 DPT=443 WINDOW=14600 RES=0x00 ACK PSH
FIN URGP=0

Apr 5 15:29:40 t4 kernel: [ 6589.698710] INVALID IN: IN=eth0
OUT= MAC=mac_address_ SRC=173.194.44.32 DST=192.168.5.200
LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=40504 PROTO=TCP
SPT=443 DPT=56236 WINDOW=0 RES=0x00 RST URGP=0

and so on... Is there something wrong, strange?

[Daniel Curtis]

H
i
Matthew and Pascal;

So, what should I do to take care of INVALID packets? What is
"the best" method? I mentioned, that this system is for testing
purposes now, but in log files (e.g. kern.log, syslog) I see a lot
of INVALID packets logged - for both input and output connections.

Best regards.