North Texas Linux Users Group Presentation
November 1999
Dave Stokes, RHCE, UHW Corporation
david@uhw.com

Ipchains
and why you won't use them in the future

"Whip me, beat me, make me use ipchains" Linux Netfilter-Howto, Second Place Motto

This is a short presentation on filtering IP packets for Linux system security. Many of the details are glossed over due to time considerations. All the real details are available in the source code for those seeking the ultimate knowledge. Some variations of the details can be found in the HOWTOs or in the files found under /usr/doc. But make sure YOU have some understanding of what is going on before implementing ANYTHING in this presentation because misapplication of this knowledge is like playing Russian roulette with a shotgun. Often the best security for the novice is to TURN the system off when not in use.

V

1. What is a packet and why does it need to be filtered?

The Internet works with the TCP/IP protocol which places information in datagrams that most people call packets.

[ sender | recipient | X | data] <- pseudo datagram
(X explained later)
(not to scale)

The sender address is in 32 bit number as is the recipient address. So you see addresses like 192.38.24.12. So if you send a packet rom 192.38.24.12 to 10.11.12.13, how does 192.38.24.12 know what to do with the datagram?

V

2. Your ethernet card's Robert DeNiro impression!

Ethernet cards listen to signals and puts the bits into a datagram. Then the computer has to determine if You talking to me?'. If the datagram is not meant for this computer it does the forgetta-boudit' and goes on it's merry way. But if the datagram is meant for this computer, it has more work to do!

V

3. Ports and Sockets, a limited liability company

Burried deep in the datagram is a port number (the X stuff). Think as the IP address as the street address of a large apartment building and the port as the apartment number. So the system know knows it has datagram destined for a certain apartment, er, port on the system. Look in /etc/services to match port number for services.

Port numbers are fairly standardized i.e. 25 for SMTP, & 80 for http. New services like Samba's SWAT usually make you add their number. Any number above 1024 is non-privledged and any below 1024 are to be suspected.

V

4. Quick summerizining example

User with pid 666 on 192.67.134.28 is using Mozilla over port 1550 to get the home page of greatgeek.com. Via DNS, 192.67.134.28 get the IP address of www.greatgeek.com and sends a message to port 80 at that address that says:

GET / HTTP/1.0<CR><CR>

The http demon on www.greatgeek.com gets the receiving IP & port numbers from the request and sends the requested information.

That was very sanitized, streamlined, and misses many wonderful things like packet sequence numbers, CSMA/CD mechanics, and ICMP packets.

V

5. So (AGAIN) why filter packets?

Not all packets come with good intentions or ask for things you want to give out freely. And each packet takes processing power to process. Many denial of service type attacks make your system so busy handling bogus requests that it can do nothing else.

The sooner you dump the unwanted packets the better for overall processing. IP filter examines the header of the packet and decides the fate of the packet.

V

6. TCP Wrappers

TCP wrappers are a comparatively high level way of denying access. System administrator sets up a /etc/hosts.allow and a /etc/hosts.deny to say who can and can not use programs like in.telnetd and in.ftpd.

Good things about wrappers: Do limit access
Bad things about wrappers: Too much packet processing before they work and only protect programs started by inetd.

V

7. IPFW

A BSD-ism to determine which packets are allowed.

Good things about IPFW: works okay.
Bad things about IPFW mainly BSD.

V

8. IPFWADM

A very blatent copy of IPFW.

Good things about IPFWADM works, popular, and does good , and has masquerading.
Bad things about IPFWADM not really low enough, fragment reassembly lacking, 32 bit counters.

V

9. IPCHAINS

Very good kernel support and a little easier to setup than ipfwadm.

Good things about ipchains: really precise tool
Bad things about ipchains Flushing rules leave you vulnerable, easy to misconfigure, code not modular (can't plug in MAC address filtering, etc.), and slow on rejects.

V

10. Netfilter

Netfilter is a packet mangling framework that provide ways of passing different packet types to different parts of the kernel. Also has cool NAT and RNAT features.

The reason that Netfilter will replace Ipchains is that it is better designed. With Ipchains, each packet runs through the entire gauntlet of rules. Netfilter expedites packet handling with a more straight forward design which puts less load on the kernel.

Good things about netfilter: Modularity, faster rejects.
Bad things about netfilter: unproven.

Netfilter has a series of queues that can hand packets off much faster to the daemons, is modular, and is part of the 2.3.15 and later kernels.

V

11. Netfiler will have IPCHAINS compatibility

Netfilter will be able to use your ipchains rules, so you will not lose everything you develop ipchains.

V

12. Where Do I start with IP Chains

Basically IPCHAINS does four things. It can just drop or DENY a packet, It can REJECT which is a DENIED packet and an ICMP message sent to the sender saying service is denied, FORWARD which pushed the packet down another wire, and REDIRECT which send the packet to a port different that the one requested.

Your kernel must have these defined:
2.0 kernels : CONFIG_EXPERIMENTAL, CONFIG_FIREWALL, CONFIG_IP_FIREWALL, and CONFIG_IP_FIREWALL_CHAINS

2.2 kernels : CONFIG_FIREWALL and CONFIG_IP_FIREWALL

V

13. Simple rules.

A primitive rc.firewall to be called from your rc.local 

 

#!/bin/sh
# allow ip packet to be forwarded between NICS
echo "1" > /proc/sys/net/ipv4/ip_forward
# Kill off syncookies attack
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
# Do not allow any packets to be forwarded ...
/sbin/ipchains -P forward DENY
# ... but well let the masquerading systems
/sbin/ipchains -A forward -s 10.0.0.0/8 -j MASQ
# Allow ftp to masquerade
/sbin/modprobe ip_masq_ftp

V


14. Where to get an easier start with IPCHAINS

Two good places to go are:

  • www.linux-firewall-tools.com: Javascript to generate custom rule set.

  • ipchains.nerdherd.org: three good scripts -> Standalone, masquerade, and routeable.

  • Mason and gfcc are also good tools after trying the above. Cruse the freshmeat.net site for more tools!

    V

    15. The flow

    Packets go though a 'chain of rules' to finally get accepted. It is not efficient but NETFILTER will take care of that in the 2.4 Kernels
    start flow of packet-> end
    filterChecksum Sanity Input Demasq Routing Forward Output Accept
    IF BAD DENY DENY DENY/REJECT goto Output Local Process DENY/REJECT DENY/REJECT  

    V

    16. The basic basics

    You giving the kernel rules to handle packets, i.e. to allow packets in and out on a local 10 network, we have to explicitly allow that behavior:

    ipchains -A input 10.0.0.0/24 -d 10.0.0.0/24 -j ACCEPT
    ipchains -A output 10.0.0.0/24 -d 10.0.0.0/24 -j ACCEPT

    V


    17. A better example

    Here we have eth0 listening to the Internet and want SMTP to work, but not telnet

    ipchains -A input -p tcp -i eth0 -d 24.24.24.24 25 -j ACCEPT
    ipchains -A input -l -p tcp -i eth0 -d $LOCALNET 23 -j DENY

    V


    18. General rules to use

    1. Deny EVERYTHING at start -> Your default protection
    2. Block any outside packets with an inside address
    3. Block 'private' Class A, B, & C addresses.
    4. Block outside packets using the loopback (127.0.0.1) address
    5. ACCEPT ICMP requests to the firewall
    6. ACCEPT PING requests only on ISP network, known systems
    7. ACCEPT anything on the inside NIC
    8. REJECT services you don't support, i.e. NFS, telnet
    9. Remember to copy applicable TCP rules to UDP!!!
    10. Test with -c, ipchains -c -i eth0 -p udp -s 0/0 -d 24.1.1.12 53 -J ACCEPT

    V


    19. Masquerading, NAT or RNAT

    Simple goal one box serves many, may appear as one or many

    Masquerading is where one computer with one IP address fronts for many computers. NAT, Network Address Translation, is when one computer uses a pool of IP numbers to front for many computers. linux-firewall-tools.com. Reverse NAT is where many computers pretend to be ONE computer and is used in high availability web sites. You can do NAT and RNAT but not with ipchains alone but it will come with netfilter.

    Most NTLUGGERs probably want to learn about masquerading for a small office with a cable modem, ISDN, or DSL line.

    10.*.*.*, 172.16.*.*, and 192.168.*.* are addesses you can use internally for private networks (RFC1597) connected to the Internet via a firewall. These private nets will not route to the outside world. So one NIC is 10.0.0.1 in the ipchained system is and another is 24.4.0.39 (A real IP address from you cable modem services). The 24.4.0.39 address does all the real fronting for up to 16 million plus devices in your home.

    V

    20. Odd cases

    You can redirect services from one port to another. One interesting use is to selectively have some address hit a virtual http sever o grandma and grandpa' see the good, wholesome web site while everyone else sees the other, evil puppy juggling site.

    V

    21. Where to start with IPCHAINS

    1. Get a 2.2 kernel
    2. Use exiting scripts to start:
      1. Get a copy of http://www.nerdherd.net/ipchains/ipchains-
        2. firewall-1.5.1.tar.gz or later and pick a script most like your environment. Put in your IP number and call the script from your rc.local file. Come with a standalone, masquerading, and routable scripts.
      2. linux-firewall-tools.com
    3. Add or subtract from the fire wall script above to suit you.
    4. Scan your system for holes
    5. Examine script to test you knowledge.

    V


    22. Security Hints

    1. Turn off services you don't use!
    2. Use shadow password, mix the case of your password and add letters, non-alpha characters, and do not pick anything obvious.
    3. Examine your /var/log/messages and /var/log/secure. And get portsentry and logcheck to watch your system and then check their output. being passive will hurt you!
    4. Use nmap to scan your own systems. (More later)
    5. Read the security updates for your distribution. Check out lwn.net each Thursday for the security section. Visit securityportal.com's Linux section regularly and read bugtraq.
    6. Use tcp wrappers on services you leave open to provide logging and extra security.
    7. Turn off anonymous ftp access unless you want people to take and leave stuff on your box. If you do leave it open, check the contents regularly.
    8. Use ssh
    9. Keep a list of changes from the standard distribution so IF you have to rebuild you know what has to be done. This will also minimize downtime in case of a big disaster. Tripwire use is recommended.
    10. For cable modem/ADSL setups at home: Use an old pc with two NICs as firewall. A p90 with 32MB works very well and allows you to shut off your main Linux box when not in use.

    V


    23. Use nmap Get nmap from www.insecure.org/nmap and test your system!

    /usr/local/bin/nmap -sS -O oddbox 

    Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost.localdomain (127.0.0.1):
Port    State       Protocol  Service
21      open        tcp       ftp                     
23      open        tcp       telnet                  
25      open        tcp       smtp                    
79      open        tcp       finger                  
80      open        tcp       http                    
98      open        tcp       linuxconf               
111     open        tcp       sunrpc                  
113     open        tcp       auth                    
513     open        tcp       login                   
514     open        tcp       shell                   
515     open        tcp       printer                 
902     open        tcp       unknown                 
6000    open        tcp       X11                     

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=2664595 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.12

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

    V


    24. Use nmap data So you have an open port:

    1. Telnet to that port, i.e. telnet localhost 111
    2. fuser -n tcp 111, note the PID
    3. ps PID
    4. Determine if you need to block

    V


    25. Q&A