Posted on

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 ] ;
then
    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 ] ;
then
    $1 > /dev/null 2>&1 ;
# otherwise stderr will follow its normal path and find its way to email
else
    $1 > /dev/null ;
fi ;

# lastly if running the $1 resulted in an abnormal exit, the counter is incremented
if [ ! $? = 0 ] ;
then
    counter=`cat /tmp/counter_ri7g3` ;
    echo "$counter+1" | bc > /tmp/counter_ri7g3 ;
# and if $1 exited normally, we reset the counter
else
    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"
Posted on

IPv6 link-local surface analyzer

Download

ipv6_surface_analyzer_1.0.tar.gz

Quick Start

    1. make sure that nmap, ifconfig & arping are installed and in your path
    2. run as root

    tested on Ubuntu 11.10 64b

    Screenshot

    (actual ips obfuscated)

    Purpose

    With more devices coming IPv6 ready out of the box, a shadow network is emerging that nobody is paying attention to.

    There’s Joe sysadmin, configuring a tight firewall for this new server, default deny, very restrictive & all. This is great but did he realize that there is nothing in front of IPv6? We are used to setting up iptables, ipfw, et cetera. Unfortunately ip6tables & ip6fw too often get forgotten.

    With IPv4, a device was manually configured or wasn’t configured until it got an address from DHCP. With IPv6 a device that is not manually configured will hop on the network with a link-local address and try to further discover its settings. In fact, IPv6 reserves a range of addresses for network discovery, these link-local addresses are based on the device’s mac address.

    Here is what ipv6_surface_analyzer.py does:

    • iterate through a given IPv4 range
    • for each address in the range, discover if a host sits behind it
    • port scan potentially found host on IPv4
    • infer IPv6 link-local address of host based on its mac address
    • port scan inferred IPv6 address

    The purpose of which is to establish by how much your attack surface is augmented by link-local IPv6.

    This threat threat is somewhat mitigated by its local nature and there are 2 reasons why:

    1. link-local isn’t routed and thus your visibility is bound to networks you have a presence on.
    2. Getting a host’s mac address is only possible while being on the same network.

    Local as it may be, having a shadow network providing a way to circumvent firewalls is quite risky.