Re: IP Firewalling/Redirect

Major'Trips' (major@jimco-fwt.com)
Mon, 4 Jan 1999 03:07:23 -0600

On Sun, Jan 03, 1999 at 05:50:38AM -0600, Major'Trips' wrote:
>
> I don't know if this is expected behavior .. but it didn't seem
> right to me so here goes.
>
I have come to the conclusion that it isn't.

> A note: this does not appear to be true for inetd. I can settup
> an entry in the inetd to run a script for port connections and
> the redirection appearrs to work flawlessly regardless if inetd
> is handling requests to a port already or not. This only appears
> to be a conflict of interests in named at the moment that I can tell.

The following is a semi walk through of sending a string "hello"
to and from a redirected port.

This experiment consisted of uzing netcat to bind to a port
and redirect some other port to that port. I did this with
both TCP and UDP to see what happned and came to the conclusion
that the Transparent Proxy is fairly busted for the UDP side.

#########################################################################
# TCP Captured Data

# Data Incomming
02:44:36.769005 192.168.1.47.4667 > 192.168.1.42.6666: S
1332186681:1332186681(0) win 512 <mss 1460>

# Redirect Notice
Jan 4 02:44:36 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=6
192.168.1.47:4667 192.168.1.42:6666 L=44 S=0x00 I=3082 F=0x0000 T=64

# Data Outgoing
02:44:36.769935 192.168.1.42.6666 > 192.168.1.47.4667: S
633205398:633205398(0)
ack 1332186682 win 32120 <mss 1460> (DF)

# Data Incomming
02:44:36.770411 192.168.1.47.4667 > 192.168.1.42.6666: . ack 1 win 32120 (DF)

# Redirect Notice
Jan 4 02:44:36 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=6
192.168.1.47:4667 192.168.1.42:6666 L=40 S=0x00 I=3083 F=0x4000 T=64

# Data Outgoing
02:44:45.834830 192.168.1.42.6666 > 192.168.1.47.4667: P 1:7(6) ack 1 win
32120
(DF)
# Data Incomming
02:44:45.854189 192.168.1.47.4667 > 192.168.1.42.6666: . ack 7 win 32120 (DF)

# Redirect Notice
Jan 4 02:44:45 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=6
192.168.1.47:4667 192.168.1.42:6666 L=40 S=0x00 I=3084 F=0x4000 T=64

# Data Outgoing
02:45:02.367179 192.168.1.42.6666 > 192.168.1.47.4667: F 7:7(0) ack 1 win
32120
(DF)

# Data Incomming
02:45:02.367631 192.168.1.47.4667 > 192.168.1.42.6666: . ack 8 win 32120 (DF)
02:45:02.367830 192.168.1.47.4667 > 192.168.1.42.6666: F 1:1(0) ack 8 win
32120

# Redirect Notice
Jan 4 02:45:02 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=6
192.168.1.47:4667 192.168.1.42:6666 L=40 S=0x00 I=3085 F=0x4000 T=64
Jan 4 02:45:02 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=6
192.168.1.47:4667 192.168.1.42:6666 L=40 S=0x00 I=3086 F=0x0000 T=64

# Data Outgoing
02:45:02.368083 192.168.1.42.6666 > 192.168.1.47.4667: . ack 2 win 32120 (DF)

############################################################################
# UDP Captured Data
#

# Data Incomming
02:45:21.459955 192.168.1.47.1361 > 192.168.1.42.6666: udp 6

# Redirect Notice
Jan 4 02:45:21 satan kernel: Packet log: input REDIRECT 6667 eth0 PROTO=17
192.168.1.47:1361 192.168.1.42:6666 L=34 S=0x00 I=3087 F=0x0000 T=64

# Data Outgoing
02:45:28.250652 192.168.1.42.6667 > 192.168.1.47.1361: udp 6

# ICMP Rejection
02:45:28.251097 192.168.1.47 > 192.168.1.42: icmp: 192.168.1.47 udp port 1361
unreachable [tos 0xc0]

You will notice that when performing the test using TCP that the
response came from the port that was beeing redirected, or at least
that is how the network see's it, which is how the other end of the
data stream saw it.

But in the UDP experiment the response came from the real port, not
the redirected port, thus getting an icmp destination unreachable
as that port did not have authority to respond so to speak.

Now .. after much thinking and pondering I have concluded this to
be a bug, I am short numerous brain cells now as most of them all
cooked in all the thinking going on and I am half a head shorter of
hair. Anyway .. I have been browsing the udp code that deals with
the transparent proxy but I am running across an interesting learning
curve as to what is going on in all of this .... Odds are in favor
that if I am forced to write a fix for this the code will suck.

-- 
   "Reality is what you can get away with!"
                      ++Robert Anton Wilson
   Major'Trips'
   E-Mail   : shadow@cyberwizards.com || major@jimco-fwt.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/