All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 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 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 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
* 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
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.