* Evil bug in netfilter/kernel 2.4.x?
@ 2003-02-10 22:28 jpiszcz
2003-02-11 0:22 ` Arnt Karlsen
0 siblings, 1 reply; 2+ messages in thread
From: jpiszcz @ 2003-02-10 22:28 UTC (permalink / raw)
To: netfilter
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
"As a secondary note, if you use connection tracking you will not see
any fragmented packets, since they are dealt with before hitting any
chain or table in iptables."
PROBLEM:
root@p300:/etc/rc.d# iptables -t filter -I INPUT -f -j LOG --log-level 3
--log-prefix "FRAG: "
root@p300:/etc/rc.d# iptables -I INPUT -f -j LOG --log-level 3
--log-prefix "FRAG: "
root@p300:/etc/rc.d# iptables -I INPUT -f -j LOG --log-level 3
--log-prefix "FRAG: "
root@p300:/etc/rc.d# iptables -I INPUT -f -j DROP
I've tried all of these, each one by itself.
However, when I run tcpdump, I can clearly see these are not getting
dropped or logged by the kernel.
I like conn_track for DCC/FTP connections, however, to get logging &
dropping of fragmented packets working properly, I must recompile
without the conn_tracker's?
Wouldn't this be considered as a bug? Someone could be
pounding/scanning you with fragmented packets, and you would never see
it, as many people run the DCC and/or FTP connection trackers!
box1# nmap -sS -P0 -f -p 1-65535 box2.com
17:11:52.659286 box1.com > box2.com: (frag 2729:4@16)
17:11:52.661416 box1.com > box2.com: (frag 986:4@16)
17:11:52.663400 box1.com > box2.com: (frag 61814:4@16)
17:11:52.665398 box1.com > box2.com: (frag 30216:4@16)
17:11:52.667401 box1.com > box2.com: (frag 4100:4@16)
17:11:52.669392 box1.com > box2.com: (frag 61387:4@16)
947 packets received by filter
0 packets dropped by kernel
Is it possible in anyway to log/drop/match fragmented packets with
connection tracking turned on?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Evil bug in netfilter/kernel 2.4.x?
2003-02-10 22:28 Evil bug in netfilter/kernel 2.4.x? jpiszcz
@ 2003-02-11 0:22 ` Arnt Karlsen
0 siblings, 0 replies; 2+ messages in thread
From: Arnt Karlsen @ 2003-02-11 0:22 UTC (permalink / raw)
To: netfilter
On Mon, 10 Feb 2003 17:28:16 -0500,
jpiszcz <jpiszcz@lucidpixels.com> wrote in message
<3E482780.2090903@lucidpixels.com>:
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html
> "As a secondary note, if you use connection tracking you will not see
> any fragmented packets, since they are dealt with before hitting any
> chain or table in iptables."
>
> PROBLEM:
>
> root@p300:/etc/rc.d# iptables -t filter -I INPUT -f -j LOG --log-level
> 3 --log-prefix "FRAG: "
> root@p300:/etc/rc.d# iptables -I INPUT -f -j LOG --log-level 3
> --log-prefix "FRAG: "
> root@p300:/etc/rc.d# iptables -I INPUT -f -j LOG --log-level 3
> --log-prefix "FRAG: "
> root@p300:/etc/rc.d# iptables -I INPUT -f -j DROP
>
> I've tried all of these, each one by itself.
>
> However, when I run tcpdump, I can clearly see these are not getting
> dropped or logged by the kernel.
>
> I like conn_track for DCC/FTP connections, however, to get logging &
> dropping of fragmented packets working properly, I must recompile
> without the conn_tracker's?
>
> Wouldn't this be considered as a bug? Someone could be
> pounding/scanning you with fragmented packets, and you would never see
>
> it, as many people run the DCC and/or FTP connection trackers!
>
> box1# nmap -sS -P0 -f -p 1-65535 box2.com
>
> 17:11:52.659286 box1.com > box2.com: (frag 2729:4@16)
> 17:11:52.661416 box1.com > box2.com: (frag 986:4@16)
> 17:11:52.663400 box1.com > box2.com: (frag 61814:4@16)
> 17:11:52.665398 box1.com > box2.com: (frag 30216:4@16)
> 17:11:52.667401 box1.com > box2.com: (frag 4100:4@16)
> 17:11:52.669392 box1.com > box2.com: (frag 61387:4@16)
>
> 947 packets received by filter
> 0 packets dropped by kernel
>
> Is it possible in anyway to log/drop/match fragmented packets with
> connection tracking turned on?
..not tested etc; tried this in PREROUTING instead of INPUT?
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-02-11 0:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-10 22:28 Evil bug in netfilter/kernel 2.4.x? jpiszcz
2003-02-11 0:22 ` Arnt Karlsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox