firewall using iptables DHCP IP may change?

David Efflandt wrote:
> On Sun, 30 Jan 2005 17:22:14 GMT, William Gill <noreply@gcgroup.net> wrote:
>
>>I am trying to set up a firewall using iptables. I'm not running any
>>servers for the outside world, but apache, and mysql for internal
>>(development) use. My internet connection is via adsl, and the IP is
>>dynamic (DHCP). Several scripts I've seen show snippets for reading
>>the IP of ppp0. Am I wrong in assuming that if the adsl connection goes
>>down for whatever reason and has to reestablish itself, the DHCP IP may
>>change? If so, shouldn't I create a cron file to test for the change and
>>rerun the firewall script accordingly?
>
>
> Whether static or dynamic, PPPoE is NOT DHCP (different protocol).
> /etc/ppp/ip-up always runs whenever pppd (including for pppoe) gets an IP.
> So all you have to do is refresh your firewall from ip-up (or ip-up.local)
> and ip-down (or ip-down.local), just like you would for dialup.

I have reread my post several times, and don't see anywhere that I
suggested that pppoe is DHCP. My pppoe client (and I have to assume any
of them) can operate on a static IP, or a dynamic. If dynamic, it can
use one of several protocols to get an IP. DHCP is one of them. As it
turns out, the gui offers "dialup" as one of the protocols, and that,
not DHCP is selected. I think "refreshing" my firewall is what I asked
about, but what has been pointed out, it that I can do things more
efficiently without getting bogged down in actual addresses.

Juha Laiho wrote:
> William Gill <noreply@gcgroup.net> said:
>
>>I am trying to set up a firewall using iptables. I'm not running any
>>servers for the outside world, but apache, and mysql for internal
>>(development) use.
>
>
> As was said, in that case don't open anything from outside.
>
>
>>My internet connection is via adsl, and the IP is dynamic (DHCP).
>>Several scripts I've seen show snippets for reading the IP of ppp0.
>>Am I wrong in assuming that if the adsl connection goes down for
>>whatever reason and has to reestablish itself, the DHCP IP may change?
>>If so, shouldn't I create a cron file to test for the change and rerun
>>the firewall script accordingly?
>
>
> Rather, write your firewall script in such a way that you're not
> dependent on the address of the external interface. I've yet to see
> a simple case where the address of the external interface is really
> needed. Instead of seeing whether something was sent to your external
> interface address (-d ext.ip), check whether it arrived via the
> external interface (-i ext_if).
>
> And if you're forwarding traffic for internal machines, masquerade them
> instead of source natting (SNAT requires you to tell the source address
> for given outbound packets, whereas MASQ just will pick whatever
> the ext_if address happened to be at the time when the packet was sent).
>
> And as much as possible, make use of the established/related states of
> the connections. This pretty much solves problems with UDP-based
> services, as well as with various inbound ICMP packets.
>
> An example of the above; something to allow only web browsing.
> For this, clearly connections to tcp port 80 on remote hosts must
> be allowed, and DNS is also needed. In addition, for nice browsing
> experience, several ICMP subtypes must be let back in.
>
> Common lines:
>
> # Set policies to drop all traffic
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> # Clear all tables so that only the above policies are in effect
> iptables -t nat -F
> iptables -t mangle -F
> iptables -F
> # Allow machine internal traffic
> iptables -I INPUT -i lo -j ACCEPT
> iptables -I OUTPUT -o lo -j ACCEPT
>
> Then, lines to use without using the connection states:
> # DNS
> iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
> iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
> iptables -A INPUT -p udp --sport 53 -j ACCEPT
> iptables -A INPUT -p tcp --sport 53 -j ACCEPT
> # HTTP
> iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
> iptables -A INPUT -p tcp --sport 80 -j ACCEPT
> # ICMP
> iptables -A INPUT -p icmp --icmp-type destination-unreahable -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
> iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type echo-response -j ACCEPT
>
>
> And the equivalent of the above, but using connection states:
> # General
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> # DNS
> iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
> iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 --syn -j ACCEPT
> # HTTP
> iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 --syn -j ACCEPT
> # ICMP
> iptables -A OUTPUT -m state --state NEW -p icmp --icmp-type echo-request -j ACCEPT
>
>
> So, using states makes the rule sets shorter: even when you only allow
> browsing (and pinging) from inside, and block all other traffic in both
> directions, the rule set using states is shorter. If you go lax and
> allow everything from inside, the difference is even greater:
>
> Not using states - you still need to mind what you accept inbound:
> # General
> iptables -P OUTPUT ACCEPT
> # DNS
> iptables -A INPUT -p udp --sport 53 -j ACCEPT
> iptables -A INPUT -p tcp --sport 53 -j ACCEPT
> # HTTP
> iptables -A INPUT -p tcp --sport 80 -j ACCEPT
> # ICMP
> iptables -A INPUT -p icmp --icmp-type destination-unreahable -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type echo-response -j ACCEPT
>
> Using states - two rules:
> # General
> iptables -P OUTPUT ACCEPT
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
>
> And the last point on using states: when you're not using states, your
> machine is open to any scanner who has the brains to set the tcp source
> port to 80 before scanning - everything with source port tcp/80 is
> allowed. With states, the kernel netfilter code will maintain a connection
> table, and only allow packets in from hosts to which your machine has
> originated a connection (and only to the port your machine used to
> originate the connection). So, much tighter firewalling, which is
> especially nice with ICMP and UDP which are otherwise a pain to
> control properly.
>
> And note the snippets above; none of them includes any IP address.
> If I did allow anything inbound, I could filter the traffic by source
> address, and similarly, in the example where I'm controlling the outbound
> traffic (only letting out http,dns,ping), I could control those by the
> destination address. But the external address of the local machine just
> isn't needed.
OK, here's what I came up with. Have I left any serious holes? I'm
particularly concerned about the NAT rules.

# Set policies to drop all traffic
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Clear all tables so that only the above policies are in effect
iptables -t nat -F
iptables -t mangle -F
iptables -F

# Allow machine internal traffic
iptables -I INPUT -i lo -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT

#I had to add these so I could talk to the barrier machine
# Allow internal LAN (eth1) traffic
iptables -I INPUT -i eth1 -j ACCEPT
iptables -I OUTPUT -o eth1 -j ACCEPT

# Deny originations from the internet (ppp0)
iptables -A INPUT -i ppp0 -m state --state NEW -j DROP

#NAT
iptables -F -t nat

iptables -P FORWARD ACCEPT
iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

# using connection states:
# General
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# DNS
iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 --syn -j ACCEPT
# HTTP
iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 --syn -j ACCEPT
# ICMP
iptables -A OUTPUT -m state --state NEW -p icmp --icmp-type echo-request
-j ACCEPT

William Gill <noreply@gcgroup.net> said:
>OK, here's what I came up with. Have I left any serious holes? I'm
>particularly concerned about the NAT rules.

Hmm.. that looks a bit strange, for a few reasons. But then, this might
still be just what you wanted; I don't know whether it's that, or is it
just that you copied too much.


># Set policies to drop all traffic
>iptables -P INPUT DROP
>iptables -P OUTPUT DROP
>iptables -P FORWARD DROP

.... later on you have a line 'iptables -P FORWARD ACCEPT' -- you're
willing to forward any traffic originated by the internal machines.
Is this what you intended (i.e. all traffic originated from the NATted
machines is allowed)? If so, you could have that '-P FORWARD ACCEPT'
right here.

># Clear all tables so that only the above policies are in effect
>iptables -t nat -F

You're clearing the NAT table also later in the script. Can do multiple
times, but would be clearer to do just once. Decide whether you like
to clear it here, or do you like clearing the table just before you place
the rules to the NAT table; they're equivalent - choose the way your
brain likes better.

>iptables -t mangle -F
>iptables -F
>
># Allow machine internal traffic
>iptables -I INPUT -i lo -j ACCEPT
>iptables -I OUTPUT -o lo -j ACCEPT
>
>#I had to add these so I could talk to the barrier machine
># Allow internal LAN (eth1) traffic
>iptables -I INPUT -i eth1 -j ACCEPT
>iptables -I OUTPUT -o eth1 -j ACCEPT

Yep, here you're allowing all traffic. This could be ok or not; depends on
what kind of network you have behind this machine (how much you can trust
that network). If it's just a home network, I don't see this as a problem;
if it's an educational campus, I'm not certain whether I'd consider the
campus network or the Internet the worse threat to the firewall.. ;-)

># Deny originations from the internet (ppp0)
>iptables -A INPUT -i ppp0 -m state --state NEW -j DROP

Redundant, as your input policy is to deny these. But then, doesn't
make any harm, either. At times it may be better to spell things out
explicitly.

>#NAT
>iptables -F -t nat
>
>iptables -P FORWARD ACCEPT
>iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

Ok, if it is ok (cf. my earlier comments).

># using connection states:
># General
>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The lines below are my biggest concern. So, you're now running the
firewall with output policy of DROP. All traffic you're not allowing
below is prohibited. Is the below traffic all you want to allow from
your firewall to the Internet? (No, I can't answer that for you)

># DNS
>iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
>iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 --syn -j ACCEPT
># HTTP
>iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 --syn -j ACCEPT
># ICMP
>iptables -A OUTPUT -m state --state NEW -p icmp --icmp-type echo-request
>-j ACCEPT


--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho wrote:
> William Gill <noreply@gcgroup.net> said:
>
>>OK, here's what I came up with. Have I left any serious holes? I'm
>>particularly concerned about the NAT rules.
>
>
> Hmm.. that looks a bit strange, for a few reasons. But then, this might
> still be just what you wanted; I don't know whether it's that, or is it
> just that you copied too much.
>
>
>
>># Set policies to drop all traffic
>>iptables -P INPUT DROP
>>iptables -P OUTPUT DROP
>>iptables -P FORWARD DROP
>
>
> ... later on you have a line 'iptables -P FORWARD ACCEPT' -- you're
> willing to forward any traffic originated by the internal machines.
> Is this what you intended (i.e. all traffic originated from the NATted
> machines is allowed)? If so, you could have that '-P FORWARD ACCEPT'
> right here.
I see what you're saying. The "how to's" and tutorials all seem to do
it this way, placing the DENY or DROP first then the ACCEPT later. I
think they do it this way as a safety net. (start by denying
everything, then explicitly allow what you want)
>
>
>># Clear all tables so that only the above policies are in effect
>>iptables -t nat -F
>
>
> You're clearing the NAT table also later in the script. Can do multiple
> times, but would be clearer to do just once. Decide whether you like
> to clear it here, or do you like clearing the table just before you place
> the rules to the NAT table; they're equivalent - choose the way your
> brain likes better.
This is definitely a cut & paste error. I didn't catch the reiteration
of the rule. It makes more sense to do all the flushing (initializing)
at the start.

>
>
>>iptables -t mangle -F
>>iptables -F
>>
>># Allow machine internal traffic
>>iptables -I INPUT -i lo -j ACCEPT
>>iptables -I OUTPUT -o lo -j ACCEPT
>>
>>#I had to add these so I could talk to the barrier machine
>># Allow internal LAN (eth1) traffic
>>iptables -I INPUT -i eth1 -j ACCEPT
>>iptables -I OUTPUT -o eth1 -j ACCEPT
>
>
> Yep, here you're allowing all traffic. This could be ok or not; depends on
> what kind of network you have behind this machine (how much you can trust
> that network). If it's just a home network, I don't see this as a problem;
> if it's an educational campus, I'm not certain whether I'd consider the
> campus network or the Internet the worse threat to the firewall.. ;-)
It's a fairly safe network, my wife browsing, e-mailing, and posting on
chat boards; me working from various development machines; and my 30 yr.
old college student son, studying and chatting. The only one who knows
enough to do any DELIBERATE damage is me, though my 5 yr. old tries.

I thought about getting more specific, but was in a hurry to get telnet
up again.
>
>
>># Deny originations from the internet (ppp0)
>>iptables -A INPUT -i ppp0 -m state --state NEW -j DROP
>
>
> Redundant, as your input policy is to deny these. But then, doesn't
> make any harm, either. At times it may be better to spell things out
> explicitly.
>
>
>>#NAT
>>iptables -F -t nat
>>
>>iptables -P FORWARD ACCEPT
>>iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
>
>
> Ok, if it is ok (cf. my earlier comments).
>
>
>># using connection states:
>># General
>>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
>
> The lines below are my biggest concern. So, you're now running the
> firewall with output policy of DROP. All traffic you're not allowing
> below is prohibited. Is the below traffic all you want to allow from
> your firewall to the Internet? (No, I can't answer that for you)
>
>
>># DNS
>>iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
>>iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 --syn -j ACCEPT
>># HTTP
>>iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 --syn -j ACCEPT
>># ICMP
>>iptables -A OUTPUT -m state --state NEW -p icmp --icmp-type echo-request
>>-j ACCEPT
>
I think my problem may be my (mis)understanding of INPUT and OUTPUT.
The iptables-intro defined them as:
INPUT - Filters packets destined to the firewall.
OUTPUT - Filters packets originating from the firewall

In my thinking I thought packets from the LAN or the WAN to the firewall
machine, were INPUT. I'm probably wrong. If so, that may explain some
of my confusion.

If , in fact, INPUT and OUTPUT, only refer to packets to and from the
WAN interface, I'm sure I can simplify things a lot.

I can't think of anything I want to originate from the internet, unless
a ping response is considered an origination.

William Gill <noreply@gcgroup.net> said:
>Juha Laiho wrote:
>> William Gill <noreply@gcgroup.net> said:
>>
>>>OK, here's what I came up with. Have I left any serious holes? I'm
>>>particularly concerned about the NAT rules.
>>
>>
>> Hmm.. that looks a bit strange, for a few reasons. But then, this might
>> still be just what you wanted; I don't know whether it's that, or is it
>> just that you copied too much.
>>
>>
>>
>>># Set policies to drop all traffic
>>>iptables -P INPUT DROP
>>>iptables -P OUTPUT DROP
>>>iptables -P FORWARD DROP
>>
>>
>> ... later on you have a line 'iptables -P FORWARD ACCEPT' -- you're
>> willing to forward any traffic originated by the internal machines.
>> Is this what you intended (i.e. all traffic originated from the NATted
>> machines is allowed)? If so, you could have that '-P FORWARD ACCEPT'
>> right here.
>I see what you're saying. The "how to's" and tutorials all seem to do
>it this way, placing the DENY or DROP first then the ACCEPT later. I
>think they do it this way as a safety net. (start by denying
>everything, then explicitly allow what you want)

Mmm.. with '-P' the things are a bit different. With '-P' you set the chain
policy, and at any given time you can only have one chain policy for
a given chain. The policy is what happens to packets that were not matched
by any (final) rule in the chain. So, treat that as the implicit 'rule
after the last rule'. So, if you're going to accept forwards, accept them
right away; no reason to keep them denied for the while when your script
is executing.

>> Yep, here you're allowing all traffic. This could be ok or not; depends on
>> what kind of network you have [...]

>It's a fairly safe network, my wife browsing, [...]

Yep. A typical home network; I don't see much reason to tighten the
security much there.

>I think my problem may be my (mis)understanding of INPUT and OUTPUT.
>The iptables-intro defined them as:
> INPUT - Filters packets destined to the firewall.
> OUTPUT - Filters packets originating from the firewall
>
>In my thinking I thought packets from the LAN or the WAN to the firewall
>machine, were INPUT. I'm probably wrong. If so, that may explain some
>of my confusion.

No, the definition above is correct; INPUT is any packet that is destined
to the firewall. Note though, you could block all INPUT and OUTPUT, and
still be able to FORWARD packets. So packets just passing through do not
traverse the INPUT and OUTPUT chains.

>If , in fact, INPUT and OUTPUT, only refer to packets to and from the
>WAN interface, I'm sure I can simplify things a lot.

The simplifiation for this is pretty much that you do (as you did) just
allow anything from the internal network interface. And this can be done
pretty much at the start of the chain. Remember that iptables processing
for a packet ends, when it encounters the first matching rule with a
terminal action (ACCEPT, REJECT, or DROP).

As an example, if you have rules in this order:
iptables -A INPUT -p tcp -j DROP
iptables -A INPUT -i eth1 -p tcp -j ACCEPT
.... the second rule won't match any packets (and as a consequence, tcp
packets coming in via eth1 will not be accepted), because the packets
already matched the first rule, and there was the terminal action to
drop them. Reverse the order to:
iptables -A INPUT -i eth1 -p tcp -j ACCEPT
iptables -A INPUT -p tcp -j DROP
.... and tcp packets arriving via eth1 will be accepted, but all other
incoming tcp packets will be dropped.

The above also serves as an example to avoid too specific rules: the
above rules don't have any effect on icmp or udp packets (because
they're limited to tcp only). For a packet to match a rule, it has to
match all of the conditions set for the rule.

Another problem with too specific rules is that they may slow down
your traffic (if you have huge amounts of them, and they happen to
be in an unfortunate order). This is why I tend to keep the rules
to accept the RELATED,ESTABLISHED state packets somewhere very near
the start of the rule chains. In most places these rules will be the
ones to match a very great majority of the packets, so it's good for
performance to have these rules to first accept all possible packets
they can, instead of making all the packets walk through the full
rule chains one by one.

>I can't think of anything I want to originate from the internet, unless
>a ping response is considered an origination.

Sounds a nice home network in that sense as well. And ping response is
not originating traffic; all valid ping responses will be related to
a ping request that went outwards a while earlier. So,
a RELATED,ESTABLISHED rule will match those as well.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)