NAT'ing firewall - Share your broadband connection
From ArchWiki
Article summary |
---|
Provides instructions on seting up router using iptables on a Arch Linux computer. |
Related articles |
iptables |
Firewalls |
This document is a tutorial and reference for turning a computer into an Internet gateway. This tutorial will explain how to set iptables to use NAT, allowing you to share a single broadband connection with an entire LAN.
This article is focused on security, since the gateway is connected directly to the Internet. It shouldn't run any services available to the outside world. Towards the LAN, it should only run gateway specific services. It should not run HTTPd, FTPd, Samba, NFSd, etc. those belong on a server on the LAN or DMZ (if you want to make these services available to the outside world) as they can introduce security flaws.
This document is it not suited to set up a shared connection between 2 PCs using cross-over cables. At the conclusion of this tutorial, the server will not be usable as a desktop computer for normal use. If you are looking for a solution to share internet using a desktop computer, see Internet share.
Contents |
Considerations
This tutorial will set up the gateway to include:
- DHCP server: allowing dynamic IP configuration of connected machines.
- Remote Administration: the gateway will work as a headless machine, allowing administration from other computers using ssh
- Firewall: to greatly increase security of the network.
- Intrusion Detection and Prevention (to do): countermeasures against attacks on the network
- Caching DNS server: a useful contingency service, for when your ISP's DNS server is temporarily down
- Transparent Caching Web Proxy: the gateway will act as a proxy server, caching frequently used websites (increasing speed and reducing your internet traffic)
- Ad Blocking: the gateway will block (static and dynamic) ads. Pop ups will be empty, and the ads won't be downloaded (decreasing traffic and increasing speed)
- Traffic Shaping / QoS: the gateway will ensure fair use of the internet connection, preventing one application from using all the available bandwidth.
- NTPd: the gateway will run a time server, allowing computers on the LAN to sync their system clock.
- Dial-up Support: if you have an xDSL-connection, you'll be able to share it
Requirements
Requirements for a gateway are:
- At least 64 MB of RAM: routing shouldn't be an intensive job; however, more is better of course.
- At least 1 GB of hard drive space. The base install will take up around 500MB of space and if you want to use a caching web proxy, you will need to reserve space for the cache as well.
- At least two physical network interfaces: a gateway connects two networks with each other. You will need to be able to connect those networks to the same physical computer. One interface must connect to the external network, while the other connects to the internal network.
- A hub, switch or UTP cable: You need a way to connect the other computers to the gateway
- (Arch) Linux experience: if the phrase "compile your own kernel" scares you, you might be better off using a distribution designed specifically for routing.
Conventions
Conventions in this guide will be to use non-realistic interface names, to avoid confusion about which interface is which. You will need to determine the names of the interfaces that you are using.
- intern0: the network card connected to the LAN. On an actual computer it will probably have the name eth0, eth1, etc.
- extern1: the network card connected to the external network (or WAN). It will probably have the name eth0, eth1, etc.
Installation
A fresh install of Arch Linux is the easiest to start from, as no configuration changes have been made. This is helpful when attempting to reduce security risk. Make only the configuration changes mentioned here, any other changes can result in security leaks.
After installation boot Arch and upgrade all the packages to their latest version:
# pacman -Syu
Install sudo:
# pacman -S sudo
Now, add a normal user. Be sure to add the user to the wheel group. This will allow the user to use sudo. Logging in as root is unsafe, it is much better to use sudo. Also, we will disable root login on OpenSSH for increased security.
Now that the base Arch Linux installation has been performed, it is necessary to remove as many packages as possible. Since we are making a gateway, keeping unneeded packages only "bloats" the system, and increases the number of security risks on the system.
Have pacman print a list of orphaned packages (packages without dependencies, i.e. packages that can safely be removed without breaking other packages):
# pacman -Qe | less
Make sure you only remove packages you won't need: if you're going to hook up your gateway to an ADSL-modem, you'd better not removed rp-pppoe or ppp. If you're not sure what a package does, simply read its description:
# pacman -Qi rp-pppoe
Here's a list of packages suitable for removal. Review every package to see if you can safely remove or not!
- hwd: If you know what hardware you have
- lshwd: a dependency of hwd
- usbutils: If you do not want to use USB devices, this can be removed.
- libusb: dependency of usbutils
- devfsd: We will be using udev, devfsd is deprecated anyway.
- mkinitrd: unless you are going to use a ramdisk with your kernel, there's no need for this.
- pcmciautils: only useful if you're using PCMCIA/CardBus hardware.
- grub / lilo: you can only use one, so remove the other one.
- nano / vim: Install your favorite editor and get rid of the rest.
- raidtools: Is only useful if you're running RAID.
- e2fsprogs / jfsutils / reiserfsprogs / xfsprogs: You only need the packages for the filesystems you are using.
- wireless_tools: Are only useful if you're going to build a wireless gateway
Completely remove the packages you don't need:
# pacman -Rscn package1 package2 package3
Remote administration: OpenSSH
This section will allow you to remotely administer your gateway. After this step, it should be possible to remove the monitor and keyboard of your gateway. Make sure that the network and power remain connected and that the gateway remains on.
To install and configure OpenSSH, see SSH. Make sure that sshd only uses protocol 2 and that root login is disabled.
NIC configuration
Setting the aliases
When you let udev handle loading the modules, you'll notice your NIC's switch names: one boot your LAN NIC is eth0, the other boot it's eth1. The easiest fix for this is to load the modules "manually". Edit /etc/rc.conf and make put in these lines:
MOD_AUTOLOAD="no" MODULES=(3c59x tulip)
Those are the modules for my NIC's. Change them to the ones you need. 3c59x is loaded first, so my 3com NIC will be eth0, and my DEC NIC will be eth1.
I don't know how long this quick and easy fix will work, if you want to do it the udev way, check out this Wiki page.
IP configuration
Open /etc/rc.conf once more and scroll down to the network config section. Here's where you define how your network cards should obtain their IP. The LAN card will have a static IP, I'm going with 10.0.0.1 because it's easy to type. :D I'm building a gateway for a small student home with 4 rooms so I'm keeping the subnet fairly small: 4 bits allow 16 IP's.
16 - 3 IP's:
- one for the network address: 10.0.0.0
- the gateway: 10.0.0.1
- and the broadcast address: 10.0.0.15 leaves 13 IP's for computers on the LAN. This translates into:
lo="lo 127.0.0.1" intern1="eth0 10.0.0.1 netmask 255.255.255.240 broadcast 10.0.0.15" extern0="dhcp"
ADSL connection: rp-pppoe
Using rp-pppoe, we can connect an ADSL modem to the eth1 of the firewall and have Arch manage the connection. Make sure you put the modem in bridged mode though, otherwise the modem will act as a router too.
# pacman -S rp-pppoe
Configuration: rp-pppoe
/usr/sbin/pppoe-setup
The questions are all documented. You can select "no firewall" because we'll let Shorewall / iptables handle that part.
There's a bug in the package, so we need to manually create a symbolic link:
ln -s /usr/sbin/pppd /sbin/pppd
Everything should be in place.
/etc/rc.d/adsl start
DNS and DHCP: dnsmasq
We'll use dnsmasq, a DNS and DHCP daemon for the LAN. It was specifically designed for small sites. As an alternative, you could also use dhcpd and bind, but you're on your own.
First, install dnsmasq:
# pacman -S dnsmasq
Now, dnsmasq needs to be configured. To do this:
Edit /etc/dnsmasq.conf and add the following lines
interface=intern1 # make dnsmasq listen for requests only on intern1 (our LAN) expand-hosts # add a domain to simple hostnames in /etc/hosts domain=foo.bar # allow fully qualified domain names for DHCP hosts (needed when # "expand-hosts" is used) dhcp-range=10.0.0.2,10.0.0.14,255.255.255.240,1h # defines a DHCP-range for the LAN: # from 10.0.0.2 to .14 with a subnet mask of 255.255.255.240 and a # DHCP lease of 1 hour (change to your own preferences)
Somewhere below, you'll notice you can also add "static" DHCP leases, i.e. assign an IP-address to the MAC-address of a computer on the LAN. This way, whenever the computer requests a new lease, it'll get the same IP. That's very useful for network servers with a DNS record. You can also deny certain MAC's from getting an IP. Evil!! ^_^ Now start dnsmasq
# /etc/rc.d/dnsmasq start
and add the daemon to the DAEMONS list in /etc/rc.conf.
I initially had trouble getting dnsmasq to start. If you get an "could not create leases: no such file or directory" error or something similar, create a few directories (they're mentioned in dnsmasq's man page)
mkdir -p /var/db mkdir -p /var/lib/misc
and try starting dnsmasq again. It should work nicely from now on.
Connection sharing
iptables
Time to tie the two network interfaces to each other.
# pacman -S iptables
iptables is a very powerful firewall. So powerful that I haven't bothered reading up on all the types of rules it can use to filter network traffic. However, this HOWTO describes an iptables setup that you can use if you don't want to use shorewall.
Shorewall
Instead, I opted for an equally powerful frontend, Shorewall. It's in the Community repo, so be sure to enable [community] in /etc/pacman.conf
# pacman -S shorewall
Shorewall configuration
Time to configure Shorewall! Open its config file in /etc/shorewall/shorewall.conf and start editing. The file is very well documented.
SUBSYSLOCK=/var/run IP_FORWARDING=On : it's a gateway, remember! ;) STARTUP_ENABLED=Yes # when you're done editing
After installing shorewall, run
$ pacman -Ql shorewall | grep Sample
to see where the sample files are. cd into the directory "two-interfaces" and copy the contents to the /etc/shorewall/ directory. Now use Shorewall's guide to set up the files correctly.
Read the document carefully. Take special care to change eth0 and eth1 (or ppp0 in if you're using PPPoE where appropriate in your config files as the Shorewall guide uses different names for the interfaces. When you've followed it thoroughly, make the following changes:
- /etc/shorewall/interfaces : add "dhcp" to the loc line to allow computers on the LAN to make use of our DHCP server
- /etc/shorewall/rules : add
ACCEPT loc $FW TCP 2367
but change 2367 into whatever port you have your SSH server listening on.
Finally, run
# /etc/rc.d/shorewall start
From here on, the Arch box is operational. Connect a hub or switch to eth0 and a computer to the LAN to test it.
--Add a script to open up ports on the firewall to run pacman.--
Port forwarding (DNAT)
- /etc/shorewall/rules : here's an example for a webserver on our LAN with IP 10.0.0.85. You can reach it on port 5000 of our "external" IP.
DNAT net loc:10.0.0.85:80 tcp 5000
Intrusion detection & prevention: Snort
According to the site's homepage title, Snort is "the de facto standard for intrusion detection/prevention". Sounds good. Let's use this one!
# pacman -S snort
Snort configuration
The main configuration file is /etc/snort/snort.conf.
Read it carefully, as usual it's very well documented.
var HOME_NET 10.0.0.0/28 # Change to the subnet of your LAN. var EXTERNAL_NET !$HOME_NET var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET # Comment these if you're not running any servers on the LAN. var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var HTTP_PORTS 80 var SHELLCODE_PORTS !80 var ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/ 24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24] var RULE_PATH /etc/snort/rules var HTTP_PORTS 80:5000 # For HTTPd's running on port 80 and 5000. Change appropriately # to the ports you are using on your LAN. config detection: search-method lowmem # If you're using a machine "with very limited resources".
At the bottom of the file, there's a list of includes. These define which rules you want to enforce. (Un)comment as you please. You should check that the corresponding file exists, as for me, none of the rules files were present.
groupadd snort mkdir -p /var/log/snort useradd -g snort -d /var/log/snort snort chown -R snort:snort /var/log/snort
Edit /etc/conf.d/snort:
SNORT_ARGS="-u snort -g snort -l /var/log/snort -K ascii -c /etc/snort/snort.conf -D -h 10.0.0.0/28 -A full
Replace 10.0.0.0/28 with the CIDR of your LAN.
Now Snort will run as user snort in group snort. Should improve security. The other options make it log to /var/log/snort in ASCII mode. Run snort -h to see other available options.
I've been running my router for 12 days now, and using the above snort options, I had around 120MB of logs! So I changed the -A switch to "-A none". This only logs alerts. I didn't know what to do with all the logs anyway.
Update the rules: Oinkmaster
If you want to be able to download Snort's latest rules, you'll need a subscription. This costs money. If you're happy enough with 5 days old rules, you just need to register for free. If you don't, the only updates you'll get are the new rules distributed with a new Snort release. Go ahead and register at Snort. If you really don't want to register, you can use the rules from BleedingSnort.com. They're bleeding edge, meaning they haven't been tested thoroughly.
A user has created a PKGBUILD for oinkmaster.
Oinkmaster setup
Edit /etc/oinkmaster.conf and look for the URL section and uncomment the 2.4 line. Make sure to replace <oinkcode> by the Oink code you generated after logging into your Snort account. For Bleeding Snort rules, uncomment the appropriate line.
When you log into your new account, create an "Oink code". Another thing to change is
use_external_bins===1 # 1 uses wget, tar, gzip instead of Perl modules
The rest of the config file is fine.
Oinkmaster usage
oinkmaster.pl -o /etc/snort/rules
Create an executable script with the exact command and place it in /etc/cron.daily to update the rules daily automatically.
Finishing touches
Daemon list
Ordered list of daemons you need to enable:
- iptables or shorewall to configure iptables, traffic shaping, etc. Don't add iptables and shorewall to the list
- dnsmasq
- adsl if sharing an ADSL connection
- sshd
- snort
"Lock" configuration files
It is important to add every config file edited in the process to the 'NoUpgrade' array. This will prevent pacman from overwriting them when there's a new version of the package available:
# OpenSSH NoUpgrade = etc/hosts.allow etc/ssh/sshd_config # rp-pppoe NoUpgrade = etc/ppp/pap-secrets etc/ppp/pppoe.conf # dnsmasq NoUpgrade = etc/dnsmasq.conf # iptables NoUpgrade = etc/conf.d/iptables # Snort NoUpgrade = etc/snort/snort.conf etc/conf.d/snort # Shorewall NoUpgrade = etc/shorewall/interface etc/shorewall/masq etc/shorewall/policy NoUpgrade = etc/shorewall/outestopped etc/shorewall/rules etc/shorewall/shorewall.conf NoUpgrade = etc/shorewall/zones
Final clean up
Review the list of packages without dependencies and decide which ones can be removed.
$ pacman -Qe
Advanced features
Read NAT'ing firewall - Adding advanced features if you feel like it. It's completely optional, though.