Fullscreen HTML5Med Res (??MB)HTML4

COMPUTERS: masquerading modules & a firewall Using Linux to Share an Optus Cable Modem Internet Con­nection Pt.3: masquerading modules & a fire­wall In this article, we show you how to load various modules that are required for effective Internet access, along with a simple yet effective firewall. We also tell you what you need to do to connect a cable modem to Telstra Bigpond Advance instead of to Optus CableNet. By JOHN BAGSTER In order to effectively use your Linux box as a gateway, you need to set the machine up so that it loads some “masquerad­ing modules” on start-up. In addition, you need to set up a firewall so everything is secure. After all, you don’t want someone break­ing in and taking over! We’ll get to our firewall shortly. Let’s deal with the masquerading modules first. The various masquerading modules are required so that the gateway correctly forwards IP packets for various Internet utili­ties on the client machines. Basically, these modules work with IP masquerading (or IP forwarding) so that it looks as though everything that’s forwarded to the Internet is coming from a single machine – ie, the Linux box. This is done by translating IP addresses from the local network into a valid Internet IP number before relaying the packets out onto the Internet. At the same time, IP masquerading translates any incoming packets into local addresses before forwarding them to the client machines. It’s all really something of a masquerade because the real IP addresses of the clients are hidden – hence the name “IP masquerading”. IP masquerading (forwarding) is carried out using a program called “ipchains” and this is also used to create the firewall rules. Recent versions of Linux also include an updated replace­ment for ipchains called iptables (although 74  Silicon Chip ipchains is still included). The firewall described here is based on ipchains (since this is used by default with RedHat 7.0) but both are supported in system startup, so you could use iptables if you want. Note, however, that the commands for iptables are differ­ ent. The differences are well documented in manual pages if you wish to convert the firewall to iptables. Loading modules In most cases, the firewall rules and the rules to load the various module are all in one script – ie, the firewall script. However, in this case, they have been separated into two scripts so that the firewall can be enabled before networking is enabled. Note that this not only applies to a cable modem connection – it is equally applicable to a dial-up modem. There are quite a few masquerading modules for Linux, most of which are optional for audio, instant messaging, and various games, etc. Basically, you only need to load the modules that you require. This is roughly similar to selecting which options you want when you install Windows. OK, so how do we ensure that these modules are loaded at start-up? The answer is that we use a file called rc.local which RedHat Linux stores in the /etc/rc.d folder. This file is the last thing executed at start-up and you can add your own commands to it. You could put all the module loading commands diwww.siliconchip.com.au Masquerading script: /etc/rc.d/rc.modules #!/bin/bash # # rc.modules # rc.modules should be called via rc.local # Load powerswitch so Linux will shutdown neatly when switched off. # Only works with ATX power supplies. Uncomment the following line and modify to suit # #/sbin/insmod /lib/modules/3rdparty/powerswitch.o # Load all required IP masquerading modules # Uncomment the modules you need. /sbin/depmod -a # Supports the proper masquerading of FTP file transfers /sbin/modprobe ip_masq_ftp # Supports the masquerading of RealAudio over UDP. # Without this module, RealAudio WILL function but in # TCP mode. This can cause a reduction in sound quality #/sbin/modprobe ip_masq_raudio # Supports the masquerading of IRC DCC file transfers #/sbin/modprobe ip_masq_irc # Supports the masquerading of Quake and QuakeWorld. # This module is for multiple users behind a Linux gateway. # If you are going to play Quake I, II, and III, use the second one. # Quake I / QuakeWorld (ports 26000 and 27000) : #/sbin/modprobe ip_masq_quake # Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960) : #/sbin/modprobe ip_masq_quake 26000,27000,27910,27960 # Supports the masquerading of the CuSeeme video conferencing software #/sbin/modprobe ip_masq_cuseeme # Supports the masquerading of the VDO-live video conferencing software #/sbin/modprobe ip_masq_vdolive rectly into the rc.local file and that would work without problems. However, it’s far neater to have the commands in a separate file and then call this from /etc/rc.d/rc.local (we’ll show you how shortly). We’ve called this separate file rc.modules and placed it in the /etc/rc.d folder. The rc.modules file OK, let’s take a look at the /etc/rc.d/rc.modules file that you need to create. You can either download this file from the SILICON CHIP website or type it in on your Linux box using a text editor. The file is shown in the accompanying www.siliconchip.com.au panel and contains the common masquerading modules that you might need. However, most of these have been commented out by placing a “#” at the beginning of their command lines. All you have to do is “uncomment” the mod­ ules that you need by removing the relevant “#” symbols. The various lines in the rc.modules file are all self-explanatory except for the “powerswitch” line. To explain, Pow­erswitch is a nifty little utility that shuts down Linux properly (and switches the PC off) when you press the power switch on the system case – provided you have an January 2003  75 COMPUTERS: masquerading modules & a firewall Firewall rules: the cablefirewall.simple script #!/bin/bash # # cablefirewall.simple # run this to set up the rules, then run # /etc/rc.d/init.d/ipchains save # to save the rules to be used every time the machine is started # modem interface (change to suit) MODIF="eth1" # local network (change to suit) LOCNET="192.168.0.0/24" # ============================================================================= # blocking rules for the input, output, forward chains respec­tively Iblock="DENY" ; Oblock="REJECT" ; Fblock="DENY" # Flush all existing rules and remove any user defined chains /sbin/ipchains -F ; /sbin/ipchains -X # loopback and local interfaces are OK on input and output /sbin/ipchains -A input ! -i $MODIF -j ACCEPT /sbin/ipchains -A output ! -i $MODIF -j ACCEPT # set policies to block everything /sbin/ipchains -P input $Iblock /sbin/ipchains -P forward $Fblock /sbin/ipchains -P output $Oblock # masquerading timeouts /sbin/ipchains -M -S 7200 10 160 # ============================================================================= # input chain: # block and log modem interface claiming to be local network (IP spoofing) /sbin/ipchains -A input -i $MODIF -s $LOCNET -l -j $Iblock # allow return tcp packets (those not requesting a connection) /sbin/ipchains -A input -p tcp -i $MODIF ! -y -j ACCEPT # allow incoming tcp ftp-data connections (for outgoing active ftp) /sbin/ipchains -A input -p tcp —sport ftp-data —dport 1024:65535 -i $MODIF -y -j ACCEPT # allow all udp and icmp in /sbin/ipchains -A input -p udp -i $MODIF -j ACCEPT /sbin/ipchains -A input -p icmp -i $MODIF -j ACCEPT # uncomment to reject and log anything else (required since policies can’t log) # the policy is the same so leave this line commented out if you’re not logging #/sbin/ipchains -A input -l -j $Iblock # ============================================================================= # output chain: continued next page . . . 76  Silicon Chip www.siliconchip.com.au Cablefirewall.simple – continued # allow everything except local network traffic out to the modem /sbin/ipchains -A output -i $MODIF ! -s $LOCNET ! -d $LOCNET -j ACCEPT # set delay and throughput times if using a dial-up modem (ppp interface) # these are not to be used if using a network card (cable modem) if [[ $MODIF == “ppp”* ]] then # set minimum delays for p in www ssh telnet ftp pop3 smtp ; do /sbin/ipchains -A output -p tcp —dport $p -t 0x01 0x10 ; done # set ftp-data for maximum throughput /sbin/ipchains -A output -p tcp —dport ftp-data -t 0x01 0x08 fi # reject and log anything else (required since policies can’t log) # the policy is the same so comment this line out if you’re not logging /sbin/ipchains -A output -l -j $Oblock # ============================================================================= # forward chain: # Masquerade from local network to anywhere on the modem inter­face /sbin/ipchains -A forward -i $MODIF -s $LOCNET -j MASQ # all other forwarding is blocked and logged # the policy is the same so comment this line out if you’re not logging /sbin/ipchains -A forward -l -j $Fblock ATX power supply, that is. It’s just the shot if you intend operating your Linux gate­ way without a mouse, monitor or keyboard. The powerswitch module does not come with the Linux distri­bution. If you intend to use it, you can download it from http://deadlock.et.tudelft.nl/~joris/powerswitch/ and install it as described in the instructions (more on this next month). In this case, the powerswitch.o file was placed in the /lib/modules/3rdparty folder (you will have to create this). #!/bin/sh # # This script will be executed *after* all the # other init scripts. # You can put your own initialization stuff in here if # you don’t want to do the full Sys V style init stuff. Modifying rc.local Once rc.modules is set up, your Linux gateway is complete except for a firewall. The one described here offers good security while not compromising access to the Internet. It is about as simple as you can get and is easy to set up. We’ll look at how the various firewall rules operate first, then give the firewall script and describe how it works. RedHat has a start-up script called /etc/rc.d/init.d/ ipchains (not to be confused with the /sbin/ipchains program). This is run before networking starts and loads a saved set of firewall rules. Furthermore, to save a new set of rules, you simply run the firewall script and then type: You now have to modify /etc/rc.d/rc.local so that it calls the rc.modules file during start-up. The start of the rc.local file initially looks like this: #!/bin/sh # # This script will be executed *after* all the # other init scripts. # You can put your own initialisation stuff in here if # you don’t want to do the full Sys V style init stuff. if [ -f /etc/redhat-release ]; then All you have to do is edit it to add a call to the /etc/rc.d/rc.modules file, so that it looks like this: www.siliconchip.com.au /etc/rc.d/rc.modules if [ -f /etc/redhat-release ]; then Setting up a firewall /etc/rc.d/init.d/ipchains save January 2003  77 COMPUTERS: masquerading modules & a firewall Once you’ve done that, the firewall is automatically set up before any networking each time you start the Linux PC. This not only gives you full security but also saves you from having to manually modify or add any start-up scripts yourself! To reload your saved rules you can type: /etc/rc.d/init.d/ipchains start and the previously saved rules are restored! Conversely, to remove all rules, you type: /etc/rc.d/init.d/ipchains stop This flushes all rules and removes all user-defined chains, thereby disabling the firewall. However, this will leave your PC wide open to attack, so it is not recommended. On the other hand, typing /etc/rc.d/init.d/ipchains panic does the opposite – ie, it denies everything (including local network traffic). Don’t do this from a local telnet or ssh connection – if you do, you will be stuck and will have to recov­er from the console! Firewall rules The firewall consists of three basic sections, called “chains”: an input chain, an output chain and a forward chain. They can be applied to each network card in the Linux PC but all we are really concerned about here is the network card connected to the cable modem (no restrictions are usually applied to the local network card, although they could be if required). The input chain covers anything coming in from the Inter­net. This is the one that the restrictions usually apply to, as you do not have any control over who or what is trying to gain access to your PC. The output chain covers anything being sent out to the Internet. The forward chain is used to transfer packets from the input chain of your local network card to the output chain of your modem network card (ie, to send stuff from your Linux PC or one of your Windows PCs to the Internet). Anything coming back from the Internet (ie, reply packets) is simply transferred directly from the input of the modem card to the output of the internal LAN card. A fourth type of chain is one you create yourself. This is effectively a subroutine, for want of an analogy, and would normally be used if you want to apply the same set of rules in more than one place. Note that in ipchains, the forward chain comes from the input chain and goes to the output chain. This means that the forward chain does not usually require any specific blocking rules. Conversely, in iptables the forward chain does not tra­verse the input or output chains at all. As a result, it requires similar security to the output chain. All chains can be told to DENY (DROP in iptables) or 78  Silicon Chip REJECT something. The difference between the two is that REJECT returns an error message (so the hacker knows what has happened) while DENY does not return any messages. This means that DENY is ideal for use with the input chain as hopefully potential crackers will give up if they get no response at all. Another option is called ACCEPT, which means to allow something through. This is not normally used in the forward chain. Instead MASQ is used, which instructs the chain to change the internal network addresses to the external (eth1) address. The input, output, and forward chains also have a thing called a “policy”, which is simply what to do when all else fails. By contrast, user defined chains do not have a policy – they simply return to the point they were called from. For a detailed description on ipchains (with lots of exam­ p les), go to the following Internet site: http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html To find out how iptables works, you can go to: http://www.linuxguruz.org/iptables/howto/iptables-HOWTO.html How the firewall works OK, let’s now take a look at the firewall rules listed here in cablefirewall.simple. We’ll start from the top and describe what each rule does: First, MODIF="eth1" is a variable that defines the network card your cable modem is connected to. Change the eth1 to eth0 if required, or to ppp0 if you are using a dial-up modem. The reason for using a variable is that you can change it here and then all later references to $MODIF will refer to the correct network card. This saves you from having to change it throughout the whole script. Similarly, LOCNET="192.168.0.0/24" refers to your internal network. The /24 means the same thing as /255.255.255.0 Iblock="DENY" ; Oblock="REJECT" ; Fblock="DENY" are three statements on one line (hence the semicolons). You can change the DENYs to REJECTs and visa versa if you want. I have used DENY for the input (so crackers get no indication) and REJECT for the output so users on the internal network are warned of any prob­lems with outgoing traffic. Next any existing firewall rules are removed by flushing all existing rules and any user-defined chains. The local and loopback networks are allowed for both input and output, so the loopback (required for internal Linux use) is enabled as quickly as possible. The local network is allowed to do anything, the theory being that users on your internal network are friends, not enemies! This is done by allowing everything except the cable modem interface (the “!” means “anything but”). Next, the policies for all three chains are defined to deny or reject everything. The following masquerading timeouts are standard values which are used everywhere. The input chain is where we stop crackers getting in. Here, crackers who are devious enough to supwww.siliconchip.com.au Connecting To Telstra Bigpond Advance Unlike OptusNet cable, Telstra Bigpond Advance requires a login script for full Internet access. Under Linux, this login script is called bpalogin and several readers have asked for further information on how this is installed. Although we haven’t tested it, the following procedure should work: (1) Go to http://bpalogin.sourceforge.net/, then click the “Download BPAlogin” link and select the download you require - eg, “RedHat Linux RPMs v2.0”. The bpalogin-2.0-1.i386.rpm file that’s download is about 170Kb in length. (2) Copy this file to the Linux PC and install it by typing: rpm -i bpalogin-2.0-1.i386.rpm This creates the following files and directories (as shown by rpm -q -p -l bpalogin-2.0-1.i386.rpm): /etc/bpalogin.conf /etc/rc.d/init.d/bpalogin /usr/doc/bpalogin-2.0 /usr/doc/bpalogin-2.0/COPYING /usr/doc/bpalogin-2.0/CREDITS /usr/doc/bpalogin-2.0/INSTALL /usr/doc/bpalogin-2.0/README /usr/sbin/bpalogin (3) Open /etc/bpalogin.conf in a text editor and change the following two lines (near the top of the file): username yourname password yourpass ply an internal IP address to try to get through are stopped. Now the important one. Anybody trying to break in must be stopped but you have to be able to get stuff back from the Inter­net yourself. The next line achieves this by allowing TCP traffic that is not a connection (ie, it allows return packets). One problem with this is that when you download data using FTP, it requires a connection! So the next line defines a rule that allows FTP data connections only. Next we allow UDP and ICMP packets in. UDP is used by DHCP and DNS, while ICMP is used for error messages, pings, etc. This does mean that crackers can ping the PC but it is possible to prevent this by setting up several ICMP rules, to be selective. The last input chain rule blocks and logs anything else, so you can check who or what is trying to break in. This is only required if you want to log any blockages. Since the only thing being blocked is TCP connections, www.siliconchip.com.au You obviously set “yourname” and “yourpass” to whatever your Bigpond Advance user name and password are. I notice that the file is set to -rwx------ and is owned by root, so it already is protected against unwanted peaking. The start of the file looks like this: # Default debug level is 1. Values range from 0-2 # with 0 being silent # All information goes to the syslog. debuglevel 1 # The user name you have for your BPA account username yourname # Your BPA password password yourpass Note that there is also a /etc/rc.d/init.d/bpalogin startstop script. Now type: chkconfig --list bpalogin This shows that the rpm installation sets the startup and shutdown as follows: bpalogin 0:off 1:off 2:off 3:on 4:on 5:on 6:off This means that after editing /etc/bpalogin.conf, you can start bpalogin either by restarting Linux or by typing: /etc/rc.d/init.d/bpalogin start which you should never allow anyway, this line is commented out. If you do want to log TCP blockages then remove the “#” from the start of the line. The output chain is a lot simpler. Everything is allowed out to the cable modem, except internal IP addresses. This is a simple safeguard in case you make a mistake configuring any of the services on your local network. Next are some delay rules which only apply to a dial-up modem (delays are optimised for a network card by default). A test is done for the external interface being ppp* (ie, a modem). The last thing is to block and log everything else. Since the output chain policy is to block, you can remove this if you do not want to log anything but that would not be a good idea. Anything logged here will be something you will need to fix. The forward chain is also quite simple and has just two January 2003  79 COMPUTERS: masquerading modules & a firewall rules. First, internal IP addresses are changed (masqueraded) to the cable modem’s IP address. Everything else is then logged and blocked. Again, if anything is logged here, it will be a problem you need to fix. Making the firewall work To get the firewall rules up and running, you must have IP forwarding enabled as described in Pt.1. The local and cable modem networks will also be up and running at this stage. Note, however, that this means that the PC is wide open to attack, so have the firewall ready to roll if you are starting with the cable modem plugged in. Actually, only the local network needs to be up for IP for­warding to be enabled, so a better scheme would be to unplug your cable modem before starting the PC. In fact, this is the recommended method as it will keep you safe while you install the firewall. You can either type cablefirewall.simple in yourself or, better still, save yourself the hassle by downloading the script from the SILICON CHIP website at: www.siliconchip. com.au It doesn’t really matter where you save it since it is only run once to initially set the rules up before they are saved (see below). However, /usr/local/bin is probably as good a place as any to store the firewall script. It’s then just a matter of running the script to activate the rules. You do that by typing: /usr/local/bin/cablefirewall.simple Note that if you have the cable modem unplugged, this script will take a while to run but it will get there. Follow this by typing: /etc/rc.d/init.d/ipchains save This command saves the firewall rules so that they are now automatically invoked on system startup, before networking is enabled. This gives you full security. By contrast, if /etc.rc.d/cablefirewall.simple was called from /etc/rc.d/rc.local, then the networking would be up long before the firewall was. And that could create security problems. The interesting thing here is that the saved rules will be restored before IP forwarding is enabled without a problem. However, trying to set the rules via cablefirewall.simple without IP forwarding enabled won’t work! Note that this isn’t a problem with cablefirewall.simple – it’s simply the way ipchains works. Assuming that you unplugged your cable modem for security, you can now plug it back in and type: ifup eth1 This will start the cable modem network. Don’t forget to use eth0 instead of eth1 if this is the cable modem interface. And that’s it. If you’ve followed all the instructions so far, you will now have a working Internet gateway, firewall, DHCP server and DNS server. In Pt.4, we will describe a script to enable easy viewing of any firewall logs and show you how to run your Linux box without a screen or keyboard, including shutting it down via the power switch (if it has an ATX power supply). We’ll also briefly discuss a few security SC safeguards. Subscribe & Get This FREE!* *Australia only. Offer valid only while stocks last. THAT’S RIGHT! Buy a 1- or 2-year subscription to SILICON CHIP magazine and we’ll mail you a free copy of “Electronics TestBench”, just to say thanks. “Electronics TestBench” is a valuable 128-page collection of the best test equipment projects from the pages of Australia’s only consumer electronics magazine. By subscribing to SILICON CHIP you’ll save money on the news-stand price. And we’ll give you a 10% discount on any other SILICON CHIP merchandise (books, etc). Contact: Silicon Chip Publications, PO Box 139, Collaroy, NSW 2097 Phone Orders: (02) 9979 5644   Fax Orders: (02) 9979 6503   Email Orders: office<at>silchip.com.au 80  Silicon Chip www.siliconchip.com.au