Utilizing AWS Traffic Mirroring with Snort on Debian Linux

I wanted to utilize the AWS Traffic Mirroring feature to deploy an IDS with an AWS environment.  It seems initially fairly simple, but there were a few minor snags.  Most specifically with the Linux kernel feeling a mac address had moved from one IP to another with messages like:

Jul 31 18:15:51 debian kernel: [ 9394.768861] vxlan-tap: 0a:93:bf:88:4b:aa migrated from 10.6.12.47 to 10.6.12.117

repeating over and over.

My initial setup was utilizing a single vxlan link setup like:

ip link add vxlan-tap type vxlan id 16668977 dev ens6 dstport 4789

ip link set vxlan-tap up

After much searching around, I got the idea to try multiple links and utilize a virtual bridge to tie them together such as:

ip link add vxlan-tap0 type vxlan id 16668977 dev ens6 dstport 4789

ip link set vxlan-tap0 up

ip link add vxlan-tap1 type vxlan id 16668976 dev ens6 dstport 4789

ip link set vxlan-tap1 up

brctl addbr vxlan-tap

brctl addif vxlan-tap vxlan-tap0

brctl addif vxlan-tap vxlan-tap1

ifconfig vxlan-tap up

And still utilizing vxlan-tap as my interface in Snort.

Utilizing an Android Phone and ADB for paging

I have long used a cellphone connected via USB to our network management system (running Nagios) for page/text/sms'ing, but we recently got a notice from ATT that our ancient Samsung 2G phone was no longer going to be supported. We originally used some software called gnokii for this purpose, but over time moved to gammu (I believe we had originally been using a Nokia phone for this purpose).

Looking at the current state of those two pieces of software, Gammu has been updated more recently but it's author has stated he will not support Android. The pickings are pretty thin, and it is difficult to get to the bottom of if your non-Android/Non-Apple phone will be supported under the software and your provider. So I explored another option, and that ended up being Android and ADB.

For initial testing, I plugged my HTC One M8 into my desktop Ubuntu 14.04 Linux box and started testing. This required me to turn on USB Debugging on my phone and to install the android-tools-adb package. There are many blogs that cover how to do this, my only advice is don't bother with the SDK steps if this is all you are doing. I found Innokenty Sokolov's blog entry about sending sms via adb shell from bash and used that as the initial basis of my work.

After the initial proof of concept, we talked to AT&T about our eligible free upgrades and went with the HTC Desire 610.

I eventually expanded that script to deal with screen blanking, ICS+ changes in screen blanking activity, and added locking with retries. And it eventually ended up something like:

#!/bin/bash
# Initial work from http://qbbr.io/blog/send-sms-via-adb-shell-from-bash.html
# using: ./sendsms.sh 89999999999 "Hello, im SMS from bash"
#

lockfile-create --use-pid --retry 5 /tmp/sendsms


ADB=/usr/bin/adb
# KEYCODE_POWER
$ADB shell input keyevent 26
# KEYCODE_HOME
$ADB shell input keyevent 3
# open form and fill them
$ADB shell am start -a android.intent.action.SENDTO -d sms:$1 --es sms_body "$2" --ez exit_on_sent true
# sleep 1 sec
sleep 1
# KEYCODE_DPAD_RIGHT
$ADB shell input keyevent 22
# KEYCODE_ENTER
$ADB shell input keyevent 66
# KEYCODE_POWER
$ADB shell input keyevent 26

This seems to be working fairly reliably, and allows our NMS system to stack a sufficient number of texts, though it doesn't have quite the elegance of Gammu's queueing, it is getting the job done.

Puppet and Virtual User Creation

I have been using Puppet for more and more admin tasks, and expanding the complexity of what I am doing. Currently, I am doing just about everything in the puppet config files, but am planning on starting to use ENC (initially through Puppet Dashboard, possibly moving to The Foreman). I didn't love the way I was managing users with Puppet, and am in the process of revamping it. I had really needed to virtualize user creation, so that things became manageable. To that end, I found Scott Lowe's Blog on Puppet Account Management, which got me 90% of where I wanted to go. The trick I still wanted to perform was to set an initial password, but not to reset their password after they change it. I had an idea of how to do this using Subscribe, and that at least seems to be working well initially.

define intusers::virtual ($uid,$realname,$pass) {

  user { $title:
    ensure            =>  'present',
    uid               =>  $uid,
    gid               =>  $title,
    shell             =>  '/bin/bash',
    home              =>  "/home/${title}",
    comment           =>  $realname,
#    password          =>  $pass,
    password_max_age => '90',
    password_min_age => '0',
    groups     => ['sudo'],
    managehome        =>  true,
    require           =>  Group[$title],
  }
  group { $title:
    gid               =>  $uid,
  }

  exec { "/usr/sbin/usermod -p \'$pass\' $title":
    refreshonly => true,
    subscribe => User[$title],
    #    logoutput => true,
  }

SMART On Windows

I have long been annoyed by the lack of SMART monitoring available for Windows, and when I had previously looked into this the tools that I found were not terribly good. It seems this has been rectified by the Smartmontools Project, which now compiles and functions under Windows. Orsiris de Jong has done one better, and wrapped some other tools and a better installer along with Smartmontools, configuring smartd to start as a service, adding notifications, etc. His project page is at Netpower.fr/smartmontools.

sudo on Debian Etch

While Debian Etch is horribly out of date, I still have a couple of servers that I administer that require Debian 4.0 aka Etch. One unfortunate bit is that it seems that the version of sudo (1.6.8p12-4) packaged for Etch is horribly broken. Specifically, it does not seem to prompt for a password to give elevated privs. Even when modifying the sudoers file to specifically say authentication is required (via the authenticate Defaults and the PASSWD tag) allows passwordless entry. The fix that I have applied is compiling the sudo package from Lenny sudo source package. The source package is available at Lenny sudo (1.6.9p17-3)

Find and Time

I have never been particularly good at remembering find's arguments related to times/dates/etc. So this is going to be a bit of a cheat sheet for myself. Find *~ files modified older than today:

find . -name \*~ ! -newermt `date +%F -s yesterday`

Find *~ files modified newer than yesterday:

find . -name \*~ -newermt `date +%F -s yesterday`

Find *~ files between certain days:

find . -name \*~ -newermt `date +%F -s '14 days ago'` ! -newermt `date +%F -s '7 days ago'`

Multiple Samba Instances on Separate Interfaces

I didn't find a lot of information on how to have multiple different samba instances running on the same machine, and what I did find didn't seem all inclusive.  So the various configuration directives I needed to set are:

#
#Specify the Interfaces that this instance will listen on for smbd
interfaces = eth0 
#Specify the IP that nmbd will use
socket address = 192.168.1.1
#Only bind the above
bind interfaces only = yes

#The following line may be needed to clear up some connection issues with older clients, and possibly it should be 139 445
smb ports = 139

#
# On at least one instance, the directories for state/cache/locks/etc will need to be changed
state directory = /var/lib/samba-eth3
private dir = /var/lib/samba-eth3
lock directory = /var/run/samba-eth3
pid directory = /var/run/samba-eth3
cache directory = /var/cache/samba-eth3

#
# Logging
# Make sure to fix the log file directive
# log file = /var/log/samba-eth3/log.%m

#
# Authentication
# May need to update passdb backend line to keep separate
passdb backend = tdbsam:/var/lib/samba-eth3/passdb.tdb

Additionally, a startup script will need to be created adding the specific configuration to the commandline for smbd/nmbd. The commandline will be something like:

/usr/sbin/nmbd -D -s /etc/samba-eth3/smb.conf -l /var/log/samba-eth3/
/usr/sbin/smbd -D -s /etc/samba-eth3/smb.conf -l /var/log/samba-eth3/