blueblog - by Christian J. Dietrich - Securing Linux

Preventing ARP flux on Linux

nospam@example.com (Christian J. Dietrich) — Tue, 13 Mar 2012 09:05:11 +0100

ARP, the address resolution protocol, is used on an Ethernet network to map IP addresses to hardware (MAC) addresses. By default, a Linux box with several network interfaces will respond to ARP requests received on any interface for any of the IP addresses of its interfaces. Here is an example: Let's assume we have a box which is connected with two interfaces A (MAC 00:00:00:AA:AA:AA) and B (MAC 00:00:00:BB:BB:BB). Interface A is configured to the IP address 172.16.0.1 and B to 172.16.0.2. Thus, both interfaces point to the same segment.

We use arping to query for the hardware address of the IP address 172.16.0.1 and expect to get the MAC address 00:00:00:AA:AA:AA of interface A in return.



[root@nugger]# arping -I eth0 172.16.0.1

ARPING 172.16.0.1 from 172.16.0.99 eth0

Unicast reply from 172.16.0.1 [00:00:00:AA:AA:AA]  7.889ms

Unicast reply from 172.16.0.1 [00:00:00:BB:BB:BB]  8.014ms



[root@nugger]# arping -I eth0 172.16.0.2

ARPING 172.16.0.2 from 172.16.0.99 eth0

Unicast reply from 172.16.0.2 [00:00:00:AA:AA:AA]  6.612ms

Unicast reply from 172.16.0.2 [00:00:00:BB:BB:BB]  8.991ms

Instead, we get the MACs of A and B alternating. You can tune this behavior using arp_ignore and arp_announce sysctl properties:



arp_ignore - INTEGER

Define different modes for sending replies in response to

received ARP requests that resolve local target IP addresses:

0 - (default): reply for any local target IP address, configured

on any interface

1 - reply only if the target IP address is local address

configured on the incoming interface

2 - reply only if the target IP address is local address

configured on the incoming interface and both with the

sender's IP address are part from same subnet on this interface

3 - do not reply for local addresses configured with scope host,

only resolutions for global and link addresses are replied





arp_announce - INTEGER

Define different restriction levels for announcing the local

source IP address from IP packets in ARP requests sent on

interface:

0 - (default) Use any local address, configured on any interface

...

2 - Always use the best local address for this target.

In this mode we ignore the source address in the IP packet

and try to select local address that we prefer for talks with

the target host. Such local address is selected by looking

for primary IP addresses on all our subnets on the outgoing

interface that include the target IP address. If no suitable

local address is found we select the first local address

we have on the outgoing interface or on all other interfaces,

with the hope we will receive reply for our request and

even sometimes no matter the source IP address we announce.

Setting net.ipv4.conf.all.arp_ignore=1 and net.ipv4.conf.all.arp_announce=2 in /etc/sysctl.conf provides adequate settings. However, you should check whether these settings work in your network environment, especially if you depend on reaching an IP address from any other than the interface that it is configured on.



net.ipv4.conf.all.arp_ignore=1

net.ipv4.conf.all.arp_announce=2

Best practice: chrooted BIND on CentOS 5.6+ with DNSSEC aware resolution

nospam@example.com (Christian J. Dietrich) — Sat, 02 Jul 2011 21:50:00 +0200

BIND is the most prevalent DNS server software. Since CentOS 5.6, BIND is readily available in the more recent version 9.7.0 in the packages bind97*. Among others, a preconfigured chroot environment is provided. In order to use chrooted BIND, install the package bind97-chroot and make sure that ROOTDIR is correct in /etc/sysconfig/named:



[us@ns ~]# grep ROOTDIR /etc/sysconfig/named

ROOTDIR=/var/named/chroot

Note that a service named restart is required in case BIND was running beforehand.
In order to provide the chroot environment, certain files and directories are (re)mounted under /var/named/chroot



/etc/named on /var/named/chroot/etc/named type none (rw,bind)

/var/named on /var/named/chroot/var/named type none (rw,bind)

/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)

/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)

/etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind)

/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)

/usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind)

/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)

/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

Thus, for example /etc/named.conf is actually made available to the chrooted BIND and you as the admin just have to take care of one file. Previously, there used to be two named.confs, one inside the chroot environment and one outside. If you do not have a named.conf yet, I suggest you start using the named.conf template by Rob Thomas of Team Cymru.
Heading for DNSSEC validating resolution, the most important settings in named.conf are the following:



    // ****** DNSSEC relevant settings ****** //

    // Since 9.5 the default value is dnssec-enable yes;.

    // This statement may be used in a view or global options clause.

    dnssec-enable yes;

    // indicates that a resolver (a caching or caching-only name server)

    // will attempt to validate replies from DNSSEC enabled (signed) zones.

    // To perform this task the server also needs either a valid trusted-

    // keys clause (containing one or more trusted-anchors or a managed-keys

    // clause. Since 9.5 the default value is dnssec-validation yes;

    dnssec-validation yes;

    dnssec-lookaside auto;

    / Path to ISC DLV key /

    //bindkeys-file "/etc/named.iscdlv.key";

    / Path to root DNSSEC key /

    bindkeys-file "/etc/named.root.key";

As shown above, I changed the bindkeys-file statement to point to the root DNSSEC key instead of ISC's DLV root key. This is fine because by now there is a verifiable path to validate ISC's DLV root key (signed root, signed .ORG and signed isc.org and dlv.isc.org zones). Thus, ISC's DLV key does not need to be included any longer.

Please note that as of now (bind97-9.7.0-6.P2.el5_6.3), there is a bug in the init script of bind97 which has been acknowleged upstream. Basically, the root DNSSEC key is not mounted in the chroot environment. Until the bug will be fixed in the package, you should apply the fix (I also provided in the bug report):



# A possible fix is to include /etc/named.root.key in /etc/init.d/named, i.e.

# change the contents of the ROOTDIR_MOUNT variable in /etc/init.d/named from



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key'



# to



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key'

Finally you should test with a domain that has authoritative DNSSEC information. The answer must contain the AD flag.



[us@ns ~]# dig +dnssec @127.0.0.1 gov. ns

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-6.P2.el5_6.2 <<>> +dnssec @127.0.0.1 gov. ns

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14572

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;gov.                           IN      NS



;; ANSWER SECTION:

gov.                    172800  IN      NS      b.gov-servers.net.

gov.                    172800  IN      NS      a.gov-servers.net.

gov.                    172800  IN      RRSIG   NS 7 1 172800 20110609040023 

20110604040023 43879 gov. FnygljkPqlL9Q08CX5lixJ7O5bB6ysM...

Protecting from SSH Bruteforce Attacks

nospam@example.com (Christian J. Dietrich) — Tue, 01 Jun 2010 15:59:00 +0200

Even botnet operators know the fine advantages of Linux servers: Some (if not most) operate their main C&C servers as Linux hosts. When reading through server logs full of SSH authentication failures due to bruteforce scans, I sometimes wonder, do those C&C servers of the botmasters also get these annoying attempts? However...

I have used fail2ban in order to prevent from these attacks for years. fail2ban scans the log files in order to identify bruteforce scans and bans the source IP addresses using iptables. If you use CentOS, you can install fail2ban from the rpmforge repository like so:

yum --enablerepo rpmforge install fail2ban.noarch

After installation, configure fail2ban must be configured. Change the parameter ignoreip in the config file /etc/fail2ban/jail.conf to match the desired IP address ranges that shall never be blocked, e.g.:



ignoreip = 127.0.0.1 192.168.0.0/24 172.16.0.0/24 10.0.0.0/18

Furthermore, the section ssh-iptables must be enabled. NOTE: Change the email address! You probably want to change the sender email address, too.



[ssh-iptables]

enabled  = true

filter   = sshd

action   = iptables[name=SSH, port=ssh, protocol=tcp]

           sendmail-whois[name=SSH, dest=RECEIVER@DOMAIN, sender=fail2ban@HOSTNAME]

logpath  = /var/log/secure

maxretry = 5

If someone else than root shall get the mail, change the directive dest in /etc/fail2ban/action.d/mail.conf.

Finally, make sure that it is enabled in the correct runlevels:

chkconfig fail2ban on

service fail2ban start