Microsoft – get your error checking act together

So the world is in a disarray, thanks to you Microsoft and your never ending buffer overflow vulnerabilities. Makes you wonder why you cannot write good tools to test for this internally, with 100% coverage. Surely it can’t be an impossible task.

Nevertheless, why do you insist on having cryptic error messages, for things that are not even an error in Windows or MS Office? Let’s take the example of Powerpoint.

For the past few weeks, I’ve been getting this error everytime I open some .pptx file. “Powerpoint found a problem with the content blah blah. Click to repair…”.


Now it doesn’t repair when I tell it to (because turns out there’s nothing to repair).


The problem was finally traced to incompatible security settings for downloaded files. If you have downloaded a MS Office file, it is automatically set to “unsafe” by Windows explorer, and hence blocked from being opened. You have to manually unblock it.


Well now Microsoft – you have written Windows and MS Office – can you not detect this and give the relevant message. Better yet, give the option with Powerpoint itself to unblock? Why should your customers have to jump through so many hoops for something so simple? Make no mistake – giving an incorrect error message is a “bug”, nothing less.

My 🐈 Spotty could do better debugging than you, Microsoft.

Securing secure-shell server


A follow-up to my earlier post about securing access to your RPi. (fail2ban-lifesaver). Some amount of security can indeed be obtained through obscurity. One way to do this is to change the default port # for the ssh server. Since most hackers will try to attack port 22 first, it’ll take some time to reach the obscure port number set by you on your RPi. Yes port scanning will eventually find it, but hey, why not delay the attack 🙂

#Port 22
Port 16022

Read up about how to change the default ssh server port here (its really quite simple): Change default ssh port.

Also remember to change it in the fail2ban config file.

#port = ssh
port = 16022

Further security measures like public key, port knocking: Harden the ssh server.

I also used iptables to block a whole range of IP addresses, from which hackers are trying to attack my RPi. This is how you do it: Block a range of IP addresses.

sudo iptables -I INPUT -s -j DROP

fail2ban – lifesaver!

borrowed from Gizmodo

Hacking attempts and DDoS attacks are commonplace. In fact, its been just a week since I setup my RPi as an always-on device, with sshd service running. Today, I opened up the authentication logs and found 100s of login failures over ssh, all coming from China. I installed fail2ban which seamlessly takes care of banning clients with repeated login failures. It is easily configurable via a simple config file.

The attacks seems to be from a Linux Malware called XOR.DDoS (details here: XOR.DDoS)

These are the IP addresses seen attacking my RPi:


(The number in the first column denotes the number of times the client has tried to connect and failed).

These are the messages in the auth.log:


Using ip2location, I traced them to:


Seriously! What are you trying to get from my RPi! Stop or I’ll have to send my attack cat to get you!


borrowed from rore@flickr

Everyone must install fail2ban (or equivalent) firewall programs for the always-on connected embedded devices like the RPi!