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

Argus monitor and keep trail of trafic

Udgivet den juli 10, 2004 af mike

Use Argus to monitor your network and to keep an audit trail of your traffic.

Wouldn’t it be nice if you could keep a complete record of everything that happened on your network? It would certainly help to track down problems and would be invaluable in the event of a security incident, but it would just take up too much space to keep all of that data around. The next best thing would be to keep a log of all the packets, but not actually keep the data. You can do this with Argus (http://www.qosient.com/argus/).

Argus, or the Audit Record Generation and Utilization System, is a tool that can log network transactions in a variety of ways and can even collect performance metrics on every connection that it is able to see. Argus also contains several utilities that can make queries against the logs, so you can easily extract the information you need. These tools allow you to generate ASCII-, RMON-, or XML-formatted information from an Argus log file. Argus also provides a Perl interface for accessing its log files, so you can easily write custom scripts to make use of the data it collects.

To set up Argus, you’ll first need to download the source distribution and unpack it. Then change into the directory that it creates:

$ tar xfz argus-2.0.5.tar.gz

$ cd argus-2.0.5

To compile Argus, run this command:

$ ./configure && make

After compilation has finished, you can install Argus by becoming root and running this command:

# make install

To get a quick demo of Argus, run it and then let it collect some data for a little while:

# argus -d -e `hostname` -w /tmp/arguslog

This command will start argus in daemon mode and have it write its logs to /tmp/argus.

After letting it collect some data, try querying it with the ra command. This will show you an ASCII representation of the packets that argus has logged:

$ ra -r /tmp/arguslog

12 Jan 04 05:42:48 udp plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT

12 Jan 04 05:43:09 udp 192.168.0.250.snmptrap -> 255.255.255.255.snmptrap INT

12 Jan 04 05:43:15 udp print.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm INT

12 Jan 04 05:43:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:43:28 nvl 0:c0:2:57:98:79 -> Broadcast INT

12 Jan 04 05:43:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:43:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:44:19 udp kryten.nnc.56581 -> 255.255.255.255.2222 TIM

12 Jan 04 05:43:34 udp sunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT

12 Jan 04 05:44:08 arp plunder.nnc who-has sirius.nnc INT

12 Jan 04 05:44:08 udp plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT

12 Jan 04 05:44:15 udp print.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm INT

12 Jan 04 05:45:06 udp sunder.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm TIM

12 Jan 04 05:40:26 man pkts 734 bytes 75574 drops 0 CON

12 Jan 04 05:44:28 nvl 0:c0:2:57:98:79 -> Broadcast INT

12 Jan 04 05:44:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:44:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:44:28 llc 0:c0:2:57:98:79.null -> Broadcast.null INT

12 Jan 04 05:45:08 udp plunder.nnc.netbios-ns -> 192.168.0.255.netbios-ns INT

12 Jan 04 05:45:09 tcp kryten.nnc.54176 ?> colossus.nnc.ssh EST

12 Jan 04 05:45:15 udp print.nnc.netbios-dgm -> 192.168.0.255.netbios-dgm INT

This is just a few minutes of logs from one host, but it is stored in a very compact manner. In fact, during testing, a whole day’s worth of logs consumed only 1.4 MB!

The ra command can also take tcpdump-style filters so that you can query the logs for packets that match a specific host, protocol, port, or any number of other characteristics.

For instance, if you wanted to query the logs for all packets sent either to or from the host named kryten, you could used a command similar to this one:

$ ra -r /tmp/argus – “host kryten”

12 Jan 04 09:26:34 udp kryten.nnc.55689 -> 255.255.255.255.2222 TIM

12 Jan 04 09:26:36 tcp kryten.nnc.54176 ?> linux-vmm.nnc.ssh EST

12 Jan 04 09:27:37 tcp kryten.nnc.54176 ?> linux-vmm.nnc.ssh EST

12 Jan 04 09:28:34 udp kryten.nnc.55691 -> 255.255.255.255.2222 TIM

12 Jan 04 09:28:05 icmp kryten.nnc <-> linux-vmm.nnc ECO

12 Jan 04 09:28:06 icmp kryten.nnc <-> linux-vmm.nnc ECO

12 Jan 04 09:29:06 tcp kryten.nnc.54176 ?> linux-vmm.nnc.ssh EST

12 Jan 04 09:30:34 udp kryten.nnc.55692 -> 255.255.255.255.2222 TIM

12 Jan 04 09:32:34 udp kryten.nnc.55693 -> 255.255.255.255.2222 TIM

12 Jan 04 09:33:06 tcp kryten.nnc.54176 ?> linux-vmm.nnc.ssh EST

12 Jan 04 09:34:34 udp kryten.nnc.55694 -> 255.255.255.255.2222

12 Jan 04 09:53:44 tcp kryten.nnc.54176 ?> linux-vmm.nnc.ssh EST

You can also generate a new Argus log file containing only the results of your query by using the -w option to ra and specifying a file to write the results to.

To get XML output from Argus, you can use the raxml utility to make queries, much in the same way as you can with ra. For instance, here’s the first record returned by using the previous query for all packets that matched the hostname of kryten:

$ raxml -r /tmp/arguslog – “host kryten”

<ArgusFlowRecord ArgusSourceId = “192.168.0.41” SequenceNumber = “3”

Cause = “Status” StartDate = “2004-01-12” StartTime = “09:25:26”

StartTimeusecs = “319091” LastDate = “2004-01-12”

LastTime = “09:25:32” LastTimeusecs = “521982”

Duration = “6.202891” TransRefNum = “0”>

<MACAddrs SrcAddr = “0:a:95:c7:2b:10” DstAddr = “0:c:29:e2:2b:c1” />

<Flow> <IP SrcIPAddr = “192.168.0.60” DstIPAddr = “192.168.0.41”

Proto = “tcp” Sport = “56060” Dport = “22” IpId = “27b8” /> </Flow>

<FlowAttrs SrcTTL = “64” DstTTL = “64” SrcTOS = “10” DstTOS = “10” />

<ExtFlow> <TCPExtFlow TCPState = “EST” TCPOptions = “TIME”

SynAckuSecs = “0” AckDatauSecs = “0” >

<TCPExtMetrics SrcTCPSeqBase = “4204580547”

SrcTCPAckBytes = “527” SrcTCPBytes = “528”

SrcTCPRetrans = “0” SrcTCPWin = “65535” SrcTCPFlags = “PA”

DstTCPSeqBase = “3077608383” DstTCPAckBytes = “1135”

DstTCPBytes = “992” DstTCPRetrans = “0” DstTCPWin = “9792”

DstTCPFlags = “PA” />

</TCPExtFlow>

</ExtFlow>

<Metrics SrcCount = “24” DstCount = “17” SrcBytes = “2112”

DstBytes = “2258” SrcAppBytes = “528” DstAppBytes = “1136” />

</ArgusFlowRecord>

As you can see, Argus keeps track of much more information than it would seem if you were just going by the output generated by ra. This is where Argus really shines, because it can store such a large amount of information about your network traffic in a small amount of space. In addition, Argus makes it easy to convert this information into other formats, such as XML, which makes it easy to write applications that can understand the data.

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

NTop web interface to show network usage

Udgivet den juli 10, 2004 af mike

See who’s doing what on your network over time with ntop.

If you’re looking for real-time network statistics, check out the terrific ntop tool (http://www.ntop.org). It is a full-featured protocol analyzer with a web frontend, complete with SSL and graphing support. Unfortunately, ntop isn’t exactly lightweight (the precise amount of resources required depend on the size of your network and the volume of network traffic), but it can give you a very nice picture of who’s talking to whom on your network.

ntop needs to run initially as root (to throw your interfaces into promiscuous mode and start capturing packets), but then releases its privileges to a user that you specify. If you decide to run ntop for long periods of time, you’ll probably be happiest running it on a dedicated monitoring box (with few other services running on it, for security and performance reasons).

Here’s a quick reference on how to get ntop up and running. First, create an ntop user and group:

# groupadd ntop

# useradd -c “ntop user” -d /usr/local/etc/ntop \

-s /bin/true -g ntop ntop

Then unpack and build ntop per the instructions in docs/BUILD-NTOP.txt. I assume that you have the source tree unpacked in /usr/local/src/ntop-2.1.3/.

Create a directory for ntop to keep its capture database in:

# mkdir /usr/local/etc/ntop

Note that it should be owned by root, and not by the ntop user.

If you’d like to use SSL for HTTPS (instead of standard HTTP), then copy the default SSL key to /usr/local/etc/ntop. Assuming that you have unpacked ntop into /usr/local/src/ntop-2.1.3/, you can do this by running this command:

# cp /usr/local/src/ntop-2.1.3/ntop/*pem /usr/local/etc/ntop

Note that the default SSL key will not be built with the correct hostname for your server. So, you’ll probably want to generate your own SSL certificate and key pair [Hack #45] . Now you’ll need to initialize the ntop databases and set an administrative password:

# ntop -A -u ntop -P /usr/local/etc/ntop

21/Sep/2002 20:30:23 Initializing GDBM…

21/Sep/2002 20:30:23 Started thread (1026) for network packet analyser.

21/Sep/2002 20:30:23 Started thread (2051) for idle hosts detection.

21/Sep/2002 20:30:23 Started thread (3076) for DNS address resolution.

21/Sep/2002 20:30:23 Started thread (4101) for address purge.

Please enter the password for the admin user:

Please enter the password again:

21/Sep/2002 20:30:29 Admin user password has been set.

Finally, run ntop as a daemon, and start the SSL server on your favorite port (4242, for example):

# ntop -u ntop -P /usr/local/etc/ntop -W4242 -d

By default, ntop also runs a standard HTTP server on port 3000. You should seriously consider locking down access to these ports, either at your firewall or by using command-line iptables rules [Hack #33] .

Let ntop run for a while, then connect to https://your.server.here:4242/. You can find out all sorts of details about what traffic has been seen on your network, as shown in Figure 5-3.
Figure 5-3. Displaying a host’s statistics in ntop’s web interface

While tools like tcpdump and Ethereal give you detailed, interactive analysis of network traffic, ntop delivers a wealth of statistical information in a very slick and easy-to-use web interface. When properly installed and locked down, it will likely become a favorite tool in your network analysis tool chest

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

graphs with rrd tool

Udgivet den juli 10, 2004 af mike

Use RRDtool to easily generate graphs for just about anything.

You may be familiar with graphing bandwidth usage with tools such as MRTG. From a security standpoint it’s useful to graph bandwidth usage, since it can help you spot anomalous behavior. Having a history of typical bandwidth usage gives you a baseline to judge what’s going on. This can make it easier to determine if somebody is performing a DoS attack on your site, or if a machine on your network is acting as a Warez depot.

RRDtool (http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/) provides similar functionality to MRTG, but it is much more flexible. RRDtool is basically a tool for storing data in a general-purpose database that will never grow in size. RRD stands for round-robin database , which is a special type of database that maintains a fixed number of entries—the oldest entry is constantly being replaced by the newest data. RRDtool also has the ability to generate graphs of the data contained in a round-robin database.

The most common use of RRDtool is to make pretty bandwidth graphs. This is easily done with RRDtool and snmpget, a utility that queries devices managed with SNMP. First, you’ll need to create a round-robin database by running a command similar to this one:

$ rrdtool create zul.rrd –start N \

DS:de0_in:COUNTER:600:U:U \

DS:de0_out:COUNTER:600:U:U \

RRA:AVERAGE:0.5:1:600 \

RRA:AVERAGE:0.5:6:700 \

RRA:AVERAGE:0.5:24:775 \

RRA:AVERAGE:0.5:288:797 \

RRA:MAX:0.5:1:600 \

RRA:MAX:0.5:6:700 \

RRA:MAX:0.5:24:775 \

RRA:MAX:0.5:288:797

This command creates a database containing entries for two separate counters, de0_in and de0_out. These will store samples of interface statistics collected every five minutes from an SNMP daemon on a router. In addition, it contains several fields for automatically maintaining running averages.

You can populate the database by running a command like this:

$ rrdtool update zul.rrd N:\

`snmpget -Oqv zul public interfaces.ifTable.ifEntry.ifInOctets.4`:\

`snmpget -Oqv zul public interfaces.ifTable.ifEntry.ifOutOctets.4`

This command queries the input and output statistics for the de0 interface on a computer named zul. To schedule it to run every five minutes, you could make a crontab entry similar to the following:

0-55/5 * * * * rrdtool update /home/andrew/rrdbs/zul.rrd N:`snmpget -Oqv zul public

interfaces.ifTable.ifEntry.ifInOctets.4`:`snmpget -Oqv zul public

interfaces.ifTable.ifEntry.ifOutOctets.4`

However, you can use whatever methods you want to collect the data. To generate hourly graphs of the data, you could run a command like this:

rrdtool graph zul_de0-hourly.png -t “Hourly Bandwidth” –start -3600 \

DEF:inoctets=zul.rrd:de0_in:AVERAGE \

DEF:outoctets=zul.rrd:de0_out:AVERAGE \

AREA:inoctets#00FF00:”de0 In” \

LINE1:outoctets#0000FF:”de0 Out”

This would create an image like the one shown in Figure 5-1.
Figure 5-1. A graph generated by RRDtool

The -3600 in the command tells rrdtool that you want to graph the data collected over the last hour (there are 3,600 seconds in an hour). Likewise, if you wanted to create a graph over the course of a day, you would use -86400.

But that’s just the beginning. After collecting multiple data sources, you can combine them all into a single graph that gives you a great deal of information at a glance. Figure 5-2 shows the relative outbound usage of several servers simultaneously, with the total average for all servers just below it. While this figure is in grayscale, the actual graph uses a different color for each server, making it easy to tell at a glance which one is hogging all of the bandwidth.
Figure 5-2. Multiple servers on a single graph

As you can see, RRDtool is a very flexible tool. All you need to do is tell it how much data you want to store and then set up some method to collect the data at a regular interval. Then you can easily generate a graph of the data whenever you want it.

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