CentOS has an extremely powerful firewall built in, commonly referred to as iptables, but more accurately is iptables/netfilter.
Iptables: is the userspace module, the bit that you, the user, interact with at the command line to enter firewall rules into predefined tables.
Netfilter is a kernel module, built into the kernel, that actually does the filtering.
Summary: netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack. iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target). netfilter, ip_tables, connection tracking (ip_conntrack, nf_conntrack) and the NAT subsystem together build the major parts of the framework.
There are many GUI/non-GUI front ends for iptables that allow users to add or define rules based on a point and click user interface, but these often lack the flexibility of using the command line interface and limit the users understanding of what's really happening.
In this doc, we are going to learn the command line interface of iptables. Before we can really get to grips with iptables, we need to have at least a basic understanding of the way it works. Iptables uses the concept of IP addresses, protocols (tcp, udp, icmp) and ports.
Iptables places rules into predefined chains (INPUT, OUTPUT and FORWARD) that are checked against any network traffic (IP packets) relevant to those chains and a decision is made about what to do with each packet based upon the outcome of those rules, i.e. accepting or dropping the packet. These actions are referred to as targets, of which the two most common predefined targets are DROP to drop a packet or ACCEPT to accept a packet.
Chains: These are 3 predefined chains in the filter table, to which we can add rules for processing IP packets passing through those chains:
INPUT - All packets destined for the host computer.
OUTPUT - All packets originating from the host computer.
FORWARD - All packets neither destined for nor originating from the host computer, but passing through (routed by) the host computer. This chain is used if you are using your computer as a router.
For the most part, we are going to be dealing with the INPUT chain to filter packets entering our machine - that is, keeping the bad guys out. Rules are added in a list to each chain. A packet is checked against each rule in turn, starting at the top, and if it matches that rule, then an action is taken such as accepting (ACCEPT) or dropping (DROP) the packet. Once a rule has been matched and an action taken, then the packet is processed according to the outcome of that rule and isn't processed by further rules in the chain. If a packet passes down through all the rules in the chain and reaches the bottom without being matched against any rule, then the default action for that chain is taken. This is referred to as the default policy and may be set to either ACCEPT or DROP the packet.
The concept of default policies within chains raises two fundamental possibilities that we must first consider before we decide how we are going to organize our firewall.
1. We can set a default policy to DROP all packets and then add rules to specifically allow (ACCEPT) packets that may be from trusted IP addresses, or for certain ports on which we have services running such as Bittorrent, FTP server, Web Server, Samba file server etc.
or alternatively,
2. We can set a default policy to ACCEPT all packets and then add rules to specifically block (DROP) packets that may be from specific nuisance IP addresses or ranges, or for certain ports on which we have private services or no services running.
Generally, option 1 above is used for the INPUT chain where we want to control what is allowed to access our machine and option 2 would be used for the OUTPUT chain where we generally trust the traffic that is leaving (originating from) our machine.
To test if your server has iptables installed, query your rpm database: rpm -q iptables
result: iptables-1.4.21-4.ul6.x86_64
To check version: iptables --version
result: iptables v1.4.21
To check all iptables Kernel [loaded] Modules installed on the server: lsmod | grep ip
lsmod - program to show the status of modules in the Linux Kernel
iptables:
iptables -L : -L, --list [chain]; List all rules in the selected chain. If no chain is selected, all chains are listed. Like every other iptables command, it applies to the specified table (filter is the default), so NAT rules get listed by.iptables -t nat -n -L: Please note that it is often used with the -n option, in order to avoid long reverse DNS lookups. It is legal to specify the -Z (zero) option as well, in which case the
chain(s) will be atomically listed and zeroed. The exact output is affected by the other arguments given. The exact rules are suppressed until you use iptables -L -v
Let's Setup Iptables:
IMPORTANT: At this point we are going to clear the default rule set. If you are connecting remotely to a server via SSH for this tutorial then there is a very real possibility that you could lock yourself out of your machine. You must set the default input policy to accept before flushing the current rules, and then add a rule at the start to explicitly allow yourself access to prevent against locking yourself out.
iptables -P INPUT ACCEPT: If we are connecting remotely, we must first temporarily set the default policy on the INPUT chain to ACCEPT otherwise once we flush the current rules we will be locked out of our server.
iptables -F: To flush all existing rules, so we start with a clean state from which to add new rules.
iptables -A INPUT -i lo -j ACCEPT: Now it's time to start adding some rules. We use the -A switch to append (or add) a rule to a specific chain, the INPUT chain in this instance. Then, we use the -i switch (for interface) to specify packets matching or destined for the lo (localhost, 127.0.0.1) interface and finally -j (jump) to the target action for packets matching the rule - in this case ACCEPT. So this rule will allow all incoming packets destined for the localhost interface to be accepted. This is generally required as many software applications expect to be able to communicate with the localhost adapter.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT: This is the rule that does most of the work, and again we are adding (-A) it to the INPUT chain. Here we're using the -m switch to load a module (state). The state module is able to examine the state of a packet and determine if it is NEW, ESTABLISHED or RELATED. NEW refers to incoming packets that are new incoming connections that weren't initiated by the host system. ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to and already established connection.
iptables -A INPUT -p tcp --dport 22 -j ACCEPT: Here we add a rule allowing SSH connections over tcp port 22. This is to prevent accidental lockouts when working on remote systems over an SSH connection. We will explain this rule in more detail later.
iptables -P INPUT DROP: The -P switch sets the default policy on the specified chain. So now we can set the default policy on the INPUT chain to DROP. This means that if an incoming packet does not match one of the following rules it will be dropped. If we were connecting remotely via SSH and had not added the rule above, we would have just locked ourself out of the system at this point.
iptables -P FORWARD DROP: Similarly, here we've set the default policy on the FORWARD chain to DROP as we're not using our computer as a router so there should not be any packets passing through our computer.
iptables -P OUTPUT ACCEPT: We have set the default policy on the OUTPUT chain to ACCEPT as we want to allow all outgoing traffic (as we trust our users).
iptables -L -v: Finally, we can list (-L) the rules which we just added to check they've been loaded correctly.
/sbin/service iptables save: Save our rules, so that next time we reboot the computer, our rules are automatically reloaded.
iptable commands for everyday use:iptables -A INPUT -s 192.168.0.7 -j ACCEPT: Accept packets from trusted IP addresses(change the IP address)iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT: Accept packets from trusted IP addresses with CIDR notion(using standard slash notation)iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT: Accept packets using a subnet mask iptables -A INPUT -p tcp --dport 6881 -j ACCEPT: Accept tcp packets on destination port 6881 (6881 is bittorrent port) [NOTE: Here we append (-A) a rule to the INPUT chain for packets matching the tcp protocol (-p tcp) and entering our machine on destination port 6881 (--dport 6881).]
Blocking an IP address:iptables -A INPUT -s 192.15.15.51 -j DROP: DROP will drop all the packets from above IPiptables -A INPUT -s 15.15.15.51 -j REJECT: To reject the connection from above IPiptables -A INPUT -p tcp --sport 80 -j REJECT: Blocking A PORT (eg:http - apache/nginx depends). This will reject all connections to Apache where users get 'connection refused' error.
CHART To UNDERSTAND LINUX KERNEL NETFILTER WITH IPTABLES:
