Archive for the 'Network' Category

Strong ciphers on Foundry ServerIron

When setting up SSL offloading on a Foundry ServerIron 4G-SSL the default installation allows weak (eg. DES, 56bit) ciphers and SSLv2. This is not a recommended setup, especially if you have to comply to certain security certifications, like PCI. The Foundry documentation does not give a lot of information on the ciphers that are supported. Below the commands to disable SSLv2 and allow only strong ciphers on an ssl accelerated host.

To change the ssl profile of a virtual server, always follow the following steps:

  1. Remove the ssl profile from the virtual server
  2. Change the ssl profile settings
  3. Enable the ssl profile on the virtual server


server virtual vservername
no port ssl ssl-terminate sslprofilename

exit

ssl profile sslprofilename
disable-ssl-v2
no cipher-suite all-cipher-suites
cipher-suite rsa-with-3des-ede-cbc-sha
cipher-suite rsa-with-aes-128-sha
cipher-suite rsa-with-aes-256-sha
cipher-suite rsa-with-rc4-128-md5
cipher-suite rsa-with-rc4-128-sha

exit

server virtual vservername
port ssl ssl-terminate sslprofilename

Racktables add custom object-type

RackTables is a datacenter asset management system. By default is is configured with several object-types that are used in most datacenters, like network-switch, server, PDU, ups, etc. However, some obvious object types are missing. A firewall or loadbalancer are quite often used in datacenter environments. But RackTables is very flexible and extensible. You can easily add your own custom object type. To do this, follow the following steps.

  1. Go to Configuration, Dictionary
  2. Click RackObjectType
  3. Click the ‘Edit’ tab
  4. Add the Object-type you want and click the ‘+’

By default, you cannot attach an ip address to an object-type. This must be configured manually. To make the object IPv4 enabled, follow the following steps.

  1. Go to Configuration, User-interface
  2. Click the ‘change’ tab
  3. Add the object id to the textbox named ‘List source: IPv4-enabled objects’

The list of IPv4 enabled objects should be something like:

{$typeid_4} or {$typeid_7} or {$typeid_8} or {$typeid_12} or {$typeid_445} or {$typeid_447} or {$typeid_50019} or {$typeid_2} or {$typeid_50063}

Racktables Rancid integration

I use Racktables to keep track of the devices in our network. To backup the configuration of our network devices I use rancid. To prevent having to edit and update multiple configuration files and systems, I thought it would be a good idea to centralize this and use Racktables as a source for configuring other systems. Racktables is a very extensible system that allows you to add attributes to a category yourself. I’ve added a ‘Rancid’ attribute as a dictionary item containing ‘Yes’ and ‘No’. I’ve bound this attribute to the object categories (Networkswitch, firewall and router) I want to backup with Rancid. I’ve scheduled a cronjob that runs the attached script, creating the routers.db file that is used by rancid.

The script runs an sql query to include all devices that have the Rancid attribute set to ‘Yes’.

To use this script in your environment, you have to edit the sql query to use the id of your rancid attribute in the dictionary. In my case the rancid attribute has the id ’10003′ and the ‘Yes’ dictionary id is ’50030′. These values can be found by looking in the racktables database.

Download the racktables-rancid export script.
Download the wrapper script

Cisco ASA and tacacs enable fails

While migrating the authentication of our ASA firewalls to tacacs, we enabled ‘enable’ authentication to tacacs and tried to switch to enable mode on the console. This did not work, and caused the following message in the tacacs log file:

Wed Jan 13 17:07:42 2010 [25444]: enable query for 'username' 13 from 10.x.x.x rejected

To fix this problem the tacacs configuration for the user needs to include the enable password in the profile, as shown below:

user = username {
login = des "XXXXXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
}
enable = des "XXXXXXX"
}

We use the following configuration on the ASA to enable AAA to tacacs.

aaa-server tacacs protocol tacacs+
aaa-server tacacs (outside) host 1.1.1.1
key TACACSKEY
aaa-server tacacs (outside) host 2.2.2.2
key TACACSKEY
aaa authentication ssh console tacacs LOCAL
aaa authentication telnet console tacacs LOCAL
aaa authentication serial console tacacs LOCAL
aaa authentication enable console tacacs LOCAL
aaa authentication http console tacacs LOCAL
aaa authorization command tacacs LOCAL

Cisco switch and Tacacs

Tacacs is a great way to centralize user authentication, authorization and accounting. While tacacs originally is a Cisco thing, there is an open source server version available, tac_plus (http://www.gazi.edu.tr/tacacs/index.php?page=download). Installing the tacacs server is quite straight forward. Configuring the switch is not difficult either, as long as you think about possible failures. You don’t want to be locked out of your switches when your tacacs server is not available. I use the following configuration that uses two tacacs servers and asks for the enable password when neither of the tacacs servers is available. To enter ‘enable’ mode, the configured enable password suffices. Use the following Cisco configuration for a save AAA authentication.

NOTE: Always be careful when changing authentication and authorization configuration, as this might lock you out of the device. The savest way is to do this on the console of the machine.


aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default enable
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group tacacs+ if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
tacacs-server host 1.1.1.1 single-connection
tacacs-server host 2.2.2.2 single-connection
tacacs-server key TACACSKEY
tacacs-server directed-request

To restrict access to specific devices, you can configure an ACL in the tacacs configuration on the server (tac_plus.conf). See the example below.


user = username {
login = des "XXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
}
}
group = admin {
default service = permit
service = exec {
priv-lvl = 15
}
}
# acl's

acl = mgmt_devices {
permit = 12.12.12.12
permit = 13.13.13.13
}

SIP with Speedtouch ADSL modem

We have a small VOIP network with 10 phone, a dedicated DSL line from Orange/Online and an external Asterisk server in a datacenter. The DSL line is terminated on a Speedtouch modem. With the default settings of the modem we experienced two problems:

  • Incoming calls did not get through
  • The sound of outgoing calls disappeared while the call was not dropped

In the Asterisk logs we could see the following message:

[Dec 30 13:40:51] WARNING[1911] chan_sip.c: Maximum retries exceeded on transmis
sion 0016c7ea-28120012-73ca27ca-35d5391a@10.0.0.45 for seqno 102 (Critical Respo
nse) -- See doc/sip-retransmit.txt.
[Dec 30 13:40:51] WARNING[1911] chan_sip.c: Hanging up call 0016c7ea-28120012-73
ca27ca-35d5391a@10.0.0.45 - no reply to our critical packet (see doc/sip-retrans
mit.txt).

To fix this, you have to disable the SIP helper on the Speedtouch modem. Connect to the modem with telnet (default ip: 10.0.0.138, default user: Administrator, default password: ) and enter the following commands:

_{Administrator}=>connection
{Administrator}[connection]=>appconfig application=SIP SIP_ALG=disabled
{Administrator}[connection]=>exit

Export rancid config from racktables

I use racktables to keep track of our devices and ip space. To prevent duplicate work and differences in naming I wrote (as all sysadmins ;) ) a script to export a rancid config file from Racktables. To be able to enable or disable configuration backup via Rancid, I created a Dictionary ‘chapter’ called Rancid, with a Yes and No option. I added this Dictionary as an Attribute and mapped this to the Firewall, Router and Switch objects.

Now I can set the Rancid backup from the properties of the object. To create the Rancid config file I created the following script:


#!/usr/bin/perl

use DBI;

$db="racktables";
$host="localhost";
$user="XXXX";
$passwd="XXXX";
$connectinfo="dbi:mysql:$db;$host";
$filename="racktables-rancid-devices.txt";
$dbh = DBI->connect($connectinfo,$user,$passwd);

$query = "select inet_ntoa(IPBonds.ip), RackObject.name from RackObject JOIN AttributeValue JOIN IPBonds ON RackObject.id=AttributeValue.object_id AND AttributeValue.object_id=IPBonds.object_id WHERE AttributeValue.attr_id=10003 AND AttributeValue.uint_value=50030 group by RackObject.name";

open FILE, ">", "$filename" or die $!;

$sth=$dbh->prepare($query);
$sth->execute();
$sth->bind_columns(\$IP, \$Name);
while($sth->fetch()) {
print FILE "# $Name \n$IP:cisco:up\n";
}

$sth->finish();

$dbh->disconnect;

This script creates the rancid ‘router.db’ configuration format. I created a keypair and used ssh-agent to be able to run the following script to copy over the file to our rancid server.


#!/bin/sh
/home/rancid/export-rancid.pl
scp racktables-rancid-devices.txt rancidserver:.
ssh rancidserver 'cp router-manual.db router.db'
ssh rancidserver 'cat racktables-rancid-devices.txt >> router.db'
ssh rancidserver 'mv router.db /usr/local/rancid/var/networking/router.db'

OpenQRM

OpenQRM uses dropbear for the communication and exchange of messages between the server and the appliances. When something goes wrong in this communication OpenQRM can’t function correctly. It can’t access the applicances for status updates and commands. These communication problems are often caused by a misconfiguration in dropbear. The most seen problem is a misconfiguration in the the public and private dropbear key.

The keys should be synchronized between the server and the appliance. On the server grep the public key with the following command:

[root@localhost log]# /usr/lib/openqrm/bin/dropbearkey -t rsa -f /usr/lib/openqrm/etc/dropbear/dropbear_rsa_host_key -y
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCBvwSO7vBBL2avDMds...pVn root@localhost.localdomain
Fingerprint: md5 65:ca:5b:3b:05:c3:61:6d:fb:75:2f:c0:d2:7e:02:cf

Copy the ssh-rsa public key in /root/.ssh/authorized_keys on the appliance.

Now communication should be established.

OpenQRM event log with example of error message caused by communication problem:

openqrm-cmd-queue ERROR executing command with token 64d478dcac6670e5fb000e7c4954863b : /usr/lib/openqrm/bin/dbclient


Aug 26 23:19:45 localhost httpd: openQRM resource-monitor: (update_info) Processing statistics from resource 2
Aug 26 23:19:48 localhost logger: openQRM-cmd-queu: Running Command with token 64d478dcac6670e5fb000e7c4954863b 1. retry : /usr/lib/openqrm/bin/dbclient -I 0 -K 10 -y -i /usr/lib/openqrm/etc/dropbear/dropbear_rsa_host_key -p 1667 root@192.168.42.243 "/usr/lib/openqrm/bin/openqrm-cmd /usr/lib/openqrm/plugins/xen/bin/openqrm-xen post_vm_list -u openqrm -p openqrm"
Aug 26 23:19:52 localhost logger: openQRM-cmd-queu: ERROR executing command with token 64d478dcac6670e5fb000e7c4954863b 2. retry : /usr/lib/openqrm/bin/dbclient -I 0 -K 10 -y -i /usr/lib/openqrm/etc/dropbear/dropbear_rsa_host_key -p 1667 root@192.168.42.243 "/usr/lib/openqrm/bin/openqrm-cmd /usr/lib/openqrm/plugins/xen/bin/openqrm-xen post_vm_list -u openqrm -p openqrm" -----
Aug 26 23:19:52 localhost logger: Host '192.168.42.243' key accepted unconditionally.
Aug 26 23:19:52 localhost logger: (fingerprint md5 64:d5:c7:8e:7a:11:08:3f:43:bc:3c:2b:bf:4a:c8:ce)
Aug 26 23:19:52 localhost logger: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: root@192.168.42.243's password: /usr/lib/openqrm/bin/dbclient: connection to root@192.168.42.243:1667 exited: remote closed the connection

IPv6 subnetting

There are couple of differences between IPv6 and IPv4 address allocation.

  • The prefix length for an IPv6 subnet will always be /64; no more, no less. It allows you to place as many IPv6 devices as the underlying network medium allows. The 128 bit IPv6 address is automatically created from the /64 bit subnet extended with the 64 bit MAC-address of the NIC.

With IPv4, prefix length varies between subnets to subnets, and it caused painful costs when renumbering subnets (for example, imagine when you renumber an IPv4 subnet from /28 to /29 or vice versa).

  • An ordinary leaf site will always get /48 of address space. This will be sufficient for most small to medium sized networks.

With IPv4, the allocation varies by the size of the site, and made it very painful when you migrated from one ISP to another, for example.

iSCSI security, how to secure your LUN?

A SAN is often implemented as a dedicated network that is considered to be a secure network. However, the nature of a SAN is that it is a shared network. This involves some serious security risks, that should be evaluated when using an iSCSI based SAN. Some vendors consider an iSCSI network save when it is implemented as a dedicated switches network (Dell EqualLogic. Securing storage area networks with iSCSI. EqualLogic Inc., 2008.). They consider it virtually impossible to snoop or inject packets in a switched network. We all know this is not the case. If this is true, why do we use firewalls, ids and tons of other security measures? Even if iSCSI runs on an isolated network, and only the management interface of the storage devices are connected to a shared/general-purpose network, security is just as good as the hosts that are connected to the dedicated network. A single compromised host connected to the dedicated iSCSI network can attack the storage devices to get access to LUNs for other hosts.

When implementing an iSCSI network you should be aware of the security risks that this imposes on the environment. To estimate the risk, awareness of the methods that can be used to secure iSCSI is paramount. The iSCSI protocol allows for the following security measures to prevent unintended or unauthorized access to storage resources:

  • Authorization
  • Authentication
  • Encryption

Because iSCSI setups are generally shared environments access to the storage elements (LUNs) by unauthorized initiators should be blocked. Authorization is implemented by means of the iQN. The iQN is the initiator node name (iSCSI Qualified Name), this can be seen as a mac-address. During an audit, storage systems must demonstrate controls to ensure that a server under one regime cannot access the storage assets of a server under another.
Typically, iSCSI storage arrays explicitly map initiators to specific target LUNs; an initiator authenticates not to the storage array, but to the specific storage asset it intends to use.

As an added security method, the iSCSI protocol allows initiators and targets to use CHAP to authenticate each other. This prevents simple access by spoofing the iQN. And last, because iSCSI runs on IP, IPSec can be used to secure and encrypt the data flowing between the client (initiator) and the storage server (target).

Now that we know there are multiple ways to secure access to the storage resouces, you might conclude that iSCSI must be safe and secure to use. Unfortunately this is not evident. There are several flaws in the iSCSI security design:

  • iQN’s are trusted, but are easy to spoof, sniff and guessed
  • iSCSI authorization is the only required security method, and this uses only the iQN
  • Authentication is disabled by default
  • Authentication is (mostly) only implemented as CHAP
  • IPSec is difficult to implement

Because iQN’s are manually configured in the iSCSI driver on the client, it is easy to change them. To get access to a LUN that is only protected by a iQN restriction, you can sniff the communication to get the iQN, or guess the iQN as it is often a default string (eg.: iqn.1991-05.com.microsoft.hostname), configure the iscsi driver to use this name and get access to the LUN.

The CHAP protocol is basically the only authentication mechanism that is supported by iSCSI vendors. The protocol allows for other mechanisms like Kerberos. The CHAP protocol is not a protocol know for its strong security on shared networks. The CHAP protocol is vulnerable to dictionary attacks, spoofing, or reflection attacks. Because the security issues with CHAP are well known, the RFC even mentions ways to deal with the limitations of CHAP (http://tools.ietf.org/html/rfc3720#section-8.2.1).

While IPSec could stop or reduce most of the security issues outlined above, it is hard to implement and manage. Therefor not many administrators will feel the need to use it. It should not only be possible to make a secure network, it should also be made easy.

To reduce the risk, and make your iSCSI network as safe as possible, you should do the following:

  • Enable mutual (incoming/outgoing) authentication
  • Follow advice to secure CHAP
  • Enable CRC checksums
  • Do not only rely on iQN for authorization
  • Enable IPSec (if performance allows it)

Also vendors/distributors should enable authentication by default, and add other authentication mechanisms to the iSCSI target and initiator software.

References:
http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-Dwivedi-update.pdf
http://en.wikipedia.org/wiki/ISCSI#Authentication
http://weird-hobbes.nl/reports/iSCSI%20security/