Geek pop quiz - SOLVED!

[theweaselking]

I have a stupid firewall. It can open a port, but not translate - I can't have port 999 on the outside redirect to an internal IP on port 443, for example.

I have a very smart Ubuntu 8.04 server. It can do anything I want it to, as long as I can tell it what to do.

I have a very, very, very stupid device that *only* listens on 443. The receiving port cannot be changed.

What I want:

1. Stupid firewall opens port 999 to smart server.
2. Smart server sees port 999 traffic and happily routes it off to 443 on device.
3. Device is happy to have 443 traffic, replies to smart server, smart server tosses it back out through the firewall to the end user.
OR
3. Device is happy to have 443 traffic, replies right back through the firewall to the end user without bugging Smart Server.

I don't care which 3 I get.

What are the magic words I need to tell iptables to do this for me? Or the magic words to have *something else* do it for me?

(And yes, I had a very similar question to this in January. Very similar devices, too. Not exactly the same, though. And that time, I just let Apache listen on 444 instead of bothering with fixing it, which is not an option, here.)

EDIT: The correct answer here is "rinetd"

10 seconds to install, 10 seconds to edit the config file with the port and IP I want forwarded, and BANG, everything works perfectly.

This is the kind of solution I really love.

Comments

[catblade.livejournal.com]

Try this:

http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/

It worked with some non-ssh specific traffic last week. You are looking for the heading titled
Secure port forwarding with "ssh -L".

[theweaselking.livejournal.com]

That's not quite what I want - that lets me tunnel 443 to Internal Device over SSH, so client makes an SSH connection to Server and then hits localhost:443 - and his SSH clients listens on 443, stuffs the traffic through the connection, the pops it out to ID:443 on the far side.

What I really want is a rule so that the server knows that *all* traffic on the nonstandard port gets forwarded.

[zastrazzi.livejournal.com]

I recommend reading up on netcat, it will do precisely this.

[theweaselking.livejournal.com]

Have you got a good link? Every instruction set I can find is a "magic spell" - a series of commands without any explanation - and none of them actually *work* to do what I'm trying.

[zastrazzi.livejournal.com]

Can't find a decent link, but the trick is to make the listener persistent


nc -l -v -p 999 | nc localhost 443

netcat -listen -verbose -port(local) 999 | netcat destination_machine portnumber


in Windows the persistent is via -L (instead of -l)

nm, I think I found what you need at http://isc.sans.org/diary.html?date=2005-02-18



There are many ways to get around this problem, such as using a different version of Netcat. However, one of my favorite simple ways to deal with this is to set up the Netcat listener in a while loop as follows:



$ while [ 1 ]; do echo "Started"; nc -l -p 41523 >> capture.txt; done



This will listen on TCP 41523, append whatever it receives to capture.txt, and then start listening again.



If you'd like to go further and actually log out while keeping this thing running, you can simply dump this while line in a file, called honeypot.sh. Then, chmod it so that it is executable (chmod 555 honeypot.sh). Finally, invoke it as follows:



$ nohup ./honeypot.sh &



Then, logout and go watch some TV. Take a nap. Run naked through the park. Do whatever it is that you do...



Come back, and your little Netcat buddy will be running with its results stored in capture.txt. To kill it, you could simply kill the pid of the nc listener itself. Thanks to Don Smith for the nohup idea. Note that Don did NOT suggest the park idea.



So something like

while [ 1 ]; do echo "Started"; nc -l -p 999 | nc localhost 443

should do the trick

[catblade.livejournal.com]

I was pretty certain that all traffic on the designated port gets forwarded and that it acted exactly like a proxy server. This worked fine when running a non-ssh server last week on a non-standard port so I could use my virtualbox server without having to go through a host network. Is that incorrect? ^_^

The below commenter is correct though-a simple netcat should work too.

[theweaselking.livejournal.com]

Maybe I don't see what you mean.

Those instructions tell an ssh client to forward local ports to the server - to, in fact, tunnel traffic through and pop it out the far side with a new address.

They also let you make your ssh server listen on ports and forward them through the tunnel to the client machine's network.

But nowhere in there does it make the server listen on a new port and forward it to a new location without an SSH connection.

Have I missed something?

[catblade.livejournal.com]

It looks like I was unwittingly creating an ssh tunnel. A lot of people use this as a proxy server. It is kind of overkill, but works:
http://erdelynet.com/archive/ssh-l/2007-09/3878.html

Does that make sense?

Netcat is probably faster. Setup directions are here:
http://www.governmentsecurity.org/archive/t3303.html

[theweaselking.livejournal.com]

That guy's netcat instructions don't work - the second netcat can't bind to 999 to accept the return, because the first one is already there.

I see what he's trying, but it doesn't actually work.

[rbarclay.livejournal.com]

Assuming 192.168.223.4 is your "smart" Ubuntu box, TCP, and "device" is on 192.168.223.5: iptables -t nat -A PREROUTING -p tcp -m tcp -d 192.168.223.4 --dport 999 -j DNAT --to-destination 192.168.223.5:443.

Or the fugly hack-method: first, define tcp/999 in /etc/services as, say, fuglyhack, and make sure netcat is installed. Then add this to /etc/inetd.conf (or Ubuntu equivalent, might be xinetd): fuglyhack stream tcp nowait root /usr/bin/nc nc 192.168.223.5 443. The downside is that your application won't see the original source IP. And performance, well, will suck if you got lots of connects.

[jsbowden.livejournal.com]

The easy answer is to pick up a $40 Linksys gateway and NAT/PAT the stupid device behind it. It'll take 10 minutes, be less complex, and Just Work.

[theweaselking.livejournal.com]

Don't tempt me.

[jsbowden.livejournal.com]

Don't tempt you with what? A simple and easy to maintain solution that does what you need and doesn't require memorizing all the arcana involved in making IP tables do what you want, is less likely to die than a full fledged PC, and maintaining is as easy as an occasional flash update?

[theweaselking.livejournal.com]

And also requires spending money. If I had a non-stupid router handy, I wouldn't be asking the stupid question.

[jsbowden.livejournal.com]

If you'd spend the $40, you'd already be done.

[theweaselking.livejournal.com]

I know.

I was actually hoping that:
#1: It would be easier than this. Y'know, somebody would have the magic spell for proxying a port right on top of their heads.
#2: I'd learn something that wasn't "money fixes problems better than geeks do"

I don't think either of those is true this time, though.

[catsidhe.livejournal.com]

#2: I'd learn something that wasn't "money fixes problems better than geeks do"

There have been decades of people commoditising the results of geeks fixing problems, to the point that for most common problems, and many of the more esoteric ones, there will be a product that can solve it more easily than any given geek could.

The trick is that the true geek will try and learn how to do it anyway, so that they can cope if when they don't have access to that particular toy.

[theweaselking.livejournal.com]

If I'd spent the money, I wouldn't have learned about rinetd, which solves this problem exactly the way I want it to.

Yay!

[theweaselking.livejournal.com]

The iptables method does not appear to work. The user doesn't see the correct page, the device doesn't twig that someone's trying to connect.

Do you know where/if iptables logs traffic?

[rbarclay.livejournal.com]

You have to explicitly tell iptables what to log. Not nice.

   LOG
       Turn  on  kernel  logging of matching packets.  When this option is set
       for a rule, the Linux kernel will print some information on all  match-
       ing  packets  (like most IP header fields) via the kernel log (where it
       can be read with dmesg or syslogd(8)).  This is a "non-terminating tar-
       get",  i.e.  rule traversal continues at the next rule.  So if you want
       to LOG the packets you refuse, use two separate  rules  with  the  same
       matching criteria, first using target LOG then DROP (or REJECT).

So something like
iptables -A FORWARD -j LOG
iptables -A INPUT -j LOG
iptables -A PREROUTING -j LOG
should log what's interesting in that case.

For my example, well, it was for example only, not complete. There's probably a couple lines missing, like:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d 192.168.223.5 -j ACCEPT

[theweaselking.livejournal.com]

Still no good. And I've managed to make "iptables -V -l" produce no output at all.

I have a headache.

[catblade.livejournal.com]

Redid the ssh tunnel

sudo ssh -L <external port>:localhost:<internal port> username@localhost

Works great. Probably slower than netcat, as I said, since it is an encrypted tunnel.

[theweaselking.livejournal.com]

#1) But that requires a user to be logged in and SSH-ing to localhost, all the time.

#2) Take external port traffic, encrypt it, transmit it via 22 to yourself, decrypt it, and forward it off to the internal port? That's... kinda sick. But I like it. Now, if only we could make it work without having the user logged in....

[catblade.livejournal.com]

#1) I know, but if you are just testing it is an okay hack for today. I'm checking into netcat (I should be debugging, but I'm pissed at the kernel right now).

zombie zombie zombie zombie.

[theweaselking.livejournal.com]

PS: Tried the port forwarding thing. STill not working for me - although I have no problem at all if I do it from my computer, SSH into the server, then connect to localhost:externalport

So I suspect there may be something wrong with the router's port forwarding, at the moment.

[catblade.livejournal.com]

Netcat:
mknod backpipe p
nc -l -p <externaltport> 0<backpipe | tee -a inflow | nc localhost <internalport> | tee -a outflow 1>backpipe

Good luck with the router!

[theweaselking.livejournal.com]

Okay: First, at no point in that string to we have the IP of the target device. I think we need that somewhere.
(external port = 999
internal port = 443
target system = 192.168.1.251
Server = 192.168.1.4
router = 192.168.1.1)

Second, can you help me parse that out so I know what it's doing?

"mknod backpipe p" creates a FIFO file called "backpipe".

"nc -l -p 999" grabs port 999 and starts listening

"0

[Error: Irreparable invalid markup ('<backpipe">') in entry. Owner must fix manually. Raw contents below.]

Okay: First, at no point in that string to we have the IP of the target device. I think we need that somewhere.
(external port = 999
internal port = 443
target system = 192.168.1.251
Server = 192.168.1.4
router = 192.168.1.1)

Second, can you help me parse that out so I know what it's doing?

"mknod backpipe p" creates a FIFO file called "backpipe".

"nc -l -p 999" grabs port 999 and starts listening

"0<backpipe" appears to take anything in backpipe and feed it to the netcat process?

Pipe that through
"tee -a inflow" - take the input from netcat listening on port 999 and write it to a file called inflow

which is in turn piped through
"nc localhost <internalport>" - which I think should be "nc 192.168.1.251 999" because it's not localhost that needs the forwarded port.

which is, in turn piped through
"tee -a outflow 1>backpipe" - write the output to "outflow" and put that, in turn, into our FIFO backpipe file.

[catblade.livejournal.com]

mknod creates a device, in this case, a pipe.

Other than that, you sound about peachy.

Good luck!

I'm going to go back to parsing hell now. :)

[theweaselking.livejournal.com]

Still no dice. Running the command

nc -l -p 999 0< backpipe | tee -a inflow | nc 192.168.1.251 443 | tee -a outflow 1>backpipe

sits waiting for further input - ps aux |grep nc shows only "nc 192.168.1.251 443"

And traffic doesn't actually go.

I can telnet to localhost:999 while it's running, but it doesn't *do* anything, and hitting https://server:999/ just times out.

[catblade.livejournal.com]

Odd, because I have it working with ssh. As in:

nc -l -p <internal port> 0<backpipe | tee -a inflow | nc <service host> <service port> | tee -a outflow 1>backpipe

It didn't work for a couple of minutes and I had to reboot since I had somehow mucked up the kernel (I'm writing a module so am quite good at mucking it up) but I'm going to ask the windows question: did you try rebooting?

Yes, I know, stupid.

[theweaselking.livejournal.com]

Nope. The machine is slightly in use right now, which makes rebooting problematic.

I may do that tonight.

[catblade.livejournal.com]

Maybe get it working on a spare machine and then try it that way? I'm making the silly assumption that you have spares.

[theweaselking.livejournal.com]

Fixed the problem - rinetd does everything I need.

[catblade.livejournal.com]

Woot!

[rbarclay.livejournal.com]

If in doubt, install fwbuilder and get a Checkpoint-like GUI ;)

[theweaselking.livejournal.com]

I'm leaning towards *not* adding a GUI to my server.

But thanks for the help. Seriously.

[rbarclay.livejournal.com]

You can use fwbuilder on any Linux box, it just creates a shellscript with the iptables-commands which you can then simply copy over to your server (which is what I usually do with my own boxes, too).

[theweaselking.livejournal.com]

that makes sense. And now, since my head hurts, I'm going to give up on this for today.

[theweaselking.livejournal.com]

Actually, I've got webmin on there. Which has a "lovely" iptables interface.

However, while it's happy to let me set rules to "accept" or "reject" or "log" or "drop" packets based on conditions, and I can set these rules for forwarded packets, I'm having a devil of a time trying to tell it to *do* anything with the packets - like, "if packet X arrives on port Y, send it to IP Z n port Q"

this is just frustrating, at this point.

[quotation.livejournal.com]

Say hello to my little friend: http://www.ubuntugeek.com/rinetd-redirects-tcp-connections-from-one-ip-address-and-port-to-another.html

I've used rinetd with absolutely stellar results on many occasions.

It. Just. Works.

[theweaselking.livejournal.com]

Have just tested it. Took 15 seconds to set up, and works perfectly, doing EXACTLY what I want it to.

I could kiss you.

Once again, I owe you beer. Thanks.

[quotation.livejournal.com]

It was worth it, to read all the insane-o suggestions from your other readers. I mean, really, holy crap.

But, you should note that your logs on the target device won't know the actual source IPs. I didn't get the impression you'd care about that, though.

Beer, I can handle, but kisses should be proxied through your hot sister.

[theweaselking.livejournal.com]

I figured it would be an easy iptables fix, but I still can't parse iptables worth shit *and* I can't find a tutorial on what any of the basic iptables stuff really means. It's not pretty.

My hot sisters are relatively hard to get to from Toronto. Beer, however, is universal.