Setting Default Browser in Linux When Things are Stubborn

Running XFCE4 and setting the preferred applications generally works. However, I noticed that some applications still would not listen to my demands of using a specific browser when launching links. For example, using python’s webbrowser module, and therefore almost any other module opening external links, would use Firefox or Opera (depending on which was available).

# Checking python invocation of a browser
import webbrowser as w

Here’s the culprit, check in your /etc/alternatives/ directory and you’ll see what I mean.

ls -l /etc/alternatives/

Notice the entry x-www-browser. This will be a symlink to a browser and this value was different than what I was attempting to set through the XFCE4 GUI configuration. This problem seems somewhat common as I’ve seen it occur in KDE and GNOME as well.

To fix this issue, simply run the following command and you should be presented with a list of browsers from which you can set.

# Update your browser choice and choose from the presented text menu
sudo update-alternatives --verbose --config x-www-browser

# Now make sure teh proper symlink is setup
ls -l /etc/alternatives/x-www-browser

Now you should have a functional default choice. Those GUIs can suck it!

Analyzing Brute Force Attempts in BASH

If you have a public facing SSH server running on the standard port, your message log is probably filled with failed authentication attempts from brute force attacks. Let’s mash up some quick BASH commands to analyze this data. For our purposes, we’ll look at the top attacker IPs and the top usernames tried.

First, pull down all of your message files and decompress them in a working directory using bunzip2.

Once you have all your message logs ready, we will search through them and pull out all of the authentication failure entries and grab the IP and username for each attempt.

grep -r "authentication error" messages* | awk '{split($0,a," "); print a[NF],a[NF-2]}' > attempts

So we first use grep to look for failed authentications by searching recursively for the string “authentication error” in all of our message logs by using the wildcard. We then pipe this to awk and split each input line found into an array delimited by a whitespace. The last part of each line, and therefore our new array, goes something like: ‘authentication error for USERNAME from IP’. So to get the username and IP from our array we can use the array length variable NF and use that to index the variables we need. Here we grab the last using a[NF] and two in from that with a[NF-2]. Finally, we output this to a file called attempts.

Now, let’s use more BASH magic to do the analyses for us. Our attempts file now is in the format as follows: IP USERNAME. We want to see the top IPs and usernames and we can do that with some sorting commands.

cut -d ' ' -f2 attempts | sort | uniq -c | sort -nr > attempts_username
cut -d ' ' -f1 attempts | sort | uniq -c | sort -nr > attempts_ip

Here, we simply grab either the username in the second column or the IP in the first with cut, sort this data, prepend lines with the number of occurrences of each, and then sort by this occurrence number and output to a new file. You can now view attempts_username and attempts_ip to see the top usernames and IPs, respectively, of brute force attacks.

Lastly, we can associate the keep usernames and IPs together and sort on one or the other to see the correlation between the two. To end our initial analyses, we will sort on usernames and find out for the top attempted usernames, what are the top originating IPs.

 sort -k 2,2 attempts| uniq -c | sort -nr | head -n 10

Next time we will be using some GEOIP methods to see where our top attack attempts are originating.

Simple Javascript Redirect

Need a quick redirect for a page? A simple Javascript location set can get the job done just fine.

Let’s redirect to go to the Mutaku GitHub Page. All we need to do is create an index.html file with the following in our subdirectory of choice (here we would have it residing at

<script type="text/javascript">
   window.location = ""

Now, as you would expect, if you visit you will be redirected to the GitHub page.

Grep a Tail to Monitor Your Access Log in Color

Here is a quick example of how to monitor your access log and colorize the IP address of the remote user:

tail -f /var/log/lighttpd/access.log | egrep --color=auto '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}' 

It is crude, but works well enough (generally). The first part tails our webserver access log using the -f switch. This is piped to egrep with the –color=auto switch to colorize the portion we are want, which is an IP address. The result is that the IP address of the remote user of the request is colorized. This makes it easier while monitoring such logs in a terminal. It isn’t perfect and you can modify the regular expression to further foolproof it, but it works well enough for simple differentiation.

We can further adapt this slightly. Here are two more examples using this scheme. The first could filter out your local subnet, while the second filters out a local email client.

tail -f /var/log/lighttpd/access.log | grep -v "192.168.1." | egrep --color=auto '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}' 

tail -f /var/log/lighttpd/access.log | grep -v "Thunderbird" | egrep --color=auto '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}' 

As you can see, the we know pipe the tail to grep with the -v switch which will filter out any line entries that contain the quoted text. You could add anything here such as IP addresses, particular page requests, certain domains, etc.

Quick. Easy. Adaptable.