IT Dribble

Sometimes you just *need* to mount an image file under Linux (ie. forensics and/or data recovery).
This isn’t always easy if you DD the disk, then you need to work out the partition maths.

Easiest way is to ‘fisk -l’ the image file:

root@HackerBox:~/forensics# fdisk -l /mnt/temp/ewf1
Disk /mnt/temp/ewf1: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x39bf39be

Device                   Boot   Start      End           Sectors      Size Id  Type
/mnt/temp/ewf1p1 *         63         20948759 20948697  10G  7   HPFS/NTFS/exFAT

From the above you should see ‘Sectors’ are 512 bytes (pretty normal for NTFS) and the partition starts at 63 (sectors) in.

So finally all we need to do is mount the image with the command:

mount /mnt/temp/ewf1 /mnt/temp1 -o ro,loop,show_sys_files,streams_interace=windows,offset=$((63*512))

You can possibly leave out the ’show_sys_files,streams_interace=windows’ parameters if you aren’t doing forensics.

Previously I always had to fumble around using FDISK, do some dangerous task of deleting the partition table while in use, then add re-adding the table with the new extended settings!
Too difficult and too danger prone (although it never failed on me…)

Anyway I just stumbled on a way easier process! Introducing ‘growpart’.
The process for resizing EXT4 partition, ‘/dev/xvda1′ would be:

Backup the partition table (just in case)

sfdisk -d /dev/xvda > partition_backup

Resize the partition

growpart -v /dev/xvda 1

And finally resize the filesystem to make use of the larger partition

resize2fs /dev/xvda1

Happy resizing.

Note: Quick investigation it seems ‘growpart’ is from the RPM ‘cloud-disk-utils’ from Amazon AWS hosted systems. So not sure about regular avaliability.

I had a requirement to filter (all) web traffic on a few servers. This is typically easy with Squid and using it’s transparent proxy function. Where it gets difficult is filtering domains for HTTPS traffic.
I don’t want to SSL intercept the traffic, I don’t want to install CA certificates on the clients, I only want to filter the URLs based on a whitelist to which it can access. This is how it is done:

yum install squid
# I used squid 3.5.20

/usr/lib64/squid/ssl_crtd -c -s /var/lib/ssl_db
chown -R squid.squid /var/lib/ssl_db

mkdir /etc/squid/ssl_cert/
chown -R squid.squid /etc/squid/ssl_cert/
cd /etc/squid/ssl_cert
openssl req -new -newkey rsa:1024 -days 1365 -nodes -x509 -keyout myca.pem -out myca.pem

echo "www.google.com" > /etc/squid/whitelist
chmod 640 /etc/squid/whitelist
chown root:squid /etc/squid/whitelist

/etc/squid/squid.conf:

acl localnet src 10.0.0.0/8	# RFC1918 possible internal network
acl localnet src 127.0.0.1/32	# RFC1918 possible internal network
acl localnet src 172.16.0.0/12	# RFC1918 possible internal network
acl localnet src 192.168.0.0/16	# RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost manager
http_access deny manager

acl step1 at_step SslBump1
acl whitelist_ssl ssl::server_name "/etc/squid/whitelist"
acl whitelist dstdomain "/etc/squid/whitelist"
acl port_80 port 80
acl http proto http

ssl_bump peek step1
ssl_bump splice whitelist_ssl
ssl_bump terminate all !whitelist_ssl

http_access deny http port_80 localnet !whitelist
http_access allow localnet
http_access deny all

https_port 3127 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem
http_port 3128 transparent

coredump_dir /var/spool/squid

refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern .		0	20%	4320

# Test it with:

iptables -m owner --uid-owner cm -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:3128
iptables -m owner --uid-owner cm -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to 127.0.0.1:3127

# Closing notes and thoughts

Around this section here:
http_access deny http port_80 localnet !whitelist
http_access allow localnet
http_access deny all

It looks a bit funny because we ‘allow localnet’ which typically allows our clients open access. However assessing:

ssl_bump terminate all !whitelist_ssl
http_access deny http port_80 localnet !whitelist

rules first, you see that we filter out all sites other than the whitelist with an explicit ‘deny’ or ssl ‘terminate’.

Also trying to use a proxy-aware application with the above configuration will not work because the proxy is configured in transparent / intercept mode ONLY. This is likely due to not having a normal http_port directive, this is good for me as it’s minimizing the abuse avenues.

Also for a final, final step, you need to configure your edge (or local) firewall to do destination NAT’ing back to the two Squid ports.

I recently had a fun task of trying to recover a Mellanox 10 GbE Network card that was dead from a failed firmware upgrade in the past. It was quite difficult to recover, due to lack of hardware information but with some educated guesses I managed to successfully write the correct firmware back on.

I’ll try run through the issue and fix. Sorry in advance the step by step will be lacking the exact outputs as I’m writing this post fix.

The problem: The server was not showing me the expected network interface during installation. I knew the card was installed but upon attempting to PXE boot, it just tried the other two on-board adapters and then moved on.

Next step for me was to boot a live cd and run: lspci -nn which output:
07:00.0 Memory controller: Mellanox Technologies MT27500 [ConnectX-3 Flash Recovery]

Ok that’s something at least, it seemed to be stuck in a recovery mode - all hope is not lost!

Next step for me was to download ‘mlxup’ from (http://www.mellanox.com/page/mlxup_firmware_tool) which was a standalone binary and could be run on the live cd…

The output from that command I don’t have, but I believe it may have had the ‘Device Type’ listed, everything else was blank and ’status’ had an error that I can’t recall.

At this point I needed to write a new firmware (It can’t get any worse or more broken than it is at present)

First step was to install Fedora on one of the disks, so I could install the Mellanox Firmware tools (http://www.mellanox.com/page/management_tools), with Fedora and firmware tools now installed it was go time!

Next is the summary of commands performed to write new firmware:

# Create the /dev/ devices for the firmware tools to use 
mst start

# Output the status 
mst status
# My device was listed as /dev/mst/mt502_pciconf0 with no assicoiated pci_cr0 device 

# Next I needed to download the correct firmware, this is where you may become unstuck as I wasn't 100% of the Product 'Line', let alone the 'OPN' or 'PSID'! Luckily for me I had an identical working server that I could reference. On that server I ran 'mlxup' which gave me the details I required! (At an educated guess).

# Download the firmware
wget http://www.mellanox.com/downloads/firmware/fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin.zip

# Unzip it
unzip fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin.zip

# Try and burn the firmware
flint -d /dev/mst/mt502_pciconf0 -i fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin burn

# Card is broken, therefore disable safety checks (not sure why I used --use_fw)
flint -nofs --use_fw -d /dev/mst/mt502_pciconf0 -i fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin burn 

# It warned that it would be updated using blank MAC addresses, So I generated some MAC addresses
flint -nofs --mac f45214810ae0 --use_fw -d /dev/mst/mt502_pciconf0 -i fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin burn 

# It warned me about something else, so I used the -use_image_ps flag
flint -nofs -use_image_ps --mac f45214810ae0 --use_fw -d /dev/mst/mt502_pciconf0 -i fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin burn 

# Hooray success! But I noticed that the guid and system guid are blank - I'm not sure what impact that would have but I generated some anyway...
flint -nofs -use_image_ps --guid beeff45214810ae0 --mac f45214810ae0 --use_fw -d /dev/mst/mt502_pciconf0 -i fw-ConnectX3-rel-2_40_7000-MCX311A-XCA_Ax-FlexBoot-3.4.746.bin burn

# Yay double success!

So I rebooted the server and lo and behold it tried to PXE boot from the card! Booting into the Fedora installation showed my recovered network interface with it’s generated MAC address, DHCP that interface and BOOM! Interwebs!!!!

Hopefully this helps someone!

Well before you power to replace the disk - can you be sure it will power back on?
Some distros have the bad habit of only install GRUB to one physical disk and if that disk dies…RAID wont save you (but a boot CD will…)

Firstly I like to confirm if /boot is configured in RAID 1. I then usually also install GRUB to all the physical disks via:

grub-install /dev/sda

and sdb and sdc etc. Then I power off the server and replace the disk.

After powering on the server, sometimes it won’t boot due to the new disk getting booted first, so make sure to select another disk in the BIOS boot-up menu.

After the operating system returns it’s a matter of recreating the partitions on the new disk, before trying to add it back into the RAID array. My servers all have the same disk sizes in the array and the same partition layouts, so to recreate them on the old disk I just perform:

sfdisk -d /dev/existing-disk | sfdisk /dev/new-disk

Confirm the new disks get the correct layout via:

cat /proc/partitions

and then add the partition back to the RAID array:

mdadm --add /dev/mdX /dev/sdXX

And then finally confirm its rebuilding via:

mdadm --detail /dev/mdX

OR

cat /proc/mdstat