Prev: IPtables - forwarding question
Next: techradar says win7 has killed the linux desktop
From: Mike Jones on 16 Jun 2010 16:33


Ok. Lessavanutha go. ;)

Assuming dnsmasq is configured properly (it works fine), and assuming
aliens are not disrupting anything else...

I've got (stripped back to related bits) these firewall details...

# === SERVER === #

IPT="/usr/sbin/iptables"

NIC_LAN="eth1"
PORTS_DHCP="53,67,68,4567"

$IPT -F;
$IPT -X;
$IPT -P FORWARD DROP
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

$IPT -A INPUT -i $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -o $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# === SERVER === #

# === CLIENT === #

IPT="/usr/sbin/iptables"

NIC_LAN="eth0"
PORTS_DHCP="53,67,68,4567"

$IPT -F;
$IPT -X;
$IPT -P FORWARD DROP
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A OUTPUT -o $NIC_LAN \
-p icmp --icmp-type 8 -j ACCEPT
$IPT -A INPUT -i $NIC_LAN \
-p icmp --icmp-type 0 -j ACCEPT

$IPT -A OUTPUT -o $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state ESTABLISHED,RELATED -j ACCEPT

# === CLIENT === #

....and the client can connect to the server ok.

However...

If I take this line in the server firewall...

$IPT -A OUTPUT -o $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

....and change it to,

$IPT -A OUTPUT -o $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state ESTABLISHED,RELATED -j ACCEPT

(Just cut the "NEW" from the "OUTPUT")

....then the client can't connect.


I'm thinking that as far as IPtables is concerned, the outgoing traffic
is "NEW" to it, and I'm blocking the client by blocking it's request
return traffic, but the client treats that traffic as ESTABLISHED,RELATED
as initial request traffic has already gone out.

Thoughts? Comments?



XP alt.os.linux.slackware,alt.os.linux
FU alt.os.linux

--

*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Grant on 16 Jun 2010 17:47
On Wed, 16 Jun 2010 20:33:07 +0000 (UTC), Mike Jones <luck(a)dasteem.invalid> wrote:

>
>
>Ok. Lessavanutha go. ;)
>
>Assuming dnsmasq is configured properly (it works fine), and assuming
>aliens are not disrupting anything else...
>
>I've got (stripped back to related bits) these firewall details...
>
># === SERVER === #
>
>IPT="/usr/sbin/iptables"
>
>NIC_LAN="eth1"
>PORTS_DHCP="53,67,68,4567"

67, 68 are different to other stuff as they're broadcast addr
>
>$IPT -F;
>$IPT -X;
>$IPT -P FORWARD DROP
>$IPT -P INPUT DROP
>$IPT -P OUTPUT DROP

why output drop?

>$IPT -A INPUT -i lo -j ACCEPT
>$IPT -A OUTPUT -o lo -j ACCEPT

first thing after policy is to accept expected return traffic
>
>/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
>
>$IPT -A INPUT -i $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
># === SERVER === #
>
># === CLIENT === #
>
>IPT="/usr/sbin/iptables"
>
>NIC_LAN="eth0"
>PORTS_DHCP="53,67,68,4567"
>
>$IPT -F;
>$IPT -X;
>$IPT -P FORWARD DROP
>$IPT -P INPUT DROP
>$IPT -P OUTPUT DROP
>$IPT -A INPUT -i lo -j ACCEPT
>$IPT -A OUTPUT -o lo -j ACCEPT

return traffic first
>
>$IPT -A OUTPUT -o $NIC_LAN \
>-p icmp --icmp-type 8 -j ACCEPT



>$IPT -A INPUT -i $NIC_LAN \
>-p icmp --icmp-type 0 -j ACCEPT

rate limit responses?
>
>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPT -A INPUT -i $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state ESTABLISHED,RELATED -j ACCEPT
>
># === CLIENT === #
>
>...and the client can connect to the server ok.
>
>However...
>
>If I take this line in the server firewall...
>
>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
>...and change it to,
>
>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state ESTABLISHED,RELATED -j ACCEPT
>
>(Just cut the "NEW" from the "OUTPUT")
>
>...then the client can't connect.
>
>
>I'm thinking that as far as IPtables is concerned, the outgoing traffic
>is "NEW" to it, and I'm blocking the client by blocking it's request
>return traffic, but the client treats that traffic as ESTABLISHED,RELATED
>as initial request traffic has already gone out.

I don't policy drop output, point being that proper input control
prevents bad output ;) Six years and works well for me :)

But then, my firewall box is between localnet and modem, so the rules
are a little different. Also, I haven't focused on iptables for quite
some time, so I cannot be more detailed at the moment. I know what works
for me, but I forget the subtle points, other than other times I suggested
changing order of rules, problems disappeared.

The kernel updates changed things some time after 2.6.27 and I haven't
gone in and compensated yet. Procrastination at work! Soon, though,
I must update as 2.6.27 extended maintenance draws to a close and
perhaps it's time to bump the slackware-11.0 firewall box up a bit too.

Skipped your first post about iptables, so not sure what your issue is.

Grant.
--
http://bugs.id.au/
From: Mike Jones on 16 Jun 2010 19:04
Responding to Grant:

> On Wed, 16 Jun 2010 20:33:07 +0000 (UTC), Mike Jones
> <luck(a)dasteem.invalid> wrote:
>
>
>>
>>Ok. Lessavanutha go. ;)
>>
>>Assuming dnsmasq is configured properly (it works fine), and assuming
>>aliens are not disrupting anything else...
>>
>>I've got (stripped back to related bits) these firewall details...
>>
>># === SERVER === #
>>
>>IPT="/usr/sbin/iptables"
>>
>>NIC_LAN="eth1"
>>PORTS_DHCP="53,67,68,4567"
>
> 67, 68 are different to other stuff as they're broadcast addr
>>
>>$IPT -F;
>>$IPT -X;
>>$IPT -P FORWARD DROP
>>$IPT -P INPUT DROP
>>$IPT -P OUTPUT DROP
>
> why output drop?
>
>>$IPT -A INPUT -i lo -j ACCEPT
>>$IPT -A OUTPUT -o lo -j ACCEPT
>
> first thing after policy is to accept expected return traffic
>>
>>/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
>>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
>>
>>$IPT -A INPUT -i $NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -o
>>$NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>># === SERVER === #
>>
>># === CLIENT === #
>>
>>IPT="/usr/sbin/iptables"
>>
>>NIC_LAN="eth0"
>>PORTS_DHCP="53,67,68,4567"
>>
>>$IPT -F;
>>$IPT -X;
>>$IPT -P FORWARD DROP
>>$IPT -P INPUT DROP
>>$IPT -P OUTPUT DROP
>>$IPT -A INPUT -i lo -j ACCEPT
>>$IPT -A OUTPUT -o lo -j ACCEPT
>
> return traffic first
>>
>>$IPT -A OUTPUT -o $NIC_LAN \
>>-p icmp --icmp-type 8 -j ACCEPT
>
>
>
>>$IPT -A INPUT -i $NIC_LAN \
>>-p icmp --icmp-type 0 -j ACCEPT
>
> rate limit responses?
>>
>>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -i
>>$NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>># === CLIENT === #
>>
>>...and the client can connect to the server ok.
>>
>>However...
>>
>>If I take this line in the server firewall...
>>
>>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>>...and change it to,
>>
>>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>>-m multiport --ports $PORTS_DHCP \
>>-m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>>(Just cut the "NEW" from the "OUTPUT")
>>
>>...then the client can't connect.
>>
>>
>>I'm thinking that as far as IPtables is concerned, the outgoing traffic
>>is "NEW" to it, and I'm blocking the client by blocking it's request
>>return traffic, but the client treats that traffic as
>>ESTABLISHED,RELATED as initial request traffic has already gone out.
>
> I don't policy drop output, point being that proper input control
> prevents bad output ;) Six years and works well for me :)
>
> But then, my firewall box is between localnet and modem, so the rules
> are a little different. Also, I haven't focused on iptables for quite
> some time, so I cannot be more detailed at the moment. I know what
> works for me, but I forget the subtle points, other than other times I
> suggested changing order of rules, problems disappeared.
>
> The kernel updates changed things some time after 2.6.27 and I haven't
> gone in and compensated yet. Procrastination at work! Soon, though, I
> must update as 2.6.27 extended maintenance draws to a close and perhaps
> it's time to bump the slackware-11.0 firewall box up a bit too.
>
> Skipped your first post about iptables, so not sure what your issue is.
>
> Grant.


First post should be considered SNAFU. ;)

No issue, just a question, as outlined above.

Not looking for "I'd have done it differently" review stuff here, just
"Why does the client get blocked if I drop OUTPUT = NEW from the server?"

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Pascal Hambourg on 17 Jun 2010 05:42
Hello,

Mike Jones a �crit :
>
> # === SERVER === #
>
> IPT="/usr/sbin/iptables"
>
> NIC_LAN="eth1"
> PORTS_DHCP="53,67,68,4567"
>
> $IPT -F;
> $IPT -X;
> $IPT -P FORWARD DROP
> $IPT -P INPUT DROP
> $IPT -P OUTPUT DROP
> $IPT -A INPUT -i lo -j ACCEPT
> $IPT -A OUTPUT -o lo -j ACCEPT
>
> /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
>
> $IPT -A INPUT -i $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPT -A OUTPUT -o $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Notes :
1) DNS (port 53) may also use TCP transport for AXFR (zone transfer) or
more generally when the data length don't fit in the maximum size of a
UDP datagram. EDNS expands this maximum size, but not all DNS servers
and client implementations support EDNS.

2) A UDP packet cannot be in the INVALID state, so your "state" match is
useless here as it will match any UDP packet.

3) The --ports option of the "multiport" match matches either the source
or destination port. Is this really what you want ? Is the box both a
server and client for these ports ?
If you want to be strict you must match only destination ports
(--dports) for outgoing requests and source ports (--sports) with the
ESTABLISHED state for incoming replies. Actually source port match is
not even required for ESTABLISHED packets because the connection
tracking automatically takes care of it.

> # === SERVER === #
>
> # === CLIENT === #
>
> IPT="/usr/sbin/iptables"
>
> NIC_LAN="eth0"
> PORTS_DHCP="53,67,68,4567"
>
> $IPT -F;
> $IPT -X;
> $IPT -P FORWARD DROP
> $IPT -P INPUT DROP
> $IPT -P OUTPUT DROP
> $IPT -A INPUT -i lo -j ACCEPT
> $IPT -A OUTPUT -o lo -j ACCEPT
>
> $IPT -A OUTPUT -o $NIC_LAN \
> -p icmp --icmp-type 8 -j ACCEPT
> $IPT -A INPUT -i $NIC_LAN \
> -p icmp --icmp-type 0 -j ACCEPT

Notes :
1) ICMP Type/code names such as "echo-request" and "echo-reply" are more
"friendly" than numbers such as 8 and 0, aren't they ?
2) If you want to be strict you must accept only an echo reply that
matches a previously sent echo request, i.e. has the ESTABLISHED state.

> $IPT -A OUTPUT -o $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPT -A INPUT -i $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> # === CLIENT === #
>
> ...and the client can connect to the server ok.
>
> However...
>
> If I take this line in the server firewall...
>
> $IPT -A OUTPUT -o $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> ...and change it to,
>
> $IPT -A OUTPUT -o $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> (Just cut the "NEW" from the "OUTPUT")
>
> ...then the client can't connect.

Of course it can't connect. NEW is the state of the first packets of a
new communication until the other end sends a reply (then this reply
packet and all subsequent packets in either direction are in the
ESTABLISHED state). If you drop these packets, how could a communication
possibly work ?

> I'm thinking that as far as IPtables is concerned, the outgoing traffic
> is "NEW" to it,

No. State and direction are independent.

> and I'm blocking the client by blocking it's request
> return traffic,

No, by blocking the outgoing request, as I wrote above.


Usually, a stateful ruleset contains the following :

- Rules that match and accept the first packet of any desired
communication in the desired direction in the state NEW.

- Rules that match and accept any packet in either direction with the
states ESTABLISHED,RELATED. These rules may be placed first in the
chains for efficiency because they generally match most traffic.
From: Mike Jones on 17 Jun 2010 14:24
Responding to Pascal Hambourg:

> Hello,
>
> Mike Jones a écrit :
>>
>> # === SERVER === #
>>
>> IPT="/usr/sbin/iptables"
>>
>> NIC_LAN="eth1"
>> PORTS_DHCP="53,67,68,4567"
>>
>> $IPT -F;
>> $IPT -X;
>> $IPT -P FORWARD DROP
>> $IPT -P INPUT DROP
>> $IPT -P OUTPUT DROP
>> $IPT -A INPUT -i lo -j ACCEPT
>> $IPT -A OUTPUT -o lo -j ACCEPT
>>
>> /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
>> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
>>
>> $IPT -A INPUT -i $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -o
>> $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> Notes :
> 1) DNS (port 53) may also use TCP transport for AXFR (zone transfer) or
> more generally when the data length don't fit in the maximum size of a
> UDP datagram. EDNS expands this maximum size, but not all DNS servers
> and client implementations support EDNS.
>
> 2) A UDP packet cannot be in the INVALID state, so your "state" match is
> useless here as it will match any UDP packet.
>
> 3) The --ports option of the "multiport" match matches either the source
> or destination port. Is this really what you want ? Is the box both a
> server and client for these ports ?
> If you want to be strict you must match only destination ports
> (--dports) for outgoing requests and source ports (--sports) with the
> ESTABLISHED state for incoming replies. Actually source port match is
> not even required for ESTABLISHED packets because the connection
> tracking automatically takes care of it.
>
>> # === SERVER === #
>>
>> # === CLIENT === #
>>
>> IPT="/usr/sbin/iptables"
>>
>> NIC_LAN="eth0"
>> PORTS_DHCP="53,67,68,4567"
>>
>> $IPT -F;
>> $IPT -X;
>> $IPT -P FORWARD DROP
>> $IPT -P INPUT DROP
>> $IPT -P OUTPUT DROP
>> $IPT -A INPUT -i lo -j ACCEPT
>> $IPT -A OUTPUT -o lo -j ACCEPT
>>
>> $IPT -A OUTPUT -o $NIC_LAN \
>> -p icmp --icmp-type 8 -j ACCEPT
>> $IPT -A INPUT -i $NIC_LAN \
>> -p icmp --icmp-type 0 -j ACCEPT
>
> Notes :
> 1) ICMP Type/code names such as "echo-request" and "echo-reply" are more
> "friendly" than numbers such as 8 and 0, aren't they ? 2) If you want to
> be strict you must accept only an echo reply that matches a previously
> sent echo request, i.e. has the ESTABLISHED state.
>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -i
>> $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> # === CLIENT === #
>>
>> ...and the client can connect to the server ok.
>>
>> However...
>>
>> If I take this line in the server firewall...
>>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>> ...and change it to,
>>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> (Just cut the "NEW" from the "OUTPUT")
>>
>> ...then the client can't connect.
>
> Of course it can't connect. NEW is the state of the first packets of a
> new communication until the other end sends a reply (then this reply
> packet and all subsequent packets in either direction are in the
> ESTABLISHED state). If you drop these packets, how could a communication
> possibly work ?
>
>> I'm thinking that as far as IPtables is concerned, the outgoing traffic
>> is "NEW" to it,
>
> No. State and direction are independent.
>
>> and I'm blocking the client by blocking it's request return traffic,
>
> No, by blocking the outgoing request, as I wrote above.
>
>
> Usually, a stateful ruleset contains the following :
>
> - Rules that match and accept the first packet of any desired
> communication in the desired direction in the state NEW.
>
> - Rules that match and accept any packet in either direction with the
> states ESTABLISHED,RELATED. These rules may be placed first in the
> chains for efficiency because they generally match most traffic.



I clearly have more reading to do.

Thanks for the heads-up.

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
 |  Next  |  Last
Pages: 1 2
Prev: IPtables - forwarding question
Next: techradar says win7 has killed the linux desktop