Why Security?
<p> 
The FBI is not your best friend, they don't know you didn't do it.<br> 
It's really time consuming backing up.<br>
It's even more time consuming restoring from your back up every other day. (every ten minutes if you run IIS, I'll show you the logs.)<br>
Expect to DOSed into oblivion every time you start to win at quake3.<br>
It's embarassing to have your love letters posted on usenet.<br>
<p>
How do I practice good security?<p>
You can... <br>
<DL><dt>Make all remotly accesable programs unexplotable.
 	<dd>	*Do all vendor/distro patches avaible. "rpm -U *" 
		"apt-get update;apt-get upgrade"
	</dd><dd>	*Run a vendor/distro where patches are avaible quickly 
		and easily(debian,ximian on anything for desktops)
	</dd><dd>	*review, understand and amend configuration of remotly 
		accesable programs "cat /etc/*"
</dd><dd>		*limit program permisions, and their ability to do damage 
		"find / -perm +4000"</dd></dl>
	<dl><dt>You make all remotly accesable programs unreachable.  
		</dd><dd>*Shut off programs not being used "netstat -a" 
		</dd><dd>*Limit network access to programs at the kernel level. 
		(firewalling)
</dd></dl>
Why Firewall?<p>

<dl><dd>Because you are a geek.(at least the potential is there.)	
</dd><dd>Geeks are power users.
</dd><dd>Power is attractive to the oppisite sex.
	</dd></dl>
<p>side note: Because redundancy is good.  To protect less flexible/safe machines 
behind the firewall.
<p>
Why Linux?
<p>	
	Well duh.  Linux is powerfull and power is....ya know. 
<p>
Why teach iptables and not ipchains? 
<dl><dd>
*IP chains is 2.2 kernels and widely documented/used.  So why no use it?  Becaus e iptables (front end to the netfilter 2.4 kernel code.) is much more flexible.  I found many specific reasons, but these stood out. 
</dd><dd>
*Firewalling code is too intrusive and dosn't belong in the kernel.  (Want to become a kernel hacker that Linus favors?  Find somthing to move out of the kernel, without sacrificing meaningful speed, security or features.)
</dd><dd>
*Now anyone can write user space programs to use as filters without doing kernel work.
</dd><dd>
*There are more points in the kernel networking process at which you can work with packets.
 </dd><dd>
*Now filtering can be done with MAC (Media Access Control) hardware addressing as well as IP (Internet Protocol) addressing and protocol type/port addressing. (a blessing for small high risk networks.)
</dd><dd>
*Sorting through dropped packets is now possible.  Setting up counters is also possible 
</dd><dd>
*Full support for Network Address Translation(NAT) filtering at all points in packet entry/exit (also known as: IPmasq or IP masquerade.)
</dd><p>
What are we looking to filter out?
<p>
	That's easy.  The bad stuff.  Basiclly all incoming packets that we 
	didn't somehow request or ask for.
<p>
What are we looking to let through?
<p><dl><dd>
	*Outgoing packets.  Possibly specifying legitimate machines by IP or MAC 	address.
</dd><dd>
  	*You don't want to stop yourself from ssh/scping (Secure SHell/ Secure a
	CoPy) into your own machine.  You want to allow any machine to come in 
	on port 22.(If you can find the #^@&*$ thing with the ISP (Internet 
	Service provider) changing your IP address all the time. PS: look into 
	dyndns.org)   
	 </dd><dd>
	*If you are building the website of the century, you proably want people 	to be able to get though to apache on port 80. 
 </dd><dd>
	*If you are building the ftp site of the millenium, you probably want 
	to let any machine through on port 21.
</dd></dl><p>
What are TCP/UDP ports, IP Address, and MAC address?
<p>
<table border="2" width="13" cellpadding="2">
<tr>
<td>OSI Layer<td>Name of data<td>Human Representation <td>Role or meaning
<tr><td>	
Tangable end of OSI spectrum (touch the wire or the card) 
<tr>
<td>1<td>Binary<td>10101010111001100110<td>voltages/lights on network wire.
<tr>
<td>2<td>MAC<td>0012:33F9:2902<td>Unique address burned into card.<tr>
<td>3<td>IP<td>192.168.100.200<td>Logical Topolgy of Internet.<tr>
<td>4<td>TCP/UDP port<td>80, 21, 22<td>represent specific applications.<tr>
<td>5<td>N/A<td>N/A<td>inter application talk<tr>
<td>6<td>N/A<td>N/A<td>file formats, data storage<tr> 
<td>7<td>N/A<td>N/A<td>application itself
<tr><td>
Abstract end of OSI spectrum (orginizational ideas.)
<tr>
</table>
<p>
The three that concern us are the MAC (psudo-random number)and IP (Logical Topolgy) addresses and the TCP/UDP port (number corrilates to program type.)  The first two are dictated, at least in part, by a central authority.  The port is flexable and can be changed to anything so long as the applications on the two computers allow it to be changed.
<p>
What software do I need?
<p>
You need a 2.4 series or better linux kernel with netfilter compiled into it.
	Most distrabutions will come with such a kernel. 
	I am not going into making your own kernel here, but if you know how, 
	select the following module from make menuconfig... 
<br>	networking options -> network packet filtering 
<p>	and go into the
<br>	networking options -> IP netfilter configuration
<p>	menu and select the modules that interest you, like the NAT module.
<p>
You will also need the iptables software.  If your system came with 2.4.x or better you already have it. 
<p>
How do I start?
<p>
You should start by setting up NAT also known as: ipmasq.  
<p>
What is NAT?
<p>
Network Adress Translation is a kinda like a router in that it fowards packets from one interface or network card to another.  It uses fake or unrouteable adresses on the side hidden from the internet.  All the packets that travel through the NAT box appear to come from it to the outside world.  It's likely the main reason that people aren't scrambling to move to a new IP version to run the Internet.  We can now use alot less real addresses.
<p>

How do I set up NAT?
<p>
If you don't use NAT you can ignore this. 
<p>
NAT is alot simpler to set up with 2.4 and IPTABLES than it was in 2.2 or 2.0. The offical word is that NAT was a cheap hack in those kernels.
<p>
You need to switch to root.
First you need to insert or load the modules so the kernel understands what iptables is telling it.
<p>
"modprobe iptable_nat"
<p>
This loads the iptable_nat.o ip_conntrak.o and ip_tables.o modulesinto the kernel.
<p>
Now we neet to set up a rule to call our kernel module.   
<p>
"iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" 
<p>
The "eth0" part of this should represent the outgoing or ISP facing interface.
<p>
now we must phone the kernel and say "hey this is A-OK"  We do this by writing plain old boring text to the phony or virtual file system in proc.
<p>
"echo 1 > /proc/sys/net/ipv4/ip_forward"
<p>
If you look around in that directory "ls -a /proc/sys/net/ipv4" you will notice alot of very cool information and settings. The proc filesystem is definatly our friend. 
<p>
Congrats NAT is set up.
<p>
What now?
<p>
So glad you asked. :)  Next we should start blocking traffic we didn't ask for.
<p>
What aren't you telling me?
<p>
Alot.  I think this is a good question to ask somtimes, great for disarming the dishonest.  There are some useful proc options that are set correctly by default.<p>

"/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects"
<br>"/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses"
<p>
This one will only work inside a script.
<br>"for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
   /bin/echo "1" > ${interface}
done"
<br>This one is only OK if you are not running NAT
<br>"/bin/echo "0" > /proc/sys/net/ipv4/ip_forward"
<p>
Were any proc options usefull?
<p>
One option that didn't show up by default in the kernel was
<p>"/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians"
<p>
This logs spoofed packet attempts.  Just be warned this may cause strange side effects if you and your ISP are using reserved IP address  from the same subnet like 192.168.x.x or 10.x.x.x.
<p>
What about this IP Tables we heard so much about?
<p>
Lets flush all iptables rules, so we know where we are starting.
<p>
"iptables -F" 
<p>
And lets zero out our counters...
<p>
"iptables -Z"
<p>
And lets kill user defined chains too...
<p>


Now lets be insanly parinoid and shut all incomming and outgoing packets off.
<p>
"iptables -P INPUT DROP"
<br>"iptables -P OUTPUT DROP"
<p>
Non-NAT people could also shut off forwarding packets with a "iptables -P FORWARD DROP"
<p>
Experimenting with this is a bit strange. At this stage you can't ping the NAT box but you can ssh through it.  Weird.  If you have a dedicated NAT only box you might want to stop here.
<p>
Lets unbreak loopback allow everything on the loopback device.  Lots of legitimate things use it.
<p>
"iptables -A INPUT  -i lo -j ACCEPT"
<br>"iptables -A OUTPUT -o lo -j ACCEPT"
<p>
OK Lets let our first port through.  DNS lookups are important. :)
<p>
"iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT"
<br>"iptables -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT"
<p> 
And Lets let the web through, both ways.  too...
<p>
"iptables -A INPUT -i eth0 -p tcp --sport 80 -j ACCEPT"
<br>"iptables -A OUTPUT -o eth0 -p tcp --sport 80 -j ACCEPT"
<p>
And last but not least ssh
<p>
"iptables -A INPUT -i eth0 -p tcp --sport 22 -j ACCEPT"
<br>"iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT"
<p>


Sources...
<p>
http://netfilter.filewatcher.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc.html
<p>http://packetstormsecurity.org/UNIX/firewall/ipchains/netfilter/netfilter-HOWTO.html
<p>http://www.cs.princeton.edu/~jns/security/iptables/