Firewall Basics (2008-11-09 classroom)

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

IRC Log of the Class

 20:00 -!- nirik changed the topic of #fedora-classroom to: Fedora Classroom -
 Introduction - See https://fedoraproject.org/wiki/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:01 <@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:02 <@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
 https://fedoraproject.org/wiki/Communicate/IRC/Classroom for more info
 20:02 <@nirik> First, a bit of history:
 20:03 <@nirik> The Linux kernel has had a number of firewall
 systems... ipfwadm,
 ipchains and now currently something called netfilter
 20:04 <@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:05 < 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:06 < 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:07 <@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:08 <@nirik> "tables" are sets of chains. The standard ones are:
 filter, nat, mangle
 20:09 <@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:10 <@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:11 <@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:12 <@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:13 <@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:14 < 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:15 <@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:16 <@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:17 < 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:18 < 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:19 <@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:20 <@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:21 <@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:23 <@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: firestarted, fwbuilder, and shorewall to name a few.
 20:24 <@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:25 <@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:26 <@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:27 <@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:28 < 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:29 <@nirik> lets talk a bit about NAT.
 20:30 <@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:31 <@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:32 <@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:33 <@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:34 <@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:35 <@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:36 <@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:37 <@nirik> domg472_: yes, note that one is used in POSTROUTING and
 the other in PREROUTING.
 20:37 < domg472_> DNAT is postrouting?
 20:38 <@nirik> domg472_: other way. DNAT is PRE and SNAT is POST
 20:38 < domg472_> thanks
 20:39 <@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:40 <@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:41 <@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:42 <@nirik> so, back to connections. There are a number of connection
 tracking modules, the default is a general purpose one called "ip_conntrack".
 20:43 <@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:44 <@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:45 <@nirik> if you would like to look at your connections, you can take
 a look at /proc/net/nf_conntrack.
 20:46 <@nirik> There is also a package called conntrack-tools in Fedora
 that will let you list, examine, or manipulate the connection tracking rules.
 20:47 <@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:48 < 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:49 <@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:50 <@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:51 <@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:52 <@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:53 <@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:54 <@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:55 < 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:56 <@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:57 <@nirik> domg472_: it shouldn't. You mean the example I posted?
 20:57 < domg472_> yes
 20:57 < domg472_> it accepts by default
 20:58 < 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:59 < 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?
 21:00 <@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:01 < neverho0d> thank you nirik!
 21:01 < erinlea80> Woohoo remix!
 21:01 < GnuBoi> now fedora remix