So finally I have Kali linux 1.0.6. installed as the main OS on my Lenovo X1 Carbon, this was not a trivial matter to say the least.
First of all the installation routine fails trying to install grub-pc; this is due to the network configuration step of the routine creating a blank /etc/resolv.conf
So right after network configuration has completed inspect your /etc/resolv.conf and if it is blank as mine was:
echo "nameserver 126.96.36.199" >> /etc/resolv.conf
Ensuring this is done BEFORE it reaches the grub installation step; this will now complete as expected.
Next up post reboot the encrypted LVM fails to mount, citing it was unable to find kali-root
Loading, please wait...
Volume group "kali" not found
Skipping volume group kali
Unable to find LVM volume kali/root
Help is however at hand, boot back into the live distro forensics mode, and what follows is my somewhat condensed and modified procedure
/dev/sda5: UUID="XXXXXX" TYPE="crypto_luks"
cryptsetup /dev/sda5 luksOpen sda1_crypt
vgchange -ay kali
mkdir -p /mnt/root
mount /dev/mapper/kali-root /mnt/root
mount -t proc proc proc
mount -t sysfs sys sys
mount -o bind /dev dev
mount /deva/sda1 boot
echo "sda1_crypt UUID=XXXXXX non luks" > /etc/crypttab
As for UEFI / EFI ? Don’t even get me started there nothing I have spent long evening hours looking into works for kali, not using the fedora shim nothing at this time; I’m very annoyed at this and will post again once I arrive to a resolution.
In the interim CaptTofu release some interesting material on leveraging Docker to test PXC deploys, he’s even go so far to produce some Ansible playbooks for the deployment process; I’ve been helping to work in some respect on the Ansible side and I can see a lot of potential in docker aswell as a lot of issues (it is a very young project it reminds me a lot of OpenStack hack in the diablo RC days), I encourage you to check this out.
Early warning This is a satirical blog post, with colourful language of which the sole intent is to troll automated scanners and script kiddies, those of a disposition nature should stop reading now.
Shortly after watching @chrisjohnriley’s Defcon 21 talk defense by numbers,
I began thinking how I could implement so of the methods within nginx, taking them to another level by trolling and generally pissing off anyone scanning the server.
Some background on this nginx server does nothing but bounce old domains, and links to their appropriate place on this blog, so it’s out of the way not something you’d typically see attacked en mass.
(seriously I see one or two hits from search engines on the instance, except recently China Telecom must LOVE my blog, 500K requests in an hour … aww shucks guys I love you too)
So let us start with response codes, because 400 response codes are so last century right? I really can’t see why the 7xx-rfc isn’t already a standard.
So I opted for responding to automated scans of my nginx instance with the 793 response code; helpfully letting the scanner know that the Zombie Apocalypse has occured where the instance is located and that I care not of their scans as I’m either shambling along biting everyone within reach and incoherently moaning, or I’m too busy trying to not get my ass zombified.
Zombie apocolypse is serious business; they should appreciate my early warning!
Providing this sorely needed public service is this small nginx server block after my main server block handling all valid requests.
if only those scanners could fully appreciate the midi tones of Rick Astley melodic symphony soothing them to sleep in the wake of the end of all things via Zombie Apocolypse … alas we wonder do calculators dream?
Yup no hostnames were being sent as part of the request, so China telecom doesn’t love my blog afterall … well screw you guys! I thought we had something but you were just a fake …
but wait there’s more just as the sweet verses dictate; we’re never going to give you up, so if you’re making so many requests in such a short time you must want to stay connected to me for as long as possible, it’s ok I’ve got you covered.
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 --state NEW -m recent --update --seconds NN --hitcount N -j TARPIT
Forever together … into the tarpit … shhhh … only dreams now …
And for those not snuggling with us down in the tarpit, sorry but you’ll just need to prove you really want to be in there; sticky cuddles …
YMMV etc this isn’t a fully tested configuration, it’s not ment to do anything but troll all the automated scanners out there hammering the instance.
OpenSSH >= 6.2 supports “multi factor authentication” which is to say you can require multiple forms of identification to complete authentication for the SSH connection.
A real world comparrison would be I suppose providing more than one form of identification to open a bank account.
OpenSSH 6.2 introduces the AuthenticationMethods setting; this combined with pam_yubico can be used to require that the connections provides both the SSH public key and the yubikey O.T.P (One time password).
Replacing the XX portions with your running kernel or you can use substitute in the uname -r output; this one liner script was obtained from: rpm -q --scripts kernel and is required to rebuild the initrd image such that the selinux settings can take effect.
Alternatively if there are updates outstanding a yum -y update will acheive the same thing (selinux settings should persist); after all of this you can now reboot and wait.
This will take a while to start back up as an selinux relabel is running (this is what the touch /.autorelabel achieves.
All being well selinux should now be running enforcing in targeted mode; if not check your /etc/selinux/config file.
My talk was well received and there was a lot of great Q&A both during and after the session … though I did run 15 minutes over sorry Tim I’ll have to buy you a beer by way of appology at the next confernece.
Ryan H also gave a great talk on backups, I’ll update this blog post with a link to the slides once tey become available.