Well... I have some notes, however they are incomplete... I made a neet
little ascii graphic illustrating old ipchains files and new iptable... I
will donate my notes, and maybe someone can fill in the rest :)
Cory Peterson: Firewall Kernel 2.4
Firewall: basically a packet filter, uses rules to filter packets, to drop
or forward packets along.
This gives us control over what trafic crosses the network.
<Cory provides some interesting quotes defining firewall>
iptables, netfilter better than ipchains
States and statefullness:
anyone that has a tcp-ip stack has a firewall.?
Stateless Firewalls are simpler, in respect to creating rules, where
statefull firewalls are more dynamic with establising and monitoring ports.
statefull gives us more secure firewalls with simpler rule sets.
in the 2.4 kernel the firewalling code iection is called netfilter.
You must use iptables with netfilter to have statefull firewall, if you use
ipchains you will end up with a stateless firewall.
Theory:
chains...
Rules: input > output (allow, deny, forward)
rule1
rule2
rule3
If a packet doesnt fall under one of the rules it goes to the policy (the
policy is the defalut action to take).
tables... chains....
------------ ------- ----------
| F | | |---------| |
-----------| | I | F | O |
| I | O | | |---------| |
| | | -------- ----------
------------
I =Input
F =Forward
O =Output
IPTables Commands:
iptables -A (accept)
iptables -L -vn (show rules)
What Defines a rule:
<command> <Match> <target>
iptables -A INPUT -s 0.0.0.0. 0/0 -p tcp --dport 80 -m limit 4/day -j
ACCEPT
You can only have one target in a rule, but you can have many matches.
Jamie
On Saturday 19 May 2001 11:04 pm, you 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
