Messages in this thread | | | From | kutek@raven ... | Date | Wed, 8 Jul 1998 14:26:00 -0400 | Subject | possible bug in firewall transparent proxy port redirection for UDP |
| |
As part of my persoanl "no daemons shall run as root " campaign, I have seized on the port redirection capabilities of the linux fireall transparent proxy to run various historically problematical daemons from non privileged ports.In doing so i think i have found a bug in the UDP port redirection code.
here's the situation with sendmail , which is here running on port 2225:
the redirection rule is ipfwadm -I -P tcp -a accept -r 2225 -S 0/0 -D 0/0 25
the following is tcpdump output processed with tcpshow-here i am telnetting to localhost port 25, the telnet port is 4719:
----------------------------------------------------------------- 127.0.0.1.25 -> 127.0.0.1.4719 over TCP 220 prism ESMTP Sendmail 8.9.0/8.6.9 ready at Wed, 8 Jul 1998 13:01:14 -0400.
----------------------------------------------------------------- 127.0.0.1.4719 -> 127.0.0.1.25 over TCP helo prism.
----------------------------------------------------------------- 127.0.0.1.25 -> 127.0.0.1.4719 over TCP <No data> ----------------------------------------------------------------- 127.0.0.1.25 -> 127.0.0.1.4719 over TCP <No data> ----------------------------------------------------------------- 127.0.0.1.25 -> 127.0.0.1.4719 over TCP 250 prism Hello root@prism [127.0.0.1], pleased to meet you.
-----------------------------------------------------------------
note that data is flowing in both directions over port 25 (recall that sendmail is actuall sitting on port 2225).
Everything is working OK.
now we try this with named, which is sitting on port 1153.
the redirection rule is : ipfwadm -I -P udp -a accept -r 1153 -S 0/0 -D 0/0 53
I now do a dns query using nslookup, this is nslookup starting up:
----------------------------------------------------------------- 127.0.0.1.1071 -> 127.0.0.1.domain over UDP .............1.0.0.127.in-addr.arpa..... ----------------------------------------------------------------- 127.0.0.1.1153 -> 127.0.0.1.1071 over UDP .............1.0.0.127.in-addr.arpa.............Q... localhost..0.0.127.in-addr.arpa.......Q....g.root-servers.net.._.....6.....p$.
nslookup is using port 1071.note that domain is talking to nslookup directly from port 1153 rather than 53 which is unexpected. but nslookup doesn't seem to mind (query umn.edu):
127.0.0.1.1073 -> 127.0.0.1.domain over UDP .............umn.edu..... ----------------------------------------------------------------- 127.0.0.1.1153 -> 127.0.0.1.1073 over UDP .............umn.edu..............h...^...........h...^...........h...^............. .ns.nts...............nss.X.............hanna.cac washington.edu..U...........eee.j...........TTT.|......Q.....#. -----------------------------------------------------------------
However, ftp ( and telnet and almost all other net apps) DO MIND, wanting an answer from port 53: (ftp ftp.kernel.org):
----------------------------------------------------------------- 127.0.0.1.1086 -> 127.0.0.1.domain over UDP .~...........ftp.kernel.org..... ----------------------------------------------------------------- 127.0.0.1.1153 -> 127.0.0.1.1086 over UDP .~...........ftp.kernel.org.............M+...linux.kernel.org..,......M+.....".2...........NS TRANSMETA.COM..2...........NS1.BEST.g.2...........NS2.|.2...........NS3.|.Z...............x.............)..............f................* ----------------------------------------------------------------- 127.0.0.1 -> 127.0.0.1 ICMP destination-unreachable because port-unreachable ....E...j...@..............>..rf.~...........ftp.kernel.org.............M+...linux.kernel.org..,......M+.....".2...........NS TRANSMETA.COM..2...........NS1.BEST.g.2...........NS2.|.2...........NS3.|.Z...............x.............)..............f................* -----------------------------------------------------------------
ftp and telnet fail with "unknown host" ,but named has the answer cached, so it IS working,as seen from nslookup output:
> ftp.kernel.org Server: localhost Address: 127.0.0.1
Non-authoritative answer: Name: linux.kernel.org Address: 206.184.214.34 Aliases: ftp.kernel.org
Thus the firewall fails to redirect packets bidirectionally for UDP, which it successfully does for tcp.
using the -b parameter to ipfwadm in the rules gets the same result, answers still come directly from port 1153 rather than 53-net apps will not accept these answers from named.
the kernel is 2.0.34
btw, did someone forget to put the ioport.c fix in 34 ?
I was unable to run X or any svgalib progs until i recompiled using a 2.1.X ioport.c. hopefully this will be included in 2.0.35.
fractoid
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |