Firewall Basics (2008-11-09 classroom)

From FedoraProject

Jump to: navigation, search

Fedora Classroom - Firewall Basics - Kevin Fenzi - Sunday, November 9, 2008

IRC Log of the Class

-!- nirik changed the topic of #fedora-classroom to: Fedora Classroom - Introduction - See for more info 20:00
@nirik Welcome everyone to the Fedora classroom. 20:00
@nirik Just a few opening comments before we start... 20:00
@nirik If you have questions about fedora topics not related to a currently running class, #fedora is open for them... 20:01
@nirik if you would like some social chatting with other fedora users, #fedora-social is available for that. 20:01
@nirik that said, lets go ahead and dive into the first class for today. 20:02
-!- nirik changed the topic of #fedora-classroom to: Fedora Classroom - Firewall Basics with your teacher nirik - See for more info 20:02
@nirik First, a bit of history: 20:02
@nirik The Linux kernel has had a number of firewall systems... ipfwadm, ipchains and now currently something called netfilter 20:03
@nirik Netfilter has improved on the past implementations quite a lot and is very flexable. 20:04
@nirik So, lets back up a step and ask: What is a firewall? 20:04
@nirik Basically it's a system to allow you to manage your machines interaction with the network 20:04
neverho0d the wall from bricks or concrete to prevent fire to spread ;) 20:05
@nirik neverho0d: yes, or the metal in a car to prevent the engine from leaking anything like a fire into the passenger part of a car. 20:05
neverho0d  :) 20:06
@nirik Netfilter is able to do filtering, inspecting, translating, modifying, tracking, limiting and logging (and possibly things I am forgetting) to network packets that hit your machine. 20:06
@nirik Lets go over some concepts before we look at some rules 20:06
@nirik "chains" are sets of rules that are examined in order. 20:07
@nirik You can define your own, or just use some standard ones that netfilter provides you. 20:07
@nirik The standard set is: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING 20:07
@nirik "tables" are sets of chains. The standard ones are: filter, nat, mangle 20:08
@nirik filter is the set that most people use and know. nat is for Network Address Translation. mangle is to modify packets. 20:09
@nirik "targets" are used in rules. This tells netfilter what to do if a packet matches that rule. 20:09
@nirik example targets are: ACCEPT, DROP, QUEUE, RETURN, LOG, many others. 20:09
@nirik Here's a simple diagram of how the packets flow: 20:10
@nirik 20:10
@nirik and a more complex one: 20:10
@nirik 20:10
@nirik basically packets arrive, get tested for the prerouting rules, a decision is made if they are going to be routed somewhere else or handled locally. 20:11
@nirik then if local, they pass thru input and back out output and postrouting. 20:11
@nirik if non local, they pass thru forwarding. 20:11
@nirik So, all thats pretty complicated sounding, but it's not so bad for most cases. 20:12
@nirik Fedora by default stores your firewall ruleset in /etc/sysconfig/iptables. 20:12
@nirik depending on if you customized it on install or not, it likely looks like: 20:13
@nirik any questions so far? Or shall I go over the simple default set there? 20:13
erinlea80 the rules read from the bottom up? 20:14
@nirik erinlea80: good question. In that file you will note that they use '-A' that tells the iptables command to "append" the rule to the chain. 20:14
@nirik so, it will add each rule to the end... 20:15
zcat When/Why was the old RH-something chain removed? 20:15
@nirik chains are evaluated from top to bottom. 20:15
@nirik zcat: in f9 I think. or possibly f8. 20:15
@nirik so, to this example, you can see "*filter" says this is in the filter table. 20:16
@nirik then it lists the INPUT/FORWARD/OUTPUT chains and what rules they contain. 20:16
@nirik INPUT and FORWARD have no rules. 20:16
nuonguy this is all at the IP level, right? Doesn't matter whether the app uses TCP or UDP, right? 20:16
domg472_ what iptables command can i use to not append, because if i append it will be below the reject line and be rejected? 20:17
@nirik nuonguy: good question. Yes, this is at the IP level. netfilter can filter on any protocol.... tcp/udp/icmp/gre/etc/ 20:17
@nirik domg472_: you can use -I to insert or -R to replace a existing rule. see 'man iptables' for more info. 20:17
domg472_ thanks 20:17
domg472_ why cant it manage raw ? 20:18
@nirik Also, the iptables service has a 'save' target. So you can use the command line to setup your rules, and then 'service iptables save' will save it to /etc/sysconfig/iptables 20:18
nuonguy and the syntax you're discussing today covers only netfilter, right? 20:18
@nirik nuonguy: correct. All the older versions are no longer in use... 20:19
nuonguy ic, thanks 20:19
@nirik domg472_: raw in what context? there is a 'raw' table. 20:19
domg472_ like dhcp broadcasts? 20:19
@nirik yes, you can match on broadcasts just fine. ;) 20:20
jds2001 that's just udp to a broadcast address. 20:20
domg472_ ok thanks 20:20
@nirik ok, I'd like to mention some administration tools available, and then perhaps go on to some examples of a few things... 20:20
@nirik first of all there is 'system-config-firewall'. Those of you on fedora machines right now, might want to pull it up and look at it. 20:21
@nirik it's gotten a lot more flexable that it used to be, and can setup many of the common things people want to do with their firewalls. 20:21
@nirik I don't have any screenshots handy, but I will say to try it out if you get the chance. 20:23
@nirik Fedora also includes a number of other firewall configurator programs: firestarter, fwbuilder, and shorewall to name a few. 20:23
@nirik ok, shall we move on to a few examples? 20:24
GnuBoi are these all gui for netfilter 20:24
jds2001 screenshot at for those not on fedora boxen. 20:24
@nirik GnuBoi: I think some of them can do command line. system-config-firewall has a console mode, but it's not as powerfull. 20:25
@nirik jds2001: thanks. 20:25
domg472_ arent they all interfaces to netfilter? 20:25
@nirik domg472_: correct. 20:25
@nirik they are all frontends that try and help you make iptables rules. 20:26
@nirik you can of course just bypass them all and make your own, but the frontends make it easier since you don't need to remember syntax or figure out how to do some things. 20:26
@nirik for at least system-config-firewall it will continue to write to /etc/sysconfig/iptables, so you can always look at what rules it's adding. 20:27
domg472_ is system-config-firewall still very activly maintained? 20:28
domg472_ can i expect improvements? 20:28
@nirik yes. It's improved a lot in recent releases... but of course more is always good. 20:28
domg472_ thanks 20:28
@nirik lets talk a bit about NAT. 20:29
@nirik NAT is Network Address Translation. It's the ability for your machine with the netfilter firewall to re-write packets to allow for machines using it as a gateway. 20:30
@nirik netfilter has SNAT and DNAT. Source NAT and Destination NAT. 20:30
@nirik SNAT is used to re-write outgoing packets to appear to come from the firewall machine and then re-write the responses so the reply goes back to the machine that sent it. 20:31
@nirik A subset of that is what many people know as Masquerade. 20:31
@nirik a SNAT rule might look like: "iptables -t nat -A POSTROUTING -s -o dsl -j SNAT --to-source' 20:32
@nirik that says use the nat table, Append a rule to the POSTROUTING chain, match anything with a source of (an internal machine) thats going out (-o) the dsl interface and make it use external address. 20:33
domg472_ are theres rules for when to use -o or -d, or -i or -s or can you jut use them mixed? 20:33
@nirik so, the machine could go out to the internet, the firewall would re-write those packets to appear to come from and then take replies and send them back to 20:33
@nirik domg472_: yes, there are rules. It depends on what table and such... iptables will give you an error if you use one that doesn't make sense in that context. 20:34
domg472_ thanks 20:34
@nirik another type of NAT is DNAT... this is forwarding something in from the outside net to an internal machine and back out. 20:35
@nirik so for example you wish to forward ssh on the firewall to an internal machine: 20:35
@nirik iptables -t nat -A PREROUTING -d -p tcp -m tcp --dport 22 -j DNAT --to-destination 20:36 < SSlater> So source and destination are relative to the local machine(s)? 20:35
@nirik if a ssh port tcp packet comes in for (an external ip) send it to and handle the translation. 20:36
@nirik SSlater: yes. 20:36
@nirik SSlater: the machine with the firewall on it. 20:36
SSlater thx 20:36
domg472_ so basicly DNAT is the nat tables input and SNAT is the nat tables output? 20:36
@nirik domg472_: yes, note that one is used in POSTROUTING and the other in PREROUTING. 20:37
domg472_ DNAT is postrouting? 20:37
@nirik domg472_: other way. DNAT is PRE and SNAT is POST 20:38
domg472_ thanks 20:38
@nirik ok, I'd like to touch a bit on connection tracking. 20:39
AndyCap MASQUERADE may be better than SNAT for people with dynamic ipaddresses, 20:39
@nirik One nice thing that netfilter has is a connection tracking setup. Some products call this "statefull packet inspection". 20:39
@nirik AndyCap: oh, quite right. MASQUERADE is a subset of SNAT, where you don't need to give it the source ip you want to nat, it figures it out based on the interface IP address. 20:40
domg472_ thats the only difference? 20:40
@nirik an example of that might be "iptables -t nat -A POSTROUTING -o cable -j MASQUERADE" ie, anything out the cable interface masquerade. 20:40
@nirik the downside for MASQ is that if your interface goes down it forgets all connections over it. 20:41
@nirik so, if you get the same IP it's better to use SNAT, or your connections will get dropped. 20:41
@nirik when you get a new lease for example. 20:41
@nirik so, back to connections. There are a number of connection tracking modules, the default is a general purpose one called "ip_conntrack". 20:42
@nirik Basically this allows the firewall to know when packets are related to an existing connection. 20:43
@nirik back in that simple default firewall we saw: 20:43
@nirik -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 20:43
@nirik that says to accept anything that is part of an already established or related connection. 20:44
@nirik so, for example if you ssh into that machine, the inital ssh is allowed via: 20:44
@nirik -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT 20:44
@nirik and after that any packets that are related to that connection are allowed via the ESTABLISHED,RELATED rule. 20:44
@nirik if you would like to look at your connections, you can take a look at /proc/net/nf_conntrack. 20:45
@nirik There is also a package called conntrack-tools in Fedora that will let you list, examine, or manipulate the connection tracking rules. 20:46
@nirik and you can match on all kinds of state in the connection tracking info. 20:47
@nirik any questions on connection tracking? 20:47
domg472_ is the [ASSURED] related to conntrack? 20:47
nuonguy yes, what do you mean by 'related'? 20:47
erinlea80 related as in passive ftp transfers with high num. random port assignments? 20:48
domg472_ why do i see if only in my tcp connection and not a udp connection? 20:48
domg472_ it* 20:48
domg472_ i have an irc connection that is assured nd a ntp connect that doesnt have the assured tag 20:48
@nirik nuonguy: related means it's a new connection, but it's related to an existing one. Ftp transfers, icmp traffic, etc. 20:48
@nirik domg472_: it means it shouldn't be expired... it's still active. 20:49
domg472_ thanks 20:49
@nirik the ntp is probibly a request thats finished and waiting to be expired from tracking. 20:49
@nirik ftp is a weird protocol. It has it's own connection tracking module... ip_conntrack_ftp (and another one for nat: ip_nat_ftp) 20:50
domg472_ i never got that to work 20:50
domg472_ with pasv 20:50
zcat nirik, will you touch on logging/troubleshooting, since it doesn't log by default 20:50
@nirik zcat: yeah, was on the list, but I see we are running low on time. :) 20:50
@nirik To help in troubleshooting there is a LOG target. 20:51
@nirik LOG is a non terminating rule. This means it matches, runs and then goes on to the next rule like nothing happened. 20:51
@nirik So, you can add LOG rules in to see where things are and what the packets look like. 20:52
domg472_ if you append a log like it will log rejected packets? 20:52
@nirik Heres an example line from a LOG match: 20:52
@nirik DROPPING packet: IN=test OUT= MAC= SRC= DST= LEN=188 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=168 20:52
@nirik domg472_: only if it's right before the reject rule. The reject rule will match and stop processing the chain at that point... 20:53
@nirik so you need to add LOG before any rule you want to see 20:53
domg472_ oh beforeso you cannot append 20:53
domg472_ thanks 20:53
@nirik so, you might want a LOG and a REJECT at the end of each chain. That will tell you if it got to there. 20:54
@nirik also, it's often a good idea to have an explicit DROP or REJECT at the end for that reason. 20:54
zcat domg472_, yeah, being able to insert at an offset from the last rule would be handy 20:55
@nirik and as with many things it's good to have a 'if it's not explicitly allowed, reject it' 20:55
SSlater like a default DROP policy? 20:55
@nirik you can add a index to -I, but then you need to know how many rules you have -1 to insert it in the right place. 20:55
@nirik SSlater: yes. 20:55
@nirik Note that each of the standard chains have a default policy you can set. This is what happens if NOTHING in that chain matches. 20:56
domg472_ why does the default configuration allow by default on less rejected instead of deny by default unleass allowed? 20:56
@nirik you can however not log those actions. 20:56
@nirik domg472_: it shouldn't. You mean the example I posted? 20:57
domg472_ yes 20:57
domg472_ it accepts by default 20:57
kanarip domg472_, the default has a policy of ACCEPT, but explicitly REJECTs in the last rule of the RH-INPUT-Firewall chain because REJECT is an invalid policy target 20:58
domg472_ why not deny by default 20:58
erinlea80 as the default, non-matching rule, is DROP or REJECT the pref. method? Is it best to simply not send a response? 20:58
@nirik domg472_: because then you cannot log that it dropped. In that case there is no LOG, but you would have to change it more to add one. 20:58
domg472_ thanks 20:58
@nirik erinlea80: there are different schools of thought on that. 20:58
@nirik it depends on what your needs are. 20:58
kanarip erinlea80, if you REJECT you're still giving some form of information, some people do not want that and choose DROP 20:59
@nirik if you REJECT someone knows the machine is up and there. DROP doesn't tell them that. DROP means they hit a timeout, which might be anoying. 20:59
SSlater There was abig debate on Fedora -list about that. 20:59
* nirik sees we are out of time. Happy to answer more questions in #fedora or the like... 20:59
domg472_ reject returns a nice informative message right? 20:59
@nirik domg472_: it does. 21:00
zcat DROP'ing, or "stealth", causes annoying timeouts. REJECT'ing is immediate, but gives you away, if that matters. 21:00
erinlea80 it resets the connection? 21:00
kanarip when you're ready nirik ;-) 21:00
erinlea80  :) 21:00
kanarip it's 21:00 UTC 21:00
erinlea80 Thanks nirik! 21:00
domg472_ thanks nirik 21:00
zcat kudos 21:00
SSlater Thanks nirik! 21:00
Bugz_ Thanks nirik 21:00
thomasj awesome, thanks nirik 21:00
erinlea80  :) 21:00
kanarip so all of you are going to hang around for the Creating a Fedora Remix session? ;-) 21:00
N3LRX Good job nirik 21:00
neverho0d thank you nirik! 21:01

Generated by 2.7 by Marius Gedminas - find it at!