Re: Port "triggering"

From: /dev/null (dev.null_at_BeginThread.com)
Date: 12/24/04 

Date: Fri, 24 Dec 2004 02:25:46 GMT

In general one thing I see here is you don't take enough care to specify
which interfaces for outbound traffic or which destination for incoming
traffic.

Here are two examples:

-A PREROUTING -i eth1 -p udp -m udp --dport 3100:3105 -j
DNAT --to-destination 192.168.0.201

Would be better:

-A PREROUTING -i eth1 -s <source IP of incoming traffic 0.0.0.0/0 if it's
the world> -d <the IP addr of eth1> -p udp -m udp --sport 1024:65535 --dport
3100:3105 -j DNAT --to-destination 192.168.0.201

I also like to put in specific --sport on the -m specs to, narrow it to
1024:65535 usually. That way you are detailing *exactly* what type of
traffic you expect, anything outside of exact parameters gets dropped.
There are some protocols that the source port and the dest port are the same
(IPSec udp is port 500, ntp uses 123, nfs uses ports < 1024 when connecting,
etc...). The narrower you can make your acceptable range of traffic the
better.

The reason you should specify the -d above is if you have two internal nets
that this box routes for the rule you had would take every packet coming in
on eth1, no matter where it's going and it sends it to your internal box.
If you are connecting to some outside server your connection will never make
it, instead the linux box re-routes it back inside. This may well be your
problem.

Here's the second example:

-A PREROUTING -p udp -m udp --dport 3783 -j DNAT --to-destination
192.168.0.201

should be:

-A PREROUTING -i ethX -p udp -s <ip range of the -i network> -d <ip of
the -i interface> -m udp --sport 1024:65535 --dport 3783 -j
DNAT --to-destination 192.168.0.201

Again, the rule you had takes every single packet going to port 3783, no
matter where it's from or where it's going you yank it and redirect it to
your 0.201.

Here's another idea I use *all the time* to help track things. I have this
as the first rules of the three standard chains (INPUT, OUTPUT, FORWARD):

-A $CHAIN -m state --state RELATED,ESTABLISHED -j ACCEPT
-A $CHAIN -j LOG --log-prefix "Incoming $CHAIN"

Now right off, anything connection that has already worked it's way through
the rules (and allowed) will immediately be allowed on without bothering
with any more rule-matching. Then anything that hasn't already been
established will get logged. This is really nice because you'll see one
entry in the syslog for *every* connection coming in or through that box,
even ones that later get dropped.

At the end of each chain I do a:

-A $CHAIN -j LOG --log-prefix "Default DROPing on $CHAIN"

Then do your ICMP or REJECT

Now I can see exactly what didn't make it through the rules. So if I do a
major mod to my rules and suddenly things break I can figure out exactly
which chain is dropping my packets and (usually) trace the rules I have back
to the culprit.

This is also handy when checking out DNAT rules. As you probably know,
PREROUTING doesn't take LOG as a -j target so you can't log "I'm sending X
packet over DNAT to Y server". Instead you end up seeing it on the FORWARD
chain as a "Incoming FORWARD" log entry, already DNATed.

Now you can go through and do tail -f syslog and then try different
connections that aren't working and (usually) figure out why.

So my two recommendations are (1) tighten your rules down by specifying as
much as you possibly can to qualify exactly which packets you want NATed,
and (2) add the above logging so you can follow what's going on as you watch
your rules.

> You asked for it ;)

That's nothing. My router/firewalls typically average about 5,000 lines
(iptables-save | wc). :-)

Relevant Pages

  • iptables questions
    ... FORWARD chain because if no connection has been established from my ... the packet will be handled by the INPUT ... supported and how would I go about having other protocols recognised? ...
    (comp.os.linux.security)
  • Re: Odd iptables blocking on port 25
    ... >>Chain OUTPUT ... >>OUTBOUND connection with SOURCE port 25 and a dynamic destination port? ... > The packet you are seeing is a SYN ACK packet, ie. a response to a new ...
    (comp.os.linux.security)
  • Re: iptables questions
    ... > FORWARD chain because if no connection has been established from my LAN ... Is this because ipchains has ... packet from nameserver:53 to gatewaybox:highport is recognised as being ...
    (comp.os.linux.security)
  • Re: peer to peer messaging
    ... attempts to open a connection to port 80 of the server at that IP address. ... For example a packet from my machine might have source IP ... Packets from the sever to my laptop would have those reversed. ...
    (comp.lang.java.programmer)
  • Re: IPFW Dynamic Rules
    ... > So if the dynamic rule has the same behaviour as the origination ... > rule on the same port with the same protocol, ... If client sends UDP query to DNS on your machine, you get the packet: ... is deleted after connection is inactive for some time. ...
    (FreeBSD-Security)