* Question about REJECT in FORWARD rule
@ 2004-08-11 14:49 Maxime Ducharme
0 siblings, 0 replies; 10+ messages in thread
From: Maxime Ducharme @ 2004-08-11 14:49 UTC (permalink / raw)
To: netfilter
Hi Everyone
I'm currently trying to ddo the following :
- we have a simple NAT running iptables 1.2.9
with about 20 hosts behind
- we have an outside SQL Server
- when ppl use their SQL Server clients, I see lots
of TCP SYN on port 445 of this SQL Server
What I'd like to do is something like :
$IPTABLES -A FORWARD -i $LAN_IFACE -p tcp --dport 445 --dst sql.se.rv.er -j
REJECT --reject-with tcp-reset
My problem :
Packet seems OK (iptables change source ip and port) and is
TCP RST, but it is sent to the external interface, and my LAN
hosts do not get the reply and must wait for a timeout to occur
(since another firewall protects the SQL Server and drops TCP 445)
Is there any way to force an interface for the REJECT rule ?
Is there any configuration that could cause this to happen ?
Thanks in advance
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
@ 2004-08-11 15:44 Jason Opperisano
2004-08-11 16:14 ` Maxime Ducharme
0 siblings, 1 reply; 10+ messages in thread
From: Jason Opperisano @ 2004-08-11 15:44 UTC (permalink / raw)
To: netfilter
> What I'd like to do is something like :
> $IPTABLES -A FORWARD -i $LAN_IFACE -p tcp --dport 445 --dst sql.se.rv.er -j
> REJECT --reject-with tcp-reset
>
> My problem :
> Packet seems OK (iptables change source ip and port) and is
> TCP RST, but it is sent to the external interface, and my LAN
> hosts do not get the reply and must wait for a timeout to occur
> (since another firewall protects the SQL Server and drops TCP 445)
>
> Is there any way to force an interface for the REJECT rule ?
>
> Is there any configuration that could cause this to happen ?
there is something wrong with your configuration. post the output of "iptables -vnL; iptables -vnL -t nat; iptables -vnL -t mangle" and clue us in as to which interface is inside, outside, dmz, etc...
-j
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question about REJECT in FORWARD rule
2004-08-11 15:44 Jason Opperisano
@ 2004-08-11 16:14 ` Maxime Ducharme
0 siblings, 0 replies; 10+ messages in thread
From: Maxime Ducharme @ 2004-08-11 16:14 UTC (permalink / raw)
To: Jason Opperisano; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
Thanks for reply,
here are some more details :
simple NAT device which has
eth0 on LAN 192.168.0.x
eth1 on WAN (dedicated ethernet link with static IP)
[root@natasha /]# iptables -V
iptables v1.2.9
[root@natasha /]# uname -a
Linux natasha.cybergeneration.com 2.4.20-16.9 #1 Thu May 22 18:22:56 EDT
2003 i686 i686 i386 GNU/Linux
I attached output of iptables, y.y.y. is my WAN IP range and x.x.x. is a
range
outside. Problematic REJECT rule can be found in FORWARD chain.
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
----- Original Message -----
From: "Jason Opperisano" <Jopperisano@alphanumeric.com>
To: <netfilter@lists.netfilter.org>
Sent: Wednesday, August 11, 2004 11:44 AM
Subject: RE: Question about REJECT in FORWARD rule
> What I'd like to do is something like :
> $IPTABLES -A FORWARD -i $LAN_IFACE -p tcp --dport 445 --dst
sql.se.rv.er -j
> REJECT --reject-with tcp-reset
>
> My problem :
> Packet seems OK (iptables change source ip and port) and is
> TCP RST, but it is sent to the external interface, and my LAN
> hosts do not get the reply and must wait for a timeout to occur
> (since another firewall protects the SQL Server and drops TCP 445)
>
> Is there any way to force an interface for the REJECT rule ?
>
> Is there any configuration that could cause this to happen ?
there is something wrong with your configuration. post the output of
"iptables -vnL; iptables -vnL -t nat; iptables -vnL -t mangle" and clue us
in as to which interface is inside, outside, dmz, etc...
-j
[-- Attachment #2: iptables_nvL_mangle.txt --]
[-- Type: text/plain, Size: 1084 bytes --]
Chain PREROUTING (policy ACCEPT 1898 packets, 337K bytes)
pkts bytes target prot opt in out source destination
69 4892 TOS udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 TOS set 0x10
63 74359 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 TOS set 0x08
Chain INPUT (policy ACCEPT 335 packets, 23221 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 1559 packets, 313K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 197 packets, 17553 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1741 packets, 328K bytes)
pkts bytes target prot opt in out source destination
[-- Attachment #3: iptables_nvL_nat.txt --]
[-- Type: text/plain, Size: 527 bytes --]
Chain PREROUTING (policy ACCEPT 112 packets, 10305 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
21 1126 MASQUERADE all -- * eth1 192.168.0.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[-- Attachment #4: iptables_nvL.txt --]
[-- Type: text/plain, Size: 15393 bytes --]
Chain INPUT (policy DROP 1 packets, 40 bytes)
pkts bytes target prot opt in out source destination
3 268 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
134 8046 CHECK_BANNED_IPS_IN all -- * * 0.0.0.0/0 0.0.0.0/0
134 8046 IN_FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::INPUT '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 1 packets, 58 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 sql.se.rv.er tcp dpt:445 reject-with tcp-reset
291 105K IN_NAT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
232 23807 OUT_NAT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 10 packets, 2892 bytes)
pkts bytes target prot opt in out source destination
3 268 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
78 6361 OUT_FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::OUTPUT '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain BAD_IP (22 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::BAD_IP '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain BAD_STATE (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::BAD_STATE '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain BAD_TCP_FLAGS (11 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::BAD_TCP_FLAGS '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain BANNED_IP (2 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::BANNED_IP '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain CHECK_BAD_IPS_IN (2 references)
pkts bytes target prot opt in out source destination
0 0 BAD_IP all -- * * 0.0.0.0/8 0.0.0.0/0
0 0 BAD_IP all -- * * 10.0.0.0/8 0.0.0.0/0
0 0 BAD_IP all -- * * 127.0.0.0/8 0.0.0.0/0
0 0 BAD_IP all -- * * 169.254.0.0/16 0.0.0.0/0
0 0 BAD_IP all -- * * 172.16.0.0/12 0.0.0.0/0
0 0 BAD_IP all -- * * 192.0.0.0/24 0.0.0.0/0
0 0 BAD_IP all -- * * 224.0.0.0/4 0.0.0.0/0
0 0 BAD_IP all -- * * 240.0.0.0/5 0.0.0.0/0
0 0 BAD_IP all -- * * 255.255.255.255 0.0.0.0/0
Chain CHECK_BAD_IPS_OUT (1 references)
pkts bytes target prot opt in out source destination
0 0 BAD_IP all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 BAD_IP all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 BAD_IP all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 BAD_IP all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 BAD_IP all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 BAD_IP all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 BAD_IP all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 BAD_IP all -- * * 0.0.0.0/0 240.0.0.0/5
0 0 BAD_IP all -- * * 0.0.0.0/0 255.255.255.255
Chain CHECK_BAD_STATE (1 references)
pkts bytes target prot opt in out source destination
0 0 BAD_STATE all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
Chain CHECK_BANNED_IPS_IN (2 references)
pkts bytes target prot opt in out source destination
0 0 BANNED_IP all -- * * 1.1.1.1 0.0.0.0/0
Chain CHECK_BANNED_IPS_OUT (1 references)
pkts bytes target prot opt in out source destination
0 0 BANNED_IP all -- * * 0.0.0.0/0 1.1.1.1
Chain CHECK_TCP_FLAGS (2 references)
pkts bytes target prot opt in out source destination
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x11/0x01
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x18/0x08
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x30/0x20
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x05/0x05
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x2B
0 0 BAD_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x37
Chain CHECK_TCP_SYN_FLOOD (0 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 10
0 0 TCP_SYN_FLOOD all -- * * 0.0.0.0/0 0.0.0.0/0
Chain IN_FIREWALL (1 references)
pkts bytes target prot opt in out source destination
134 8046 CHECK_BAD_STATE all -- * * 0.0.0.0/0 0.0.0.0/0
134 8046 IN_IP_CHECK all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 IN_FIREWALL_ICMP icmp -- * * 0.0.0.0/0 0.0.0.0/0
107 5699 CHECK_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 192.168.0.0/24 0.0.0.0/0 tcp dpt:22 state NEW
109 5947 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:135
22 1716 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
1 229 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1900
2 154 DROP udp -- eth1 * y.y.y.209 0.0.0.0/0 udp dpt:712
0 0 DROP udp -- eth1 * x.x.x.1 0.0.0.0/0 udp dpt:520
0 0 DROP udp -- eth1 * y.y.y.193 0.0.0.0/0 udp dpt:520
0 0 DROP 2 -- eth0 * 192.168.0.200 224.0.0.1
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::IN_FIREWALL '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain IN_FIREWALL_ICMP (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 192.168.0.0/24 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 4
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 12
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::IN_FIREWALL_ICMP '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain IN_IP_CHECK (1 references)
pkts bytes target prot opt in out source destination
134 8046 CHECK_BAD_IPS_IN all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 BAD_IP all -- eth0 * 192.168.0.1 0.0.0.0/0
0 0 BAD_IP all -- eth0 * y.y.y.195 0.0.0.0/0
0 0 BAD_IP all -- eth1 * 192.168.0.0/24 0.0.0.0/0
0 0 BAD_IP all -- eth1 * y.y.y.195 0.0.0.0/0
Chain IN_NAT (1 references)
pkts bytes target prot opt in out source destination
291 105K CHECK_BANNED_IPS_IN all -- * * 0.0.0.0/0 0.0.0.0/0
291 105K CHECK_BAD_IPS_IN all -- * * 0.0.0.0/0 0.0.0.0/0
272 102K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
19 2588 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::IN_NAT '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUT_FIREWALL (1 references)
pkts bytes target prot opt in out source destination
78 6361 OUT_IP_CHECK all -- * * 0.0.0.0/0 0.0.0.0/0
76 6215 CHECK_TCP_FLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0
78 6361 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.0.3 udp dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.0.5 udp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 x.x.x.33 tcp dpt:3306
0 0 ACCEPT tcp -- * * 0.0.0.0/0 x.x.x.33 tcp dpt:21
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::OUT_FIREWALL '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUT_IP_CHECK (1 references)
pkts bytes target prot opt in out source destination
78 6361 CHECK_BAD_IPS_OUT all -- * * 0.0.0.0/0 0.0.0.0/0
76 5922 RETURN all -- * eth0 192.168.0.1 0.0.0.0/0
2 439 RETURN all -- * eth1 y.y.y.195 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::OUT_IP_CHECK '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUT_NAT (1 references)
pkts bytes target prot opt in out source destination
232 23807 CHECK_BANNED_IPS_OUT all -- * * 0.0.0.0/0 0.0.0.0/0
3 156 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
14 1052 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
199 21475 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
16 1124 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23456 LOG flags 0 level 7 prefix `firewall::OUT_NAT '
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::OUT_NAT '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain TCP_SYN_FLOOD (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `firewall::TCP_SYN_FLOOD '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
@ 2004-08-11 16:30 Jason Opperisano
2004-08-11 17:37 ` Maxime Ducharme
2004-08-11 20:00 ` Carlos Villegas
0 siblings, 2 replies; 10+ messages in thread
From: Jason Opperisano @ 2004-08-11 16:30 UTC (permalink / raw)
To: netfilter
> I attached output of iptables, y.y.y. is my WAN IP range and x.x.x. is a
> range
> outside. Problematic REJECT rule can be found in FORWARD chain.
upon further review--i think you'd be best to only match that rule on SYN packets, in addition to specifying the inbound interface. something along the lines of:
-A FORWARD -i $INTERNAL_IF -p tcp --syn -d $SQL_SERVER --dport 445 -j REJECT --reject-with tcp-reset
since the rule you're using according to:
Chain FORWARD (policy DROP 1 packets, 58 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 sql.se.rv.er tcp dpt:445 reject-with tcp-reset
is not narrowing down the interface/source, and is hit before any connection tracking occurs. i've never used "-j REJECT --reject-with tcp-reset" without also specifying "--syn" as it could have very odd results (and also doesn't make sense from a TCP perspective)...
you should be able to test this from a client on the internal network by just typing "telnet <sql.srv.ip.addr> 445" and making sure you get back "Connection refused" instead of a timeout.
-j
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question about REJECT in FORWARD rule
2004-08-11 16:30 Question about REJECT in FORWARD rule Jason Opperisano
@ 2004-08-11 17:37 ` Maxime Ducharme
2004-08-11 20:00 ` Carlos Villegas
1 sibling, 0 replies; 10+ messages in thread
From: Maxime Ducharme @ 2004-08-11 17:37 UTC (permalink / raw)
To: Jason Opperisano, netfilter
Thanks again Jason,
I totally agree with your points about specify
IN, OUT and SYN
Now with some -j LOG i can see the packet going
into OUTPUT with eth1 as dst interface
Now it gets into my anti-spoof rule :
Aug 11 13:20:17 natasha kernel: firewall::OUT_IP_CHECK IN= OUT=eth1
SRC=sql.se.rv.er DST=192.168.0.149 LEN=40 TOS=0x00
PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=3394 WINDOW=0 RES=0x00 ACK
RST URGP=0
If i open this rule, i can see the packet adressed to 192.168.0.149
sent on eth1 (WAN) with tcpdump.
Any other ideas ?
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
----- Original Message -----
From: "Jason Opperisano" <Jopperisano@alphanumeric.com>
To: <netfilter@lists.netfilter.org>
Sent: Wednesday, August 11, 2004 12:30 PM
Subject: RE: Question about REJECT in FORWARD rule
> I attached output of iptables, y.y.y. is my WAN IP range and x.x.x. is a
> range
> outside. Problematic REJECT rule can be found in FORWARD chain.
upon further review--i think you'd be best to only match that rule on SYN
packets, in addition to specifying the inbound interface. something along
the lines of:
-A FORWARD -i $INTERNAL_IF -p tcp --syn -d $SQL_SERVER --dport 445 -j
REJECT --reject-with tcp-reset
since the rule you're using according to:
Chain FORWARD (policy DROP 1 packets, 58 bytes)
pkts bytes target prot opt in out source
destination
0 0 REJECT tcp -- * * 0.0.0.0/0
sql.se.rv.er tcp dpt:445 reject-with tcp-reset
is not narrowing down the interface/source, and is hit before any connection
tracking occurs. i've never used "-j REJECT --reject-with tcp-reset"
without also specifying "--syn" as it could have very odd results (and also
doesn't make sense from a TCP perspective)...
you should be able to test this from a client on the internal network by
just typing "telnet <sql.srv.ip.addr> 445" and making sure you get back
"Connection refused" instead of a timeout.
-j
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
@ 2004-08-11 19:01 Jason Opperisano
0 siblings, 0 replies; 10+ messages in thread
From: Jason Opperisano @ 2004-08-11 19:01 UTC (permalink / raw)
To: netfilter
> Now with some -j LOG i can see the packet going
> into OUTPUT with eth1 as dst interface
>
> Now it gets into my anti-spoof rule :
> Aug 11 13:20:17 natasha kernel: firewall::OUT_IP_CHECK IN= OUT=eth1
> SRC=sql.se.rv.er DST=192.168.0.149 LEN=40 TOS=0x00
> PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=3394 WINDOW=0 RES=0x00 ACK
> RST URGP=0
>
> If i open this rule, i can see the packet adressed to 192.168.0.149
> sent on eth1 (WAN) with tcpdump.
>
> Any other ideas ?
yeah--in order for your netfilter machine to be able to reset the connection--it has to spoof/pretend to be the original destination of the packet (sql.se.rv.er). i.e. it generates a packet locally with a source IP of the SQL server and a destination of the client that is subject to the OUTPUT chain filters. your OUT_IP_CHECK chain only allows the source IP to be the actual IP's of the netfilter machine (this is actually a good thing).
my guess is adding this:
-I OUTPUT -p tcp --tcp-flags SYN,RST,FIN RST -j ACCEPT
would fix the situation. if it does--i'll leave it to you to decide how you want to incorporate it into your custom chains.
-j
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question about REJECT in FORWARD rule
2004-08-11 16:30 Question about REJECT in FORWARD rule Jason Opperisano
2004-08-11 17:37 ` Maxime Ducharme
@ 2004-08-11 20:00 ` Carlos Villegas
2004-08-12 1:32 ` Mark E. Donaldson
1 sibling, 1 reply; 10+ messages in thread
From: Carlos Villegas @ 2004-08-11 20:00 UTC (permalink / raw)
To: Jason Opperisano; +Cc: netfilter
On Wed, Aug 11, 2004 at 12:30:50PM -0400, Jason Opperisano wrote:
> is not narrowing down the interface/source, and is hit before any connection tracking occurs. i've never used "-j REJECT --reject-with tcp-reset" without also specifying "--syn" as it could have very odd results (and also doesn't make sense from a TCP perspective)...
Really? I thought "-j REJECT --reject-with tcp-reset" would always do
the right thing, even without specifying --syn (of course, it wouldn't
be a bad idea to specify it anyway). I have several systems running fine
without the --syn option explicitly mentioned. Could any of the "core"
guys say if my assumption is wrong?
Carlos
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
@ 2004-08-11 20:24 Jason Opperisano
0 siblings, 0 replies; 10+ messages in thread
From: Jason Opperisano @ 2004-08-11 20:24 UTC (permalink / raw)
To: netfilter
> On Wed, Aug 11, 2004 at 12:30:50PM -0400, Jason Opperisano wrote:
> > is not narrowing down the interface/source, and is hit before any connection tracking occurs. i've never used "-j REJECT --reject-with tcp-reset" without also specifying "--syn" as it could have very odd results (and also doesn't make sense from a TCP perspective)...
>
> Really? I thought "-j REJECT --reject-with tcp-reset" would always do
> the right thing, even without specifying --syn (of course, it wouldn't
> be a bad idea to specify it anyway). I have several systems running fine
> without the --syn option explicitly mentioned. Could any of the "core"
> guys say if my assumption is wrong?
>
> Carlos
i should probably clarify my statement. i suggested "--syn" to the OP because the desired outcome he had was for the client to receive a "Connection Refused" instead of a timeout--like you would get with no firewall in place and a host not listening on the requested destination port. that is:
Client Server
SYN ->
<- RST
in the generic case, either side of an established TCP session can choose to reset the connection at any time; so "--syn" in that sense is not required.
i am surely no coder--and would be interested in hearing the answer to this from the gurus myself as well. perusing /usr/src/linux/net/ipv4/netfilter/ipt_REJECT.c leads me to believe the only TCP-flag-related sanity check is to not send a RST to a RST (~ line 98 on the version i have).
i guess i got gunshy back in my IPF days, when if you didn't use "flags S/SA" with a "return-rst" you would end up blowing away connections all over the place...old habits die hard.
-j
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
2004-08-11 20:00 ` Carlos Villegas
@ 2004-08-12 1:32 ` Mark E. Donaldson
2004-08-12 12:46 ` Dick St.Peters
0 siblings, 1 reply; 10+ messages in thread
From: Mark E. Donaldson @ 2004-08-12 1:32 UTC (permalink / raw)
To: 'Carlos Villegas', 'Jason Opperisano'; +Cc: netfilter
Really? I thought "-j REJECT --reject-with tcp-reset" would always do the
right thing, even without specifying --syn (of course, it wouldn't be a bad
idea to specify it anyway). I have several systems running fine without the
--syn option explicitly mentioned. Could any of the "core"
guys say if my assumption is wrong?
Carlos
My views are this: If you are going to reset a TCP connection, it is best to
do so at the earliest possible moment of a TCP session, preferably after the
initial syn of the three-way handshake. When I use "-j REJECT --reject-with
tcp-reset" it is always in response to a NEW (thus syn) packet. Perhaps Mr.
Stone will weigh in on this. If Chris Brenton is listening in, I would like
to hear his views on this as well.
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question about REJECT in FORWARD rule
2004-08-12 1:32 ` Mark E. Donaldson
@ 2004-08-12 12:46 ` Dick St.Peters
0 siblings, 0 replies; 10+ messages in thread
From: Dick St.Peters @ 2004-08-12 12:46 UTC (permalink / raw)
To: markee; +Cc: netfilter
Mark E. Donaldson writes:
> My views are this: If you are going to reset a TCP connection, it is best to
> do so at the earliest possible moment of a TCP session, preferably after the
> initial syn of the three-way handshake. When I use "-j REJECT --reject-with
> tcp-reset" it is always in response to a NEW (thus syn) packet.
There are times when the earliest possible moment is long after the
initial syn. For example: you ssh from A to B and then someone
reboots B while you're idle. When B is back up, if it simply DROPs
packets that aren't established and aren't syns, your ssh session will
appear hung. A reset makes it clear the session is terminated.
--
Dick St.Peters, stpeters@NetHeaven.com
Gatekeeper, NetHeaven, Saratoga Springs, NY
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-08-12 12:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-11 16:30 Question about REJECT in FORWARD rule Jason Opperisano
2004-08-11 17:37 ` Maxime Ducharme
2004-08-11 20:00 ` Carlos Villegas
2004-08-12 1:32 ` Mark E. Donaldson
2004-08-12 12:46 ` Dick St.Peters
-- strict thread matches above, loose matches on Subject: below --
2004-08-11 20:24 Jason Opperisano
2004-08-11 19:01 Jason Opperisano
2004-08-11 15:44 Jason Opperisano
2004-08-11 16:14 ` Maxime Ducharme
2004-08-11 14:49 Maxime Ducharme
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.