Tunnel with VTUN and SSH

Udgivet den juli 10, 2004 af mike

Connect two networks using VTun and a single SSH connection.

VTun is a user-space tunnel server, allowing entire networks to be tunneled to each other using the tun universal tunnel kernel driver. An encrypted tunnel such as VTun allows roaming wireless clients to secure all of their IP traffic using strong encryption. It currently runs under Linux, BSD, and Mac OS X. The examples in this hack assume that you are using Linux.

The procedure described next will allow a host with a private IP address (10.42.4.6) to bring up a new tunnel interface with a real, live, routed IP address (208.201.239.33) that works as expected, as if the private network weren’t even there. Do this by bringing up the tunnel, dropping the default route, and then adding a new default route via the other end of the tunnel.

To begin with, here is the (pretunneled) network configuration:

root@client:~# ifconfig eth2

eth2 Link encap:Ethernet HWaddr 00:02:2D:2A:27:EA

inet addr:10.42.3.2 Bcast:10.42.3.63 Mask:255.255.255.192

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:662 errors:0 dropped:0 overruns:0 frame:0

TX packets:733 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:105616 (103.1 Kb) TX bytes:74259 (72.5 Kb)

Interrupt:3 Base address:0x100

root@client:~# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

10.42.3.0 * 255.255.255.192 U 0 0 0 eth2

loopback * 255.0.0.0 U 0 0 0 lo

default 10.42.3.1 0.0.0.0 UG 0 0 0 eth2

As you can see, the local network is 10.42.3.0/26, the IP is 10.42.3.2, and the default gateway is 10.42.3.1. This gateway provides network address translation (NAT) to the Internet. Here’s what the path looks like to yahoo.com:

root@client:~# traceroute -n yahoo.com

traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets

1 10.42.3.1 2.848 ms 2.304 ms 2.915 ms

2 209.204.179.1 16.654 ms 16.052 ms 19.224 ms

3 208.201.224.194 20.112 ms 20.863 ms 18.238 ms

4 208.201.224.5 213.466 ms 338.259 ms 357.7 ms

5 206.24.221.217 20.743 ms 23.504 ms 24.192 ms

6 206.24.210.62 22.379 ms 30.948 ms 54.475 ms

7 206.24.226.104 94.263 ms 94.192 ms 91.825 ms

8 206.24.238.61 97.107 ms 91.005 ms 91.133 ms

9 206.24.238.26 95.443 ms 98.846 ms 100.055 ms

10 216.109.66.7 92.133 ms 97.419 ms 94.22 ms

11 216.33.98.19 99.491 ms 94.661 ms 100.002 ms

12 216.35.210.126 97.945 ms 93.608 ms 95.347 ms

13 64.58.77.41 98.607 ms 99.588 ms 97.816 ms

In this example, we are connecting to a tunnel server on the Internet at 208.201.239.5. It has two spare live IP addresses (208.201.239.32 and 208.201.239.33) to be used for tunneling. We’ll refer to that machine as the server, and our local machine as the client.

Now let’s get the tunnel running. To begin with, load the tun driver on both machines:

# modprobe tun

It is worth noting that the tun driver will sometimes fail if the server and client kernel versions don’t match. For best results, use a recent kernel (and the same version, e.g., 2.4.20) on both machines.

On the server machine, save this file to /usr/local/etc/vtund.conf:

options {

port 5000;

ifconfig /sbin/ifconfig;

route /sbin/route;

syslog auth;

}

default {

compress no;

speed 0;

}

home {

type tun;

proto tcp;

stat yes;

keepalive yes;

pass sHHH; # Password is REQUIRED.

up {

ifconfig “%% 208.201.239.32 pointopoint 208.201.239.33”;

program /sbin/arp “-Ds 208.201.239.33 %% pub”;

program /sbin/arp “-Ds 208.201.239.33 eth0 pub”;

route “add -net 10.42.0.0/16 gw 208.201.239.33”;

};

down {

program /sbin/arp “-d 208.201.239.33 -i %%”;

program /sbin/arp “-d 208.201.239.33 -i eth0”;

route “del -net 10.42.0.0/16 gw 208.201.239.33”;

};

}

Launch the vtund server like so:

root@server:~# vtund -s

Now you’ll need a vtund.conf file for the client side. Try this one, again in /usr/local/etc/vtund.conf:

options {

port 5000;

ifconfig /sbin/ifconfig;

route /sbin/route;

}

default {

compress no;

speed 0;

}

home {

type tun;

proto tcp;

keepalive yes;

pass sHHH; # Password is REQUIRED.

up {

ifconfig “%% 208.201.239.33 pointopoint 208.201.239.32 arp”;

route “add 208.201.239.5 gw 10.42.3.1”;

route “del default”;

route “add default gw 208.201.239.32”;

};

down {

route “del default”;

route “del 208.201.239.5 gw 10.42.3.1”;

route “add default gw 10.42.3.1”;

};

}

Finally, run this command on the client:

root@client:~# vtund -p home server

Presto! Not only do you have a tunnel up between client and server, but also a new default route via the other end of the tunnel. Take a look at what happens when we traceroute to yahoo.com with the tunnel in place:

root@client:~# traceroute -n yahoo.com

traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets

1 208.201.239.32 24.368 ms 28.019 ms 19.114 ms

2 208.201.239.1 21.677 ms 22.644 ms 23.489 ms

3 208.201.224.194 20.41 ms 22.997 ms 23.788 ms

4 208.201.224.5 26.496 ms 23.8 ms 25.752 ms

5 206.24.221.217 26.174 ms 28.077 ms 26.344 ms

6 206.24.210.62 26.484 ms 27.851 ms 25.015 ms

7 206.24.226.103 104.22 ms 114.278 ms 108.575 ms

8 206.24.238.57 99.978 ms 99.028 ms 100.976 ms

9 206.24.238.26 103.749 ms 101.416 ms 101.09 ms

10 216.109.66.132 102.426 ms 104.222 ms 98.675 ms

11 216.33.98.19 99.985 ms 99.618 ms 103.827 ms

12 216.35.210.126 104.075 ms 103.247 ms 106.398 ms

13 64.58.77.41 107.219 ms 106.285 ms 101.169 ms

This means that any server processes running on the client are now fully available to the Internet, at IP address 208.201.239.33. This has all happened without making a single change (e.g., port forwarding) on the gateway 10.42.3.1.

Here’s what the new tunnel interface looks like on the client:

root@client:~# ifconfig tun0

tun0 Link encap:Point-to-Point Protocol

inet addr:208.201.239.33 P-t-P:208.201.239.32 Mask:255.255.255.255

UP POINTOPOINT RUNNING MULTICAST MTU:1500 Metric:1

RX packets:39 errors:0 dropped:0 overruns:0 frame:0

TX packets:39 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10

RX bytes:2220 (2.1 Kb) TX bytes:1560 (1.5 Kb)

And here’s the updated routing table (note that we still need to keep a host route to the tunnel server’s IP address via our old default gateway; otherwise, the tunnel traffic can’t get out):

root@client:~# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

208.201.239.5 10.42.3.1 255.255.255.255 UGH 0 0 0 eth2

208.201.239.32 * 255.255.255.255 UH 0 0 0 tun0

10.42.3.0 * 255.255.255.192 U 0 0 0 eth2

10.42.4.0 * 255.255.255.192 U 0 0 0 eth0

loopback * 255.0.0.0 U 0 0 0 lo

default 208.201.239.32 0.0.0.0 UG 0 0 0 tun0

To bring down the tunnel, simply kill the vtund process on client. This restores all network settings back to their original states.

This method works fine if you trust VTun to use strong encryption and to be free from remote exploits. Personally, I don’t think you can be too paranoid when it comes to machines connected to the Internet. To use VTun over SSH (and therefore rely on the strong authentication and encryption that SSH provides), simply forward port 5000 on the client to the same port on the server. Give this a try:

root@client:~# ssh -f -N -c blowfish -C -L5000:localhost:5000 server

root@client:~# vtund -p home localhost

root@client:~# traceroute -n yahoo.com

traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets

1 208.201.239.32 24.715 ms 31.713 ms 29.519 ms

2 208.201.239.1 28.389 ms 36.247 ms 28.879 ms

3 208.201.224.194 48.777 ms 28.602 ms 44.024 ms

4 208.201.224.5 38.788 ms 35.608 ms 35.72 ms

5 206.24.221.217 37.729 ms 38.821 ms 43.489 ms

6 206.24.210.62 39.577 ms 43.784 ms 34.711 ms

7 206.24.226.103 110.761 ms 111.246 ms 117.15 ms

8 206.24.238.57 112.569 ms 113.2 ms 111.773 ms

9 206.24.238.26 111.466 ms 123.051 ms 118.58 ms

10 216.109.66.132 113.79 ms 119.143 ms 109.934 ms

11 216.33.98.19 111.948 ms 117.959 ms 122.269 ms

12 216.35.210.126 113.472 ms 111.129 ms 118.079 ms

13 64.58.77.41 110.923 ms 110.733 ms 115.22 ms

In order to discourage connections to vtund on port 5000 of the server, add a net filter rule to drop connections from the outside world:

root@server:~# iptables -A INPUT -t filter -i eth0 \

-p tcp –dport 5000 -j DROP

This allows local connections to get through (since they use loopback), and therefore requires an SSH tunnel to the server before accepting a connection.

As you can see, this can be an extremely handy tool to have around. In addition to giving live IP addresses to machines behind a NAT, you can effectively connect any two networks if you can obtain a single SSH connection between them (originating from either direction).

If your head is swimming from this vtund.conf configuration or you’re feeling lazy and don’t want to figure out what to change when setting up your own client’s vtund.conf file, take a look at the automatic vtund.conf generator [Hack #79] .

Udgivet i Knowledge Base, Networking, Old Base | Skriv en kommentar

Tunnel connections inside http

Udgivet den juli 10, 2004 af mike

Break through draconian firewalls by using httptunnel.

If you’ve ever been on the road and found yourself in a place where the only connectivity to the outside world is through an incredibly restrictive firewall, you probably know the pain of trying to do anything other than sending and receiving email or basic web browsing.

Here’s where httptunnel (http://www.nocrew.org/software/httptunnel.html) comes to the rescue. Httptunnel is a program that allows you to tunnel arbitrary connections through the HTTP protocol to a remote host. This is especially useful in situations like the one mentioned earlier, when web access is allowed but all other services are denied. Of course, you could just use any kind of tunneling software and configure it to use port 80, but where would that leave you if the firewall is actually a web proxy? This is roughly the same as an application-layer firewall, and will accept only valid HTTP requests. Fortunately, httptunnel can deal with these as well.

To compile httptunnel, download the tarball and run configure and make:

$ tar xfz httptunnel-3.3.tar.gz
$ cd httptunnel-3.3

$ ./configure && make

Install it by running make install, which will install everything under /usr/local. If you want to install it somewhere else, you can use the standard –prefix= option to the configure script.

The httptunnel client program is called htc, and the server is hts. As with ssh [Hack #76], httptunnel can be used to listen on a local TCP port for connections, forward the traffic that it receives on this port to a remote server, and then decrypt and forward the traffic to another port outside of the tunnel.

Try tunneling an SSH connection over HTTP. On the server, run a command like this:

# hts -F localhost:22 80

Now, run a command like this on the client:

# htc -F 2222 colossus:80

In this case, colossus is the remote server, and htc is listening on port 2222. You can use the standard port 22 if you aren’t running a local sshd. If you’re curious, you can verify that htc is now listening on port 2222 by using lsof:

# /usr/sbin/lsof -i | grep htc

htc 2323 root 6u IPv4 0x02358a30 0t0 TCP *:2222 (LISTEN)

And now to try out the tunnel:

[andrew@kryten andrew]$ ssh -p 2222 localhost

andrew@localhost’s password:

[andrew@colossus andrew]$

You can also forward connections to machines other than the one that you’re running hts on. To do this, just replace the localhost in the hts command with whatever remote host you wish to forward to.

For instance, to forward the connection to oceana.ingsoc.net instead of colossus, you could run this command:

# hts -F oceana.ingsoc.net:22 80

If you’re curious to see what an SSH connection tunneled through the HTTP protocol looks like, you can take a look at it with a packet sniffer. Here’s the initial portion of the TCP stream that is sent to the httptunnel server by the client:

POST /index.html?crap=1071364879 HTTP/1.1

Host: linux-vm:80

Content-Length: 102400

Connection: close

SSH-2.0-OpenSSH_3.6.1p1+CAN-2003-0693

If your tunnel needs to go through a web proxy, no additional configuration is needed as long as the proxy is transparent and does not require authentication. If the proxy is not transparent, you can specify it with the -P switch. Additionally, if you do need to authenticate with the proxy, you’ll want to make use of the -A or –proxy-authorization options, which allow you to specify a username and password to authenticate with.

Here’s how to use these options:

htc -P myproxy:8000 -A andrew:mypassword -F 22 colossus:80

If the port that the proxy listens on is the standard web proxy port (8080), then you can just specify the proxy by using its IP address or hostname.

Udgivet i Knowledge Base, Networking, Old Base, SSH | Skriv en kommentar

Using SSH as socks proxy

Udgivet den juli 10, 2004 af mike

Protect your web traffic using the basic VPN functionality built into SSH itself.

In the search for the perfect way to secure their wireless networks, many people overlook one of the most useful features of SSH: the -D switch. This simple little switch is buried within the SSH manpage, toward the bottom. Here is a direct quote from the manpage:

-D port

Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS 4 protocol is supported, and SSH will act as a SOCKS 4 server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.

This turns out to be an insanely useful feature if you have software that is capable of using a SOCKS 4 proxy. It effectively gives you an instant encrypted proxy server to any machine that you can SSH to. It does this without the need for further software, either on your machine or on the remote server.

Just as with SSH port forwarding [Hack #72], the -D switch binds to the specified local port and encrypts any traffic to that port, sends it down the tunnel, and decrypts it on the other side. For example, to set up a SOCKS 4 proxy from local port 8080 to remote, type the following:

rob@caligula:~$ ssh -D 8080

remote

That’s all there is to it. Now you simply specify localhost:8080 as the SOCKS 4 proxy in your application, and all connections made by that application will be sent down the encrypted tunnel. For example, to set your SOCKS proxy in Mozilla, go to Preferences Advanced Proxies, as shown in Figure 6-7.
Figure 6-7. Proxy settings in Mozilla.

Select “Manual proxy configuration”, then type in localhost as the SOCKS host. Enter the port number that you passed to the -D switch, and be sure to check the SOCKSv4 button.

Click OK, and you’re finished. All of the traffic that Mozilla generates is now encrypted and appears to originate from the remote machine that you logged into with SSH. Anyone listening to your wireless traffic now sees a large volume of encrypted SSH traffic, but your actual data is well protected.

One important point to keep in mind is that SOCKS 4 has no native support for DNS traffic. This has two important side effects to keep in mind when using it to secure your wireless transmissions.

First of all, DNS lookups are still sent in the clear. This means that anyone listening in can still see the names of sites that you browse to, although the actual URLs and data are obscured. This is rarely a security risk, but it is worth keeping in mind.

Second, you are still using a local DNS server, but your traffic originates from the remote end of the proxy. This can have interesting (and undesirable) side effects when attempting to access private network resources.

To illustrate the subtle problems that this can cause, consider a typical corporate network with a web server called intranet.example.com. This web server uses the private address 192.168.1.10 but is accessible from the Internet through the use of a forwarding firewall. The DNS server for intranet.example.com normally responds with different IP addresses depending on where the request comes from, perhaps using the views functionality in BIND 9. When coming from the Internet, you would normally access intranet.example.com with the IP address 208.201.239.36, which is actually the IP address of the outside of the corporate firewall.

Now suppose that you are using the SOCKS proxy example just shown, and remote is actually a machine behind the corporate firewall. Your local DNS server returns 208.201.239.36 as the IP address for intranet.mybusiness.com (since you are looking up the name from outside the firewall). But the HTTP request actually comes from remote and attempts to go to 208.201.239.36. Many times, this is forbidden by the firewall rules, as internal users are supposed to access the intranet by its internal IP address, 192.168.1.10. How can you work around this DNS schizophrenia?

One simple method to avoid this trouble is to make use of a local hosts file on your machine. Add an entry like this to /etc/hosts (or the equivalent on your operating system):

192.168.1.10 intranet.example.com

Likewise, you can list any number of hosts that are reachable only from the inside of your corporate firewall. When you attempt to browse to one of those sites, the local hosts file is consulted before DNS, so the private IP address is used. Since this request is actually made from remote, it finds its way to the internal server with no trouble. Likewise, responses arrive back at the SOCKS proxy on remote, are encrypted and forwarded over your SSH tunnel, and appear in your browser as if they came in from the Internet.

SOCKS 5 support is planned for an upcoming version of SSH, which will also make tunneled DNS resolution possible. This is particularly exciting for Mac OS X users, as there is support in the OS for SOCKS 5 proxies. Once SSH supports SOCKS 5, every native OS X application will automatically be able to take advantage of encrypting SSH socks proxies. In the meantime, we’ll just have to settle for encrypted HTTP proxies [Hack #74] .

Udgivet i Knowledge Base, Networking, Old Base, SSH | Skriv en kommentar

Opportunistic Encryption with FreeS/WAN

Udgivet den juli 10, 2004 af mike

Use FreeS/WAN and DNS TXT records to automatically create encrypted connections between machines.

One particularly cool feature supported by FreeS/WAN [Hack #67] is opportunistic encryption with other hosts running FreeS/WAN. This allows FreeS/WAN to transparently encrypt traffic between all hosts that also support opportunistic encryption. To do this, each host must have a public key generated to use with FreeS/WAN. This key can then be stored in a DNS TXT record for that host. When a host that is set up for opportunistic encryption wishes to initiate an encrypted connection with another host, it will look up the host’s public key through DNS and use it to initiate the connection.

To begin, you’ll need to generate a key for each host that you want to use this feature with. You can do that by running this command:

# ipsec newhostkey –output /tmp/`hostname`.key

Now you’ll need to add the contents of the file that was created by that command to /etc/ipsec.secrets:

# cat /tmp/`hostname`.key >> /etc/ipsec.secrets

Next, you’ll need to generate a TXT record to put into your DNS zone. You can do this by running a command similar to this one:

# ipsec showhostkey –txt @colossus.nnc

; RSA 2192 bits colossus Mon Jan 12 03:02:07 2004

IN TXT “X-IPsec-Server(10)=@colossus.nnc” ”

AQOR7rM7ZMBXu2ej/1vtzhNnMayZO1jwVHUyAIubTKpd/

PyTMogJBAdbb3I0xzGLaxadPGfiqPN2AQn76zLIsYFMJnoMbBTDY/2xK1X/

pWFRUUIHzJUqCBIijVWEMLNrIhdZbei1s5/

MgYIPaX20UL+yAdxV4RUU3JJQhV7adVzQqEmdaNUnCjZOvZG6m4zv6dGROrVEZmJFP54v6WhckYf

qSkQu3zkctfFgzJ/rMTB6Y38yObyBg2HuWZMtWI”

“8VrTQqi7IGGHK+mWk+wSoXer3iFD7JxRTzPOxLk6ihAJMibtKna3j7QP9ZHG0nm7NZ/

L5M9VpK+Rfe+evUUMUTfAtSdlpus2BIeXGWcPfz6rw305H9”

Now add this record to your zone and reload it. You can verify that DNS is working correctly by running this command:

# ipsec verify

Checking your system to see if IPsec got installed and started correctly

Version check and ipsec on-path [OK]

Checking for KLIPS support in kernel [OK]

Checking for RSA private key (/etc/ipsec.secrets) [OK]

Checking that pluto is running [OK]

DNS checks.

Looking for TXT in forward map: colossus [OK]

Does the machine have at least one non-private address [OK]

Now just restart FreeS/WAN by running a command similar to this:

# /etc/init.d/ipsec restart

You should now be able to connect to any other host that supports opportunistic encryption. But what if other hosts want to connect to you? To allow this, you’ll need to create a TXT record for your machine in your reverse DNS zone.

You can generate the record by running a command similar to this:

# ipsec showhostkey –txt 192.168.0.64

; RSA 2192 bits colossus Tue Jan 13 03:02:07 2004

IN TXT “X-IPsec-Server(10)=192.168.0.64″ ”

AQOR7rM7ZMBXu2ej/1vtzhNnMayZO1jwVHUyAIubTKpd/

PyTMogJBAdbb3I0xzGLaxadPGfiqPN2AQn76zLIsYFMJnoMbBTDY/2xK1X/

pWFRUUIHzJUqCBIijVWEMLNrIhdZbei1s5/

MgYIPaX20UL+yAdxV4RUU3JJQhV7adVzQqEmdaNUnCjZOvZG6m4zv6dGROrVEZmJFP54v6WhckYf

qSkQu3zkctfFgzJ/rMTB6Y38yObyBg2HuWZMtWI”

“8VrTQqi7IGGHK+mWk+wSoXer3iFD7JxRTzPOxLk6ihAJMibtKna3j7QP9ZHG0nm7NZ/

L5M9VpK+Rfe+evUUMUTfAtSdlpus2BIeXGWcPfz6rw305H9”

Add this record to the reverse zone for your subnet, and other machines will be able to initiate opportunistic encryption with your machine. With opportunistic encryption in use, all traffic between the hosts will be automatically encrypted, protecting all services simultaneously. Pretty neat, huh?

Udgivet i Knowledge Base, Kryptering, Networking, Old Base | Skriv en kommentar

Forward and encrypt trafic with ssh

Udgivet den juli 10, 2004 af mike

Keep network traffic to arbitrary ports secure with ssh port forwarding.

In addition to providing remote shell access and command execution, OpenSSH can also forward arbitrary TCP ports to the other end of your connection. This can be extremely handy for protecting email, web, or any other traffic that you need to keep private (at least, all the way to the other end of the tunnel).

ssh accomplishes local forwarding by binding to a local port, performing encryption, sending the encrypted data to the remote end of the ssh connection, then decrypting it and sending it to the remote host and port you specify. Start an ssh tunnel with the -L switch (short for Local):

# ssh -f -N -L 110:mailhost:110

user

@

mailhost

Naturally, substitute user with your username, and mailhost with your mail server’s name or IP address. Note that you will have to be root for this example, since you’ll be binding to a privileged port (110, the POP3 port). You should also disable any locally running POP3 daemon (look in /etc/inetd.conf) or it will get in the way.

Now, to encrypt all of your POP3 traffic, configure your mail client to connect to localhost port 110. It will happily talk to mailhost as if it were connected directly, except that the entire conversation will be encrypted. Alternatively, you could tell ssh to listen on a port above 1024 and eliminate the need to run it as root; however, you would have to configure your email client to also use this port, rather than port 110.

-f forks ssh into the background, and -N tells it not to actually run a command on the remote end (just do the forwarding). One interesting feature is that when using the -N switch you can still forward a port, even if you do not have a valid login shell on the remote server. However, for this to work you’ll need to set up public key authentication with the account beforehand. If your ssh server supports it, you can also try the -C switch to turn on compression. This can significantly reduce the time it takes to download email. In addition, connections can be sped up even more by using the blowfish cipher, which is generally faster than 3des (the default). To use the blowfish cipher, type -c blowfish. You can specify as many -L lines as you like when establishing the connection. To also forward outbound email traffic, try this:

# ssh -f -N -L 110:mailhost:110 -L 25:mailhost:25

user

@

mailhost

Now set your outbound email host to localhost, and your email traffic will be encrypted as far as mailhost. Generally, this is useful only if the email is bound for an internal host, or if you can’t trust your local network connection (as is the case with most wireless networks). Obviously, once your email leaves mailhost, it will be transmitted in the clear, unless you’ve encrypted the message with a tool such as pgp or gpg.

If you’re already logged into a remote host and need to forward a port quickly, try this:

1.

Press Enter.
2.

Type ~C.
3.

You should be at an ssh> prompt; enter the -L line as you would from the command line.

For example:

rob@catlin:~$

rob@catlin:~$ ~C ( it doesn’t echo)
ssh> -L8080:localhost:80

Forwarding port.

Your current shell will then forward local port 8000 to catlin’s port 80, as if you had entered it in the first place.

You can also allow other (remote) clients to connect to your forwarded port, with the -g switch. If you’re logged into a remote gateway that serves as a NAT for a private network, then use a command like this:

$ ssh -f -g -N -L8000:localhost:80 10.42.4.6

This will forward all connections from the gateway’s port 8000 to internal host 10.42.4.6’s port 80. If the gateway has a live Internet address, this will allow anyone from the Net to connect to the web server on 10.42.4.6 as if it were running on port 8000 of the gateway.

One last point worth mentioning: the forwarded host doesn’t have to be localhost; it can be any host that the machine you’re connecting to can access directly. For example, to forward local port 5150 to a web server somewhere on an internal network, try this:

$ ssh -f -N -L5150:intranet.insider.nocat:80 gateway.nocat.net

Assuming that you’re running a private domain called .nocat, and that gateway.nocat.net also has a connection to the private network, all traffic to port 5150 of remote will be obligingly forwarded to intranet.insider.nocat:80. The address intranet.insider.nocat doesn’t have to resolve in DNS to remote; it isn’t looked up until the connection is made to gateway.nocat.net, and then it’s gateway that does the lookup. To securely browse that site from remote, try connecting to http://localhost:5150/ .

Udgivet i Knowledge Base, Linux, Old Base, SSH | Skriv en kommentar

PPTP Tunneling

Udgivet den juli 10, 2004 af mike

Set up quick and easy VPN access using the Point-to-Point Tunneling Protocol.

The Point-to-Point Tunneling Protocol (PPTP) is basically a means to set up PPP tunnels [Hack #81] automatically without needing to manually start a PPP daemon on the remote machine. The main benefit of using PPTP is that both Windows and Mac OS X natively support the creation of VPN connections, and both provide easy-to-use GUIs for setting up the connections on the client side. Thus, you can provide a VPN solution without much effort on your users’ part.

To set up the server end, you can use PoPToP (http://www.poptop.org), an open source PPTP server. You can get a very simple PPTP VPN going with minimal effort—just download the source distribution and unpack it, then go into the directory it created.

After you’ve done that, you can run this command to compile it:

$ ./configure && make

Then become root and run this command to install PoPToP:

# make install

The PPTP daemon that this installs is called pptpd. Now you’ll need to create a configuration file for pptpd (i.e., /etc/pptpd.conf) and a pppd options file to use with it.

Here’s a suitable /etc/pptpd.conf to start out with:

option /etc/ppp/options.pptpd

localip 10.0.0.1

remoteip 10.0.0.2-100

This defines the IP address of the local end of the PPTP connection as 10.0.0.1 and creates a pool of addresses to be dynamically allocated to clients (i.e., 10.0.0.2-100). When you create your pptpd.conf file, you should use addresses from the range used by your internal network. In addition, this configuration file tells pptpd to set up the PPP interface using /etc/ppp/options.pptpd when it starts pppd. Otherwise it would use the default of /etc/ppp/options, which probably isn’t what you want.

Now you’ll need to create the aforementioned /etc/ppp/options.pptpd:

lock

name pptpd

auth

These options basically tell pppd to use authentication (auth), and indicate what entries in the /etc/ppp/chap-secrets file correspond to this instance of pppd (name pptpd). So, to finish configuring authentication for pptpd, you’ll need to create an entry for each client in the /etc/ppp/chap-secrets file.

Here’s a simple entry that allows someone with the username of andrew to connect with the password mypassword from any remote IP address:

# Secrets for authentication using CHAP

# client server secret IP addresses

andrew pptpd mypassword *

The pptpd in the server field should be replaced with whatever you used in the name directive in your /etc/ppp/options.pptpd file (if you didn’t use pptpd). You can of course limit the client to specific IP addresses by listing them.

Now that you have a basic setup for PoPToP , you can try it out by connecting to it with a Windows machine. Go to your Network Connections folder and click “Create a new connection” (this is for Windows XP; for Windows 2000, look for “Make New Connection”). After you click this, a wizard dialog should appear that looks similar to Figure 6-1.
Figure 6-1. Windows XP’s New Connection Wizard

Click Next and then select the “Connect to the network at my workplace” radio button, as shown in Figure 6-2.
Figure 6-2. Choosing the connection type

After you’ve done that, click Next again and then click the “Virtual Private Network connection” radio button. You should now see something similar to Figure 6-3.
Figure 6-3. Selecting a VPN connection

Click Next and fill in a name for the newly created connection (e.g., PoPToP Test). After you’ve done that, click Next once again and then enter the external IP address of the server running pptpd. Now click Next and then Finish. You’ll then be presented with a login dialog similar to the one shown in Figure 6-4.
Figure 6-4. The connection login dialog

Before entering the username and password that you specified in the /etc/ppp/chap-secrets file, you’ll need to click Properties and locate the Security tab. After you’ve done that, locate the “Require data encryption” checkbox and uncheck it. You should now see something similar to Figure 6-5.
Figure 6-5. Changing the security properties

Now click OK, enter your login information, and then click Connect. In a few seconds you should be connected to the PPTP server and will be allocated an IP address from the pool that you specified. You should now test the connection by pinging the remote end of the tunnel. With the PPTP connection active, all traffic leaving the client side will be encrypted and sent to the PoPToP server. From there, traffic will make its way to its ultimate destination.

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Set up IPSEC under freebsd

Udgivet den juli 10, 2004 af mike

Use FreeBSD’s built-in IPsec support to secure your traffic.

Using IPsec with IKE under FreeBSD requires enabling IPsec in the kernel and installing a user-land program, racoon, to handle the IKE negotiations.

You’ll need to make sure that your kernel has been compiled with the following options:

options IPSEC #IP security

options IPSEC_ESP #IP security (crypto; define w/ IPSEC)

options IPSEC_DEBUG #debug for IP security

If it hasn’t, you’ll need to define them and then rebuild and install the kernel. After you’ve done that, reboot to verify that it works.

racoon can be installed using the network section of the ports tree, or it can be downloaded from ftp://ftp.kame.net/pub/kame/misc/. Install raccoon per the instructions provided with the distribution.

On the client, you should first configure racoon. You will need to modify this example racoon.conf to suit your needs:

path include “/usr/local/etc/racoon” ;

path pre_shared_key “/usr/local/etc/racoon/psk.txt” ;

remote anonymous

{

exchange_mode aggressive,main;

my_identifier user_fqdn “user1@domain.com”;

lifetime time 1 hour;

initial_contact on;

proposal {

encryption_algorithm 3des;

hash_algorithm sha1;

authentication_method pre_shared_key ;

dh_group 2 ;

}

}

sainfo anonymous

{

pfs_group 1;

lifetime time 30 min;

encryption_algorithm 3des ;

authentication_algorithm hmac_sha1;

compression_algorithm deflate ;

}

In your firewall configuration, be sure you allow IKE connections to your machine (UDP port 500). racoon needs to be configured to start at boot time. Save the following script in /usr/local/etc/rc.d/racoon.sh:

#!/bin/sh

# This script will start racoon in FreeBSD

case “$1” in

start)

# start racoon

echo -n ‘starting racoon’

/usr/local/sbin/racoon

;;

stop)

# Delete the MAC address from the ARP table

echo ‘stopping racoon’

killall racoon

;;

*)

# Standard usage statement

echo “Usage: `basename $0` {start|stop}” >&2

;;

esac

exit 0

Make sure the file is executable by performing this command:

# chmod 755 /usr/local/etc/rc.d/racoon.sh

The /usr/local/etc/racoon/psk.txt file contains your credentials. This file must be readable only by root. If the permissions are not set correctly, racoon will not function. For a shared-secret IPsec connection, the file contains your identification (in this case your email address) and the secret. For instance, you can set up a psk.txt as the following:

user1@domain.com supersecret

Finally, you must set up the security policy, using the setkey utility to add entries to the kernel SPD. Create the following client.spd that can be loaded by setkey. For this setup, the station IP is 192.168.0.104 and the gateway is 192.168.0.1:

# spdadd 192.168.0.104/32 0.0.0.0/0 any -P out ipsec \

esp/tunnel/192.168.0.104-192.168.0.1/require ;

# spdadd 0.0.0.0/0 192.168.0.104/32 any -P in ipsec \

esp/tunnel/192.168.0.1-192.168.0.104/require ;

The first entry creates a security policy that sends all traffic to the VPN endpoint. The second entry creates a security policy that allows all traffic back from the VPN endpoint. Note that in this configuration the client is unable to talk to any hosts on the local subnet, except for the VPN gateway. In a wireless network where the client is a prime target for attack, this is probably a good thing for your workstation.

Load the SPD by running:

# setkey -f client.spd

The gateway racoon.conf is the same as the file for the client side. This allows any client to connect. The psk.txt file must contain all the identification and shared secrets of all clients who may connect. For instance:

user1@domain.com supersecret

user2@domain.com evenmoresecret

user3@domain.com notsosecret

Again, make sure psk.txt is readable only by root. Start racoon and make sure there are no errors. Finally, set up a gateway.spd that creates an SPD for each client. The following example assumes your clients are at 192.168.0.10[4-6]:

# spdadd 0.0.0.0/0 192.168.0.104/32 any -P out ipsec \

esp/tunnel/192.168.0.1-192.168.0.104/require ;

# spdadd 192.168.0.104/32 0.0.0.0/0 any -P in ipsec \

esp/tunnel/192.168.0.104-192.168.0.1/require ;

# spdadd 0.0.0.0/0 192.168.0.105/32 any -P in ipsec \

esp/tunnel/192.168.0.1-192.168.0.105/require ;

# spdadd 192.168.0.105/32 0.0.0.0/0 any -P out \

ipsec esp/tunnel/192.168.0.105-192.168.0.1/require ;

# spdadd 0.0.0.0/0 192.168.0.106/32 any -P in ipsec \

esp/tunnel/192.168.0.1-192.168.0.106/require ;

# spdadd 192.168.0.106/32 0.0.0.0/0 any -P out ipsec \

esp/tunnel/192.168.0.106-192.168.0.1/require ;

Load the SPD by issuing setkey -f gateway.spd. Verify the SPD entries using the spddump command in setkey. At this point, you should be able to ping a client from the gateway. It may take a packet or two for the VPN negotiation to complete, but the connection should be solid after that. If you are unable to ping, examine your syslog output for errors and warnings.

Udgivet i FreeBSD, Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Set up IPSEC under linux

Udgivet den juli 10, 2004 af mike

Secure your traffic in Linux with FreeS/WAN.

The most popular way of configuring IPsec connections under Linux is to use the FreeS/WAN (http://www.freeswan.org) package. FreeS/WAN is made up of two components, KerneL IP Security (KLIPS) and pluto. KLIPS is the kernel-level code that actually encrypts and decrypts the data; it also manages the Security Policy Database (SPD). pluto is a user-land daemon that controls IKE negotiation.

The FreeS/WAN build process builds a new kernel and the required management utilities. Download the latest FreeS/WAN source from the project’s web site and unpack the source tree in /usr/src. The documentation that comes with FreeS/WAN is very extensive and can help you tailor the installation to suit your needs. The kernel component can be either installed as a kernel-loadable module or statically compiled directly into your kernel. In order to compile FreeS/WAN, the kernel source must be installed on your machine. During the compilation process, the kernel configuration utility will launch. This is normal. Compile FreeS/WAN using your kernel configuration method of choice (such the menu-based or X11-based options). Once the compilation is complete, install the kernel and user-land tools per the FreeS/WAN documentation (typically a make install will suffice).

FreeS/WAN configuration is controlled by two configuration files: /etc/ipsec.conf and /etc/ipsec.secrets. The examples given in this hack are very limited in scope and apply only to a wireless network. The manpages for both files are quite informative and useful for more complicated connection requirements. Another excellent resource for more information is the book Building Linux Virtual Private Networks (VPNs), by Oleg Kolesnikov and Brian Hatch (New Riders).

The ipsec.conf file breaks a VPN connection into right- and lefthand segments. This difference is merely a logical division. The lefthand side can be either the internal or external network; this allows the same configuration file to be used for both ends of a VPN network-to-network tunnel. Unfortunately, in our case, there will be differences between the client and gateway configurations.

The file is broken up into a configuration section (config) and a connection section (conn). The config section specifies basic parameters for Ipsec, such as available interfaces and specific directives to be passed to pluto. The conn section describes the various connections that are available to the VPN. There is a global conn section (conn %default) where you can specify values that are common to all connections, such as the lifetime of a key and the method of key exchange.

The following ipsec.conf encrypts all information to the Internet with a VPN endpoint on your gateway:

# /etc/ipsec.conf

# Set configuration options

config setup

interfaces=%defaultroute

# Debug parameters. Set either to “all” for more info

klipsdebug=none

plutodebug=none

# standard Pluto configuration

plutoload=%search

plutostart=%search

# make sure there are no PMTU Discovery problems

overridemtu=1443

# default configuration settings

conn %default

# Be aggressive in rekeying attempts

keyingtries=0

# use IKE

keyexchange=ike

keylife=12h

# use shared secrets

authby=secret

# setup the VPN to the Internet

conn wireless_connection1

type=tunnel

# left is the client side

left=192.168.0.104

# right is the internet gateway

right=192.168.0.1

rightsubnet=0.0.0.0/0

# automatically start the connection

auto=start

Now add the shared secret to ipsec.secrets:

192.168.0.104 192.168.0.1: PSK “supersecret”

That’s it. Once your gateway is configured, try to ping your default gateway. pluto will launch automatically and the connection should come up. If you have a problem reaching the gateway, check the syslog messages on both the client and gateway.

The gateway configuration is largely the same as the client configuration. Given the intelligence of the ipsec.conf file, very few changes need to be made. Since your gateway has more than one Ethernet interface, you should hard-set the IPsec configuration to use the right interface:

# assume internal ethernet interface is eth0

interfaces=”ipsec0=eth0″

You will then need to add a connection for each internal client. This can be handled in different ways as your network scales, but the following configuration should work for a reasonable number of clients:

…

conn wireless_connection2

type=tunnel

left=192.168.0.105

right=192.168.0.1

rightsubnet=0.0.0.0/0

auto=start

conn wireless_connection3

type=tunnel

left=192.168.0.106

right=192.168.0.1

rightsubnet=0.0.0.0/0

auto=start

…

Finally, add the shared secrets for all the clients to ipsec.secrets:

192.168.0.105 192.168.0.1: PSK “evenmoresecret”

192.168.0.106 192.168.0.1: PSK “notsosecret”

Clients should now be connecting to the Internet via a VPN tunnel to the gateway. Check the log files or turn up the debug level if the tunnel does not come up.

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Sniff the ether remotely

Udgivet den juli 10, 2004 af mike

Monitor your networks remotely with rpcapd.

If you’ve ever wanted to monitor network traffic from another segment and use a graphical protocol analyzer like Ethereal (http://www.ethereal.com), you know how time-consuming it can be. First you have to capture the data. Then you have to get it onto the workstation that you’re running the analyzer from, and then you have to load the file into the analyzer itself. This creates a real problem because it increases the time between performing an experiment and seeing the results, which makes diagnosing and fixing network problems take much longer than they should.

One tool that solves this problem is rpcapd, a program included with WinPcap (http://winpcap.polito.it). rpcapd is a daemon that monitors network interfaces in promiscuous mode and sends the data that it collects back to a sniffer running on a remote machine. You can run rpcapd either from the command line or as a service. To start rpcapd, you will probably want to use the -n flag, which tells the daemon to use null authentication. Using this option, you will be able to monitor the data stream that rpcapd produces with any program that uses the WinPcap capture interface. Otherwise, special code will have to be added to the program that you are using that will allow it to authenticate itself with rpcapd. Since the -n option allows anyone to connect to the daemon, you’ll also want to use the -l option, which allows you to specify a comma-separated list of hosts that can connect.

So, to run rpcapd from the command line, use a command similar to this:

C:\Program Files\WinPcap>rpcapd -l obsidian -n

Press CTRL + C to stop the server…

When run as a service, rpcapd uses the rpcapd.ini file for its configuration information. This file resides in the same directory as the executable and is easily created by running rpcapd with the -s switch, which instructs rpcapd to save its configuration to the file you specify.

To create a pcap.ini, run a command like this:

C:\Program Files\WinPcap>rpcapd -l obsidian -n -s rpcapd.ini

Press CTRL + C to stop the server…

Now press Ctrl-C and see what the file contains:

C:\Program Files\WinPcap>type rpcapd.ini

# Configuration file help.

# Hosts which are allowed to connect to this server (passive mode)

# Format: PassiveClient = <name or address>

PassiveClient = obsidian

# Hosts to which this server is trying to connect to (active mode)

# Format: ActiveClient = <name or address>, <port | DEFAULT>

# Permit NULL authentication: YES or NOT

NullAuthPermit = YES

To start the service, you can either use the Services control panel applet or use the net command from the command line:

C:\Program Files\WinPcap>net start rpcapd

The Remote Packet Capture Protocol v.0 (experimental) service was started

successfully.

Now, to connect to the daemon you will need to find out the name that WinPcap uses to refer to the network device you want to monitor. To do this, you can use either WinDump, a command-line packet sniffer for Windows, or Ethereal. WinDump is available from the same web site as WinPcap.

To get the device name with WinDump simply run it with the -D flag:

C:\Program Files\WinPcap>windump -D

1.\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F} (NDIS 5.0 driver)

You can use Ethereal to obtain the device name by starting up Ethereal, going to the Capture menu, and clicking Start. After you do that, a dialog will open that has a list of the available adapters on the system, much like the one seen in Figure 5-4. The device names in the list are those that you will later specify when connecting to rpcapd from a remote system.
Figure 5-4. Ethereal Capture Options dialog

When you connect to a remote machine with your favorite sniffer, simply put the device name for the interface you want to monitor prefixed by rpcap and the hostname, like this:

rpcap://plunder/\Device\NPF_{EE07A5AE-4D19-4118-97CE-3BF656CD718F}

You can see an example of this with Ethereal in Figure 5-5.
Figure 5-5. Using a remote capture source with Ethereal

If you’ve set up everything correctly, you should see traffic streaming from the remote end into your sniffer just as if it were being captured from a local interface.

Udgivet i Knowledge Base, Networking, Old Base | Skriv en kommentar

Collect statics via IPTABLES

Udgivet den juli 10, 2004 af mike

Make your firewall ruleset do the work for you when you want to collect statistics.

If you want to start collecting statistics on your network traffic but dread setting up SNMP, you don’t have to worry. You can use the firewalling code in your operating system to collect statistics for you.

For instance, if you were using Linux, you could use iptables commands similar to the following to keep track of bandwidth consumed by a particular machine that passes traffic through your firewall:

# iptables -N KRYTEN && iptables -A KRYTEN -j ACCEPT

# iptables -N KRYTEN_IN && iptables -A KRYTEN_IN -j KRYTEN

# iptables -N KRYTEN_OUT && iptables -A KRYTEN_OUT -j KRYTEN

# iptables -A FORWARD -s 192.168.0.60 -j KRYTEN_OUT

# iptables -A FORWARD -d 192.168.0.60 -j KRYTEN_IN

This leverages the packet and byte counters associated with each iptables rule to provide input and output bandwidth statistics for traffic forwarded through the firewall. It works by first defining a chain named KRYTEN, which is named after the host that the statistics will be collected on. This chain contains an unconditional accept rule and will be used to quickly add up the total bandwidth that kryten consumes. To itemize the downstream bandwidth kryten is using, another chain is created called KRYTEN_IN. This chain contains only one rule, which is to unconditionally jump to the KRYTEN chain in order for the inbound bandwidth to be added with the outbound bandwidth being consumed. Similarly, the KRYTEN_OUT chain tallies outbound bandwidth being consumed and then jumps to the KRYTEN chain so that the outbound bandwidth will be added to the inbound bandwidth being consumed. Finally, rules are added to the FORWARD chain that direct the packet to the correct chain, depending on whether it’s coming from or going to kryten.

After applying these rules, you can then view the total bandwidth (inbound and outbound) consumed by kryten by running a command like this:

# iptables -vx -L KRYTEN

Chain kryten (2 references)

pkts bytes target prot opt in out source destination

442 46340 ACCEPT all — any any anywhere anywhere

You can easily parse out the bytes field, and thereby generate graphs with RRDtool [Hack #62], by using a command like this:

# iptables -vx -L KRYTEN | egrep -v ‘Chain|pkts’ | awk ‘{print $2}’

To get the inbound or outbound bandwidth consumed, just replace KRYTEN with KRYTEN_IN or KRYTEN_OUT, respectively. Of course, you don’t have to limit your statistic collection criteria to just per-computer bandwidth usage. You can collect statistics on anything that you can create an iptables rule for, including ports, MAC addresses, or just about anything else that passes through your network.

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar