20:59:32 <bodhi_zazen> #startmeeting IPTABLES
20:59:32 <zodbot> Meeting started Thu Sep 15 20:59:32 2011 UTC.  The chair is bodhi_zazen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:59:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:59:39 <drakeman> i already have the odt :D
20:59:52 <bodhi_zazen> The topic of today's classroom is iptables, commonly referred to as your firewall.
20:59:58 <bodhi_zazen> The goal of this classroom is to explain the basic syntax of iptables.
21:00:11 <bodhi_zazen> Many people are intimidated by iptables.
21:00:34 <bodhi_zazen> if you wish, there is a graphical front end - http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Firewalls-Basic_Firewall_Configuration.html
21:00:46 <bodhi_zazen> but today I was going to discuss the rules / syntax
21:01:25 <bodhi_zazen> Honestly, one of the hardest parts is a basic understanding of networking
21:01:37 <bodhi_zazen> I would like to cover "the basics" here
21:02:03 <bodhi_zazen> Does everyone here understand ip addresses ? public vs private ?
21:02:18 <tnelis> (yep)
21:02:26 <bodhi_zazen> *we are going to talk ipv4 today - ipv6 is similar *
21:02:38 <agustinbf> yes
21:02:40 <drakeman> yep,
21:02:58 <sash_> yes
21:03:07 <bodhi_zazen> OK, network protocols - icmp / tcp / udp ?
21:03:12 <sash_> yes
21:03:16 <tnelis> yup
21:03:16 <drakeman> thats correct
21:03:17 <jrgifford> Yes and yes.
21:03:24 <drakeman> the basic :D
21:03:34 <agustinbf> not familiar with icmp
21:03:45 <bodhi_zazen> icmp is "ping" among other functions
21:04:01 <agustinbf> ok, got it
21:04:10 <bodhi_zazen> Anyone want to see what a three way handshake looks like on tcpdump ?
21:04:27 <drakeman> ok.
21:04:40 <agustinbf> yes
21:04:55 <sash_> why not?
21:05:07 <jrgifford> sounds interesting.
21:05:08 <drakeman> im taking notes :D
21:05:11 <bodhi_zazen> http://fpaste.org/sVBh/
21:05:32 <bodhi_zazen> The important points there -
21:05:54 <bodhi_zazen> on line 8 , my clinet is using port 35641
21:06:15 <bodhi_zazen> Flags [S] = syn
21:06:47 <bodhi_zazen> Line 10 - server sends an ack
21:07:16 <bodhi_zazen> Line 17 , client requests web page , Flag = P or push
21:07:44 <bodhi_zazen> Lines 24 and 28 server sends data, client acknowledges
21:08:06 <bodhi_zazen> The first packet to the server would be a NEW
21:08:14 <bodhi_zazen> The first response from the server is RELATED
21:08:36 <bodhi_zazen> After  that the connection is ESTABLISHEDl
21:09:05 <bodhi_zazen> Any background questions ?
21:09:12 <bodhi_zazen> #topic PORTS
21:09:40 <bodhi_zazen> I found it useful to think of ip addresses as post offices or apartment buildings
21:09:59 <bodhi_zazen> so servers listen on a specific port on your server ip address
21:10:16 <bodhi_zazen> How do you open a port ?
21:10:28 <bodhi_zazen> Install and start a service (apache, ssh, etc)
21:10:41 <bodhi_zazen> How do you list your open ports ?
21:10:51 <bodhi_zazen> From localhost
21:10:53 <bodhi_zazen> lsof -i -n -P
21:11:03 <bodhi_zazen> netstat -ntulp
21:11:26 <bodhi_zazen> From another client on your lan, nmap -v -A ip_address
21:11:43 <bodhi_zazen> How do you close a port ?
21:11:50 <bodhi_zazen> 1. Stop the service
21:11:52 <drakeman> with iptables :D or stopping the daemon
21:12:07 <bodhi_zazen> 2. Or you can do it with iptables, BUT ....
21:12:21 <bodhi_zazen> IMO better to stop the server if you are not going to use it
21:12:54 <bodhi_zazen> #topic packets
21:13:03 <bodhi_zazen> http://www.linuxhomenetworking.com/wiki/images/f/f0/543x760xIptables.gif.pagespeed.ic.A-oBumv4CC.png
21:13:17 <bodhi_zazen> Let me show you a summary picture ^^
21:13:43 <bodhi_zazen> Here the firewall has 2 NIC, one listening on Network A, the other on B
21:14:03 <bodhi_zazen> The picture is easier to understand if you ignore all the mangle boxes =)
21:14:30 <bodhi_zazen> A packet comes into the box -> PREROUTING tables -> notice the routing decision ?
21:15:02 <bodhi_zazen> If the packet is going somewhere else it goes out the FORWARD and POSTROUTING -> Network B
21:15:09 <bodhi_zazen> That is basically NAT
21:15:48 <bodhi_zazen> If it is going to the firewall, or server, then it goes through INPUT and to your applications (firefox or what have you)
21:16:15 <bodhi_zazen> #topic iptables rules
21:16:29 <bodhi_zazen> OK, now we get to the details
21:16:34 <bodhi_zazen> Any questions so far ?
21:16:43 <agustinbf> no
21:16:45 <drakeman> no
21:16:59 <nirik> nope. ;)
21:17:00 <sash_> no
21:17:04 <bodhi_zazen> OK, so the general syntax of iptables is iptables <option> <table> <rule> <target>
21:17:26 <bodhi_zazen> Options manipulate - add / delete update rules
21:17:43 <bodhi_zazen> table = the table, ie INPUT OUTPUT FORWARD etc
21:17:56 <bodhi_zazen> rules we will cover in a minute
21:18:09 <bodhi_zazen> target is the action to take - ACCEPT DROP LOG
21:18:40 <bodhi_zazen> The rules can be "simple"
21:18:42 <bodhi_zazen> iptables -A INPUT --dport 80 -j ACCEPT
21:18:47 <bodhi_zazen> Or Barouque
21:18:52 <bodhi_zazen> iptables -A INPUT -p tcp --dport 80 -d 192.168.1.100 --sport 1024:65535 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
21:19:17 * bodhi_zazen prefers starting with simple =)
21:19:54 <bodhi_zazen> I listed the major options here
21:20:00 <bodhi_zazen> http://fpaste.org/QOsD/
21:20:34 <bodhi_zazen> It is critical to understand that the order of your rules is very important
21:21:04 <bodhi_zazen> If your first rule is to drop a packet, it does not matter how many rules you add to accept it, it will be dropped
21:21:25 <bodhi_zazen> Similarly, if an early rule accepts a packet, you can not drop it later in your rules
21:21:49 <bodhi_zazen> -P sets the default policy, what will happen to a packet if no rule is matched
21:21:56 <bodhi_zazen> Many people set this to DROP
21:22:02 <bodhi_zazen> iptables -P DROP
21:22:20 <bodhi_zazen> but take care, if you flush your rules you can lock yourself out
21:22:40 <bodhi_zazen> so personally I set it to ACCEPT and make the last rule of a chain to DROP
21:22:56 <bodhi_zazen> You can add rules with -A or -I
21:23:14 <bodhi_zazen> -A adds to the end, -I can specify a postition
21:23:28 <jrgifford> Question real quick: so it's a heirarchal config file?
21:23:56 <bodhi_zazen> jrgifford: we will get to config files later =)
21:24:11 <bodhi_zazen> iptables -I INPUT 2 <foo>
21:24:20 <bodhi_zazen> inserts the rule second in the chain
21:24:25 <jrgifford> bodhi_zazen: Ok. :)
21:24:32 <bodhi_zazen> You can delete a rule with -D
21:24:41 <bodhi_zazen> either by rule or number
21:25:06 <bodhi_zazen> iptables -D INPUT 2 deletes the second rule
21:25:39 <bodhi_zazen> or you can iptable -D INPUT -p ..... -j ACCEPT <- type out the rule long hand
21:25:48 <bodhi_zazen> -F removes all the rules
21:26:14 <bodhi_zazen> N and X adds and removers custom chains (blacklist)
21:26:25 <bodhi_zazen> The chain must be empty to delete it
21:26:32 <bodhi_zazen> iptables -F blacklist
21:26:38 <bodhi_zazen> iptables -X blacklist
21:26:57 <bodhi_zazen> Now you can list your rules with -L
21:27:03 <bodhi_zazen> iptables -L -v -n
21:27:30 <bodhi_zazen> -v is verbose and -n disables hostname resolution, so you see ip addresses rather then host names and it is faster
21:27:52 <bodhi_zazen> Ready to cover some rules then ?
21:28:06 <tnelis> so, what we call a chain is really a set/table of rules, correct? and we send packets from chain to chain?
21:28:17 <bodhi_zazen> Yes
21:28:47 <agustinbf> ready to type
21:28:52 <bodhi_zazen> A packet hits a chain, as per the picture I showed you earlier, and then is checked against a set of rules
21:29:04 <bodhi_zazen> http://fpaste.org/PC3I/
21:29:11 <bodhi_zazen> Just the basics there ^^
21:29:29 <bodhi_zazen> I love this quote - "All the different qualities you can select a packet by are detailed in painful detail in the manual page (man iptables)."
21:29:55 <bodhi_zazen> hopefully at the end of today you will find man iptables helpful rather then overwhelming
21:30:53 <bodhi_zazen> OK, so assuming we are starting from scratch lets add a rule to accept traffic on http, port 80
21:31:23 <bodhi_zazen> iptables -A INPUT -p tcp --dport 80 -j ACCEPT
21:31:38 <bodhi_zazen> or you can use service names if you prefer
21:32:14 <bodhi_zazen> iptables A- INPUT -p tcp --dport ssh -j ACCEPT
21:32:27 <sarvesh> ok
21:32:32 <bodhi_zazen> That is for ssh (sorry for any confusion)
21:32:57 <bodhi_zazen> You can specify a range of ports --dport low:high
21:33:48 <bodhi_zazen> On the client side if you want to allow established connections
21:34:00 <bodhi_zazen> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
21:34:13 <bodhi_zazen> So here is a "basic" set of rules
21:34:15 <bodhi_zazen> http://fpaste.org/SHNH/
21:34:39 <bodhi_zazen> I usually skip setting a policy, but I included that for completeness
21:35:01 <bodhi_zazen> -i lo is the loop back interface
21:35:19 <bodhi_zazen> you could specify -i eth0 or wlan0 or what have you if you wish
21:35:36 <bodhi_zazen> Those rules then accept established traffic
21:35:43 <bodhi_zazen> drop invalid packets
21:35:57 <bodhi_zazen> allow ping, but limit it to once a second
21:36:04 <sarvesh> quick Question : What is -m
21:36:04 <bodhi_zazen> allow ssh
21:36:11 <bodhi_zazen> then reject everything else
21:36:17 <bodhi_zazen> -m is "match"
21:36:29 <sarvesh> match what?
21:36:35 <bodhi_zazen> You can then match several things, state, users, ports
21:36:35 <drakeman> rule?
21:36:48 <bodhi_zazen> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
21:36:55 <bodhi_zazen> -m state matches state
21:37:04 <bodhi_zazen> -m uid would match a user
21:37:19 <bodhi_zazen> -m multiport would match multiple ports
21:37:27 <sarvesh> ok
21:37:33 <drakeman> where do you limit ping to one second, i didnt see that rule
21:37:50 <drakeman> oh oh sorry, in the pastebin
21:37:57 <bodhi_zazen> drakeman: iptables -A INPUT -p imcp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
21:38:04 <drakeman> thansk
21:38:08 <bodhi_zazen> -m limit here matches limits
21:38:24 <bodhi_zazen> -m is basically an extended set of options
21:39:12 <bodhi_zazen> so -m limit (match is another option, here we are matching "limit) --limit 1/second (here we set the limit)
21:39:39 <bodhi_zazen> Questions on other rules ?
21:39:44 <drakeman> yes
21:39:49 <bodhi_zazen> How to use some options ?
21:39:57 <bodhi_zazen> go for it drakeman
21:40:12 <drakeman> what is an invalid in --state
21:40:26 <drakeman> in this one -> iptables -A INPUT -m state --state INVALID -j DROP
21:40:29 <bodhi_zazen> invalid would be an invalid packet, lol
21:40:39 <bodhi_zazen> One you did not request for example
21:40:46 <drakeman> ok, i understand :D
21:40:48 <bodhi_zazen> One with wrong flags
21:41:05 <bodhi_zazen> a packet a cracker designed perhaps
21:41:21 <drakeman> ok :D thanks
21:41:21 <tnelis> it's probably not relevant to this course, but i'm curious how this uid module you mentioned works, how can we id a user at this point?
21:41:37 <bodhi_zazen> Other questions ?
21:42:07 <agustinbf> what about redirection
21:42:10 <bodhi_zazen> So basically with a rule we match things such as the protocol (tcp / udp) , where it came from, where it is going to , port
21:42:30 <bodhi_zazen> agustinbf: That is more NAT, I will cover that last if we have time
21:42:48 <agustinbf> ok
21:42:49 <bodhi_zazen> So to accept ssh from your LAN ?
21:43:20 <bodhi_zazen> iptables -A INPUT -p tcp --dport -s 192.168.0.0/24 -j ACCEPT
21:43:42 <bodhi_zazen> Most of the filtering happens on the INPUT table
21:44:06 <bodhi_zazen> If you wish to filter OUTPUT you can use similar syntax
21:44:38 <bodhi_zazen> iptables -A OUTPUT -p tcp --dport -d 192.168.0.0/24 -j ACCEPT
21:44:45 <bodhi_zazen> allows outgoing ssh to your LAN
21:45:14 <bodhi_zazen> IMO filtering output is generally redundant and unnecessary
21:45:33 <bodhi_zazen> iptables -A OUTPUT -p tcp --dport --sport 1025:65535 -d 192.168.0.0/24 -j ACCEPT
21:45:45 <bodhi_zazen> allows all non-priviliged "client" ports
21:46:09 <bodhi_zazen> If there are no quesions - logging ?
21:46:14 <bodhi_zazen> #topic LOGGING
21:46:33 <bodhi_zazen> Most people thing LOG AND DROP
21:46:52 <bodhi_zazen> iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/hour -j LOG --log-level alert --log-prefix 'SSH'
21:46:54 <bodhi_zazen> iptables -A INPUT -p tcp --dport 22 -j DROP # or REJECT
21:47:17 <bodhi_zazen> I like to limit the logs because keep in mind these are packets, and your logs will get full fast
21:47:32 <bodhi_zazen> Personally I will use logging for debugging
21:47:35 <drakeman> in that rule you are allowing the ssh for 1 hour?
21:47:46 <bodhi_zazen> but generally I do not use iptables for NIDS
21:48:01 <bodhi_zazen> close drakeman , logging the ipaddress once an hour
21:48:13 <drakeman> ok thanks.
21:48:30 <bodhi_zazen> IMO if you want NIDS use snort
21:48:53 <bodhi_zazen> snort filters through the thousands of packets you receive and "alerts" you to those you need to investigate
21:49:21 <bodhi_zazen> but on a busy server, logging all packets will fill your logs very fast =)
21:49:40 <bodhi_zazen> How about some more on limits ?
21:49:47 <bodhi_zazen> #topic limits
21:49:57 <bodhi_zazen> http://fpaste.org/ZJXR/
21:50:21 <bodhi_zazen> Here I start to think of services as public vs private (http vs ssh for example)
21:50:40 <tnelis> just a quickie: earlier you mentioned that if a packet matched a rule and was either accepted or dropped, netfilters wouldn't try to match it to other rules (if i got that correctly); i assume this doesn't apply with the LOG target?
21:50:57 <bodhi_zazen> correct tnelis
21:51:15 <bodhi_zazen> log just logs the activity
21:51:31 <tnelis> is it possible to specify this behavior when creating a custom chain?
21:51:37 <bodhi_zazen> Those rules for ssh allow 8 connection attempts
21:51:40 <bodhi_zazen> tnelis: yes
21:51:46 <bodhi_zazen> custom chains next =)
21:51:48 <tnelis> (ok, thanks)
21:52:08 <bodhi_zazen> keep in mind, each ssh connection attempt is say 3 passwords
21:52:28 <bodhi_zazen> After 8 attempts , 9+ will be dropped
21:53:06 <bodhi_zazen> -m recent starts tracking the connection attempts , --set --name gives it a name
21:53:43 <bodhi_zazen> On line 14 -rttl matches on time to live , so helps if your intruder changes ip addresses (hope that makes sense to you all)
21:54:09 <bodhi_zazen> --update 600 tracks the connection attempt for 600 seconds, or 10 min
21:54:20 <bodhi_zazen> After 10 min they can again try to connect on ssh
21:54:51 <bodhi_zazen> This is effective at stopping script kiddies as they are called without having to install an additional service
21:55:08 <bodhi_zazen> I find they go away after a few attempts =)
21:55:35 <bodhi_zazen> The rules for apache are more liberal , apache is very fast
21:56:11 <drakeman> can i ask a question about the limit in the rule that i asked before? you answer loggin the ip paddres once in an hour, so it will be one log every hour? if there is someone conected?
21:56:11 <bodhi_zazen> But if you connect to a server with these rules and try a poor mans DOS (by refreshing as fast as possible) you will see they limit abusive traffic
21:56:40 <bodhi_zazen> drakeman: yes, but you can configure that
21:56:55 <drakeman> ok thanks
21:57:05 <bodhi_zazen> -m state --state NEW would match only new connections , so it would not log ESTABLISHED
21:57:20 <drakeman> excellent, thanks
21:57:36 <bodhi_zazen> #custom chains
21:57:44 <bodhi_zazen> http://fpaste.org/WcaJ/
21:57:56 <bodhi_zazen> Again to continue on the public / private theme
21:58:22 <bodhi_zazen> In general you want to allow all traffic on http (public server) and allow only certain ip on ssh (private server)
21:58:34 <bodhi_zazen> so on http , allow all and blacklist abusive IP
21:58:48 <bodhi_zazen> On ssh, block all, and allow a white list
21:58:59 <bodhi_zazen> -N makes the custom chain
21:59:08 <bodhi_zazen> we then -A or -I as with other chains
21:59:27 <bodhi_zazen> You can add in logging if you wish
22:00:05 <bodhi_zazen> So line 6 sends http traffic to the blacklist chain (lines 9 & 10)
22:00:39 <bodhi_zazen> if the ip matches those bad boys it is dropped, otherwise it returns to line 7 and is accepted
22:00:52 <bodhi_zazen> Similar behavior with ssh, but with ssh we drop
22:01:15 <bodhi_zazen> #topic saving your changes
22:01:25 <bodhi_zazen> To save your changes ...
22:01:45 <bodhi_zazen> 1. On Fedora - /etc/init.d/iptables save
22:01:53 <bodhi_zazen> or use iptables-save
22:02:04 <bodhi_zazen> iptables-save will dump the rules to your console
22:02:22 <bodhi_zazen> iptables-save > /etc/iptables.save dumps them to a file
22:02:30 <bodhi_zazen> you will see all your chains there
22:02:42 <bodhi_zazen> and your rules are listed without the "iptables"
22:03:08 <bodhi_zazen> -A INPUT <rule> <action>
22:03:14 <bodhi_zazen> to restore from a file
22:03:28 <bodhi_zazen> iptables-restore < /etc/iptables.save
22:03:56 <bodhi_zazen> We are at the 1 hour mark - so I was planing on 30 min for open questions
22:04:04 <bodhi_zazen> #topic QUESTIONS
22:04:29 <bodhi_zazen> If there are no questions, and people are not overwhelmed I can cover NAT
22:04:47 <sarvesh> yes please
22:04:56 <agustinbf> please
22:05:05 <bodhi_zazen> Does everyone understand this rule ?
22:05:07 <bodhi_zazen> iptables -A INPUT -p tcp --dport 80 -d 192.168.1.100 --sport 1024:65535 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
22:05:38 <drakeman> i think yes , but not sure
22:05:56 <bodhi_zazen> drakeman: what part do you not understand ?
22:06:05 <tnelis> DMZ for .100, almost?
22:06:14 * bodhi_zazen prefers questions first , nat takes just a few minutes
22:06:39 <tnelis> oh wait, nvm
22:06:42 <bodhi_zazen> .100 would be the ip address of the server, the destination of the packet, where we are running these rules
22:06:52 <drakeman> mm you are taking input on port 80 coming from 192.168.1.100 between ports 1024 and 65535 in the interface eth0 mathing state new,stablished
22:06:58 <bodhi_zazen> -d your_public_ip
22:07:09 <drakeman> between source ports sorry :D
22:07:34 <bodhi_zazen> Yes, clients use random high ports, thus sport 1024:65535
22:07:45 <drakeman> ok, its clear then :D
22:07:47 <bodhi_zazen> All that syntax is not necessary
22:08:08 <bodhi_zazen> Sometimes people will specify a network interface -I eth0 or what not
22:08:25 <tnelis> another quick one: do you know if NEW implies RELATED? (does that make sense?)
22:08:29 <bodhi_zazen> but if you understand that rule, you are going to understand 90 % of what you see posted about iptables
22:08:43 <bodhi_zazen> NEW != RELATED
22:08:56 <bodhi_zazen> New is the initial syn packet in the 3 way hand shake
22:08:59 <drakeman> ok, i read some time before a basic iptables setting and the rules allows ssh only 3 or 4 connections and every other attempt it logs the failure in /proc/net/ or something similar, how they do that rule
22:09:09 <bodhi_zazen> Related it (usually) the second packet, syn-ack
22:09:38 <bodhi_zazen> s/is/is
22:10:05 <bodhi_zazen> drakeman: do you have a link ?
22:10:17 <drakeman> uhh let me see if i cant find it quickly
22:10:34 <bodhi_zazen> otherwise I use http://fpaste.org/ZJXR/
22:10:53 <bodhi_zazen> drakeman: if you find it later, and I am on irc I would be happy to look at it
22:11:00 <drakeman> thanks
22:11:21 <bodhi_zazen> As always, there are usually 5 ways of doing the same thing
22:11:40 <drakeman> bodhi_zazen, this is not the same rule but very similar ---> http://www.ducea.com/2006/06/28/using-iptables-to-block-brute-force-attacks/
22:11:53 <drakeman> when they use --hitcount
22:11:54 <bodhi_zazen> Some people use very Barouque rules when a simple one would work as well
22:12:30 <bodhi_zazen> yep, similar options drakeman , I hope you understand the syntax ?
22:13:02 <bodhi_zazen> See line 14 here : http://fpaste.org/ZJXR/
22:13:05 <drakeman> this line is confusing to me --> iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
22:13:11 <drakeman> ok
22:13:19 <bodhi_zazen> SSHSCAN is a custom table
22:13:39 <drakeman> yes, i did not understand from -m recent to hitcount 3
22:13:51 <bodhi_zazen> -m recent ... remember match is a set of options,
22:14:01 <drakeman> ok.
22:14:07 <bodhi_zazen> here we are using the option "recent" to track connections
22:14:32 <bodhi_zazen> update - how long to track ? a minute ? an hour --update --seconds 600
22:14:45 <bodhi_zazen> hitcount and name should be obvious
22:15:15 <bodhi_zazen> so basically drop any connection from any ip in the last 10 minutes with a hit count > 3
22:15:31 <drakeman> ok
22:15:34 <bodhi_zazen> you can add in -m state --state NEW or LOG or what you wish
22:15:52 <bodhi_zazen> NAT in 15 minutes anyone ?
22:15:52 <drakeman> bodhi_zazen, excellent , thanks
22:16:01 <tnelis> is the timer per-IP or global?
22:16:14 <bodhi_zazen> in the first line it is per IP
22:16:26 <bodhi_zazen> In line 14 http://fpaste.org/ZJXR/
22:16:41 <bodhi_zazen> -rttl tries to track by ttl or time to live
22:17:14 <tnelis> hmm okay, isn't that sort-of-a-long shot?
22:17:14 <sarvesh> what is --limit-burst 20
22:17:16 <bodhi_zazen> The ttl is going to be the same for ip 1.2.3.4 and 1.2.3.5 , so if your attacker simply changes ip, ttl still (tries) to track them
22:17:32 <bodhi_zazen> yes tnelis , very much so
22:17:41 <tnelis> but better than nothing, i guess
22:17:45 <bodhi_zazen> yep
22:17:57 <bodhi_zazen> exactly sarvesh
22:18:03 <bodhi_zazen> oosp, tnelis
22:18:05 <bodhi_zazen> lol
22:18:16 <bodhi_zazen> sarvesh: bad example on my part, sorry
22:18:46 <bodhi_zazen> take --limit 1/minute --limit-burst 20
22:19:05 <bodhi_zazen> would allow one connection per minute, an a burst of up to 20 / second
22:19:25 <bodhi_zazen> I suppose they could chain connections second-by-second
22:19:52 <bodhi_zazen> on http you will see a "burst" with new connections due to pipeling
22:20:11 <sarvesh> ok
22:20:21 <bodhi_zazen> See also : http://thelowedown.wordpress.com/2008/07/03/iptables-how-to-use-the-limits-module/
22:20:36 <bodhi_zazen> OK, nat ?
22:20:47 <drakeman> go
22:20:50 <bodhi_zazen> #topic NAT
22:20:58 <bodhi_zazen> again see : http://www.linuxhomenetworking.com/wiki/images/f/f0/543x760xIptables.gif.pagespeed.ic.A-oBumv4CC.png
22:21:11 <bodhi_zazen> iptables -L -v -n -t nat
22:21:18 <bodhi_zazen> Basically we have a router
22:21:50 <bodhi_zazen> a computer with 2 network interfaces, A to "the internet" and B to 192.168.0.0/24
22:22:09 <bodhi_zazen> Packets come in and hit the PREROUTING table
22:22:41 <bodhi_zazen> iptables -t nat PREROUTING -p tcp -i eth0 -o eth1 -d your_public_ip --dport 80 -j DNAT --to 192.168.1.10:80
22:22:55 <bodhi_zazen> That rule is for "port forwarding"
22:23:11 <bodhi_zazen> It takes incoming traffic to port 80 ...
22:23:28 <bodhi_zazen> and directs it to your internal server -j DNAT --to ...
22:24:06 <bodhi_zazen> You then allow in your FORWARD chain
22:24:07 <bodhi_zazen> iptables - A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.1.10 --dport 80 -m state --state NEW -j ACCEPT
22:24:33 <bodhi_zazen> Notice the -I eth0 and -o eth1 ?
22:24:44 <bodhi_zazen> in from eth0 and going out eth1
22:25:13 <bodhi_zazen> Now how do we allow the clients on 192.168.0.0/24 out ?
22:25:21 <bodhi_zazen> Here we use SNAT
22:25:46 <bodhi_zazen> If your ip provider uses DHCP
22:25:48 <bodhi_zazen> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
22:25:57 <bodhi_zazen> If you have a static IP
22:26:03 <bodhi_zazen> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to your_static_ip_address
22:26:21 <bodhi_zazen> SNAT changes the source IP in the packet to your public ip address
22:26:46 <bodhi_zazen> so a packet coming from a private, non-routable ip (192.168.1.2) is changed to your public ip
22:26:50 <bodhi_zazen> iptables tracks the packet
22:27:16 <bodhi_zazen> and when it comes back, changes the destination from your_public_ip to 192.168.1.2
22:27:21 <bodhi_zazen> Same with DNAT
22:27:31 <bodhi_zazen> you had a connection coming to your server
22:28:16 <bodhi_zazen> you took a packet coming to your_public_ip:80 and changes the packet to 192.168.1.100:80 (assuming your server is on 192.168.1.100 )
22:28:32 <bodhi_zazen> SNAT - where the packet came from , allows clients out
22:28:47 <bodhi_zazen> DNAT - where the packet is going to - allows port forwarding
22:29:00 <bodhi_zazen> For details see : http://fedoraunity.org/Members/kanarip/iptables-howto
22:29:03 <tnelis> i suppose these *NAT chains are built-in filters we can't alter with -A/-I/-D?
22:29:16 <bodhi_zazen> tnelis: no , you manage them the same
22:29:33 <tnelis> oh okay
22:29:42 <bodhi_zazen> iptables -t nat -A  PREROUTING <rule> <action>
22:30:07 <bodhi_zazen> it is just the you still generally use the FORWARD chain in your filtering table
22:30:13 <bodhi_zazen> http://www.linuxhomenetworking.com/wiki/images/f/f0/543x760xIptables.gif.pagespeed.ic.A-oBumv4CC.png
22:30:40 <bodhi_zazen> See the outgoing connection from "Data for the firewall" --- > Network B
22:31:02 <bodhi_zazen> see "filter Table FORWARD chain" ?
22:31:20 <tnelis> oh yes, but, aren't targets/actions just some other chains? (usually, probably not here)
22:31:21 <bodhi_zazen> so ...
22:31:24 <bodhi_zazen> port forward
22:31:26 <bodhi_zazen> iptables -t nat PREROUTING -p tcp -i eth0 -o eth1 -d your_public_ip --dport 80 -j DNAT --to 192.168.1.10:80
22:31:36 <bodhi_zazen> see the -t nat ?
22:31:42 <bodhi_zazen> And accept the connection
22:31:43 <bodhi_zazen> iptables - A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.1.10 --dport 80 -m state --state NEW -j ACCEPT
22:32:14 <bodhi_zazen> targets are ACCEPT / DROP / REJECT
22:32:16 <bodhi_zazen> or LOG
22:32:36 <tnelis> i was also wondering about the -t switch yes, the manpage seems to make a distinction between tables and chains -- is that interesting or just some internal/logical grouping?
22:32:38 <bodhi_zazen> OR perform DNAT (change the destination) or SNAT (change the source)
22:33:05 <bodhi_zazen> You have two major tables
22:33:13 <bodhi_zazen> the default is the filter table
22:33:21 <bodhi_zazen> the other table is NAT
22:33:27 <bodhi_zazen> Each table has chains
22:33:40 <bodhi_zazen> filter - INPUT , OUTPUT , FORWARD
22:33:50 <bodhi_zazen> user those for filtering (blocking) connections
22:34:17 <tnelis> got it, thanks
22:34:33 <bodhi_zazen> nat has PREROUTING POSTROUTING
22:34:44 <bodhi_zazen> use those for DNAT / SNAT
22:35:03 <bodhi_zazen> remember with DNAT and SNAT you are changing the header in the packet
22:35:22 <bodhi_zazen> We sort of covered NAT very fast =)
22:35:57 <bodhi_zazen> We are at 90 minutes, any other questions ?
22:35:59 <tnelis> yes, i just read the rest of the descriptions of the page, it makes perfect sense now (btw feel free to tell me to rtfm at this point)
22:36:03 <bodhi_zazen> #topic feedback
22:36:17 <bodhi_zazen> I am hoping to do a few classroom sessions
22:36:23 <bodhi_zazen> please suggest topics
22:36:27 <bodhi_zazen> and feedback
22:36:49 <bodhi_zazen> was it helpful to have documents available for review before the session ?
22:36:52 <tnelis> well i saw your interest in LXC on your page, if i'm not mistaken
22:37:00 <bodhi_zazen> Too much information / too little
22:37:07 <bodhi_zazen> too fast / too slow ?
22:37:38 <sarvesh> It was appropriate ... and helpful
22:37:44 <bodhi_zazen> Please add topics to : http://fedoraproject.org/wiki/Classroom
22:38:04 <bodhi_zazen> You can send feedback via PM, email whatever
22:38:15 <bodhi_zazen> improvement only comes from feedback =)
22:38:18 <tnelis> *I have another question* -- http://www.urbandictionary.com/define.php?term=barouque
22:38:29 <bodhi_zazen> I will hang here for questions for a half hour or so ?
22:39:11 <bodhi_zazen> tnelis: did I spell it wrong ? lol
22:39:16 <bodhi_zazen> http://www.merriam-webster.com/dictionary/baroque
22:39:26 <bodhi_zazen> #endmeeting