1,234
edits
Changes
→PART 2: IPTABLES
* Use yum to uninstall firewalld and install iptables-services
* Use systemctl to start the iptables service and configure it to be started on boot.
IPtables is a complex system, and there's a lot of material this week to cover it. Keep in mind as you're going through the lab that you're trying to learn three things:
* '''How iptables works'''
* '''How to understand the current state of the firewall'''
* '''How to make useful changes to the firewall'''
== IPtables overview ==
We will use an example of setting up a firewall on a web server.
[[Image:iptables.png]]
'''There are some important things to be aware of in terms of this diagram:'''
:*There are '''<u>two sets</u> of IPtables rules (chains) that apply:''' '''OUTPUT/INPUT on the client''' and '''INPUT/OUTPUT on the server'''.<br>It is important to think about trafic from the perspective from the client as well as the server.
:* '''Outbound traffic is rarely blocked <u>unless</u> there is a security policy to <u>prevent</u> some kind of traffic'''.<br>Even in that case, that security policy is usually performed on a router.
:* '''Inbound traffic is of two distinct types'''. Our diagram shows:
::# '''New incoming <u>connections</u>''' (what you normally think of as '''<u>inbound traffic</u>'''): the web server receives a '''new incoming connection'''.
::# '''Incoming <u>data</u> that client receives as a response from the server''': the web page that the server sent back in the diagram above.
::::The analogy would be like making a '''telephone call''':<ul><li>A '''NEW''' packet is like the phone ringing</li><li>An '''ESTABLISHED''' packet is the connection and the packet says "hello", along with any further communication.</li><li>A '''RELATED''' packet would be the same person calling on a second line. (eg. a second connection that is made because of something that happened in the first, like an ftp transfer).</li></ul>
::::We normally don't want to do anything special for the response. It is safe to assume that '''a connection that was allowed to be established should be allowed to receive a response'''. This is accomplished with the following '''INPUT chain rule''' that should be there by default on your machines:<br>
::::<pre>ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED</pre>
:* '''Rules are applied to:''' '''chains''' (e.g. ''input/output'') and contain information regarding the type of traffic they apply to. For example, '''protocols''' such as ''tcp/udp/icmp'', '''port numbers''' such as ''22 (SSH), 80 (HTTP), 443 (SHTTP)'', '''addresses''', and many other things.
::Let's look at how these rules would apply to a simple web connection (HTTP - port 80):
::# For the ''request'', the '''source port (sport) for the example in the above diagram is 40112''' and the '''destination port (dport) is 80'''
::# For the ''response'', the '''source port (sport) is 80''' and the '''destination port (dport) is 40112'''
::# Since the '''RELATED,ESTABLISHED''' rule already exists, we are only concerned about <u>'''controlling'''</u> the '''incoming traffic on the server''', which in our example, the '''chain is: INPUT''', the '''protocol is: tcp''', and the '''destination is: port 80'''.
:* 'Most other services work in a similar way as discussed above.