Shellshocked.

It's been several months since the public has become aware of the ShellShock bug. So all of you Linux, BSD, UNIX, and Mac users out there, if the following command works in your shell, you're vulnerable to one of the most devistating *nix bugs around (STILL!). Yes, all you new Ubuntu / Mint / Fedora users out there, I'm talking to you. If you have no idea what in the world I'm talking about, then I'm talking to YOU.

env check='Not vulnerable' x='() { :;}; check=Vulnerable' bash -c 'echo $check'

If you see "Not vulnerable", you're good to go. everyone else, please see your distribution's website for updates... like yesterday.

howto: DHCPD with multiple subnets on the same interface

It took me tons of Google research to figure this out. From a mix of various posts and forums, I was able to piece together how to do this interesting little setup.

The Scenario: You have a DHCP server running on your gateway (or other machine), and you want to segregate different devices to their own subnet. For example, say you have a group of terminals or thin clients you want on one subnet, your VOiP phones on another subnet, and people using laptops on another subnet.
Tools Needed: the ISC DHCP Server.

• Ubuntu Linux
• apt-get install isc-dhcp-server
• Gentoo Linux
• emerge dhcp

My network is dual-firewalled (at least from the perspective of my Thin Clients). My hardware firewall has a public IP address, and of course a lan address.

• The lan address of my hardware firewall is 192.168.0.1 with a netmask of 255.255.255.0.
• The lan address of my Thin Client Server is 10.1.0.1 with a netmask of 255.255.255.0
• The Thin Client Server has a SECOND lan address of 10.0.1.1 with a netmask of 255.255.255.0

Why so many ip addresses you ask?

So here's what we do, we are going to take our VOiP phones, and put them on the 192.168.0.1 subnet, because they dont need any other services (besides DNS and DHCP) off of our server. This well help avoid collisions on the network, and hopefully keep our conversations crisp and clear.

We are then going to take our Thin Clients and again give them their own subnet for the same reason. There is going to be alot of traffic between the clients and server, so we want to avoid disrupting phone the phone service.

The "everyone else" catagory: This could be employee laptops who need no direct interaction with our server (besides DHCP and DNS). But I also wanted them to be on a different subnet than the phone system.

The VOiP Phones get their IP address from the local DHCP server. Since they are then on the same subnet as the firewall, they are good to go. However, the Thin Clients and "Other Devices" are on 2 other subnets each. Therefor, the server has to act as a NAT for those devices if they wish to access the Internet. The IPTABLES rules for the server to make it use Network Address Translation for the 2 subnets on 10.* is no different than normal.
The trick is getting your DHCP server to assign addresses to all these different subnets. Here's the config!

authoritative;

# match the MAC addresses of our VOIP phones
class "voip"    { match if substring (hardware,1,3) = 00:04:f2; }

# match the MAC addresses of our LTSP clients.
class "clients" { match if substring (hardware,1,3) = 00:e0:c5; }

shared-network lan {

        # the phones
        subnet 192.168.0.0 netmask 255.255.255.0 {
                pool {
                        range 192.168.0.128 192.168.0.254;
                        allow members of "voip";
                }
                option routers 192.168.0.1;
                option domain-name-servers 192.168.0.2;
                option broadcast-address 192.168.0.255;
                option subnet-mask 255.255.255.0;
        }
        
        # unknown devices / laptops / tables / cellphones
        subnet 10.1.0.0 netmask 255.255.255.0 {
                pool {
                        range 10.1.0.5 10.1.0.128;
                        allow unknown-clients;
                }
                option routers 10.1.0.1;
                option domain-name-servers 10.1.0.1;
                option broadcast-address 10.1.0.255;
                option subnet-mask 255.255.255.0;
        }

        # Linux Terminals
        subnet 10.0.0.0 netmask 255.255.255.0 {
                pool {
                        range 10.0.0.5 10.0.0.128;
                        allow members of "clients";
                }
                option routers 10.0.0.1;
                option domain-name-servers 10.0.0.1;
                option domain-name "your.domain.name.here";
                option broadcast-address 10.0.0.255;
                option subnet-mask 255.255.255.0;

                option root-path "/opt/ltsp/i386";
                if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
                        filename "ltsp/i386/pxelinux.0";
                } else {
                        filename "ltsp/i386/nbi.img";
                }
        }

} # end shared net

Edit 2013-03-19: Tinman has another guide over here with even more advanced features.

Linux BASH script to encode video for the Motorola Xoom

Just a quick an dirty linux bash script that you can use on the command line to convert any video supported by FFmpeg to your Motorola Xoom running Android OS.

I have this setup as a bash alias in $HOME/.bash_profile. You can of course use it as a stand alone script if that is your preference.

Usage is quite simple: to_xoom <input file> [<destination directory>]
to_xoom /path/to/some_video_file.mkv /tmp/

Then all you have to do is send it to your tablet using ftp, or by mounting it.

to_xoom()
{
        # XOOM screen dimensions
        # set this to the width of your device, in pixels
        max_width="1280"

        set_dir=0
        dir=""
        in="$1"
        if [ -n "$2" ] && [ -d "$2" ]; then
                set_dir=1
                dir="$2/"
        fi
        if [ ! -f "$in" ]; then
                echo "Error: File: $in does not exist."
                return -1
        fi

        width="`ffprobe -show_streams \"${in}\" 2>/dev/null \
                | grep width \
                | cut -d'=' -f2`"

        if [ "$width" -gt "$max_width" ]; then
                width=${max_width}
        fi

        out="`echo $in | perl -pe '{ s/\..{3,4}$// }'`.mp4"
        if [ $set_dir -eq 1 ]; then
                out="`echo $out | perl -pe '{ s/^.*\/// }'`"
        fi

        echo "Converting $in to $out for Xoom playback"
        nice /usr/bin/ffmpeg \
                -i "${in}" \
                -vcodec libx264 \
                -vpre medium -crf 20 \
                -threads 0 -bf 1 \
                -b 20480k \
                -vf scale=${width}:-1 \
                -qscale 3 \
                -acodec libfaac -ab 192k \
                -ac 2 -ar 48000 -f mp4 "${dir}${out}"

        return $?
}

Marching On

avi2ipod.pl - Convert any supported video to an IPOD playable mp4

Requirements
perl
ffmpeg
libfaac (for audio)

Usage: ./avi2ipod.pl -i <input>
Output file will be written to the same directory as the original,
unless specified with the --output option.
Command Flags:
--input|-i <input> - Specify input file.
--output|-o <output> - Specify output file.
--force - Force a possibly unsafe operation.
--help|-h - Print's this help.
--version|-v - Print this script's version information.

Then just copy to your ipod with something like gtkpod

Download: avi2ipod.pl

Enjoy!

-dan

Howto: BOPM via SSL

This short HOWTO will explain how to setup Blitzed Open Proxy Monitor to connect to an IRC Server via SSL. I expect that you have basic knowledge of Linux/Unix, and already know how to configure/compile, and setup the BOPM as normal.

tools you will need:

• stunnel
• Blitzed Open Proxy Monitor
• An SSL-Capable ircd such as ircd-ratbox

I will assume you already have your SSL-Capable IRCD up and running correctly. I will also assume you have your BOPM up and running correctly. All we are going to do is SSLify it.

Stunnel Setup

• Create a certificate for yourself. You can do this with the following command:

openssl req -new -newkey rsa:1024 -days 365 \
-nodes -x509 -keyout `uname -n`.pem \
-out `uname -n`.pem

• Move or copy the created file, which will be named YOUR_MACHINE_NAME.pem to ~/.YOUR_MACHINE_NAME.pem.
(obviously, YOUR_MACHINE_NAME will be the actual name of your server, such as "leetbox" or something).

• Copy the following text into ~/.stunnel.conf and edit the ip addresses and ports to suit your needs.

cert = /home/YOUR_USERNAME/.YOUR_MACHINE_NAME.pem

[bopm]
; adjust the port number if necessary
accept = 127.0.0.1:8500

; local is the "vhost" stunnel will use to connect to your irc server.
; If you don't use a vhost, leave it commented out.
;local = 0.0.0.0

; connect is the irc server's ip address and port that we are connecting to
connect = 0.0.0.0:6697
client = yes

• Save and close ~/.stunnel.conf. then run:

stunnel ~/.stunnel.conf

• You can test that stunnel is working correctly by connecting to it with telnet.

telnet 127.0.0.1 8500

• If you see the server connect notices, you are in business, otherwise you made a mistake somewhere.

BOPM Setup

• Edit bopm.conf and adjust it's settings as follows:

server = 127.0.0.1
port = 8500

• Save and restart your bopm.
• Your BOPM should now be connected to IRC via SSL.

Howto: Remote logging with syslog-ng

As anyone who uses any flavor of GNU/Linux should know, system logs are stored in /var/log. If you are like me, you may have more than one machine at home. Maybe you have a file server, or a gateway box, or maybe a workstation that you allow your kids to use so they don't mess up your own. Being able to review system logs is an important task. It allows you to debug problems, as well as track things that could alert you to potential problems. If you have more than one PC, this can be a pain in the rear. I found numerous HOWTO's on the internet on how to setup remote logging... some were a little out dated, and others gave too many options that made it all a bit confusing. This little howto is how I setup my remote system logging to make life a little simpler.

My GNU/Linux distro of choice is Gentoo, but this should work on any flavor of linux that uses the logging daemon syslog-ng. Check your package manager to see if that is what you are using. If you're using something else, like SYSKLOGD, you will need to replace it.

First you will need a remote-logging server. This could very well be your desktop computer, or some other dedicated machine. This will be the machine that stores the logs from all your other computers. I will refer to this machine as the log server. Remote machines that you wish to keep track of (file servers, gateways, proxy server, whatever) will be refered to as remote. So lets get started.

Log Server Setup

1. If you are using Gentoo, switch on the hardened use flag for syslog-ng. It makes syslog-ng logs a little more organized. Why this is not done by default is beyond me.
2. The syslog-ng config file should be located at /etc/syslog-ng/syslog-ng.conf. Open it up with your favorite text editor. You should see several lines that look like this example:
   
source src { unix-stream("/dev/log"); internal(); };
source kernsrc { file("/proc/kmsg"); };
destination authlog { file("/var/log/auth.log"); };
filter f_auth { facility(auth); };
filter f_authpriv { facility(auth, authpriv); };
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };

   It's ok if you have more, or slightly different information. this is just an example.
   
3. At the bottom of the file, you are going to add the following:
   
source remote_log {
udp( port(1999) );
};

   This tells syslog-ng that we are going to listen on udp port 1999 for incoming log information.
   Next we are going to add destination files for the logs we receive over the network.
   
#define destinations.
destination remote_authlog { file("/var/log/remote.d/$HOST/auth.log"); };
destination remote_syslog { file("/var/log/remote.d/$HOST/syslog"); };
destination remote_cron { file("/var/log/remote.d/$HOST/cron.log"); };
destination remote_daemon { file("/var/log/remote.d/$HOST/daemon.log");};
destination remote_kern { file("/var/log/remote.d/$HOST/kern.log"); };
destination remote_lpr { file("/var/log/remote.d/$HOST/lpr.log"); };
destination remote_user { file("/var/log/remote.d/$HOST/user.log"); };
# Should be remote_maillog (Without dot) as it was the default on logwatch
destination remote_mail { file("/var/log/remote.d/$HOST/maillog"); };
destination remote_mailinfo { file("/var/log/remote.d/$HOST/mail.info");};
destination remote_mailwarn { file("/var/log/remote.d/$HOST/mail.warn");};
destination remote_mailerr { file("/var/log/remote.d/$HOST/mail.err");};
destination remote_newscrit { file("/var/log/remote.d/$HOST/news/news.crit");};
destination remote_newserr { file("/var/log/remote.d/$HOST/news/news.err");};
destination remote_newsnotice { file("/var/log/remote.d/$HOST/news/news.notice");};
destination remote_debug { file("/var/log/remote.d/$HOST/debug");};
destination remote_messages { file("/var/log/remote.d/$HOST/messages"); };
destination remote_grsec { file("/var/log/remote.d/$HOST/grsec.log"); };
destination remote_pax { file("/var/log/remote.d/$HOST/pax.log"); };

   Next we want to setup log filters, which tell syslog what data goes to what file.
   
   
#connect filter and destination
log { source(remote_log); filter(f_authpriv); destination(remote_authlog); };
log { source(remote_log); filter(f_syslog); destination(remote_syslog); };
log { source(remote_log); filter(f_cron); destination(remote_cron); };
log { source(remote_log); filter(f_daemon); destination(remote_daemon); };
log { source(remote_log); filter(f_kern); destination(remote_kern); };
log { source(remote_log); filter(f_lpr); destination(remote_lpr); };
log { source(remote_log); filter(f_mail); destination(remote_mail); };
log { source(remote_log); filter(f_user); destination(remote_user); };
log { source(remote_log); filter(f_mail); filter(f_info); destination(remote_mailinfo); };
log { source(remote_log); filter(f_mail); filter(f_warn); destination(remote_mailwarn); };
log { source(remote_log); filter(f_mail); filter(f_err); destination(remote_mailerr); };
log { source(remote_log); filter(f_debug); destination(remote_debug); };
log { source(remote_log); filter(f_messages); destination(remote_messages);};
log { source(remote_log); filter(f_pax); destination(remote_pax);};
log { source(remote_log); filter(f_grsec); destination(remote_grsec);};

4. Save your file. you're done with it.
5. Make the log directory for remote machines. with the command:
   mkdir /var/log/remote.d
   
6. restart syslog-ng: /etc/init.d/syslog-ng restart

Remote Setup

1. Setting up the remote machines is way easier. Again, you will need syslog-ng on these machines too. Open up /etc/syslog-ng/syslog-ng.conf with your favorite editor.
2. Add the following lines at the bottom of the config:
   
destination remote {
udp("10.1.1.2" port(1999));
};
log {source(src);destination(remote);};

   You will need to change the IP address '10.1.1.2' to the real address of your log server.
   
3. Save the file, you're done with it.
4. Restart syslog-ng: /etc/init.d/syslog-ng restart
   
5. Repeat these steps on all machines you want to report back to your log server.
   

It might take a few minutes, but you should soon see logs appearing in /var/log/remote.d/hostname from your remote machines.

Optional Steps

Keep syslog-ng.conf from being accidently (or intentionally) overwritten:
chattr +i /etc/syslog-ng/syslog-ng.conf

Install a GUI log parser to make reading your logs easier. A program such as ksystemlog if you're a KDE fan.

Additional Notes
there is a plethora of other options, including encryption if you plan on remote-logging over the internet. I intentionally left this information out, because this howto is geared more to home-networks. If you want to setup remote-logging over the internet, I highly recommend you find a howto that includes SSL options :)

This howto was adapted from articles listed at:
http://www.campin.net/syslog-ng/faq.html
http://gentoo-wiki.com/HOWTO_create_a_logserver_with_syslog-ng