Until recently I had a server that provided information on port 3168 to client apps elsewhere on the internet. However, the office building, that I am located in, has IT personnel who have recently adopted very strict (almost fascist) attitudes towards security. All incoming ports to the building have been shut off. (Checkpoint firewall) No webservers, no mail servers, no ftp servers, no nothing. ICMP has been shut off too. NO VPN! Outgoing from this building , one can surf the net or check email-that's it. So I moved my server offsite.
I have this static ip to a NAT router with port forwarding 3168 to the ip of my server. Everything is fine if my client tries to access the server from almost anywhere. Even dialup access through AOL works! My proprietary client can access my server. However, I cannot get to the server from the building I am in. The IT personnel are unwilling to open any inbound ports, but that should not prevent me from getting out. In fact I can surf the net (port 80) and even access a friend's webserver setup on port 81. I am a little surprised to see that I cannot get to port 3168. However, I CAN ping my static ip. Does this mean that outbound ports can be blocked as well.? I know my server is working because I can access it from other physical sites as well as from the inside of my building if I use dialup. I just cant get to it through the T1 line of my building. Do firewalls allow inspection of the destination port of each departing packet?
Is there a 'port remapping' application that will change my destination port info to '80' so it can get out of my building? Then I can run the same app on my client, in reverse. Converting the port 80 header to a port 3168 so that my server will hear it?
Re: getting out of a shrinking box...
14 years 10 months ago #705
I'm not sure if I understood your question correctly, but since you have web access, here's a little bit of info that you can use beware though that its a little devious 8) .. it can be used to tunnel any outgoing connection (allowed/unallowed) through an http proxy.. for example if you wanted to telnet to a host outside your network and outbound telnet is disallowed, but you are allowed to surf the net, this method will probably work -
Its called HTTP tunneling through proxies and (simplified) it works on the principle that proxies do not (cannot) examine encrypted (SSL) outbound connections ! This allows you to send to your http proxy what looks like a regular outbound SSL request, which in fact can be a connection to any machine, and *using any protocol* !! You create an ssl tunnel to your host and communicate with it, while the http proxy thinks this is legit SSL traffic
You dint mention which OS you use so I assumed linux (thus you can use the perl script that is mentioned in the above doc) if you use windows - no problem, there is a windows util called httport (or something similar) which does the same thing, with a nice gui, and has built in presets for tunneling instant messaging traffic as well as i said im not sure of the exact name of the program - i have it somewhere at home, but a quick google on the subject will find it for sure.
With regard to the end of your question - yes outbound traffic can be blocked (its called egress filtering). Inspection of the destination port for outbound traffic is very well within the capabilities of CheckPoint 1
Be warned though, your admins may not like the idea that you're evading all their carefully planned egress filtering rules
Hope I got your question right
Ps. another thought just struck me, if you have a machine that you can access outside the firewall which has a static ip, you can use a relay, to forward your traffic. For example you said you can send port 80 requests out, so you can have your outside server bind netcat to relay information like this
nc -l -p 80 | nc yourinnaccessibleserver.com 3168
to break this command down, -l -p 80 tells netcat to 'listen' for connections on this intermediate server on port 80 (which is allowed), then the | just pipes anything that comes in on that connection to the following command 'nc innaccessible.com 3168' which basically just connects to your server:3168 voila ! instant relay. Of course depending on how your port 3168 server handles traffic etc it may or may not work, but its the simplest way to connect to an allowed port and pipe the output to the final destiantion (for all intents and purposes the two machines can be the same.. if you have control of your offsite server and you arent running a webserver on it, you can just set up this binding and leave it on)
to end a long post - heres the diagram
you --> Checkpoint (outbound port 80 allowed) ---> Relay:80 ==forwards to==> inaccessible:3168
your request goes to checkpoint asking for permission to connect to relay.com:80 which just pipes the traffic to inaccessible.com:3168
i appreciate your post and am grateful for your time. my os is macintosh OS X 10.2. Although it may be possible to set up a service to do this port forwarding on said machine, it is beyond me to dig in the underbelly of the macos. My familiarity with unix is crude though it seems I am destined to set up a linux box for thiis purpose. My planned topology therefore will be:
clients in the restricted office run mac os x
linux box with 2 NICS
port 3168 in
port 80 out
office NAT router #1
office NAT router #2
verizon static ip on a dsl line
NAT router with port 80 open
linux box with 2 NICS
port 80 in
port 3168 out
macintosh running server app on port 3168
OF course, this setup precludes using my server through all other locations where i do not have a proxy box (for example if i use aol dial up i can currently access my server from anywhere in its current config).
The topology you described looks like a good solution Hope it works out for you.. post your results if it does.
Btw I did a bit of looking around for you, netcat CAN be compiled for the mac Its always handy to have around for those band-aid solutions.. especially when you are faced with Gestapo type firewall admins