firewall using iptables DHCP IP may change?

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?

Bill

Davide Bianchi wrote:
> On 2005-01-30, 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
>
>
> Then close everything FROM outside, let everything FROM inside and
> you're done.
>
something as simple as this,

iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i ppp0 -s 0/0 -d 0/0 -j DENY

plus a masq rule ?

>
>>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?
>
>
> It depends, sometimes the dhcp just does a 'refresh' and the IP is the
> same, sometimes the IP change without even going down. Unless you can get
> a FIXED ip, assume that your IP is unknown.
>
> Davide
>

On Sun, 30 Jan 2005 17:22:14 GMT, William Gill wrote:

> 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?

Please read http://www.catb.org/~esr/faqs/smart-questions.html
Always provide distribution, release, and if Mandrake, community,
official, cooker, when posting questions.
It could help you get better answers.

If using dhclient, on Mandrakelinux 10.x you can create a
/etc/dhclient-exit-hooks scrip to do whatever you like.
Example script found here.

Please bookmark the following, very large,
Frequently Asked Questions (faq) Search engine:

http://groups.google.co.uk/advanced_group_search
dhclient-exit-hooks in the first box
bit twister in the Author box
*linux* in Newsgroup box. You need to use the two
asterisks around linux, pick English

If you want/need more control over the first box search,
http://www.google.com/help/refinesearch.html

Davide Bianchi wrote:
> On 2005-01-30, William Gill <noreply@gcgroup.net> wrote:
>
>>something as simple as this,
>
>
> Well, keep in mind that the request you send out have to came back in,
> so you need to accept incoming connection when they are requested from
> the inside. The firewall-howto has some examples and explanations.
>
> Davide
>
I'll re-read the how to, though I seem to be in overload mode, and keep
confusing myself. Would denying originations from ppp0 do the trick?

Bit Twister wrote:
> On Sun, 30 Jan 2005 17:22:14 GMT, William Gill wrote:
>
>
>>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?
>
>
> Please read http://www.catb.org/~esr/faqs/smart-questions.html
> Always provide distribution, release, and if Mandrake, community,
> official, cooker, when posting questions.
> It could help you get better answers.

Good advice, but I felt this was more "generic" in nature. i.e. "yes
you need to do something",or "no you don't". If yes, then I would have
researched my configuration specifically to see what specific "do
something."

I have found that often too much non-pertinent detail clouds the
response. Sorry if I was wrong.

Though I don't use Mandrake, it looks like they have a hook for their
particular "do something."

>
> If using dhclient, on Mandrakelinux 10.x you can create a
> /etc/dhclient-exit-hooks scrip to do whatever you like.
> Example script found here.
>
> Please bookmark the following, very large,
> Frequently Asked Questions (faq) Search engine:
>
> http://groups.google.co.uk/advanced_group_search

Great link! Thanks.

> dhclient-exit-hooks in the first box
> bit twister in the Author box
> *linux* in Newsgroup box. You need to use the two
> asterisks around linux, pick English
>
> If you want/need more control over the first box search,
> http://www.google.com/help/refinesearch.html

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.
--
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)

On Sun, 30 Jan 2005 18:41:18 GMT, William Gill wrote:
>
> Good advice, but I felt this was more "generic" in nature. i.e. "yes
> you need to do something",or "no you don't".
> If yes, then I would have
> researched my configuration specifically to see what specific "do
> something."

But, then again you might have received pointers to specific something
to save you and anyone using google some time. :)

> I have found that often too much non-pertinent detail clouds the
> response. Sorry if I was wrong.

All you would had to add was rh fc3, suse 9.x,....

> Though I don't use Mandrake, it looks like they have a hook for their
> particular "do something."

It is kinda dhcp client specific.

man your_dhcp_client_here for specific script you can create.

William Gill 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?
>

Pretty often you do not need the IP of the external interface,
be it eth0 or ppp0 (if PPPoE) - it suffices to identify the
interface for the iptables rules. All input from the interface
(ppp0 if PPPoE, eth0 else) is suspect until filtered.

--

Tauno Voipio
tauno voipio (at) iki fi

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. ...

That was my first thought, but after seeing them pour out page after
page of scripting dealing with IP's, I thought "What do I know, I'm a
rookie."

> ...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.
That's what I thought, Thanks.

>
> 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.

Thanks a lot. If I can't figure out what to do now, I shouldn't me
messing with things.

sincerely

Bill

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.