From Fedora Project Wiki
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 Communicate/IRC/Classroom 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 Communicate/IRC/Classroom 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 | http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html | 20:10 |
| @nirik | and a more complex one: | 20:10 |
| @nirik | http://www.aptalaska.net/~jclive/IPTablesFlowChart.pdf | 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: http://fpaste.org/paste/8806 | 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 http://jstanley.fedorapeople.org/firewall.png 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 10.1.1.8 -o dsl -j SNAT --to-source xxx.xxx.xxx.xxx' | 20:32 |
| @nirik | that says use the nat table, Append a rule to the POSTROUTING chain, match anything with a source of 10.1.1.8 (an internal machine) thats going out (-o) the dsl interface and make it use xxx.xxx.xxx.xx 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 10.1.1.8 machine could go out to the internet, the firewall would re-write those packets to appear to come from xxx.xxx.xxx.xxx and then take replies and send them back to 10.1.1.8 | 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 192.168.1.100 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.1.1.104 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 192.168.1.100 (an external ip) send it to 10.1.1.104 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=172.17.17.254 DST=172.17.17.255 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 irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!