Bypass your firewall

Disclaimer: This document is for educational purposes only. The author(me) is not responsible for any damages or losses if happened upon following this material.

Here in this document I am going to describe you a way through which one can bypass a corporate firewall and remotely access your home computer. Obviously you know what you can do if you have remote desktop(Surf internet, etc). This is highly discouraged by the employers/universities. Use it at your own risk.  Ofcourse for this method to work, You should be having a internet connection at decent speed in your home and your system should be left running while you are in your college/office. For the one who are curious enough to know how and why this works can go through the below section. Others can directly jump into “Taking advantage of the CONNECT method” section.

Details of the firewall:

The most common way the firewall is setup in most of the colleges, corporates is to have a proxy server. The proxy servers will be set up to provide access to the ports 80(HTTP) & 443(HTTPS) and all other port access are restricted. The proxy server will be having the firewall solutions installed like websense, etc which would perform the filtering based on the URL, IP and the content(Most commonly  there will be a URL & IP black list set up in the proxy server to deny access).  These firewalls have a neat hole through which one can access the public machines from inside the firewall without alarming the admin. The trick is in the way the proxy servers provide access to the port 443(HTTPS).

The tunneling mechanism:

When we request an URL through our browser,  Your browser will send the request to the proxy server using the GET method of the HTTP protocol similar to the below line.

 GET www.example.com

 ——-
 —- Request  —-
 ——–

The proxy server will parse this line and connect to example.com and forward the request. Similarly the response.

The HTTP protocol also provides a feature called CONNECT method(RFC2616) specifically to be used with proxy servers  to tunnel to a different port other than 80. This is one of the features a proxy servers can optionally provide to connect with internet machines with ports other than 80.  In fact your browsers send the CONNECT request to the proxy server when you try to hit a URL using port other than 80 (e.g HTTPS). It will be similar to the lines below

 CONNECT www.abc.com:544

 ——-
 —- Request  —-
 ——–

What happens in this case is that,  The proxy server establishes a tunnel directly from your machine and to the  machine in the internet without much care about the content you are sending.

An important point here is to note that the GET method is specifically designed to support the HTTP protocol and thus connects to port 80 of the outside machine(Thats why we dont specify any port in the GET method). So while using the GET method the proxy server has all access to the request & response(All text & HTML content) you are making and thus can filter, cache them based on the content. But in case of the CONNECT method, the CONNECT method is designed to handle all the protocols  regardless of the content,  which means a proxy server can also be used to relay non HTTP contents (e.g. SSL). Here the proxy server cannot choose to filter the data based on the content because the data flowing through this method is so generic as it supports all the protocols of all the formats (For e.g What is the criteria upon which you will be able to filter, if the data flowing through the tunnel is encrypted using SSL).

The proxy server and the HTTPS problem:

A proxy server can handle  websites based on HTTP protocol using the GET method. But the proxy server also should provide a way to handle website based on HTTPS protocol. As you know the HTTPS is the secured version of HTTP, the data is obviously encrypted and the HTTPS web servers also run on port 443. This is where the CONNECT method comes in to picture. So to support the HTTPS protocol inside a proxy server, the CONNECT method using tunneling seems to the simplest solution but as you will see below, it is not the secure solution.

A proxy server can choose not to support the CONNECT method but the problem is that,  the HTTPS protocol involves certificate exchanges from both sending & receiving ends. So when a proxy server is involved, the real sender is the proxy server. So the proxy server have to do the certificate exchanges and have to implement the entire SSL protocol.So what most of the proxy servers(notice the “most”, not all the server does this) does is to simply use the CONNECT method using tunneling.

So for the sake of supporting the HTTPS protocol, The CONNECT feature of the HTTP protocol is enabled in the proxy server for tunneling the HTTPS data. And this is the feature we are going to take advantage of.

Taking advantage of the CONNECT method:

 Now we know what the CONNECT method is. You very well know that your proxy server supports the HTTPS(443) protocol using the CONNECT method. And you also know that any machine in the world(internet) which hosts a HTTPS server can be contacted through your proxy server. And you also very well know that nothing could be traced when using the CONNECT method because the proxy server doesnt have a way to filter this data and thus allows the data to be tunnelled. So here comes the idea. Host your application on port 443 on any machine on the internet(impersonating as a real HTTPS Server) and access it from inside and that is it!! You have successfully communicated with your program on the outside machine without monitoring. Your pity proxy server thinks that he is accessing a real HTTPS server thus establishing a tunnel between your college/office machine and the machine on the internet.(Impersonation is crime!! So beware ).

There are a range of possibilities one could perform from here. You could host a proxy server in your home machine(ofcourse at port 443) and access internet without restrictions from the office machine, access shell account, connect to a game server etc, etc . Below I have described how to host the windows remote desktop server on your home machine at port 443 and remotely access it.

There are 2 softwares reqd. DynDNS and the cntlm. “DynDNS” is the software which provides DNS functionality for your dynamically changing IP address(Suppose you switch on and off your modem). It is to be used at your home machine and not in the office.  DynDNS provides you a domain name address which you can use instead of your frequently changing IP address. Just take a look at dyndns.com.  ”cntlm” is a small tunneling software between your machine at the office/college and the proxy server. This software is used with the applications which doesnt have option to specify a proxy server to communicate with the internet. For e.g Windows Remote desktop client(Which can be used only to communicate with host directly and not through a proxy). ”cntlm” is to be used at your office/college machine and not in your home. It requires no installation.  Just you can copy through your mail.

So for a successful setup these are the steps you need to follow.

In your home machine:

1) Setup windows remote desktop server at port 443. change the registry value “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber” to 443 and restart the machine. This activity hosts your remote desktop at port 443.

2) Install DynDNS(optional).

In the machine in your work place:

1) Edit cntlm.ini file to specify the proxy server IP, Your home machine IP or domain name(DynDNS), local port, user name, password for your proxy server, etc. See below

Username testuser
Domain  corp-uk
Password password  # Use hashes instead (-H)
#Workstation netbios_hostname # Should be auto-guessed

Proxy  10.217.112.41:8080
Proxy  10.217.112.42:8080

# Tunnels mapping local port to a machine behind the proxy
#
Tunnel  1045:homeip.com:443
2) start cntlm in the commandline using cntlm -c cntlm.ini -v

3) Start your remote desktop client using mstsc.exe and specify the localhost and localport which you specified in step 1. For e.g localhost:1045

4) In the cntlm window you can see whether the connection has been successfully established.

Configuring XA with Websphere MQ v5.3 for AIX 5.2(IBM RISC System/6000) and Sybase 12.5.2

Anyone having a hard time configuring XA to work with Sybase 12.5.2 + Embedded SQL/C and Websphere MQ 5.3 can go through the below document and see if it helps. I really had a hard time figuring this out with no proper documentation or help page given in the IBM or Sybase website and finally had it working.

The real problem was in the sample switch provided by IBM in /usr/mqm/samp/xatm folder. You have to make a few changes to make it work.

1) First, In the sybswit.c change the sybase_TUX_xa_switch to sybase_TXA_xa_switch. This is the structure we need to use for multithreaded applications.(Ref: http://www2.roguewave.com/support/docs/sourcepro/edition8/html/dbxaug/5-3.html)

2) Next, In the make file change the SYBLIBS line to SYBLIBS=-lintl_r.so -lct_r.so -lcs_r.so -lcomn_r.so -ltcl_r.so -lxadtm. The libraries linked should be shareable versions of CS-Library which ends with .so.(Ref: http://manuals.sybase.com/onlinebooks/group-as/asg1250e/xainterf/@Generic__BookTextView/2131;pt=991/*)  Also make sure you use the proper version of the library. The below command in AIX can be used to check it.

strings intl_r.so | grep Sybase

3) If you are using C/Embedded SQL make sure the -V flag for cpre(ESQL precompiler) is set to CS_VERSION_125. MQ uses this version of the global context to store the connection. IMHO it depends on the version of the xadtm library you use it to link with the switch file or you can use the -V of XAOpenString  in the qm.ini file to emulate  older versions. The only option for -V is -V11 which emulates CS_VERSION_110.

If you mess up with any of the above three steps you will end up with the “connection does not exist” error in the “EXEC SQL SET CONNECTION connection01″ connection statement of the C/Embedded SQL and with no clues in the XA logs, the system logs or any logs for that matter. Below is the error,

** SQLCODE=(-33620271)
** SQL Server Error
** cs_objects: cslib user api layer: external error: 08003 Connection exception — Connection does not exist.

Note: Although the reference I had provided is for different products(One for CICS and the other for DB XA module), IMO the statements hold for MQ too(Atleast It works for me!!) although no documentation is provided.

Below I am giving the detailed step by step procedure for configuring the XA connection with MQ and sybase + C/Embedded SQL, assuming that you already have the programming experience in Embedded SQL and MQ but don’t know how to setup and use XA connections in code. We had the below system configuration. Make sure it matches yours.

$ uname
AIX
$ oslevel
5.2.0.0
$ getconf -a | grep KERN
KERNEL_BITMODE:                         32
$ dspmqver
Name:        WebSphere MQ
Version:     530.11  CSD11
CMVC level:  p530-11-L050802
BuildType:   IKAP - (Production)
$ isql -U****** -P****** -S****** -w1000
1> select @@version
2> go

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Adaptive Server Enterprise/12.5.2/EBF 12056 ESD#2/P/RS6000/AIX 5.1/ase1252/1844/64-bit/FBO/Thu Aug 12 02:44:26 2004

Below are the steps:

1) The database settings should have the below properties for XA DTM to work.

1> select license_enabled('ASE_DTM')
2> go

-----------
1

(1 row affected)

1> sp_displaylogin
2> go
Suid: 3
Loginame: *******
Fullname:
Default Database: ******
Default Language:
Auto Login Script:
Configured Authorization:
sybase_ts_role (default ON)
dtm_tm_role (default ON)
Locked: NO
Date of Last Password Change: Jan 24 2007  7:12PM
Password expiration interval: 0
Password expired: NO
Minimum password length: 6
Maximum failed logins: 0
Current failed login attempts:
Authenticate with: ANY
(return status = 0)

1> sp_configure "enable DTM"
2> go
Parameter Name                 Default     Memory Used Config Value Run Value   Unit                 Type
------------------------------ ----------- ----------- ------------ ----------- -------------------- ----------
enable DTM                               0           0           1            1 switch               static

(1 row affected)
(return status = 0)
1> sp_configure "enable xact coordination"
2> go
Parameter Name                 Default     Memory Used Config Value Run Value   Unit                 Type
------------------------------ ----------- ----------- ------------ ----------- -------------------- ----------
enable xact coordination                 1           0           1            1 switch               static

(1 row affected)
(return status = 0)

2) Build the sybase switch for MQ using the steps I had discussed above.

3) Stop the queue manager using endmqm and add the Resource Manager stanza to the qm.ini of the queue manager (found in /var/mqm/qmgrs/) as below

XAResourceManager:
Name=mysybase
SwitchFile=/var/mqm/qmgrs/TEST!QM2/sybswit
XAOpenString=-U****** -P****** -Nconnection01 -L/tmp/sybaseQM2.log -Txa
ThreadOfControl=THREAD

4) The “connection01″ specified in the XAOpenString above is the LRM(Logical Resource Manager) name which should be added in the sybase XA config file found in (/usr/sybase/xa_config) as shown.

[xa]
lrm=connection01
server=*****

The path of the xa_config file is determined by the XACONFIGFILE environment variable.

$ echo $XACONFIGFILE
/usr/sybase/xa_config

5) Use the MQBEGIN API in the code to establish the connection with the database. It will be done internally. While running the code monitor the xa logs for errors.

6) Instead of “EXEC SQL CONNECT :username IDENTIFIED BY :password;” in the code use “EXEC SQL SET CONNECTION connection01;” to use the connection already established by the MQBEGIN API. The connection01 is the LRM name we specified in the XAOpenString in the qm.ini and the sybase xa_config file.

7) You need not disconnect the connection using “EXEC SQL DISCONNECT”. The connection will be closed automatically by the MQCMIT and MQBACK API.

8 ) Build your C/Embedded SQL application using the same libraries used for making the switch file.

9) Start the queue manager and make sure no errors are logged in the xa trace file which we specified in the XAOpenString of the qm.ini

I think the above steps help to get started.