Wednesday, September 8, 2010

Linux - Virus free??

I have heard many people asking about viruses for Linux systems. So, is Linux really virus free? The answer is NO, it is not. But yes, there are many technical as well as other challenges in creating a malicious software for Linux. This applies for Unix systems as well. So, what are they? Lets start with the non-Technical problems.

1. Linux is opensource - One very straight forward reason is, no one is interested in opening an already open box. Its always wonderful and motivating to break through a closed system.

2. Huge Community support - This means that there are millions of developer scanning the code for any security risks. And as soon as a virus appears on the web, these developers are always ready to squash them out by providing fixes to the code. This happens much before the virus spreads to the masses. This is highly demotivating for the people who write viruses, just to get them thrown out within minutes.

2. No monetary gain for Linux viruses - Since Linux is free and created by community, there is no one who is going to pay you for writing viruses for Linux.

Now the Technical Challenges - The only technical challenge is the strict file permissioning system in the *nix based systems including Mac OS X. If you are running as root, then its as vulnerable as any other Microsoft OS. In such cases the processes will all the access they want and can easily modify the system binaries and insert virus code in them. However, if you are running as normal user, then no virus can harm your system. The processes wont have access to modify the binaries, and in any case they will not be able to change them.

Hope that was helpful. Comments invited.

Wednesday, April 21, 2010

Tunneling - Breaking through firewalls



Ever irritated by blocked ports and websites in your office? Ever thought, what if you could send all your data to the external world using the ports that are open to you. This is very much possible using ssh (secure shell) tunneling. All you need is a ssh server in external network that is accessible to you from your restricted network. (You can easily setup you home computer with internet connection to work as a ssh server for you, this will be covered in a separate post).
What we are trying to achieve can be summarized by the picture below:


Here the client machine is the system in the restricted network (with only few ports open to external world). Sshdserver, is a ssh server running on one of the ports which are allowed by your firewall (in your restricted network) and the appserver is the machine that you want to have access to, but cannot directly access it from your Client (due to firewall rules, blocked ports or whatever reason). So how do we achieve this:

For windows users they will need a freeware called putty, which is an excellent terminal emulator and ssh client. For unix and linux users, they already have ssh client built-in to their system, so they just need to execute a simple command.

Scenario: Suppose you want to access remote desktop (windows rdc service) of Appserver which by default runs on port 3389. Also, SshdServer should be able to access Appserver's 3389 port. Let us also assume that you have ports 80 (http) and 22 (ssh) open in you firewall. (these ports can be any x and y ports). In this scenario, you will have to configure you sshdserver to run on port 22 (this is default, you can change the port settings of an ssh server to run on different port, lets say y).

Then for windows, open putty, and enter the details as in the picture below:


Then click on the Connection->SSH->Tunnels option in the left tree. There enter 80 (or x) in the source port and Appserver:3389 in the destination and click add. Then you will have a screen something like:

Let us understand what this setting means. It instructs putty to capture any network traffic that will be sent from any application on your client system to it's loopback interface (or to self) on port 80 and redirect that traffic to you sshdserver. It also instructs your sshdserver to forward this traffic to Appserver's 3389 port and get the response back to your client machine. So basically it establishes a tunnel like:

App on client <-> localhost:80 <--> putty (running on client) <==> SshdServer <--> Appserver:3389

Here == denotes the secure tunnel established between putty on your Client machine and the SshdServer.

Now, go back to the session option in putty and click save and open. Enter the user and password for the sshdserver. Putty will now create the tunnel for you.

For Linux or Unix users just type:

ssh -f userid@Sshdserver -L 80:Appserver:3389 -N


Here userid is the user that you can use to login to Sshdserver's terminal.

Once you have the tunnel created, you can open the rdc of Appserver using mstsc:

Please note that here we specify localhost as the host name and 80 as the port number and click connect. And VOILA!! you have it. For linux or unix, you can use rdesktop to do the same.