Rate this page del.icio.us  Digg slashdot StumbleUpon

Video tip from RHCEs: Firewalls


Download this video: [Ogg Theora]

Video by Colby Hoke. Produced by Julie Bryce and Jim Haverkamp.

We bring the advice of experts straight from San Diego to your desktop.

Red Hat Summit 2007 collected hundreds of Linux users all in one place–many of them experienced Red Hat Certified Engineers® (RHCE). And somewhere between all those smart people walking around–and our video crew shooting footage–the idea for some video tips was born.

This tip is from Vinny Valdez. Look for more in the coming weeks.

The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

6 responses to “Video tip from RHCEs: Firewalls”

  1. Tom says:

    Can someone provide an example of how this would look in the /etc/sysconfig/iptables file?

  2. Jeremy L. Gaddis says:

    Take an /etc/sysconfig/iptables that looked like this (at the end):

    -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
    -A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited

    Now, let’s assume we want to log any attempts to access a web server (on port 80) and that a web server isn’t running on this system.

    In between the two lines above, insert an additional line:

    -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j LOG –log-prefix=”attempt to access apache”

    (Make sure ipt_LOG is loaded)

    Reload your firewall ruleset (/sbin/service iptables restart). From another machine (required since a prior rule allows anything from localhost), attempt to connect to port 80 on this box.

    Afterwards, run `grep “attempt to access apache” /var/log/messages` and you should see an entry with the details (source IP/port, destination IP/port, etc.)


  3. Jeremy L. Gaddis says:

    That’s “–log-prefix” above (two hyphens), by the way. Not sure if I only put one hyphen or if it just looks like one.

  4. Vinny Valdez says:

    Hey guys, thanks for viewing my tip. Jeremy is correct when you want to log http. However, my original intent was to be able to discover something that was being blocked that you weren’t sure of.

    For example, let’s say you are trying to setup tftp-server for PXE boot, and you are not sure which port to open (all normal services are listed in /etc/services, but this could help you find any port being blocked).

    After configuring everything, your client cannot boot properly, and gets some error while trying to connect to the tftp-server. /var/log/messages on your server does not reveal anything useful. You turn off your firewall, try again, and it “just works.”

    This may be a good troubleshooting method to determine that the firewall is what was blocking your client from accessing the tftp-server. However, you should not leave it in this state. Here is what I suggest:

    Let’s do this from the cli in 10 easy steps, instead of the /etc/sysconfig/iptables like I suggest in the video. I did that in essence of time.

    1. Make sure your firewall is on:
    # service iptables start

    2. List your current rules:
    # iptables -L –line

    3. Most likely you will have a table named something like “RH-Firewall-1-INPUT”. If you notice the very last line, by default it says:
    10 REJECT all — anywhere anywhere reject-with icmp-host-prohibited

    On my ruleset, the “10” represents the last line, but YMMV. This line says to reject everything. Since the rules are processed in order, anything that has not had a match yet will match this line, and be rejected.

    4. Now you want to insert a logging line before this reject statement:
    # iptables -I RH-Firewall-1-INPUT 10 -j LOG –log-prefix “firewall reject: ”

    Notice I used the number “10” after the table called “RH-Firewall-1-INPUT”. This in combination with the option “-I” at the beginning tells it to insert this line above line 10.

    5. Now list your rules again to verify:
    # iptables -L –line

    6. You should see that there is one additional line, just before the reject line, telling it to log. With the “LOG” target, packets will continue on to the next rule, unlike normal “REJECT” or “ACCEPT.”

    7. Now start monitoring your log. Ideally you would not want to see anything yet, since you have not started accessing the server:
    # tail -f /var/log/messages | grep “firewall reject:”

    If you see too many lines such as local broadcast traffic, you can filter your results using grep even further (of course replacing “my_client” with a hostname or ip):
    # tail -f /var/log/messages | grep -e “firewall reject:” -e “my_client”

    8. Now try your application. In this example we were setting up tftp server, but since we didn’t specify any specific ports to log, all traffic that will be rejected will be logged first.

    You should begin to see packets as they are rejected.

    9. Once you identify the offending ports, you can now use the same tactic as above to add a line. Let’s use the tftp example, and say you saw an entry for “DPORT” on the server of “69”. To allow this, you could do:
    # iptables -I RH-Firewall-1-INPUT 10 -p udp –dport 69 -j ACCEPT

    10. You can also restrict it down to your subnet, and only to your server with the “–source” and “–destination” options. See “man iptables” for full details. This line will open all traffic to this port. Your client should now be able to access the tftp-server. If not, repeat for any rejected packets you see in the log.

    When you are satisfied everything is working, you may want to remove the logging entry. After listing out your rules, grab the line number and do:
    # iptables -D RH-Firewall-1-INPUT 11

    If everything is working, you can now save your rules:
    # service iptables save

    Hopefully this is helpful. If at anytime you mess up and want to start over (before you save the rules, of course) just issue: “service iptables restart” to reset your rules.

    I think this is more useful than directly editing your /etc/sysconfig/iptables, especially to get you familiar with iptables. However, if you feel comfortable editing the config file directly, make sure to back it up first.

    One last tip, if doing this remotely, be careful. Certainly don’t issue “service iptables panic” remotely! If you need to do this remotely, you can setup a cron job to reset or stop iptables as insurance, just be sure to start it up ASAP.


  5. Bob says:

    This is a great tip! I have had many situations where we know an application works when the firewall is down, but we just don’t know what ports it needs.

  6. Gescape says:

    Fantastic :)
    Thank you.