############################################################################# # Linux Firewalling - Insights and Explainations... # # by spender (c) 2000 # ############################################################################# Table of Contents: ------------------------------------- I. Introduction II. Basic IPChains firewalling III. Advanced firewalling IV. Insights V. Conclusion VI. Contact Me I. Introduction ------------------------------------- Well, it's appx. 6:40PM, Wednesday, June 14, 2000 right now. I figured that i should probably do something other than just sit here, so here goes. Firewalling is a simple concept that's frequently overlooked in system security. Of greater concern is mis-configured firewalls, which give system administrators a false sense of security. Another sad twist of the truth is the belief that a script is a "do-all wonder" for system security. My goal in this paper is to show how to CORRECTLY set up a firewall using the Linux operating system, which as of the 2.2.x kernel subset supports IPChains firewalling, and to do so in a way that actually improves the security of the system, instead of giving assumed security. II. Basic IPChains firewall ------------------------------------- Ok, here goes...i'm going over all this from memory, so bear with me;) There's a few basic ipchains commands you should know before you begin. (i assume ipchains is in /sbin) /sbin/ipchains -L (lists active firewall ruleset) /sbin/ipchains -A (adds a rule to the active ruleset) /sbin/ipchains -D (deletes a rule from the active ruleset) /sbin/ipchains -F (flushes the active firewall ruleset) That's about all you need to know to configure a firewall. There's a number of flags you also need to know to configure your rules, however. -y (matches packets with the SYN flag set..ones used to request a TCP connection) -l (logs packets that match the rule) -d (specifies destination address...in format a.b.c.d/x where a.b.c.d is an ip address, and x specifies the mask bits. If you don't know what they are, here's the only ones you'll really have to mess with: 0: Specifies all ip addresses....no matter what ip comes before the bit. 8: Class A subnet...good for denying traffic from AOL;) 16: Class B subnet...many large isps use these 24: Class C subnet...many schools and small isps use these 32: Static ip address...whatever address is specified is matched. in addition to the -d option is the optional port specification. it is done in the form: -d portx where port can be specified in any of the following ways :portx any port below portx portx port is portx portx: any port above portx portx:portx2 any port above portx but below portx2 -s (specifies source address...has same options etc of the -d option) -p (specifies protocol....TCP/ICMP/UDP/IGMP) --icmp-type (specifies type of icmp packet to deny/allow if option -p icmp is set) -j (specifies whether to ACCEPT/DENY/REJECT packet matched in rule... for example -j ACCEPT allows the packet) -i (specifies the interface the rule should apply to...if you have more than one of the same type of network device, the "+" character can be used as a wildcard...ex. -i eth+ means the rule applies to eth0 eth1 eth2 or whatever ethernet cards are available on the system.) ! (this character used with any option negates its meaning...i.e. ! -y matches all packets except those with the SYN flag set) -f (matches the second fragmented packet and every one after that in a stream) And that's all as far as flags are concerned...note that as far as ports go, the name of the service running on the port can be specified, or the number of the port. personally i use numbers just to be sure...tho you'll notice that in executing the ipchains -L command, the numbered ports are converted to service names. Here's a few examples of firewall rules, and their explaination ipchains -A input -p tcp -d 0.0.0.0/0 80 -s 0.0.0.0/0 1024: -i eth0 -j ACCEPT this rule allows any normal web access to your machine. -s 0.0.0.0/0 1024: means it can come from any outside host, and specifying that only ports in the temporary port range(1024-65535) can be used keeps a lamer from trying to ./dos u with a source port of 23 for example. ipchains -A output -p icmp -j DENY this rule denies any outbound icmp packets (not recommended if u want to ping other hosts(echo-request)) the lack of a -i option means the rule applies to all interfaces on the system...including lo(local loopback... meaning any connections occuring internally within the system, not being sent outside of the system) the lack of -d and -s options means the rule blocks icmp packets with ANY source or destination ip set. ipchains -A input -p tcp -d 0.0.0.0/0 1024: -s 0.0.0.0/0 80 -i eth+ -j ACCEPT this rule is an important one i don't think many documents comment on... access to the temporary port range is something that shouldn't be given out to the world in a flagrant way...the only reason the temporary port range of the machine should be accessed is from receiving data back from a connection to an outside host...such as accessing www.hotmail.com for example. I'll talk more about this in section IV, since i believe it deserves some discussion. the -i eth+ specifies that the rule should apply to only the ethernet cards available on the system. ipchains -A input -p tcp -y -l -d 0.0.0.0/0 80 -s 10.53.120.5/32 -i ppp0 -j DENY this rule logs all packets with the SYN flag (meaning connection requests) from the ip 10.53.120.5 on the ppp0 interface...and denies them. it's important to remember that specifying 0.0.0.0/0 for the destination ip on an input rule for an ethernet device, doesn't make much of a difference unless ip aliasing is used on the machine...but for ppp connections, it's a must, since the ip of the host would be generated dynamically. III. Advanced firewalling ------------------------------------ Ok, now that i've shown u the basic commands to set up a firewall ruleset, I'm now going to give you some pointers on how to configure an effective firewall. Allow all packets from the internal host...meaning all packets passing through interface lo. it's unlikely that you'll haveta protect yourself from yourself, since blocking the access internally may create some problems with certain daemons that interact internally through the loopback. As far as public services...keep them to a minimum. The more services you have running, the more vulnerable you are to attacks on them, and the more experienced you have to be as an admin to make sure that the services are up to date and as exploit-free and you can get them. Also, a person with a lot of ports open is obviously more interesting than someone with ssh open. If only certain people are going to be connecting to a certain port.. for example if only people from your network are supposed to access your ftp server, specify that in your firewall, as this will block any attacks on that port from the outside. Make sure that all access to ports on your system are done from the temporary port range on the source end. This is just to block some attacks from idiots, and will not harm normal traffic to your system. This is about as close to a keep-state like rule in ipf under openbsd as ipchains can get.... though not nearly as effective. Block ALL incoming ICMP traffic except echo-reply(icmp code 0) ICMP used to be used for a useful purpose to control internet traffic, however now its risks are far outweighing its benifits, and its legitimate use is lessening greatly. time-exceeded packets can be used in traceroutes to map networks...as well as some of the other icmp codes. destination unreachables are definately a block...they are greatly abused. it's also not a good idea to allow pings (echo-request) inbound as they can be abused as well. certain machines will send u malformed packets to see what kind of responses (sometimes icmp error codes) they can get back from you....which wastes your bandwith...so it's also a good idea to block all outbound ICMP traffic except echo-request....which will still allow you to ping outside hosts...if you don't need to ping hosts from your machine, then u can simply deny all icmp traffic and breathe easy. Deny traffic from your network broadcast...especially if you have a stupid admin who doesn't know how to login to his cisco router and type "configure interface ethernet 0" "no ip directed broadcast"...but that's another topic. Deny traffic from private ip addresses....namely the 10.0.0.0/8 range, specified by RFC....the only way you'd get traffic from those addresses would be if they were spoofed...being as they're not public. For your outbound ruleset, create one that reflects your inbound ruleset... meaning, any packets that you receive must either come from someone trying to access your host, or from receiving data from a connection made to the outside by the machine. This will help your system from being used as a mount point for attacks on other machines...tho most likely if they obtain root, the firewall will be removed, unless they want to be sneaky. Use a default target of DENY for your chains...for the forward chain, all packets should be denied, unless you're using the machine as a router as well. It is important to use DENY instead of the REJECT flag since REJECT sends a message back to the connection-requesting machine saying that the packet was rejected...which in the case of ICMP packets, has an adverse effect. DENY is much more stealth-like, it simply drops the packets. If you use a certain remote dns server, only allow udp connections to the domain port of that server...and block all others. IV. Insights ------------------------------------ As far as network security goes, placing a firewall on the machine to secure is generally not an effective answer...by the time the packets reach the firewall, they've already entered the network, and at that point, you've pretty much lost the battle. You have to have some sort of security at the border level, meaning the router. Disable icmp echo's to the broadcast to prevent from being smurfed. It's also a good idea to disable any kind of ICMP messages the router will send out. Disable any services running on the router such as finger, and CDP that serve no functional purpose for the network. Block out incoming connections from the internal network, which would only be coming in from spoofed attacks. And if you have a good enough router that you can create a firewall on it, by all means do so. It should be kept to a minimum tho, so as not to excessively restrict traffic, there shouldn't be too much load on any one machine. As far as the rest of the network, I would recommend setting up a dual-homed network. It would look something like this: Internet | | ROUTER | | External Network Server(with firewall) | OpenBSD ipf Firewall | / \ / \ Internal Network Client 2 Internal Network Client 1 Basically, this setup creates two distinct networks, an external and an internal. The internal network is of course more restrictive as to what is allowed in, and I would even suggest setting up NAT(Network Address Translation)on the ipf firewall, and implementing keep-state rules, which makes sure that incoming traffic is coming in from a connection already made to the outside. The external network would have a firewall on each machine, just for security, since it would be accessed by the world: the machines in the internal network would not. When setting up firewalls, it is VERY important to make sure that there is no rule that allows temporary port ranges on the source end to reach temporary port ranges on the destination end, except of course for any running daemons on the external network(which should be kept to a minimum). When allowing access at all to the temporary ports, which should only be done when accessing an outside host's services..make sure that only those services have access to the temporary ports on your system. While such a configuration will not allow such things as DCC in IRC, it will make your system MUCH more protected against any kind of flooding or similar dos attacks, since most of them use random temporary port ranges on the source end to connect to random temporary ports on the destination end. Use a network IDS such as snort to keep track on what kind of traffic is entering the network. If you notice something being abused, adjust your network configuration accordingly. V. Conclusion ------------------------------------ Well, I hope i've helped you in setting up a secure firewall. The ideas outlined in this document are my own, and result from my experience in configuring and implimenting linux and openbsd firewalls. Firewalls don't solve all security problems in a network environment, but they sure help. In addition to this, firewalls are no help for an admin who is lazy. If you don't keep up on your software, the firewall will be of no help to you. VI. Contact Me ------------------------------------ Email: spender@exterminator.net IRC: spender- or spender_