Tuesday, July 19, 2016

how to make LXC forwarding again traffic towards real network in ubuntu 16

We had a problem recently when migrating from ubuntu14 to ubuntu16 our LXC infrastructure:
the overall networking from outside (MASQUERADE and DNAT) was not working all of a sudden...

Apparently the difference is in the host machine:
-ubuntu 14 has the bridge module charged in the kernel with by default (check with sysctl -a)
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

in this case we used to forward the traffic "from" and "to" the bridges where we had LXC attached and to masq the ips when needed.

-ubuntu 16 has not (even if you create bridges and set iptables to forward the bridges traffic) unless you add the following rule: 
(check with sysctl -a|grep bridges)
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
(check again with sysctl -a|grep bridges)

this way we had the same behaviour as with the Ubuntu 14 (well...more or less, you may need to trim a bit the forwarding table)

hope this will help... it took quite a while to figure this out
ciao
Alex 

how to use an LXC to setup a MAAS region controller

First a word of warning: this feature is experimental. As far as I know it should be stable, but there are known security concerns, specifically with mounting ext2/3/4 volumes. 
It should only be enabled in trusted environments where potentially malicious users do not have shell access to your system.

A lxc container will not have the device nodes needed for mounting (/dev/fuse for fuse and some block device for ext4, e.g. /dev/loop0) and will not be permitted to mount by AppArmor. 
This how to shows how to create a lxc config which will run the container without AppArmor confinement and will allow you to mount the devices.

Requirements
In order to use this feature, you will need a 4.4.0-6.21 or later kernel in Ubuntu xenial. To follow these instructions you will also need to have lxc installed on the host machine

Setup:
in the HOST 
You need to flip the module parameters to enable user namespace mounts for ext4.
$ echo Y | sudo tee /sys/module/ext4/parameters/userns_mounts

In the LXC 
add the following to the /etc/rc.local 
for i in `seq 0 7`; do /bin/mknod /dev/loop$i b 7 0; done
to create the needed loop devices (they are needed by MAAS top manage the tftp images)

run it or reboot the LXC 
$ /etc/rc.local 

check for /dev/loopNN devices and you are done 

Test

$ dd if=/dev/zero of=ext4.img bs=1M count=8
$ mkfs.ext4 ext4.img
$ sudo losetup /dev/loop0 ext4.img
 
$ mkdir -p mount
$ mount /dev/loop0 mount  
$ df

This filesystem can be unmounted in the usual way.

Now you have to follow the MAAS install guide and you are free to move the MAAS LXC wherever you want. 



Friday, April 1, 2016

pxe install KALI linux with a broadcom non free driver

Today I needed to install a KALI linux through the PXE on a server with a broadcom nic.
The kali is a powerful penetration suite Debian based (for info kali.org) and uses by default only free repositories.
The installer complains about non-free firmware when trying to load the proper nic firmware during the boot (and from there take note of the name of the firmware)

Find online the proper .deb (in my case:  firmware-bnx2x_20160110-1_all.deb) containing the firmware that you noted before (bnx2x-e2-7.12.30.0.fw), 
download it and check that it correctly contains what you need with:

#dpkg -c firmware-bnx2x_20160110-1_all.deb 
[...]
-rw-r--r-- root/root    321320 2016-01-10 22:35 ./lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw
[...]

then:
#mkdir /tmp/firmware ; cd .. 
#pax -x sv4cpio -w firmware | gzip -c >firmware.cpio.gz

now copy the firmware.cpio.gz in your tftp_root_dir/kali_install/amd64 where you have the initrd.gz file and brutally attach it to your initrd:

#cp  initrd.gz initrd.gz.orig; cat initrd.gz.orig firmware.cpio.gz > initrd.gz

works like a charm.

now boot and enjoy your pxe installed Kali farm
alex barchiesi

Monday, February 8, 2016

how to convert a virtual box image to qcow2

I recently needed a KALI linux image in my openstack cluster. There was only a ova image provided by kali.org.

We need a Linux instance with around 4 CPU's and 4GB or RAM

Let's download the vbox image from https://www.offensive-security.com/kali-linux-vmware-virtualbox-
image-download/

Then extract:
(# apt-get install p7zip-full) <optional to install p7zip
# 7za e Kali-Linux-2.0.0-vbox-amd64.7z
Let's extract the ova file to review the VMDK files inside:

# file Kali-Linux-2.0.0-vbox-amd64.ova
Kali-Linux-2.0.0-vbox-amd64.ova: POSIX tar archive (GNU)

# tar -xvf Kali-Linux-2.0.0-vbox-amd64.ova
Kali-Linux-2.0.0-vbox-amd64.ovf
Kali-Linux-2.0.0-vbox-amd64-disk1.vmdk
Kali-Linux-2.0.0-vbox-amd64.mf
then convert the VMDK to a qcow2

# qemu-img convert -O qcow2 Kali-Linux-2.0.0-vbox-amd64-disk1.vmdk Kali-Linux-2.0.0-vbox-amd64-disk1.qcow2
Finally upload the converted image to glance using the glance client

# glance image-create --name "Kali2_64" --disk-format qcow2 --container-format bare --is-protected True < Kali-Linux-2.0.0-vbox-amd64-disk1.qcow2

The image is ready and we can boot an instance from it.

PS a side note for KALI linux: ssh server is not installed so you need to install it and start the service. To do that you better use the console login with root-toor credentials

This procedure should more or less be valid for almost any ova image. Please let me know if you make other conversions. 


Friday, December 18, 2015

mount a qcow2 image or a virtual machine disk

To mount qcow2 images there is qemu-nbd util. It shares image through kernel network block device protocol and this allows to mount it:
modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 image.img
mount /dev/nbd0p1 /mnt/image


If LVM is present on image it could be initialized with:
vgscan
vgchange -ay
mount /dev/VolGroupName/LogVolName /mnt/image


Finishing is done with (depending on how it was initalized):
umount /mnt/image
vgchange -an VolGroupName
killall qemu-nbd
kpartx -d /dev/loop0
losetup -d /dev/loop0
details and thanks to 
Alexey Torkhov's blog

Tuesday, September 8, 2015

how to setup EMBY server for access only from a certain network and your dynamic home ip

Assuming that you know how to:
-configure EMBY server 
-setup iptables
-using a linux machine 

I found a bit annoying from a security point of view to have my videos and pictures exposed as a public ip to the world.

the case: 
I have a static ip on one location on a linux machine 
and I'd love to access the Emby server only from my machine, and the network from where my phone is connected + my home network (this should also help in case of copyrighted material)

I first setup a dyndns for my router (which actually was already working)
then I focused on the iptables with the following script that I added to a cron job running every minute


#!/bin/bash

iptables -D INPUT -p tcp -m tcp --dport 8096 -j EMBY
iptables -D INPUT -p tcp -m tcp --dport 8290 -j EMBY
iptables -D INPUT -p tcp -m tcp --dport 8096 -j DROP
iptables -D INPUT -p tcp -m tcp --dport 8290 -j DROP

iptables -A INPUT -p tcp -m tcp --dport 8096 -j EMBY
iptables -A INPUT -p tcp -m tcp --dport 8290 -j EMBY
iptables -A INPUT -p tcp -m tcp --dport 8096 -j DROP
iptables -A INPUT -p tcp -m tcp --dport 8290 -j DROP

iptables -A EMBY -j DYNAMIC # tell iptables to redirect the EMBY traffic on the DYNAMIC table

iptables -F DYNAMIC # Flush the DYNAMIC chain
iptables -A DYNAMIC -s <home hostname> -j ACCEPT # Accept packets from home
iptables -A DYNAMIC -s <network of emby> -j ACCEPT # Accept packets from my machine in the emby location
iptables -A DYNAMIC -s <wireless dhcp network> -j ACCEPT # Accept packets from my machine in the emby location wifi - needed for the mobile

that's basically all that is needed

Alex 

Wednesday, May 13, 2015

how to change the root pass to a VM image in openstack

Why is this needed:  for example to setup the root pass of an existing image in glance without recreating it.

  1. setup the needed packages: 
    • apt-get install -y libguestfs-tool
  2. locate the image: mine is in /tmp/debian-8.0.0-openstack-amd64.qcow2 
  1. inspect the image to know what's the root disk partition: 
    • guestfish --rw -a /tmp/debian-8.0.0-openstack-amd64.qcow2
    • ><fs> run
    • ><fs> list-filesystems
    • /dev/sda1: ext3
  2. mount it in a dir: 
    • guestmount  -a /tmp/debian-8.0.0-openstack-amd64.qcow2  -m /dev/sda1 --rw /mnt/
  3. change the /etc/shadow file with the correct md5 crypted pass 
  4. unmount with:
    •  guestunmount  /mnt
  5. import into glance:
    • glance image-create --name="debian 8 amd64" --is-public=true --disk-format=qcow2 --container-format=bare < /tmp/debian-8.0.0-openstack-amd64.qcow2