I'm having some trouble with the ipmasq firewall setup on my Debian box. For those that aren't familiar with how it works, the iptables commands are specified in a number of .def/.rul files in /etc/ipmasq/rules. I think these get run by run-parts when /usr/sbin/ipmasq is run. Also ipmasq gets run whenever ppp goes up or down. The default ipmasq with ppp installation firewalls the internal (masqueraded) machines but does not protect the firewall machine itself. A while back this machine got rootkitted (over a dialup link!) and at that time I discovered that when the ipmasq docs talk about it providing a firewall, they don't mean the masq machine itself. I then modified one of the the ipmasq rule scripts using some info from the wlug wiki and it all worked. Recently I was looking at trying to make the audio work in Windows Messenger[1] and discovered that my firewall was no longer working and I couldn't see any dropped packets in the logs ( which led me to think that logging wasn't enabled). I must have upgraded something, don't know what, that caused the firewall to stop working. I discovered that there are some default scripts that provide what I want in the ipmasq examples and installed those. Now I'm firewalled but the firewall drops DNS forwards from my internal bind so things don't work so well. However if I do: $/etc/init.d/ipmasq stop $/etc/init.d/ipmasq start after dialing in then it works. What should I be looking for to diagnose the problem? As far I can tell, which admittedly is not very far, the configuration is fine and is essentially the default install with only changes made to the config definitions to specify which ports to block. Any advice appreciated. g [1] If anyone has done that, any advice would be appreciated on that too. -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Glenn Ramsey wrote:
However if I do:
$/etc/init.d/ipmasq stop $/etc/init.d/ipmasq start
after dialing in then it works.
I take that back, it still doesn't work. Some stuff works but only temporarily, probably because my internal dns server cached the addresses while the firewall was down. g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Glenn Ramsey wrote:
I'm having some trouble with the ipmasq firewall setup on my Debian box.
What version of debian are you using, and what kernel version? I assume you're using debian woody on a machine like that. 2.4 and 2.6 series linux kernels use iptables instead of ipmasq - my woody box doesn't have any files named "*ipmasq*" on it at all. I think the woody install defaults to 2.2, although 2.4 is an option. You could try looking in /etc/ppp - there are scripts that get run eg in ip-up.d, so maybe something in there is fiddling with the settings. John McPherson
John R. McPherson wrote:
Glenn Ramsey wrote:
I'm having some trouble with the ipmasq firewall setup on my Debian box.
What version of debian are you using, and what kernel version? I assume you're using debian woody on a machine like that.
It started as woody but now it's mainly sarge. Has kernel 2.4.21-1-k7. The machine is a workstation that doubles as a dialup machine and masq host for a couple of other machines.
2.4 and 2.6 series linux kernels use iptables instead of ipmasq - my woody box doesn't have any files named "*ipmasq*" on it at all. I think the woody install defaults to 2.2, although 2.4 is an option.
ipmasq is a set of config scripts, the scripts have options for ipfwadm, ipchains and iptables. You should see it listed if you do dpkg -l ipmasq
You could try looking in /etc/ppp - there are scripts that get run eg in ip-up.d, so maybe something in there is fiddling with the settings.
It defintely does run when ppp comes up and goes down because it needs to regenerate all the external rules because the ppp ip address changes. Here's what it does: $ ipmasq -v -n #: Interfaces found: #: ppp0 203.79.74.40/255.255.255.255 #: ppp0 203.79.74.40/255.255.255.255 #: eth0 192.168.1.1/255.255.255.0 #: Turn off forwarding for 2.1 kernels #: Disable automatic IP defragmentation echo "0" > /proc/sys/net/ipv4/ip_forward #: Flush all and set default policy of deny. /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -F INPUT /sbin/iptables -F OUTPUT /sbin/iptables -F FORWARD /sbin/iptables -t mangle -P PREROUTING ACCEPT /sbin/iptables -t mangle -P OUTPUT ACCEPT /sbin/iptables -t mangle -F PREROUTING /sbin/iptables -t mangle -F OUTPUT /sbin/iptables -t nat -P PREROUTING ACCEPT /sbin/iptables -t nat -P POSTROUTING ACCEPT /sbin/iptables -t nat -P OUTPUT ACCEPT /sbin/iptables -t nat -F PREROUTING /sbin/iptables -t nat -F POSTROUTING /sbin/iptables -t nat -F OUTPUT #: #: ********************************************************** #: *** CUSTOM CHAINS *** #: ********************************************************** #: #: #: ********************************************************** #: *** FORWARD CHAIN *** #: ********************************************************** #: #: Forward packets among internal networks #: #: ********************************************************** #: *** INPUT CHAIN *** #: ********************************************************** #: #: Accept all packets coming in from the loopback interface /sbin/iptables -A INPUT -j ACCEPT -i lo #: Deny and log all packets trying to come in from a 127.0.0.0/8 address #: over a non-'lo' interface /sbin/iptables -A INPUT -j LOG -i ! lo -s 127.0.0.1/255.0.0.0 /sbin/iptables -A INPUT -j DROP -i ! lo -s 127.0.0.1/255.0.0.0 #: Accept dumb broadcast packets on internal interfaces /sbin/iptables -A INPUT -j ACCEPT -i eth0 -d 255.255.255.255/32 #: Accept packets from internal networks on internal interfaces /sbin/iptables -A INPUT -j ACCEPT -i eth0 -s 192.168.1.1/255.255.255.0 #: Accept multicast packets (adresses 224.0.0.0) from internal interfaces /sbin/iptables -A INPUT -j ACCEPT -i eth0 -d 224.0.0.0/4 -p ! 6 #: Disallow and log packets trying to come in over external interfaces #: from hosts claiming to be internal /sbin/iptables -A INPUT -j LOG -i ppp0 -s 192.168.1.1/255.255.255.0 /sbin/iptables -A INPUT -j DROP -i ppp0 -s 192.168.1.1/255.255.255.0 /sbin/iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT /sbin/iptables -A PREROUTING -t nat -j ACCEPT -i ppp0 -d 203.79.74.40/32 -p udp --destination-port 5004:65535 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 137:139 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 80 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 111 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 445 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p udp --destination-port 137:139 /sbin/iptables -A PREROUTING -t nat -j LOG -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 0:5003 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p tcp --destination-port 0:5003 /sbin/iptables -A PREROUTING -t nat -j LOG -i ppp0 -d 203.79.74.40/32 -p udp --destination-port 0:5003 /sbin/iptables -A PREROUTING -t nat -j DROP -i ppp0 -d 203.79.74.40/32 -p udp --destination-port 0:5003 #: Accept dumb broadcast packets on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 255.255.255.255/32 #: Accept incoming packets from external networks on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 203.79.74.40/32 #: #: ********************************************************** #: *** IP MASQUERADING *** #: ********************************************************** #: #: Masquerade packets from internal networks /sbin/iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.1/255.255.255.0 -j MASQUERADE /sbin/iptables -A FORWARD -i eth0 -o ppp0 -s 192.168.1.1/255.255.255.0 -j ACCEPT /sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT #: #: ********************************************************** #: *** OUTPUT CHAIN *** #: ********************************************************** #: #: Allow packets to go out over the loopback interface /sbin/iptables -A OUTPUT -j ACCEPT -o lo #: Allow dumb broadcast packets to leave on internal interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o eth0 -d 255.255.255.255/32 #: Allow packets for internal hosts to be delivered using internal interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o eth0 -d 192.168.1.1/255.255.255.0 #: Allow multicast packets (adresses 224.0.0.0) to be delivered using #: internal interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o eth0 -d 224.0.0.0/4 -p ! 6 #: Deny and log packets attempting to leave over external interfaces claiming #: to be for internal networks /sbin/iptables -A FORWARD -j LOG -o ppp0 -d 192.168.1.1/255.255.255.0 /sbin/iptables -A FORWARD -j DROP -o ppp0 -d 192.168.1.1/255.255.255.0 /sbin/iptables -A OUTPUT -j LOG -o ppp0 -d 192.168.1.1/255.255.255.0 /sbin/iptables -A OUTPUT -j DROP -o ppp0 -d 192.168.1.1/255.255.255.0 /sbin/iptables -A POSTROUTING -t nat -j ACCEPT -o ppp0 -s 203.79.74.40/255.255.255.255 -p udp --source-port 5004:65535 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 137:139 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 80 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 111 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 445 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p udp --source-port 137:139 /sbin/iptables -A POSTROUTING -t nat -j LOG -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 0:5003 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p tcp --source-port 0:5003 /sbin/iptables -A POSTROUTING -t nat -j LOG -o ppp0 -s 0.0.0.0/0 -p udp --source-port 0:5003 /sbin/iptables -A POSTROUTING -t nat -j DROP -o ppp0 -s 0.0.0.0/0 -p udp --source-port 0:5003 #: Allow dumb broadcast packets to leave on external interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o ppp0 -d 255.255.255.255/32 #: Allow packets for external networks leave over external interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o ppp0 -s 203.79.74.40/32 #: #: ********************************************************** #: *** SERVICES *** #: ********************************************************** #: #: Turn on forwarding for 2.1 kernels #: Enable automatic IP defragmentation echo "1" > /proc/sys/net/ipv4/ip_forward #: Set masqerading timeouts: #: 2 hrs for TCP #: 10 sec for TCP after FIN has been sent #: 160 sec for UDP (important for ICQ users) #: Run the deprecated /etc/ipmasq.rules, if present #: Deny and log anything that may have snuck past any of our other rules /sbin/iptables -A INPUT -j LOG -s 0.0.0.0/0 -d 0.0.0.0/0 /sbin/iptables -A INPUT -j DROP -s 0.0.0.0/0 -d 0.0.0.0/0 /sbin/iptables -A OUTPUT -j LOG -s 0.0.0.0/0 -d 0.0.0.0/0 /sbin/iptables -A OUTPUT -j DROP -s 0.0.0.0/0 -d 0.0.0.0/0 /sbin/iptables -A FORWARD -j LOG -s 0.0.0.0/0 -d 0.0.0.0/0 /sbin/iptables -A FORWARD -j DROP -s 0.0.0.0/0 -d 0.0.0.0/0 g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Hi Glenn.
However if I do:
$/etc/init.d/ipmasq stop $/etc/init.d/ipmasq start
after dialing in then it works.
It sounds like your rules might be binding to an IP address instead of an interface - in your case, probably ppp0. As you get a new IP every time you dial up, your rules may be incorrect. I'm not at all familiar with this "ipmasq" thing though - I recommend just using standard iptables rules...maybe it is, I've never seen it. -- Greig McGill
Greig McGill wrote:
Hi Glenn.
However if I do:
$/etc/init.d/ipmasq stop $/etc/init.d/ipmasq start
after dialing in then it works.
It sounds like your rules might be binding to an IP address instead of an interface - in your case, probably ppp0. As you get a new IP every time you dial up, your rules may be incorrect.
It appears to be handling the new ip properly. The dropped packets log like this: 203.96.152.4 is the dns server, 203.79.74.233 is my dynamic ip Jul 8 09:13:06 pixie kernel: IN= OUT=ppp0 SRC=203.79.74.233 DST=203.96.152.4 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=147 DF PROTO=UDP SPT=53 DPT=53 LEN=59 Why is it using udp?
I'm not at all familiar with this "ipmasq" thing though - I recommend just using standard iptables rules...maybe it is, I've never seen it.
It does just use standard iptables rules, but wraps them in "easy to use" config scripts. I have fixed the problem for now by opening port 53. I think this is pretty secure because bind is only listening on the internal interface. My question now is why would it be dropping packets from the masq machine itself that are destined for the external interface? And why only dns lookup forward packets? g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Glenn Ramsey wrote:
The dropped packets log like this: 203.96.152.4 is the dns server, 203.79.74.233 is my dynamic ip
Jul 8 09:13:06 pixie kernel: IN= OUT=ppp0 SRC=203.79.74.233 DST=203.96.152.4 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=147 DF PROTO=UDP SPT=53 DPT=53 LEN=59
Why is it using udp?
I have fixed the problem for now by opening port 53. I think this is pretty secure because bind is only listening on the internal interface.
My question now is why would it be dropping packets from the masq machine itself that are destined for the external interface? And why only dns lookup forward packets?
dns uses udp. It will use tcp if the data is too big to fit in a udp packet. It's kind of weird to see requests both from port 53 and to 53. I looked at your rules earlier and checked at home - my bind sends requests from high ports, which is why I couldn't see anything wrong with your rules, and I also thought
#: Accept incoming packets from external networks on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 203.79.74.40/32
would allow dns responses. Also, bear in mind that bind will not listen on interfaces created after it starts (just in case this trips you up). But I don't think that's the problem in this case. John
John R. McPherson wrote:
The dropped packets log like this: 203.96.152.4 is the dns server, 203.79.74.233 is my dynamic ip
Jul 8 09:13:06 pixie kernel: IN= OUT=ppp0 SRC=203.79.74.233 DST=203.96.152.4 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=147 DF PROTO=UDP SPT=53 DPT=53 LEN=59
and I also thought
#: Accept incoming packets from external networks on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 203.79.74.40/32
would allow dns responses.
sorry, I thought it was blocking incoming, not outgoing. Do your rules allow *any* outgoing packets with ppp0's ip address as the source? John
John R. McPherson wrote:
John R. McPherson wrote:
The dropped packets log like this: 203.96.152.4 is the dns server, 203.79.74.233 is my dynamic ip
Jul 8 09:13:06 pixie kernel: IN= OUT=ppp0 SRC=203.79.74.233 DST=203.96.152.4 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=147 DF PROTO=UDP SPT=53 DPT=53 LEN=59
and I also thought
#: Accept incoming packets from external networks on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 203.79.74.40/32
would allow dns responses.
sorry, I thought it was blocking incoming, not outgoing.
Do your rules allow *any* outgoing packets with ppp0's ip address as the source?
I don't know, should they? I'm using the ipmasq "stronger" firewall setup, from /usr/share/doc/ipmasq/examples straight out of the box, except for editing the config file to close of all access from outside. In any case, it's working now, and I know a little more about how it works :-). Anyone have any ideas on the windows messenger audio setup? I found a newsgroups message that says a I need to open udp ports 5004:65535 for this. But I think I also need to configure it to forward these ports to my windows box, I tried that using an iptables command from the wiki but it didn't work, however now that my firewall is working I'll give it another go. If there is a practical alternative then I'll give that a go. However the people I want to talk with all use windows exclusively. Cheers g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Thanks everyone for your help. I think I found the problem, read on. John R. McPherson wrote:
dns uses udp. It will use tcp if the data is too big to fit in a udp packet.
Ok that explains it.
It's kind of weird to see requests both from port 53 and to 53. I looked at your rules earlier and checked at home - my bind sends requests from high ports, which is why I couldn't see anything wrong with your rules, and I also thought
its probably because of this, from named.conf: // If there is a firewall between you and nameservers you want // to talk to, you might need to uncomment the query-source // directive below. Previous versions of BIND always asked // questions using port 53, but BIND 8.1 and later use an unprivileged // port by default. query-source address * port 53; I just tried commenting out this line and now it seems to be working.
#: Accept incoming packets from external networks on external interfaces /sbin/iptables -A INPUT -j ACCEPT -i ppp0 -d 203.79.74.40/32
would allow dns responses.
But isn't the log message saying that the SRC ip address is not being accepted as valid for IN? Jul 8 09:13:06 pixie kernel: IN= OUT=ppp0 SRC=203.79.74.233 DST=203.96.152.4 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=147 DF PROTO=UDP SPT=53 DPT=53 LEN=59 and shouldn't this cover it? #: Allow packets for external networks leave over external interfaces /sbin/iptables -A OUTPUT -j ACCEPT -o ppp0 -s 203.79.74.40/32 g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
participants (3)
-
Glenn Ramsey -
Greig McGill -
John R. McPherson