Errr! DSL is here, DSL is gone.
bscott at ntisys.com
bscott at ntisys.com
Mon Jul 14 21:13:26 EDT 2003
On Mon, 14 Jul 2003, at 8:52pm, gnhlug at sophic.org wrote:
> Which is to say that, it's fine to have these as defaults, but I prefer to
> have rules that do this explicitly at the end of my chains, rather than
> relying on policy to do the DROP. The reason is that you can not log a
> policy decision; you must have a rule to log it explicitly.
I prefer the same. You will note that I set out to duplicate the
firewall/router functionality of a typical SOHO router, and *not* to design
the best overall firewall. :-)
> Though, IIRC, iptables can not do this atomically (i.e. both LOG and DROP
> in one rule) ...
You remember correctly. The general method is to create a user-defined
chain, and then use that as the terminating target. For example:
# utility target to reject-and-log
iptables -N rej
iptables -A rej -j LOG --log-prefix "firewall "
iptables -A rej -j REJECT
# ....
# reject traffic from unwanted sources
iptables -A INPUT -s 207.46.249.27 -j rej
# ....
# reject by default
iptables -A INPUT -j rej
>> # clear everything iptables -F
>> iptables -X
>
> I would also like to point out that the above does /not/ clear the NAT
> tables.
Oops! You're very right. I forgot to include those commands in my
quick-and-dirty script. (Well, it wouldn't be a quick-and-dirty script if
it didn't have any errors, right?)
> If you want to do that, you need to add this:
>
> iptables -F -t nat
Yah. For completeness:
# 'filter' table (default)
iptables -F # flush all rules from all chains
iptables -X # delete any user-defined chains
# 'nat' table
iptables -t nat -F # flush all rules from all chains
iptables -t nat -X # delete any user-defined chains
> This is probably not a big deal for most people, but IIRC if you don't do
> this, AND you use this script to restart your firewall, you'll end up with
> multiple entries in your nat chain which do the same thing.
You again remember correctly. :)
> It included rules which used IP addresses, which might change based on
> DHCP (i.e. the external interface IP served via AT&T's DHCP server), and
> it re-ran hourly to fix problems associated with IP address changes.
FWIW, it should also be possible to have the firewall fix-up script invoked
automatically when the "dhcpcd" daemon sees the new IP address. It is
supposed to be able to invoke an external program when that happens. I've
never tried it, though.
--
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind. |
More information about the gnhlug-discuss
mailing list