How To Set Up a Firewall Using IP Tables on Ubuntu 12.04


SUBMITTED BY: Guest

DATE: Jan. 10, 2015, 9:31 a.m.

FORMAT: Text only

SIZE: 12.3 kB

HITS: 787

  1. About IP Tables
  2. In order to make a server more secure after the initial set up, Ubuntu ships with Iptables which is the distribution’s default firewall. At the outset, although the Ubuntu firewall is configured, it is set up to allow all incoming and outgoing traffic on a virtual private server. To enable some stronger protection on the server, we can add some basic rules to the IP Table.
  3. The IP table rules come from a series of options that can be combined to create each specific process. Each packet that crossing the firewall is checked by each rule in order. As soon as it matches a rule, the packet follows the associated action, otherwise it proceeds down the line.
  4. Note: This tutorial covers IPv4 security. In Linux, IPv6 security is maintained separately from IPv4. For example, “iptables” only maintains firewall rules for IPv4 addresses but it has an IPv6 counterpart called “ip6tables”, which can be used to maintain firewall rules for IPv6 network addresses.
  5. If your VPS is configured for IPv6, please remember to secure both your IPv4 and IPv6 network interfaces with the appropriate tools. For more information about IPv6 tools, refer to this guide: How To Configure Tools to Use IPv6 on a Linux VPS
  6. IP Table Commands
  7. Although this tutorial will go over a limited amount of commands that would provide a server with some basic security, there are a variety of nuanced and specific cases that can be developed for the IP Table. Below are some of the most useful commands for developing a firewall for your VPS, but keep in mind that this is a short list and there are a variety of other options.
  8. -A: (Append), adds a rule to the IP Tables -L: (List), shows the current rules -m conntrack: allows rules to be based on the current connection state, elaborated in the the --cstate command. --cstate: explains the states that connections can be in, there are 4: New, Related, Established, and Invalid -p: (protocol), refers to the the protocol of the rule or of the packet to check.The specified protocol can be one of tcp, udp, udplite, icmp, esp, ah, sctp or the special keyword "all". --dport: (port), refers to the the port through which the machine connects -j: (jump), this command refers to the action that needs to be taken if something matches a rule perfectly. It translates to one of four possibilities: -ACCEPT: the packet is accepted, and no further rules are processed -REJECT: the packet is rejected, and the sender is notified, and no further rules are processed -DROP: the packet is rejected, but the sender is not notified, and no further rules are processed -LOG: the packet is accepted but logged, and the following rules are processed -I: (Insert), adds a rule between two previous ones -I INPUT 3: inserts a rule into the IP Table to make it the third in the list -v: (verbose), offers more details about a rule
  9. 1
  10. 2
  11. 3
  12. 4
  13. 5
  14. 6
  15. 7
  16. 8
  17. 9
  18. 10
  19. 11
  20. 12
  21. 13
  22. 14
  23. -A: (Append), adds a rule to the IP Tables
  24. -L: (List), shows the current rules
  25. -m conntrack: allows rules to be based on the current connection state, elaborated in the the --cstate command.
  26. --cstate: explains the states that connections can be in, there are 4: New, Related, Established, and Invalid
  27. -p: (protocol), refers to the the protocol of the rule or of the packet to check.The specified protocol can be one of tcp, udp, udplite, icmp, esp, ah, sctp or the special keyword "all".
  28. --dport: (port), refers to the the port through which the machine connects
  29. -j: (jump), this command refers to the action that needs to be taken if something matches a rule perfectly. It translates to one of four possibilities:
  30. -ACCEPT: the packet is accepted, and no further rules are processed
  31. -REJECT: the packet is rejected, and the sender is notified, and no further rules are processed
  32. -DROP: the packet is rejected, but the sender is not notified, and no further rules are processed
  33. -LOG: the packet is accepted but logged, and the following rules are processed
  34. -I: (Insert), adds a rule between two previous ones
  35. -I INPUT 3: inserts a rule into the IP Table to make it the third in the list
  36. -v: (verbose), offers more details about a rule
  37. Creating the IP Table:
  38. If you type in the following, you can see the current rules in the virtual server’s IP Table:
  39. sudo iptables -L
  40. 1
  41. sudo iptables -L
  42. They should look like this:
  43. Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
  44. 1
  45. 2
  46. 3
  47. 4
  48. 5
  49. 6
  50. 7
  51. 8
  52. Chain INPUT (policy ACCEPT)
  53. target prot opt source destination
  54. Chain FORWARD (policy ACCEPT)
  55. target prot opt source destination
  56. Chain OUTPUT (policy ACCEPT)
  57. target prot opt source destination
  58. If you have another set of rules in place or want to start fresh, you can always set the rules back to the default by flushing and deleting all of them:
  59. sudo iptables -F
  60. 1
  61. sudo iptables -F
  62. Additionally, if you want speed up your work with IP Table, you can include -n in the command. This option disables DNS lookups and prevents the command from trying to find the reverse of each IP in the ruleset. You could use this to list rules, as an example:
  63. iptables -L -n
  64. 1
  65. iptables -L -n
  66. A Basic Firewall
  67. As it stands the current rules allow all connections, both incoming and outgoing. There are no security measures in place whatsoever. As we build up the table, keep in mind that as soon as a packet is ACCEPTED, REJECTED, or DROPPED, no further rules are processed. Therefore the rules that come first take priority over later ones.
  68. While creating the rules, we have to be sure to prevent ourselves from accidentally blocking SSH (the method through which we connected to the server).
  69. To start off, let’s be sure to allow all current connections, all of the connections at the time of making the rule, will stay online:
  70. sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  71. 1
  72. sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  73. We can go ahead and break this down:
  74. -A tells the IP table to append a rule to the table.
  75. INPUT designates this rule as part of the Input chain.
  76. m conntrack followed by the –cstate ESTABLISHED,RELATED guarantees that the result of this rule will only apply to current connections and those related to them are allowed
  77. -j ACCEPT tells the packet to JUMP to accept and the connections are still in place.
  78. After we are assured that all the current connections to the virtual private server can stay up uninterrupted, we can proceed to start blocking off other insecure connections.
  79. Let’s assume that we want to block all incoming traffic, except for those coming in on 2 common ports: 22 for SSH and 80 for web traffic. We proceed by allowing all traffic on the designated ports with the following commands:
  80. sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT
  81. 1
  82. sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT
  83. sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
  84. 1
  85. sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
  86. In both of these commands, the -p option stands for the protocol with which the connection is being made, in this case tcp, while the –dport specifies the port through which the packet is being transmitted.
  87. After we have guaranteed that the desirable traffic will make it through the firewall, we can finish up by blocking all remaing traffic from accessing our virtual server. Because this is the last rule in the list, all traffic that matches any of the previous rules in the IP Table will not be affected, and will be treated as we set up previously.
  88. Let’s make a rule to block all of the remaining traffic:
  89. sudo iptables -P INPUT DROP
  90. 1
  91. sudo iptables -P INPUT DROP
  92. With that, we can see what our updated rules look like:
  93. sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:http
  94. 1
  95. 2
  96. 3
  97. 4
  98. 5
  99. 6
  100. sudo iptables -L
  101. Chain INPUT (policy DROP)
  102. target prot opt source destination
  103. ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
  104. ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
  105. ACCEPT tcp -- anywhere anywhere tcp dpt:http
  106. We are almost finished. However, we are missing one more rule. We need to provide our VPS with loopback access. If we were to add the rule now without further qualifiers, it would go to the end of the list and, since it would follow the rule to block all traffic, would never be put into effect.
  107. In order to counter this issue, we need to make this rule first in the list, using the INPUT option :
  108. sudo iptables -I INPUT 1 -i lo -j ACCEPT
  109. 1
  110. sudo iptables -I INPUT 1 -i lo -j ACCEPT
  111. -I INPUT 1 places this rule at the beginning of the table
  112. lo refers to the loopback interface
  113. -j ACCEPT then guarantees that the loopback traffic will be accepted
  114. Now we have finished creating a basic firewall. Your rules should look like this (we can see the details of the iptable by typing -v):
  115. sudo iptables -L -v
  116. 1
  117. sudo iptables -L -v
  118. Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo any anywhere anywhere 1289 93442 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 2 212 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 157 packets, 25300 bytes) pkts bytes target prot opt in out source destination
  119. 1
  120. 2
  121. 3
  122. 4
  123. 5
  124. 6
  125. 7
  126. 8
  127. 9
  128. 10
  129. 11
  130. 12
  131. Chain INPUT (policy DROP 0 packets, 0 bytes)
  132. pkts bytes target prot opt in out source destination
  133. 0 0 ACCEPT all -- lo any anywhere anywhere
  134. 1289 93442 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
  135. 2 212 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
  136. 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http
  137. Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  138. pkts bytes target prot opt in out source destination
  139. Chain OUTPUT (policy ACCEPT 157 packets, 25300 bytes)
  140. pkts bytes target prot opt in out source destination
  141. However, as soon as the virtual server reboots, the IP tables will be wiped. The next step will go over saving and restoring the IP tables.
  142. Saving IP Tables
  143. Although the IP tables are effective, they will automatically be deleted if the server reboots. To make sure that they remain in effect, we can use a package called IP-Tables persistent.
  144. We can install it using apt-get:
  145. sudo apt-get install iptables-persistent
  146. 1
  147. sudo apt-get install iptables-persistent
  148. During the installation, you will be asked if you want to save the iptable rules to both the IPv4 rules and the IPv6 rules. Say yes to both.
  149. Your rules will then be saved in /etc/iptables/rules.v4 and /etc/iptables/rules.v6.
  150. Once the installation is complete, start iptables-persistent running:
  151. sudo service iptables-persistent start
  152. 1
  153. sudo service iptables-persistent start
  154. After any server reboot, you will see that the rules remain in place.
  155. http://nowquestion.net/questions/how-to-set-up-a-firewall-using-ip-tables-on-ubuntu-12-04

comments powered by Disqus