iptables Linux firewall system. http://rlworkman.net/howtos/iptables/iptables-tutorial.html Internet protocol Application Transport Internet Datalink or Network Access layer. Firewalls target the transport and internet layers of the TCP stack. Firewalls don't examine the data packets being transported. That is left to anti-virus programs anti-malware. Firewalls combined with direct IP filtering such as fail2ban or denyhosts provide a primary form of security by actually limiting or blocking access altogether. fail2ban monitors failed attempts to connect to a system from a particular IP. If the attempts exceed a chosen value, the IP is placed in /etc/hosts.deny. Admin can white-list white-list a particular IP or a range.
iptables provides the ability to lay out a set of rules that filter the transport and internet layers for unacceptable packets. The table is laid out as a series of chained rules. Rules and rule chains can filter incoming or out-going packets. Rules can filter on incoming and out-going IPs. Rules can filter on incoming and out-going ports. Rules can filter on connection states. NEW - initiation of a connection. ESTABLISHED - connection activity on connection already established. RELATED - a connection created as an adjunct to another connection. ftp use both ports 20(control) and 21(data) INVALID - usually a corrupted packet. UNTRACKED - used to mark packets that need no further tracking. i.e Set on a web server to not track web-pages requests from a local IP. Rules are usually chained. Rule has a basic structure of : Name Filter Action A rule chain is created by giving a series of rules the same name. The rules are evaluated sequentially unless an action branches to another rule chain. Branching can be one way or can be treated like a subroutine call. Rules examine the IP level and TCP level headers. Rules do NOT examine the data body of the packet. Rule chains are organized to handle incoming and out-going packets separately.
Rules can only be added/viewed by an admin. Rules can be added to the table from the command line one at a time. Or a table can be pre-built and loaded whole. /sbin/iptables-save > iptable /sbin/iptables-restore < iptable
Rule structure. command filter action Some commands : -A, --append : append rule, probably most common rule. appended to end of chain specified. -D, --delete : delete a rule from a chain. either describe whole rule or specify rule number in chain specified. -R, --replace : replace a rule in a chain. either describe whole rule or specify rule number in chain specified. -I, --insert : insert rule in chain. specify location in chain. -L, --list : list current chains in user friendlyish format. -F, --flush : flushes (deletes all rules). Useful if rebuilding rules. -N, --new chain : create a new chain. -X, --delete-chain chain : delete a chain. -E, --rename-chain old new : renames chain. -P, --policy : define a policy for any packets not caught by any chain. Most of these make more sense when being issued one rule at a time from the command line. You can also edit a file with all the rules in the desired order and simply load the table. In which case, generally, only -A, -P, and -F useful.
Actions indicated with the -j option. -j target-rule - used to jump to named target chain. Some predefined actions. ACCEPT - keyword, terminates the rule filtering and indicates the packet is accepted. DNAT/SNAT - keyword, used to IP address translation, using the iptable as a NAT. iptables has several additional actions dealing with network address translation. DROP - keyword, terminates the rule filtering and disposes of the packet. without informing sender of action. LOG - keyword, log information about packet, often used before dropping. NOTRACK - keyword, turns off tracking on packet. (untracked status). RETURN - keyword, used to return to rule following rule that jumped to current chain. (sub-routine return). REJECT - keyword, drops packet but does send reject status back to sender. uses option --reject-with and message descriptor.
The main work of an iptable is done in the filtering. Initial filtering. PREROUTING raw - this is where NOTRACK can be set to avoid additional filtering. nat - change IPs mangle - modify packets before processing (TOS, Hop or TTL, etc.) POSTROUTING - work done after rules processed.
Filter by data direction. First filter modifier is : -i : filter incoming packets -o : outgoing packets. Filter by interface A system's network connections will have an identifier. Most systems have loop-back, lo, 127.0.0.1 Systems will also have 1 or more network interfaces. On Macs, it is usually ID-ed with en# where # is a number. On Linux, an Ethernet connections usually uses eth#. Combined with data direction, we can start building rule chains. # Create an "INPUT" rule and append to rule chain. # Accept any packets coming into loop-back. -A INPUT -i lo -j ACCEPT # Create an "INPUT" rule and append to rule chain. # Redirecting all packets coming in from the 1st Ethernet card to # the "Incoming" rule chain # If you have more than one interface card, use separate rules. -A INPUT -i eth0 -j Incoming -A INPUT -i eth1 -j local-in # log any other sources, most likely there none, but a safe practice. # The droplog rule/rule chain will have logging actions. -A INPUT -j droplog # Assume one of the droplog rules is RETURN # and drop. -A INPUT -j DROP # Accept all packets going out across loop-back. -A OUTPUT -o lo -j ACCEPT # Start rule chain for outing packets. -A OUTPUT -o eth0 -j Outgoing -A OUTPUT -o eth1 -j local-out -A OUTPUT -j droplog -A OUTPUT -j DROP ... -A droplog -j LOG --log-prefix "[mark] " --log-level 6 -A droplog -j RETURN
Filter by IP Filters, both in and out, can filter on source or destination IP. IPs can be specified with sub-net mask to create ranges. -s source IP -d destination IP # packets coming in from any other system on the private sub-net # and communicating with one of the well-known ports. -A local-in -s 192.168.8.0/24 -p tcp -m tcp --dport 1:1023 -j ACCEPT # packets headed out to any other system on the private sub-net # and communicating with one of the well-known ports. -A local-out -d 192.168.8.0/24 -p tcp -m tcp --sport 1:1023 -j ACCEPT Generally, you won't use -s and -p on IPs in same rule except with NAT. Note the /24, this basically says 192.167.8.0-255 are matches.
Filter by port --sport : source port --dport : destination port Using both a source and destination port in a rule is not uncommon. # For incoming packets from the local private sub-net and that # target any well know port on current system, accept. # Note the use of 1:1024 to specify port range. # (same rule as above) -A local-in -s 192.168.8.0/24 -p tcp -m tcp --dport 1:1023 -j ACCEPT # Modified to accept packet only if it originated from an ephemeral port. # This will usually be followed by rules to handle other cases. -A local-in -s 192.168.8.0/24 -p tcp -m tcp --sport 41891:65546 --dport 1:1023 -j ACCEPT
Filter by protocol tcp - transmission control protocol udp - user datagram protocol icmp - internet control message protocol sctp - stream control transmission protocol Using just -p implies a match on the protocol time is all that is required. Most often used with -m to further identify what is being matched.
Filter by match. -m match : explicit match, can specify a number of filters to match on. The match possibilities is quite large, so see the document. # Allow any TCP packets going out to public interface that consists of a # connection between two ephemeral ports > 1024 and there were the result # of the action of a client's negotiation with a service. # For instance a chat service that negotiated a direct connection between # two chat clients. -A out-going -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT # Limit range of acceptable IPs. Allows for a more controlled designation # than the /mask identifier. -A INPUT -p tcp -m iprange -src-range 192.168.1.13-192.168.2.19