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"
- make sure that nmap, ifconfig & arping are installed and in your path
- run as root
tested on Ubuntu 11.10 64b
(actual ips obfuscated)
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:
- link-local isn’t routed and thus your visibility is bound to networks you have a presence on.
- 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.
Here’s another project that’s been on the back burner for a while: my new Mame box:
This is the 5th arcade cabinet I turn into a Mame box. Gutting them always breaks my heart but having all the games in one cabinet with original artwork is very much worth it. The X-men cabinet is spacious, easy to work with and looks great.
The buttons and joysticks were bought from X-arcade: www.xgaming.com
And the control board to make them interface with a PC is an Ipac2: www.ultimarc.com
It can also be addressed directly via:
for all your API needs.
Link-local IPv6 addresses are used as part of the IPv6 network auto-configuration process. Instead of getting an address via DHCP, a NIC will hop on the network with a link-local IPv6 address and with this will have to ability to do further configuration automatically (soliciting neighbors, router, et cetera).
This link-local IPv6 is infered from the NIC’s mac address.
A mac address is 48 bits, an IPv6 address is 128 bits. Here’s the conversion process step by step:
- take the mac address: for example 52:74:f2:b1:a8:7f
- throw ff:fe in the middle: 52:74:f2:ff:fe:b1:a8:7f
- reformat to IPv6 notation 5274:f2ff:feb1:a87f
- convert the first octet from hexadecimal to binary: 52 -> 01010010
- invert the bit at index 6 (counting from 0): 01010010 -> 01010000
- convert octet back to hexadecimal: 01010000 -> 50
- replace first octet with newly calculated one: 5074:f2ff:feb1:a87f
- prepend the link-local prefix: fe80::5074:f2ff:feb1:a87f
Going the other way
A converter to do the same operation in reverse is available here.
There have been a few interesting comments on this post, I encourage you to read them if you want to learn more about this mechanism. Specifically:
Modeling in Google Sketchup really helped make building fast & seamless. The 2x12x16 are very thick so the hive weights a ton, on the other hand joining pieces was really easy as there is much surface for glue and screws. And I hope this will provide some good insulation against New England winters.