PiCSPARK: Security

There Are Some Network Security Tips May Help you To Protect Yourself On Internet.

Detect ARP Spoofing

Find out if there's a "man in the middle" impersonating your server.
One of the biggest threats to a computer network is a rogue system pretending to be a trusted host. Once someone has successfully impersonated another host, they can do a number of nefarious things. For example, they can intercept and log traffic destined for the real host, or lay in wait for clients to connect and begin sending the rogue host confidential information. Spoofing a host has especially severe consequences in IP networks, as this opens many other avenues of attack. One technique for spoofing a host on an IP network is Address Resolution Protocol (ARP) spoofing. ARP spoofing is limited only to local segments and works by exploiting the way IP addresses are translated to hardware Ethernet addresses.
When an IP datagram is sent from one host to another on the same physical segment, the IP address of the destination host must be translated into a MAC address. This is the hardware address of the Ethernet card that is physically connected to the network. To accomplish this, the Address Resolution Protocol is used.
When a host needs to know another host's Ethernet address, it sends out a broadcast frame that looks like this:
```
01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62
```
This is called an ARP request. Since this is sent to the broadcast address, all Ethernet devices on the local segment should see the request. The machine that matches the requests responds by sending an ARP reply:
```
01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1
```
Since the ARP request already contained the MAC address of the sender in the Ethernet frame, the receiver can send this response without making yet another ARP request. Unfortunately, ARP's biggest weakness is that it is a stateless protocol . This means that it does not track responses to the requests that are sent out, and therefore will accept responses without having sent a request. If someone wanted to receive traffic destined for another host, they could send forged ARP responses matching any chosen IP address to their MAC address. The machines that receive these spoofed ARP responses can't distinguish them from legitimate ARP responses, and will begin sending packets to the attacker's MAC address.
Another side effect of ARP being stateless is that a system's ARP tables usually only use the results of the last response. In order for someone to continue to spoof an IP address, it is necessary to flood the host with ARP responses that overwrite legitimate ARP responses from the original host. This particular kind of attack is commonly known as ARP cache poisoning .
Several tools—such as Ettercap (http://ettercap.sourceforge.net), Dsniff (http://www.monkey.org/~dugsong/dsniff/), and Hunt (http://lin.fsid.cvut.cz/~kra/)—employ techniques like this to both sniff on switched networks and perform man-in-the-middle attacks. This technique can of course be used between any two hosts on a switched segment, including the local default gateway. To intercept traffic bidirectionally between hosts A and B, the attacking host C will poison host A's ARP cache, making it think that host B's IP address matches host C's MAC address. C will then poison B's cache, to make it think A's IP address corresponds to C's MAC address.
Luckily, there are methods to detect just this kind of behavior, whether you're using a shared or switched Ethernet segment. One program that can help accomplish this is Arpwatch (ftp://ftp.ee.lbl.gov/arpwatch.tar.gz). It works by monitoring an interface in promiscuous mode and recording MAC/IP address pairings over a period of time. When it sees anomalous behavior, such as a change to one of the MAC/IP pairs that it has learned, it will send an alert to the syslog. This can be very effective in a shared network using a hub, since a single machine can monitor all ARP traffic. However, due to the unicast nature of ARP responses, this program will not work as well on a switched network.
To achieve the same level of detection coverage in a switched environment, Arpwatch should be installed on as many machines as possible. After all, you can't know with 100% certainty what hosts an attacker will decide to target. If you're lucky enough to own one, many high-end switches allow you to designate a monitor port that can see the traffic of all other ports. If you have such a switch, you can install a server on that port for network monitoring, and simply run Arpwatch on it.
After downloading Arpwatch, you can compile and install it in the usual manner by running:
```
# ./configure && make && make install
```
When running Arpwatch on a machine with multiple interfaces, you'll probably want to specify the interface on the command line. This can be done by using the -i command-line option:
```
arpwatch -i iface
```
As Arpwatch begins to learn the MAC/IP pairings on your network, you'll see log entries similar to this:
```
Nov  1 00:39:08 zul arpwatch: new station 192.168.0.65 0:50:ba:85:85:ca
```
When a MAC/IP address pair changes, you should see something like this:
```
Nov  1 01:03:23 zul arpwatch: changed ethernet address 192.168.0.65 0:e0:81:3:d8:8e 

(0:50:ba:85:85:ca)

Nov  1 01:03:23 zul arpwatch: flip flop 192.168.0.65 0:50:ba:85:85:ca (0:e0:81:3:d8:8e)

Nov  1 01:03:25 zul arpwatch: flip flop 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca)
```
In this case, the initial entry is from the first fraudulent ARP response that was received, and the subsequent two are from a race condition between the fraudulent and authentic responses.
To make it easier to deal with multiple Arpwatch installs on a switched environment, you can send the log messages to a central syslogd , aggregating all the output into one place. However, due to the fact that your machines can be manipulated by the same attacks that Arpwatch is looking for, it would be wise to use static ARP table entries on your syslog server, as well as all the hosts running Arpwatch.
- Create a Static ARP Table
  
  Use static ARP table entries to combat spoofing and other nefarious activities.
  As discussed in , a lot of bad things can happen if someone successfully poisons the ARP table of a machine on your network. The previous hack discussed how to monitor for this behavior, but how do we prevent the effects of someone attempting to poison an ARP table?
  One way to prevent the ill effects of this behavior is to create static ARP table entries for all of the devices on your local network segment. When this is done, the kernel will ignore all ARP responses for the specific IP address used in the entry and use the specified MAC address instead.
  To do this, you can use the arp command, which allows you to directly manipulate the kernel's ARP table entries. To add a single static ARP table entry, run this:
```
arp -s ipaddr macaddr
```
  If you know that the MAC address that corresponds to 192.168.0.65 is 00:50:BA:85:85:CA, you could add a static ARP entry for it like this:
```
# arp -s 192.168.0.65 00:50:ba:85:85:ca
```
  For more than a few entries, this can be a time-consuming process. To be fully effective, you must add an entry for each device on your network on every host that allows you to create static ARP table entries.
  Luckily, most versions of the arp command can take a file as input and use it to create static ARP table entries. Under Linux, this is done with the -f command-line switch. Now all you need to do is generate a file containing the MAC and IP address pairings, which you can then copy to all the hosts on your network.
  To make this easier, you can use this quick-n-dirty Perl script:
```
#!/usr/bin/perl

#

# gen_ethers.pl <from ip> <to ip>

#



my ($start_1, $start_2, $start_3, $start_4) = split(/\./, $ARGV[0], 4);

my ($end_1, $end_2, $end_3, $end_4) = split(/\./, $ARGV[1], 4); 

my $ARP_CMD="/sbin/arp -n";



for(my $oct_1 = $start_1; $oct_1 <= $end_1 && $oct_1 <= 255; $oct_1++ ){

  for(my $oct_2 = $start_2; $oct_2 <= $end_2 && $oct_2 <= 255; $oct_2++){

    for(my $oct_3 = $start_3; $oct_3 <= $end_3 && $oct_3 <= 255; $oct_3++){

      for(my $oct_4 = $start_4; $oct_4 <= $end_4 && $oct_4 < 255; $oct_4++){

    system("ping -c 1 -W 1 $oct_1.$oct_2.$oct_3.$oct_4 > /dev/null 2>&1");

          my $ether_addr = `$ARP_CMD $oct_1.$oct_2.$oct_3.$oct_4 | egrep 'HWaddress|

(incomplete)' | awk '{print \$3}'`;

    chomp($ether_addr);

    if(length($ether_addr) == 17){

      print("$ether_addr\t$oct_1.$oct_2.$oct_3.$oct_4\n");

    }

      }

    }

  }

}
```
  This script will take a range of IP addresses and attempt to ping each one once. In doing this, each active IP address will appear in the machine's ARP table. After an IP address is pinged, the script will then look for that IP address in the ARP table, and print out the MAC/IP address pair in a format suitable for putting into a file to load with the arp command. This script was written with Linux in mind but should work on other Unix-like operating systems as well.
  For example, if you wanted to generate a file for all the IP addresses from 192.168.1.1 to 192.168.1.255 and store the results in /etc/ethers, you would run the script like this:
```
# ./gen_ethers 192.168.1.1 192.168.1.255 > /etc/ethers
```
  When using arp with the -f switch, it will automatically use the /etc/ethers file to create the static entries. However, you can specify any file you prefer. For example, if you wanted to use /root/arp_entries instead, you would run this:
```
# arp -f /root/arp_entries
```
  This script isn't perfect, but it can save a lot of time when creating static ARP table entries for the hosts on your network. Once you've generated the file with the MAC/IP pairings, you can copy it to the other hosts and add an arp command to the system startup scripts, to automatically load them at boot time. The main downside to using this method is that all the devices on your network need to be powered on when the script runs; otherwise, they will be missing from the list. In addition, if the machines on your network change frequently, you'll have to regenerate and distribute the file often, which may be more trouble than it's worth. But for servers and devices that never change their IP or MAC address, this method can protect your machines from ARP poisoning attacks.
  - Fool Remote Operating System Detection Software
    
    Evade remote OS detection attempts by disguising your TCP/IP stack.
    Another method to thwart operating system detection attempts is to modify the behavior of your system's TCP/IP stack and make it emulate the behavior of another operating system. This may sound difficult, but can be done fairly easily in Linux by patching your kernel with code available from the IP Personality project (http://ippersonality.sourceforge.net). This code extends the kernel's built-in firewalling system, Netfilter, as well as its user-space component, the iptables command.
    To set up IP Personality, download the package that corresponds to your kernel. If you can't find the correct one, visit the SourceForge patches page for the project (http://sourceforge.net/tracker/?group_id=7557&atid=307557), which usually has more recent kernel patches available.
    To patch your kernel, unpack the IP Personality source distribution and go to the directory containing your kernel source; then run the patch command:
```
# cd /usr/src/linux

# patch -p1 < \ 

../ippersonality-20020819-2.4.19/patches/ippersonality-20020819-linux-2.4.19.diff
```
    If you are using a patch downloaded from the patches page, just substitute it in your patch command. To verify that the patch has been applied correctly, you can run this command:
```
# find ./ -name \*.rej
```
    If the patch was applied correctly, this command should not find any files.
    Now that the kernel is patched, you will need to configure the kernel for IP Personality support. As mentioned in, running make xconfig, make menuconfig, or even make config while you are in the kernel source's directory will allow you to configure your kernel. Regardless of the method you choose, the menu options will remain the same.
    First, be sure that "Prompt for development and/or incomplete code/drivers" is enabled under "Code maturity level options". Under Networking Options, find and enable the option for Netfilter Configuration.
    The list displayed by make xconfig is shown in Figure 3-7. Find the option labeled IP "Personality Support", and either select y to statically compile it into your kernel, or select m to create a dynamically loaded module.
    
    Figure 3-7. Enable IP Personality Support
    
    After you have configured in support for IP Personality, save your configuration. Now compile the kernel and modules, and install them by running commands similar to these:
```
# make dep && make clean

# make bzImage && make modules

# cp arch/i386/boot/bzImage /boot/vmlinuz

# make modules_install
```
    Now reboot with your new kernel. In addition to patching your kernel, you'll also need to patch the user-space portion of Netfilter, the iptables command. To do this, go to the Netfilter web site (http://www.netfilter.org) and download the version specified by the patch that came with your IP Personality package. For instance, the iptables patch included in ippersonality-20020819-2.4.19.tar.gz is for Netfilter Version 1.2.2.
    After downloading the proper version and unpacking it, you will need to patch it with the patch included in the IP Personality package. Then build and install it in the normal way:
```
# tar xfj iptables-1.2.2.tar.bz2

# cd iptables-1.2.2

# patch -p1 < \

../ippersonality-20020819-2.4.19/patches/ippersonality-20020427-iptables-\1.2.2.diff 

patching file pers/Makefile

patching file pers/example.conf

patching file pers/libipt_PERS.c

patching file pers/pers.h

patching file pers/pers.l

patching file pers/pers.y

patching file pers/pers_asm.c

patching file pers/perscc.c

# make KERNEL_DIR=/usr/src/linux && make install
```
    This will install the modified iptables command, its supporting libraries, and the manpage under the /usr/local hierarchy. If you would like to change the default installation directories, you can edit the Makefile and change the values of the BINDIR, LIBDIR, MANDIR, and INCDIR macros. Be sure to set KERNEL_DIR to the directory containing the kernel sources you built earlier.
    If you are using Red Hat Linux, you can replace the iptables command that is installed by changing the macros to these values:
```
LIBDIR:=/lib

BINDIR:=/sbin

MANDIR:=/usr/share/man

INCDIR:=/usr/include
```
    In addition to running make install, you may also want to create a directory for the operating system personality configuration files. These files are located in the samples/ directory within the IP Personality distribution. For example, you could create a directory called /etc/personalities and copy them there.
    Before setting up IP Personality, try running Nmap against the machine to see which operating system it detects:
```
# nmap -O colossus



Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-12 18:36 MST

Interesting ports on colossus (192.168.0.64):

(The 1651 ports scanned but not shown below are in state: closed)

PORT    STATE SERVICE

22/tcp  open  ssh

25/tcp  open  smtp

111/tcp open  rpcbind

139/tcp open  netbios-ssn

505/tcp open  mailbox-lm

631/tcp open  ipp

Device type: general purpose

Running: Linux 2.4.X|2.5.X

OS details: Linux Kernel 2.4.0 - 2.5.20

Uptime 3.095 days (since Tue Dec 9 16:19:55 2003)



Nmap run completed -- 1 IP address (1 host up) scanned in 7.375 seconds
```
    If your machine has an IP address of 192.168.0.64 and you want it to pretend that it's running Mac OS 9, you can run iptables commands like these:
```
# iptables -t mangle -A PREROUTING -d 192.168.0.64 -j PERS \

  --tweak dst --local --conf /etc/personalities/macos9.conf

# iptables -t mangle -A OUTPUT -s 192.168.0.64 -j PERS \

  --tweak src --local --conf /etc/personalities/macos9.conf
```
    Now run Nmap again:
```
# nmap -O colossus



Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-12 18:47 MST

Interesting ports on colossus (192.168.0.64):

(The 1651 ports scanned but not shown below are in state: closed)

PORT    STATE SERVICE

22/tcp  open  ssh

25/tcp  open  smtp

111/tcp open  rpcbind

139/tcp open  netbios-ssn

505/tcp open  mailbox-lm

631/tcp open  ipp

Device type: general purpose

Running: Apple Mac OS 9.X

OS details: Apple Mac OS 9 - 9.1

Uptime 3.095 days (since Tue Dec 9 16:19:55 2003)



Nmap run completed -- 1 IP address (1 host up) scanned in 5.274 seconds
```
    You can of course emulate other operating systems that aren't provided with the IP Personality package. All you need is a copy of Nmap's operating system fingerprints file, nmap-os-fingerprints, and then you can construct your own IP Personality configuration file for any operating system Nmap knows about.
    
    Some More Security tips Coming Soon............!!!!!!!!!!!

Pages

Security

Detect ARP Spoofing

Create a Static ARP Table

Fool Remote Operating System Detection Software

Figure 3-7. Enable IP Personality Support