this webby may solve some problems of yours. (i'm settin up a vmware router , so i'm sourcing out some 'how-to's as well)
Credits to this person who set up this website of this router set up: http://www.stanford.edu/~fenn/linux , thanks alot for continuin the spirit of open source.
Linux gateway/router - (another) HOWTO
Fri Jun 4 10:51:28 PDT 2004
(Update dhcpd.conf, named.conf, fix daemon load order)
Quick jump:
* Intro
* Hardware/prior necessities
* Network block selection
* Summary
* Configuring port forwarding
* Firewall config
* DHCPD setup
* BIND setup
* Enabling the firewall
* Epilogue
* future development: WAP setup (when I get a wireless card)
* suggest additional howtos
Intro
A hot item on the market nowadays is the "all-in-one" router+WAP+switch. This allows one to split a net connection across a number of computers. However, I've used these with less than successful results (router would inexplicibly drop connections at periodic intervals), and thusly now use a Linux box as my gateway to the internet. Not only can it do the router/WAP/switch combo, but (typically) for less cost and with far greater usability, as the gateway can also be used as a file server, print server, DNS server, NIS server, web server, mail server, SSH server, etc, etc. This web page is to help those who would like to set up a configuration that will allow for this, plus get a firewall up to keep it secure. The information here is pretty much general for any DHCP based ethernet connection to the internet (e.g. cable modems, most DSL services, etc.).
Hardware/prior necessities
Here are a few things I'm assuming before we get started:
* Cheapo/free linux box (hint: hang around near/in dumpsters.)
* 2 ethernet cards in linux box (Make sure one matches the duplex settings on the LAN cards to avoid potential problems, use mii-tool to check this)
* hub or switch of some kind (I scored a netgear FS108 for 20 bucks, ebay style)
* Fedora Core 1/2 install, or at least DHCP distribution (dhclient/dhcpd) and netfilter (aka iptables) available
* eth0 is the exterior (internet) interface, eth1 is the interior (LAN) interface
* eth0 is configured (via dhclient) and linux box can access internet
Network block selection
The computers on your LAN will need to be assigned IP addresses, so thats the first thing: pick a block of reserved addresses for private address space. As per the IANA standards set forth (see here, RFC1918, or RFC3330), this means you can use anything in the blocks:
* 10.0.0.0/8 (class A)
* 172.16.0.0/12 (class
* 192.168.0.0/16 (class C)
as you can see from the masks, each one has a decreasing number of allotable addresses. So unless you have over 64,000 computers at home, go with the 192.168 block. I use a single class C network (network 3), and thusly use 192.168.3.x below.
Summary
Here's a summary of the necessary files you'll want to edit:
* /etc/sysctl.conf
* /etc/dhclient-exit-hooks
* /etc/dhclient-eth0.conf
* /etc/dhcpd.conf
* /var/named/chroot/etc/named.conf
* /var/named/chroot/var/named/192.168.3.db
* /var/named/chroot/var/named/ventura.c.db
Note: you MUST *at least* edit the following:
dhcpd.conf:
option domain-name-servers 192.168.3.1, ns2.yourisp.com,
ns3.yourisp.com;
named.conf:
forwarders{
ns1.yourisp.com;
ns2.yourisp.com;
};
192.168.3.db:
NS ns2.yourisp.com.
ventura.c.db:
NS ns2.yourisp.com.
put in values for any additional backup nameservers (e.g. those provided by your ISP) in the above lines!!! (Remember: redundancy good)
here are the rpms you'll probably need:
* dhclient
* dhcp
* bind
* bind-utils
* bind-chroot
remember: FC1/2 is yum-friendly, so its a simple one liner to install the necessary goods:
$ yum install dhclient dhcp bind bind-utils bind-chroot
Configure linux for port forwarding
Now we need to enable packet forwarding on the kernel level (more on what the hell this means later). Edit your /etc/sysctl.conf so it contains the following:
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
Since most people have dynamic IP's, you'll probably also want:
# Enable dynamic-ip address hacking
net.ipv4.ip_dynaddr = 1
For other potentially worthwhile settings, you can check out my whole sysctl.conf file.
Now set the eth1 interface up, which we'll manually assign as 192.168.3.1 on our internal network. This is done by editing /etc/sysconfig/network-scripts/ifcfg-eth1 like so:
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
# (put your correct value below)
HWADDR=XX:XX:XX:XX:XX:XX
IPADDR=192.168.3.1
Firewall configuration
Now for my favorite part. Before we bring up eth1, we'll want to protect our internal LAN. Further, we've only told the linux kernel to allow packet forwarding. It won't actually do so until we provide it with some configuration parameters. Enter iptables, the userspace command to interface with the kernel firewalling subsystem. The concept is a simple one: filter packets as they arrive via eth0 and perform NAT (network address translation) for the LAN.
Most stock linux installs (nowadays) include a pre-configured and already running configuration of iptables. However, the Redhat/Fedora stock scripts aren't dynamic - i.e. we can't change certain parameters that may be set/unset during the DHCP lease negotiation process for our IP, or do so in a device-dependent manner. For example, I like to set my firewall to block reserved IP addresses (like those discussed above for internal networks), but sometimes my DHCP server is on a specific reserved address - which most likely is unknown before acquiring an IP or may likely change at some point. Also, I like to block my *own* IP address from trying to connect to my gateway - just as an extra precaution, but again is unknown information before the IP has actually been assigned. The one handy feature of dhclient (the DHCP client keeping track of your IP lease) is that it can run scripts at various parts of the lease negotiation process and provide all kinds of handy variables (like the assigned IP address or DHCP server). The punchline is, I ditch the the builtin iptables service in Fedora:
$ service network stop # (since we don't want our network up until we reconfigure iptables)
$ chkconfig --levels 2345 iptables off
$ service iptables stop
And, as per the manpage of dhclient, provide a /etc/dhclient-exit-hooks script. This script will be executed during all stages of the lease negotiation process (which is extra useful, since a firewall will be established *before* an IP is assigned), and even provide information as to which stage the process is at. (The script should be executable, of course.)
Now to rundown the various parts of the script, since its the main part of setting up and understanding the gateway.
#!/bin/sh
# firewall.mules - created by levy.pl on Mon Sep 10 11:35:04 2001
# this is a -skeleton- ruleset-- adapt as needed.
This script is derived from the neato perl script levy, available here.
# setup response based on dhclient input
logger -t iptables reason: ${reason}
if [ "x${reason}" = "xBOUND" -o "x${reason}" = "xREBIND" ]; then
staticaddr=${new_ip_address}/32
dhcpgate=${new_dhcp_server_identifier}
elif [ "x${reason}" = "xRENEW" -o "x${reason}" = "xREBOOT" ]; then
if [ "x${new_ip_address}" != "x${old_ip_address}" -o \
"x${new_dhcp_server_identifier}" != "x${old_dhcp_server_identifier}" ]; then
staticaddr=${new_ip_address}/32
dhcpgate=$new_dhcp_server_identifier
else
# don't want to _always_ run this script
exit 0
fi
else
staticaddr=
dhcpgate=
fi
logger -t iptables IP is ${staticaddr}
logger -t iptables DHCP gateway is ${dhcpgate}
This set of shell code interprets the dhclient call and determines if anything needs to be done. For example, if we're just renewing our lease and the IP and DHCP server are the same, then there's no point in re-running the rest of the script. The logger -t stuff logs the important information, which probably ends up in /var/log/messages.
# other definitions
IFext="eth0"
IFint="eth1"
lannet="192.168.3.0/16"
logger -t iptables Setting default policies
# chain policies
# drop everything and open stuff as necessary
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
logger -t iptables Flushing tables
/sbin/iptables -F
/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F -t mangle
/sbin/iptables -F -t nat
/sbin/iptables -X
/sbin/iptables -Z
This chunk of the script initializes some variables (they should be relatively self-explanatory), sets the default policies to DROP (i.e. drop all packets) and cleans out any existing rules.
logger -t iptables Creating user tables + rules
# create DUMP table
/sbin/iptables -N DUMP
/sbin/iptables -F DUMP
# limited logs
/sbin/iptables -A DUMP -p icmp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT ICMPDUMP: "
/sbin/iptables -A DUMP -p tcp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT TCPDUMP: "
/sbin/iptables -A DUMP -p udp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT UDPDUMP: "
/sbin/iptables -A DUMP -p tcp -j REJECT --reject-with tcp-reset
/sbin/iptables -A DUMP -p udp -j REJECT --reject-with--icmp-port-unreachable
/sbin/iptables -A DUMP -j DROP
Now to create (-N to create, -F to flush) and setup the DUMP table, which is where packets will be sent if they get dropped. First the packet is logged (up to a limit) based on the type of packet (icmp, tcp or udp) and a return packet is sent to indicate the error to the violating host. Finally, the packet is dropped.
# Stateful table
/sbin/iptables -N STATEFUL
/sbin/iptables -F STATEFUL
/sbin/iptables -I STATEFUL -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A STATEFUL -m state --state NEW -i ! ${IFext} -j ACCEPT
/sbin/iptables -A STATEFUL -j DUMP
This second table will be used to make sure connections are allowed based on the state of the connection (thusly, a stateful table), and also shows off some of the power of iptables and the linux kernel firewalling code. We can use this table to allow connections *only* of if the connection has already been established (ESTABLISHED) or is associated with a connection that has already been started (RELATED) or is a new connection coming from an interface other than the external interface. Therefore, connections can only be initiated from *inside* the LAN. Otherwise, they're sent to the DUMP table we made above.
# SYN protection table
/sbin/iptables -N SYN-FLOOD
/sbin/iptables -F SYN-FLOOD
/sbin/iptables -A SYN-FLOOD -m limit --limit 1/s --limit-burst 4 -j RETURN
/sbin/iptables -A SYN-FLOOD -j DROP
/sbin/iptables -A INPUT -i ${IFext} -p tcp --syn -j SYN-FLOOD
/sbin/iptables -A INPUT -p tcp -i ${IFext} ! --syn -m state --state NEW -j DROP
# watch out for fragments
/sbin/iptables -A INPUT -i ${IFext} -f -j LOG --log-prefix "IPT FRAGMENTS: "
/sbin/iptables -A INPUT -i ${IFext} -f -j DROP
Now to set up some tables to attempt avoiding SYN-floods and fragmented packets, both of which are Bad. The syn-flood table allows us to only accept 4 connections per second. If the packet falls under the limit, the -j RETURN flag allows it to "jump" back to the call to this chain. Otherwise, start dropping packets - don't even send them to the DUMP table.
The next two lines either call the SYN-FLOOD table if the SYN flag is set (jumping back to this rule and continuing if its under the connection attempt limit), or dump the packet if its a new connection and the SYN flag *isn't* set (note the ! --syn -m state --state NEW statement). The final two lines drop any fragmented packets (-f), caused by missing parts of the TCP/IP header.
logger -t iptables Setting input/output rules
# allow loopback in
/sbin/iptables -A INPUT -i lo -j ACCEPT
# allow loopback and LAN out
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A OUTPUT -p ALL -s ${lannet} -j ACCEPT
# don't allow our own IP *in*
if [ "x${staticaddr}" != "x" ] ; then
/sbin/iptables -A INPUT -p ALL -s ${staticaddr} -j DUMP
fi
Now to start letting connections in. Anything coming in or out on the loopback interface is certainly OK. We also trust anything going out from the LAN. Finally, we block any packets claiming to be from our own IP address (if defined), which is nonsense.
logger -t iptables Setting ISP specific rules
# needs to be defined before reserved addresses,
# since our ISP typically uses a reserved address for a DHCP server (sigh)
if [ "x${dhcpgate}" != "x" ] ; then
/sbin/iptables -A INPUT -i ${IFext} -s ${dhcpgate} -j ACCEPT
fi
This is something you may not need, but be sure to check. I had to add this rule to prevent my ISP from being blocked by my firewall. Quite simply, the DHCP server was given a reserved address. In order to let it in, we have to explicitly declare it before blocking all the reserved addresses (see below). That way, this rule is matched first by the packet and the connection is allowed. Again, we only set this rule up if the DHCP server is defined by the script.
logger -t iptables Preventing reserved addresses
# drop reserved addresses incoming as per IANA listing
/sbin/iptables -A INPUT -i ${IFext} -s 0.0.0.0/8 -j DUMP
<snip>
/sbin/iptables -A INPUT -i ${IFext} -s 240.0.0.0/8 -j DUMP
This is pretty self explanatory. Just dump any connection purporting to be from a reserved IP address. You may want to remove this block of rules, but I try to be extra-cautious.
logger -t iptables Setting ICMP rules
# allow certain inbound ICMP types
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type echo-reply -j ACCEPT
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type destination-unreachable -j ACCEPT
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type source-quench -j ACCEPT
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type echo-request -j ACCEPT
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type time-exceeded -j ACCEPT
/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type parameter-problem -j ACCEPT
Now to set up protocol specific rules. We'll allow certain ICMP connections which tend to be used for critical network functions. Filtering some of this stuff may screw up your connection. However, you may need to change these for your specific settings.
logger -t iptables Setting TCP/UDP rules
# opened ports
/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport ssh -j ACCEPT
/sbin/iptables -A INPUT -p udp -i ${IFext} --dport ssh -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport sftp -j ACCEPT
/sbin/iptables -A INPUT -p udp -i ${IFext} --dport sftp -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i ${IFext} --sport bootps --dport bootpc -j ACCEPT
/sbin/iptables -A INPUT -p udp -i ${IFext} --sport bootps --dport bootpc -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport auth -j ACCEPT
/sbin/iptables -A INPUT -p udp -i ${IFext} --dport auth -j ACCEPT
# accept all other public ports
/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport 1024: -j ACCEPT
/sbin/iptables -A INPUT -p udp -i ${IFext} --dport 33434: -j ACCEPT
Next is TCP/UDP - I allow in SSH, authorization requests via INETD, and requests from bootp servers to the bootp client (which we'll need to get our IP lease). Also, public port connections are allowed. You'll probably want to change these settings, depending on which services you want available from outside the LAN. Of course, one should always keep in mind the terms of service (TOS) set forth by your ISP (which most likely won't appreciate nor allow web servers, for example).
logger -t iptables Turning on NAT
# masquerade from internal network
/sbin/iptables -t nat -A POSTROUTING -s ${lannet} -o ${IFext} -j MASQUERADE
This single line is the _real_ reason we called this script - to get NAT up and running. Anything coming from the LAN that is destined for the internet is masqueraded as coming from IFext before being sent out (i.e. postrouting). All in one line. Damnit, I love iptables.
logger -t iptables Finish up
# push everything else to state table
/sbin/iptables -A INPUT -j STATEFUL
/sbin/iptables -A FORWARD -j STATEFUL
/sbin/iptables -A OUTPUT -j STATEFUL
Finally, anything else we haven't covered is pushed to the STATEFUL table we made above.
Also of interest in regards to iptables is port forwarding, which is a cinch to do. There are some commented out lines in the provided script that should help getting started with this if you need it.
There are some helper modules associated with iptables that can be used for protocols that require a second connection of some sort (e.g. a UDP and a TCP connection), such as FTP or IRC. To get these modules to load with iptables, add the following to /etc/modules.conf:
add above ip_conntrack ip_conntrack_ftp ip_conntrack_irc
add above iptable_nat ip_nat_ftp ip_conntrack_ftp ip_nat_irc ip_conntrack_irc
to find other modules, look in /lib/modules/<kernel_version>/kernel/net/ipv4/netfilter
Assigning IPs to the LAN
DHCPD
The next step is to assign IP addresses to each machine on the LAN. A simple way to do this is just setup aliases in the /etc/hosts file of all the machines, but thats slightly time consuming depending on the size of the network. I prefer using a DHCP server, which comes with the dhclient package from ISC, but is packaged separately by RedHat/Fedora. Setting it up is a cinch - just download my dhcpd.conf file. Some more salient points of this file:
* ddns-update-style interim: Dynamic DNS is employed, which additionally requires the BIND package. This further allows us to simply use the gateway as a nameserver for all the LAN machines.
* deny client-updates: Clients don't provide DNS updates, the server will take care of it (more on this below).
* ddns-domainname "ventura.c": In order to assign names, a "fake" top-level domain is used (the ".c" in ventura.c) - this is to avoid conflicts with any real TLD's. So, any client will have the FQDN of ".ventura.c". Of course, you can set this to whatever you'd like - just be sure to be consistent throughout.
* option domain-name-servers 192.168.3.1, ns1.yourisp.com, ns2.yourisp.com: This sets the name servers to send to the clients - be sure to change these values to suit your ISP (or, if you'd rather, just rely on the internal nameserver configured below).
* range 192.168.3.10 192.168.3.100: Clients will be assigned addresses in the 192.168.3.(10-100) range.
ddns-hostname = pick (option fqdn.hostname, option host-name,
concat ("dhcp-",
binary-to-ascii (10, 8, "-", leased-address)));
option host-name = config-option server.ddns-hostname;
* These two entries will allow the client to either specify a host name or be given one by the dhcp server in the form "dhcp-192-168-3-98.ventura.c" if a host name isn't requested. You can tweak this to your needs.
include "/etc/rndc.key";
zone ventura.c. {
primary 127.0.0.1;
key rndckey;
}
zone 3.168.192.in-addr.arpa. {
primary 127.0.0.1;
key rndckey;
}
* This chunk allows the DHCP server to update the nameserver using an HMAC-MD5 encoded key (more info below). The /etc/rndc.key comes with the Fedora install, so you don't need to generate one, unless you'd like to, of course. This will be handy in that clients can dictate their hostname, and the nameserver will append the domain name. So if a client requests the hostname "foo", it will have a FQDN on the LAN of foo.ventura.c without having to manually muck with the nameserver.
You'll probably want to change some of these settings (lease time, domain name, etc), but note this will affect the nameserver configuration as well.
One thing to keep in mind is dhcpd should only be visible from our LAN interface (eth1 in our examples so far). This is easy to do with the dhcpd command line switch "eth1". However, since we want dhcpd to start every time we boot the gateway, we'll need to add the flag to the Fedora start up script. This is specified in /etc/sysconfig/dhcpd, like so:
DHCPDARGS=eth1
Finally, we need to tell Fedora to turn on dhcpd at boot time:
$ chkconfig --levels 345 dhcpd on
BIND
Ok, now lets configure the nameserver so it will work for all the LAN machines as well as store all the dynamic names (thanks to our DHCP server). First is the named.conf file, which I like to have set up in a chrooted jail under /var/named/chroot (this is conveniently included as part of the bind-chroot package). I'll just highlight the important parts:
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
forwarders{
ns1.yourisp.com;
ns2.yourisp.com;
};
allow-transfer{
none;
};
allow-query {
192.168.3/24;
localhost;
};
listen-on {
127.0.0.1;
192.168.3.1;
};
};
These options set up the nameserver to listen on and allow queries from the LAN. They also set up some "backup" nameservers (the "forwarders", configure these to your settings) but do *not* allow zone transfers, which we don't need (and if we did, we could override this setting on a zone basis anyway).
zone "ventura.c" IN {
type master;
file "ventura.c.db";
allow-update { localhost; key rndckey; };
};
zone "3.168.192.in-addr.arpa" in {
type master;
file "192.168.3.db";
allow-update { localhost; key rndckey; };
};
include "/etc/rndc.key";
This sets up both the forward and reverse master zones for our LAN, and specifies the files to use to configure those zones (detailed below). It also allows either the localhost or a key validated server to update those zones, which is important given our DHCPD setup. Note the keys match for both daemons.
logging {
category dnssec { security_log; };
category update { security_log; };
category security { security_log; };
channel security_log {
file "dns_security.log" versions 4 size 10m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
};
This last bit sets up some additional logging from named, but you can remove this part if you'd like.
Here's the skeleton ventura.c.db and 192.168.3.db files, which only defines the nameserver (192.168.3.1 in our case) and any aliases you'd like for it. Be sure to change any of the lines labelled "ns2.yourisp.com" to match additional nameservers available for your clients. (If you'd like to understand the specifics of these files, check out the BIND ARM or get a copy of O'Reilly's DNS and BIND, both of which are great resources for everything you'll want to know about DNS and the configuration files provided here.)
Upon assigning IPs, the DHCP server will update these files periodically for you - you'll know its working if you see .jnl files, which correspond to zone journal files from any updates.
Now that we have the nameserver configured, its important to make sure the linux box knows to use it. The list of nameservers (in order of preference) is contained in /etc/resolv.conf. dhclient generates this file, and can be told to prepend nameservers and domain names for resolving by editing /etc/dhclient-eth0.conf as such:
# NOTE: the space at the end "ventura.c " is significant!!!
prepend domain-name "ventura.c ";
prepend domain-name-servers 127.0.0.1;
So our homemade nameserver is queried first, with our fake domain name appended to any host name query.
Now to enable the named service at boot time:
$ chkconfig --levels 345 named on
Enabling the firewall
Ok, now to light this candle either type in the following or reboot the machine:
$ sysctl
$ service network start
$ service named start
$ service dhcpd start
(Its important to start named first, so its ready to receive name requests from the dhcp daemon) Check for errors in /var/log/messages. If none, setup the LAN machines to configure using DHCP. Reboot the LAN network interfaces, and watch the fun!!! To check things out, take a look at the logged packets in /var/log/messages under the subtext "IPT (TCP|UDP|ICMP)DUMP:", which might look something like this:
Jan 16 23:32:36 localhost kernel: IPT TCPDUMP: IN=eth0 OUT= MAC=xx SRC=xx DST=xx LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=39764 DF PROTO=TCP SPT=3415 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Aha! someone (my isp server in this case, but I've blocked stuff out to protect the innocent) is attempting to make a TCP connection (note the SYN flag is set) on port 80 (DPT=80), which is typically where web servers reside. Since we didn't open up a hole on port 80 (nor do we allow new connections from eth0), this packet passes through the stateful table and ends up being dropped.
To further check the firewall, there are several options. The file /proc/net/ip_conntrack shows all current, active connections. To view all the tables rules, try the following script:
#!/bin/sh
tables=$(cat /proc/net/ip_tables_names 2>/dev/null)
for i in $tables ; do
echo table $i
iptables -t $i -L
echo
done
which will show all the current rules and gory details. Further, Fedora has the logwatch analyzer running by default, so expect mailings in the root inbox detailing daily activities involving iptables (run as part of the kernel services script).
