|
P.S.
almost forgot......I have a router (Cisco806 DSL)
which is where I will have my external public ip address (on order) and this
will be configure in a nat table on the router it self that will point to
eth0...sorry about that. All Im doing is playing with iptable scripts so as to
get some sort of handle on configuring the netfilter iptables firewall. This
particular exercise is to allow icmp packets to flow through to the DMZ
machines.
thanks
Tim
----- Original Message -----
From: Tim
To: iptables
Sent: Sunday, July 07, 2002 4:32 PM
Subject: seeking heavy weaponry !! Hey ppl,
In Rusty Russell's packet filtering HOWTO there is
an introduction, (to make short), "This HOWTO flips between a gentle
introduction (which will leave you feeling warm and fuzzy now, but unprotected
in the real world) and raw full-disclosure (which would leave all but the
hardiest souls confused, paranoid and seeking heavy weaponry)."
I feel like the latter, seeking heavy weaponry, I
must be missing (obviously, since I'm writing to the list) something in my
configuration of either the script or the box itself. This is what my script
looks like:
#!/bin/bash
# # This is my first attempt at a personalized iptables script # # ## Variables ## LOOPBACK="lo" ## Loopback Interface EXTERNAL_NET="eth0" ## External Interface DMZ_NET="eth1" ## DMZ Interface INTERNAL_NET="eth2" ## Internal Interface # # INTERNAL="192.168.1.0/24" ## Network address for internal network DMZ="172.16.1.0/24" ## Network address for the DMZ EXTERNAL="192.168.2.0/24" ## Network address for external network # # ##INT_IP="192.168.1.11" ## IP address of Internal Interface INT_IP=`ifconfig $INTERNAL_NET | grep "inet addr" | cut -d ":" -f 2 | cut -d " " -f 1` # ##DMZ_IP="172.16.1.1" ## IP address of DMZ Interface DMZ_IP=`ifconfig $DMZ_NET | grep "inet addr" | cut -d ":" -f 2 | cut -d " " -f 1` # ##EXT_IP="192.168.2.1" ## IP address of External Interface EXT_IP=`ifconfig $EXTERNAL_NET | grep "inet addr" | cut -d ":" -f 2 | cut -d " " -f 1` # LOG_LEVEL="notice" ## Default log level: kern.notice: # ## Routing packets (traffic) between interfaces echo 1 > /proc/sys/net/ipv4/ip_forward # # echo "[---Flushing the chains---]" iptables -F iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD # # # echo "[--Setting Policies--]" iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD ACCEPT # # ## Allow inside traffic to get to the DMZ and back iptables -A FORWARD -i $INTERNAL_NET -o $DMZ_NET -j ACCEPT iptables -A FORWARD -i $DMZ_NET -o $INTERNAL_NET -j ACCEPT iptables -A INPUT -i $INTERNAL_NET -s 192.168.1.0/24 -d 172.16.1.0/24 -p icmp -j ACCEPT iptables -A OUTPUT -o $DMZ_NET -s 172.16.1.0/24 -d 192.168.1.0/24 -p icmp -j ACCEPT iptables -A INPUT -i $DMZ_NET -s 192.168.1.0/24 -d 172.16.1.0/24 -p icmp -j ACCEPT iptables -A OUTPUT -o $INTERNAL_NET -s 192.168.1.0/24 -d 172.16.1.0/24 -p icmp -j ACCEPT # # After I loaded the script and verified with the
command iptables -L I go to one of my internal machines and attempt to ping one
of the two machines on the DMZ to no avail. I checked that the machine I'm
pinging from has a default gateway...this would be the address of eth2. The
command to allow ip_forwarding is on the script and I get no errors when I load
the script or do I need to set the default gateways for each of the NICs on the
firewall machine? I have tried this both ways ..... there is also a setting in
the network configuration utility that will allow me to enable ip
forwarding....I have also tried it with this. Hence, "seeking heavy weaponry", I
generally understand the concept, however putting it into action is another
story, which I'm sure some of you might have witnessed yourselves.
This is the output of the command iptables -L -n -v
after I performed the ping from an internal machine to one of the DMZ
machines.
Chain INPUT (policy DROP 2 packets, 310
bytes)
pkts bytes target prot opt in out source destination 0 0 ACCEPT icmp -- eth2 * 192.168.1.0/24 172.16.1.0/24 0 0 ACCEPT icmp -- eth1 * 192.168.1.0/24 172.16.1.0/24 Chain FORWARD (policy ACCEPT 0 packets, 0
bytes)
pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth2 eth1 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth1 eth2 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy DROP 0 packets, 0
bytes)
pkts bytes target prot opt in out source destination 0 0 ACCEPT icmp -- * eth1 172.16.1.0/24 192.168.1.0/24 0 0 ACCEPT icmp -- * eth2 192.168.1.0/24 172.16.1.0/24 As you can see the packets are making it to the
INPUT chain but it is either being dropped at the INPUT chain because of
incorrect rule structure or it is not being forwarded out through the FORWARD
chain.....routing ??? Any insights will be gratefully appreciated. I dislike
violence, so any input into a resolution and/or pointer to documentation will
keep me from seeking any need for heavy weaponry.
Tim Rodriguez-- Mia/Fla.
Network Security Student --
90% of networking problems are routing
problems.
9 of the remaining 10% are routing problems, but in the other direction. The final 1% might not be routing, but check it anyway. --
|
