Firewall Basics (2008-11-09 classroom)

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!