I don't want to take anything away from Corys' excellent presentation, it was very informative and I learned a lot, I just didn't take any notes. It was my first Sat meeting and one I didn't want to miss. Thanks Cory. This AM I was catching up on some of my emails and found this two week old tutorial from IBM - yes, IBM. Just thought it might come in handy for those that missed the meeting. All it will cost you is to register for the tutorial (a user ID, password and email) and once that is done, you will be able to take any of the tutorials you feel is of interest. ::: Linux 2.4 Stateful Firewall Design ::: In this tutorial you'll learn how to use netfilter to set up a powerful Linux stateful firewall -- and, in the process, you'll gain several example configurations to use in your own projects. http://www-106.ibm.com/developerworks/education/r-fw.html?n-l-5101 Dave On Sat, 19 May 2001, Cory Petkovsek wrote: > > Thanks Jamie. > > Here is a supplement to my lecture. Rob will you please post this, and the firewall >scripts I'll be sending you to the euglug site? Did someone happen to take notes >that they would be willing to send to Rob and the list to complement this information >here? > > Cory > > > Kernel modules needed for netfilter (some are optional): > config_netfilter (network packet filtering) > config_ip_nf_conntrack (connection tracking) > config_ip_nf_ftp (provides ftp support, two mods: ip_nat_ftp, ip_conntrack_ftp) > > config_ip_nf_iptables (iptables support) > config_ip_nf_match_limit (good one) > config_ip_nf_match_unclean (experimental, matches invalid packets) > config_ip_nf_match_state (required for statefulness) > config_ip_nf_filter (required) > config_ip_nf_reject (generates a return packet) > config_ip_nf_nat (required to do nat) > config_ip_nf_mangle (only needed for the mangle table. I don't use this) > config_ip_nf_log (good one to have) > > > Links > > Read through the packet filtering and NAT howtos, the iptables man page > Netfilter site / CVS / HOWTO's / Mailing list > http://netfilter.samba.org > > Ulogd -- client app > http://www.gnumonks.org/gnumonks/projects > --Must have ulog target in kernel. Currently requires patch-o-matic from netfilter >cvs (see ulogd install docs for info). > > Obsid's rf.firewall.iptable scripts -- those really big, complex scripts > http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/ > > > Misc > > # Get IP address from ifconfig, assign it to a variable > intip=`ifconfig |grep -A1 $intif |grep -v $intif \ > |cut -f 2 -d \: |cut -f 1 -d \ ` > > > Conntrack > > With iptables, netstat -M (show masqueraded connections) doesn't work. We have a >work around until it's fixed. > > cat /proc/net/ip_conntrack > > Here's a description of the fields from the netfilter firewall list: > > Alexander V Alekseev wrote: > OK, now, in order: > > tcp 6 431985 ESTABLISHED src=1.2.3.4 dst=5.6.7.8 sport=1023 dport=22 src=5.6.7.8 > +dst=1.2.3.4 sport=22 dport=1023 [ASSURED] use=1 > > First is, of course, protocol name, second is protocol number, > third field is TTL, i.e. number of seconds till this entry will > expire (in current state, which is represented by fourth field). > > Connection state field (if present, and usually it is present only > for UDP and TCP) may have few values, meaining is obvious (I hope). > > First src/dst/sport/dport shows how this connection seen from > _your_ side (i.e., in case if you use NAT you will see original > source but real destination), second src/dst/etc shows how this > connection is seen from connection endpoint (again, in case of NAT > it will show real but not local IP on your side). > > Most useful, I think, would be explanation how to "decipher" > masqueraded connections, so lets go.. > > I assume that real IP of your host is 128.1.1.1, real IP of server > you are connecting to is 129.1.1.1, and your internal IP (behind > firewall) is 10.1.1.1, in this case record will look like this: > > tcp 6 431985 ESTABLISHED src=10.1.1.1 dst=129.1.1.1 sport=1023 dport=22 > +src=129.1.1.1 dst=128.1.1.1 sport=22 dport=50000 [ASSURED] use=1 > > This way, you can easily find out where your masqueraded host is > connected to, and also you see how it looks from the server itself > (in my example it thinks that connection is coming from 128.1.1.1 > port 50000, and if you will reverse the src/dst you will see _how_ > your connection is masqueraded/NATed). > > Last two fields are not so important, IMHO (to be honest, I don't really > know their exact meaning, but fields that I've described give a lot of > info already). > > Hope this helps... > > /Al Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com
