linux

Ubuntu 11 on Kingston SV100S2/256G SSD

abb — Sat, 08 Oct 2011 11:40:17 +0000

Ubuntu 11 on Kingston SV100S2/256G SSD

Here are some notes about my attempt to install Ubuntu 11 on Kingston SV100S2/256G SSD (on Dell Latitude E6510 laptop). Just in case somebody else finds it useful.

I have Googled around for information about SSD disk optimization for Linux and found that there are two main things to consider: partition alignment and filesystem options.

It appears to be important to (try to) align disk writes by the boundaries of SDD erase block size. This [1] article talks about LVM volumes alignment.

Most tutorials out there seems to blindly assume SSD erase block size is 128KB, unclear on what ground. This post [3] suggest the kind of disk I have features 1MB erase block size. I decided to take use this value.

Finally, I have ended up with the following partition layout, with alignment by 1MB:
$ sudo fdisk -S 64 -H 32 /dev/sdb ... Command (m for help): p

Disk /dev/sdb: 256.1 GB, 256060514304 bytes
32 heads, 63 sectors/track, 248074 cylinders
Units = cylinders of 2016 * 512 = 1032192 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfeb3c9c1

Device Boot Start End Blocks Id System
/dev/sdb1 1 103 103792+ 83 Linux
/dev/sdb2 104 248074 249954768 8e Linux LVM

Creating LVM physical volume, with its meta-data size set to align start offset of its extents to with 1MB boundary.
$ sudo pvcreate --metadatasize 994k /dev/sdb2 Physical volume "/dev/sdb2" successfully created $ sudo pvs /dev/sdb2 -o+pe_start PV VG Fmt Attr PSize PFree 1st PE /dev/sdb2 lvm2 -- 238.38g 238.38g 1.00m

Create physical volume group and logical volume.
$ sudo vgcreate e6510-ssd1 /dev/sdb2 Volume group "e6510-ssd1" successfully created $ sudo lvcreate --size 32G --name root e6510-ssd1 Logical volume "root" created

Finally, create a file system, with stripe width set to 1MB (256 x 4K blocks). "Resize" parameter limits the maximum size your filesystem can grow live, it is optional parameter, just saves a few megabytes.
$ sudo mke2fs -t ext4 -E stripe-width=256,resize=250G /dev/e6510-ssd1/root

To make use the instructions above, you will need to use alternative installer CD which lets you interfere with partitioning/filesystem creation process.

References:
[1] http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-… (also available at http://web.archive.org/web/20101130200444/http://thunk.org/tytso/blog/2…)
[2] http://williamscott.me/blog/2010/12/ssd-tweaks-linux-align-partitions/
[3] http://forum.notebookreview.com/notebook-news-reviews/395398-kingston-s…

abb Sat, 10/08/2011 - 13:40

Self-encrypting (FDE) Hard Disks & Linux

abb — Thu, 03 Feb 2011 14:52:14 +0000

Self-encrypting (FDE) Hard Disks & Linux

Recently I have upgraded to Dell Latitude E6510 with 4 cores / 8 threads processor, plenty of RAM, and a fast hard disk. Nevertheless, the interactive performance of Ubuntu becomes sloppy beyond any measure when a virtual machine or two start trashing the disks.

There seems to be known performance problems in Linux kernel, like Bug 12309. And full disk encryption makes things even worse. It appears that new FDE technology will give laptop users a chance to move the burden of encryption to hard drives.

Some vendors already offer devices doing all the crypto stuff by themselves, on-the-fly, and supposedly with no performance impact whatsoever. I have heard about these drives a while ago, but just now came across this document from Seagate, which convinced me that their drive are likely to work in my laptop and Linux, or pretty much any laptop/OS with BIOS supporting password-protected hard drives.

I have just ordered ST9500421AS - Momentus 7200 FDE.2 500-GB Hard Drive for a bit over 62 euro before tax, we will see how it works out...

abb Thu, 02/03/2011 - 15:52

Linux Routing Quirks

abb — Mon, 18 Oct 2010 10:32:45 +0000

Linux Routing Quirks

Recently I have spent some time trying to mess up a routing table of Linux appliance to trick it into leaking out certain network traffic I was interested in. In theory it looked reasonably simple, but not quite so in practice. While trying to screw up the appliance I have learned a couple of new things about Linux networking:

1. Linux box (at least kernel <= 2.6.32) silently drops packets with source IP addresses equal to any local address of the box. It was not easy to find the reason for this. Tried to ask other people on the net, but everybody was puzzled and kept telling me to switch off my iptables... Finally, I have found this post: http://patchwork.ozlabs.org/patch/40152/ which suggests it will be possible to disable this feature via sysctl by changing value 'accept_local' parameter. It was almost a show-stopper... very annoying. I so got used to Linux not doing things it is not asked to.

2. Linux kernel implement Reverse Path filtering, something like Cisco IOS's URPF. Again, this piece of ... mmm ... useful functionality is on by default on my Ubuntu, and quite possibly other distributions. Luckily, this one is easy to disable with sysctl by setting net.ipv4.conf.*.rp_filter to 0.

3. On the positive side, I have found that it is possible to convince Linux to use another IP address when originating connections, useful if certain program does not have bind-to-address option. Assuming you want all traffic to be originated from 10.0.0.1 and your default gateway is 192.168.1.1:
1) create loopback interface with the desired source address
# ifconfig lo:0 10.0.0.1 netmask 255.255.255.255 up
2) replace your routing table entry with a custom one:
# route delete default
# ip route add default via 192.168.1.1 src 10.0.0.1
3) check if it has any effect
# ip route get to 8.8.8.8
Now locally generated traffic flowing towards the default gateway (except if emitted through raw sockets, for example by nmap -sS or hping) will be originated from 10.0.0.1. I guess it should be possible to apply this more selectively on per-process basis using iptable's fwmarks or something.

abb Mon, 10/18/2010 - 12:32

Capstats: fast NIC statistics reporting tool

abb — Tue, 14 Sep 2010 16:27:29 +0000

Capstats: fast NIC statistics reporting tool

Just came across a nice tool to display NIC statistics, it is called capstats. Capstats is much less CPU intensive that iptraf, so it can be run along with hping3 to monitor its performance.

Example from capstats's website:
>capstats -i nve0 -I 1
1186620936.890567 pkts=12747 kpps=12.6 kbytes=10807 mbps=87.5 nic_pkts=12822 nic_drops=0 u=960 t=11705 i=58 o=24 nonip=0
1186620937.901490 pkts=13558 kpps=13.4 kbytes=11329 mbps=91.8 nic_pkts=13613 nic_drops=0 u=1795 t=24339 i=119 o=52 nonip=0
1186620938.912399 pkts=14771 kpps=14.6 kbytes=13659 mbps=110.7 nic_pkts=14781 nic_drops=0 u=2626 t=38154 i=185 o=111 nonip=0
1186620939.012446 pkts=1332 kpps=13.3 kbytes=1129 mbps=92.6 nic_pkts=1367 nic_drops=0 u=2715 t=39387 i=194 o=112 nonip=0
=== Total
1186620939.012483 pkts=42408 kpps=13.5 kbytes=36925 mbps=96.5 nic_pkts=1 nic_drops=0 u=2715 t=39387 i=194 o=112 nonip=0

So far the tool worked nicely for me, except that on one host I had to run it with -N, otherwise it fails to produce output when there is no traffic on the wire.

abb Tue, 09/14/2010 - 18:27

Making Linux network bridge transparent for 802.1x packets

abb — Tue, 31 Aug 2010 09:33:58 +0000

Making Linux network bridge transparent for 802.1x packets

Update 17/01/2011: If you are interested in 802.1x bridging, have a look at my Tapping 802.1x Links with Marvin blog post.

802.1x authentication messages are sent in Ethernet frames with destination MAC address set to 01:80:C2:00:00:03. This address belongs to “IEEE 802.1D MAC Bridge Filtered MAC Group Addresses” (01:80:C2:00:00:00 to 01:80:C2:00:00:0F) and such frames are not supposed to be relayed by bridges conforming to IEEE 802.1D [2]. For a number of reasons, you may want these frames to go through your bridge.

The quick and dirty way to solve the problem is to hack the Linux kernel – just comment out the “unnecessary” functionality. To do so:
1) Unpack your kernel sources and prepare for compilation
2) Apply a patch.
3) Compile and install the kernel

Steps 1 and 3 are specific to your distribution, these instructions works file for my Ubuntu. Step 2:

abb@d820:~/build$ cd linux-2.6.27/
abb@d820:~/build/linux-2.6.27$ patch -p0 < ~/br_input.patch
patching file net/bridge/br_input.c

abb Tue, 08/31/2010 - 11:33

Transparent Connection Interception Trick

abb — Wed, 07 Jul 2010 17:09:31 +0000

Transparent Connection Interception Trick

Now when I have a blog for half a year I figured I should post something. So here goes description of using Linux (Ubuntu in my case) bridge configured to redirect selected TCP connections to intercepting proxy (Burp) and while letting the intercepting proxy communicate with the server. Quite useful when doing pentests of fat clients and appliances communicating over HTTP(S), especially in a situation when you can't tamper with client's /etc/hosts file or use other technique to redirect interesting traffic.

Assuming the networking and bridging are configured, there is one thing which needs to be done to start playing with traffic redirection. You should create a group which will be used to designate local processes exempt from traffic redirection. Here I use group name 'noredir' which is hardcoded in 'do_redirect.sh' script, so you have to alter it if you decide to use another group name.

$ sudo addgroup noredir
Adding group `noredir' (GID 1003) ...
Done.

Choose a password and generate a hash for it. You can also just take the one specified below, it corresponds to an empty password.

$ echo -n | mkpasswd 
Password: 
H4ueB58xqisRQ

Set the password for 'noredir' group. (Yes, groups can have passwords. You didn't know? Neither did I.) Edit /etc/gshadow file and change

noredir:!::

noredir:7eVADNYgCIWO6::

Now by issuing 'sg noredir' command you can easily spawn a new shell process with primary GID set to 'noredir'. You will need it to control what iptable rules get applied to traffic generated by programs I use.

$ id
uid=1000(abb) gid=1000(abb) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb)

$ sg noredir
Password: 

$ id
uid=1000(abb) gid=10000(noredir) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb),10000(noredir)

Now run Burp under 'noredir' group.

$ sg noredir
Password: 
$ java -jar burpsuite_pro_v1.3.jar

Proxy options must be set as following:

loopback only = NO
support invisible = YES

Consider disabling interception until the networking part is working fine. If some of services under attack run over SSL, you may want to provide SSL keys as well. Having one listener for both HTTP and HTTPS traffic has worked out for me.

Now everything is ready to kick off traffic redirection. Create a shell script file like the one shown below and save it in the same directory as do_redirect.sh file available here.

#!/bin/sh -xe

snatip=XXX.YYY.64.57
burpport=8008

. `dirname $0`/do_redirect.sh

reset_redirects
redirect_tcp XXX.YYY.3.187 80 $burpport
redirect_tcp XXX.YYY.3.215 8088 $burpport
redirect_tcp XXX.YYY.8.57 80 $burpport

true

Some explanations regarding redirect_tcp() function are in order.

TCP connections (originated by from local programs and in bridged traffic) heading towards the selected TCP ports get redirected to local TCP port 8008. NB: this port has to be bound to *, ports bound to 127.0.0.1 will not receive redirected traffic. Don't ask me how I know.
Connections originated by Burp (and other programs running under 'noredir' group) don't get redirected. You will know something goes wrong here if Burp hangs and eventually run out of file handles. If you get this it is better to restart Burp.
Connections exempt from redirection get SNAT'ed to the specified IP address. You should manually set 'snatip' to the IP address of the client under attack. This is done to prevent server from noticing requests are coming from another IP address. (The same can be done with source MAC address if needed.) If SNAT'ting is not required, don't set this variable.
All other traffic gets bridged. One notable exception is link-local traffic such as 802.1x. You have to tweak the kernel a bit to make the described approach work on 802.1x-enabled links, check this article for details.

All this is implemented in do_redirect.sh file using iptables and ebtables. Have a look inside if you are interested in how it is actually done.

The end.

abb Wed, 07/07/2010 - 19:09