Archive for May, 2007

Port Tunneling HOWTO Part 2

May 22, 2007

In my previous post I focused on how to use port tunneling for only one server. In the world of world wide web, however, you will most likely want to connect to different servers repeatedly, jumping between pages without having to reissue ssh commands over and over. Well, the power of ssh provides even that option. Using this configuration, you will essentially create a SOCKS service running from your computer to the server. The command is simple:

ssh -N -D portNum userName@serverName

On the screen, a prompt will ask you for your password. The N flag stands for no output, meaning it will only make the connection, without actually letting you type commands. The D flag is for the SOCKS connection that I mentioned earlier. Now, all you will need to do is tell you browser/IM client/whatever else program that can use SOCKS sockets, to use your local address, ie 127.0.0.1, with port number being the number that you entered following the D flag. In Firefox it is accomplished by going to Preferences, hitting the Advanced tab, navigating the Network tab underneath, and under connections hitting Settings. From there, you can hit Manual Proxy Configuration, and under SOCKS Host write the mentioned before. When everything is good, try going to different sites and see if it works.

Advertisements

Firewall for the Practical User

May 21, 2007

Firewalls are mostly used in enterprise companies to restrict access to certain ports and services. The difference between proxies and firewalls is that proxies can filter or modify content that passes through them. Firewalls work on a lower lever, filtering access to certain ports, certain services, or tcp or udp traffic. With that being said, why would an average computer user want a firewall? Of course, there is increased security, since only the ports that you need are open, meaning you can deny ping requests or telnet sessions ever being opened. Most average users don’t really care about security though, since malicious users usually will try to go after big-name servers. However, a practical use of setting up a firewall at home is to allow to computers or more to exist on the network at the same time. Most people nowadays buy home routers made by Linksys or D-Link, but those can be expensive. For a firewall, all you really need is a computer with two NIC cards. You can buy one really cheap either from ebay or from a local computer store. Make sure it is working when you start the computer, and assign it with a static ip address, usually 192.168.0.1. Make sure you can ping that ip address. If you only have one more computer to connect, you can connect it straight to the firewall, but make sure that you use a crossover cable, because it is a peer-to-peer connection. If you have more than one computer to connect, would like to have the potential to link other computers, or simply don’t want to deal with crossover cables, you can get yourself a small hub or switch to put between your firewall and your internal network. There’s no point in putting a router there, since it creates unneeded redundancy. Assign the internal node a static ip address also, for example 192.168.0.5. If the internal node can ping the firewall at the static ip address 192.168.0.1, then you are golden. Otherwise, there is something wrong with the cables or with the switch/hub. Since assigning static ips is a pain, we want DHCP to do the work for us. So, install and configure dnsmasq, in order to make sure it is running. If you configure your internal nodes to automatically assign themselves an IP address from a DHCP server at boot up and point them to the firewall, they should have an automatic IP address on startup. Test this setup thoroughly to make sure it is working. That is the easy part. The hard part is getting iptables to work, which you’ll have to install in order to have the firewall running. What we want to do is NAT (Network Address Translation), which takes all the packets originating at the internal nic, and modifies the origin to be the external nic, thereby abstracting the internal computers from the rest of the world. First of all, you need to make sure that your kernel supports iptables. Most distributions come with iptables configured, but you need to make sure. Since I use Gentoo, the kernel usually doesn’t have it. I therefore used genkernel after many frustrating recompiles, but ideally this configuration guide should let you know what to have enabled in your .config file. After you know your kernel is working and supports iptables (I suggest building everything as modules), make some basic rules to know that it’s working. Now, in order to get everything flowing nicely together, you can do two things. You can either install firestarter, a firewall GUI which will setup the rules for you, or you can do it by hand. Here is what you would need to type in order for iptables to work with NAT:


First we flush our current rules
# iptables -F
# iptables -t nat -F

Setup default policies to handle unmatched traffic
# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD DROP

Copy and paste these examples ...
# export LAN=eth0
# export WAN=eth1

Then we lock our services so they only work from the LAN
# iptables -I INPUT 1 -i ${LAN} -j ACCEPT
# iptables -I INPUT 1 -i lo -j ACCEPT
# iptables -A INPUT -p UDP --dport bootps -i ! ${LAN} -j REJECT
# iptables -A INPUT -p UDP --dport domain -i ! ${LAN} -j REJECT

(Optional) Allow access to our ssh server from the WAN
# iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

Drop TCP / UDP packets to privileged ports
# iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP
# iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 --dport 0:1023 -j DROP

Finally we add the rules for NAT
# iptables -I FORWARD -i ${LAN} -d 192.168.0.0/255.255.0.0 -j DROP
# iptables -A FORWARD -i ${LAN} -s 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

Tell the kernel that ip forwarding is OK
# echo 1 > /proc/sys/net/ipv4/ip_forward
# for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

This is so when we boot we don't have to run the rules by hand
# /etc/init.d/iptables save
# rc-update add iptables default
# nano /etc/sysctl.conf

Add/Uncomment the following lines:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

If you have a dynamic internet address you probably want to enable this:
net.ipv4.ip_dynaddr = 1

Courtesy of a gentoo linux howto.

From there on, try to access google from one your internal computers. If everything is done correctly it should work. Granted, some ports will be blocked by your firewall, so you will need to open them on a need-per-port basis.

Port Tunneling HOWTO

May 19, 2007

As almost everyone knows by now, the internet is not anonymous at all. There are numerous ways for someone, whether it be your Internet Service Provider, some curious onlooker, or a potential vandal, to see what you what articles and information you process when you are online. Whether that is right or not I don’t really care about, but what is annoying is someone restricting access to what you can use. Fortunately, there is OpenSSH, a free telnet-like service, which lets you remotely control a machine, but also encrypts everything on the way. The cool thing about it, though, is that we can use it as a secure channel to remotely send information, which no one in the middle can understand, since it is encrypted. Basically, what happens is that the client encrypts the information that it is about to send, and when the server receives the information, it decrypts it back into a normal packet and sends it to its appropriate destination. The opposite thing happens when the server sends information to a client. Therefore, it is possible to connect to a port which is restricted on the network you are on, as well as send and receive totally secure information between yourself and the ssh server. In order for this to work, you will need to have access to some remote ssh server that is outside of the network you feel uncomfortable with. A nice solution is to set up a ssh server at home, and then connect to it from work or school, where you are on the restricted network. If you’re using a Unix-like OS, just follow your distribution’s guides. If you’re using Windows, you can install cygwin or alternative try to get sshwindows working. Once you have it setup and running (you actually verified this), you should be able to connect to your server from the unsecure network. Although it is possible to use port tunneling for any port whatsoever, I will focus on port 80, known as http, which is restricted most of the time. If there is no ssh client on your client, and you are on Windows, you can always use plink, an ssh replacement, and replace all commands that start with “ssh” to start with “plink”. The syntax is such:

# ssh -l userName -v -L sourcePort:externalServer:DestPort sshServer

For instance, we will make a tunnel to ecks.homeunix.net (this site is always blocked). For the sourcePort, we will use 9999, although you can use any non-active port you choose.Thus, the command becomes such:

# ssh -l userName -v -L  9999:ecks.homeunix.net:80 mysshserver

After you login with your password, it should give you some diagnostic output as to what is going on. Next fire up your favorite web browser and type into the url field “http://127.0.0.1:9999”. If everything is done right, this site should be staring you in the face. You can now browse through it securely, without worrying about someone knowing what you are looking at. I hope you enjoyed this informative article. In the meantime, here is an article that explains tunneling in more detail:

securityfocus link