network diagnostic using mtr

There is a few ways to diagnose network problem, and tools like ping, and traceroute, are indispensable for the task.

Here’s another tools that, is useful. mtr. mtr can be seen as a combination of ping and traceroute. When started it runs as a ncurses program. And what make it interesting is that, it shows the result, live. To me it’s interesting. There is 2 version in the ubuntu repository, one is mtr, another is mtr-tiny. The version I use, is mtr-tiny, which do not have x11 support. to install it on ubuntu, is a matter of
sudo apt-get install mtr or sudo apt-get install mtr-tiny

To run in is a matter of

mtr destination(could be address or URL)

or to leave ncurses, useful if you want to redirect the output to a file.

mtr -r destination

or to run on certain cycle

mtr -c 10 destination

or you can combine it

mtr -c 10 -r destination

SSH Tunneling Made Easy

Using OpenSSH on a Linux/Unix system you can tunnel all of the traffic from your local box to a remote box that you have an account on.

For example I tunnel all of my outbound E-mail traffic back to my personal server to avoid having to change SMTP servers, use SMTP-AUTH, etc. when I am behind firewalls. I find that hotel firewalls, wireless access points, and the other various NATing devices you end up behind while traveling often do not play nice.

To do this I use the following:

ssh -f user@personal-server.com -L 2000:personal-server.com:25 -N

The -f tells ssh to go into the background just before it executes the command. This is followed by the username and server you are logging into. The -L 2000:personal-server.com:25 is in the form of -L local-port:host:remote-port. Finally the -N instructs OpenSSH to not execute a command on the remote system.

This essentially forwards the local port 2000 to port 25 on personal-server.com over, with nice benefit of being encrypted. I then simply point my E-mail client to use localhost:2000 as the SMTP server and we’re off to the races.

Another useful feature of port forwarding is for getting around pesky firewall restrictions. For example, a firewall I was behind recently did not allow outbound Jabber protocol traffic to talk.google.com. With this command:

ssh -f -L 3000:talk.google.com:5222 home -N

I was able to send my Google Talk traffic encrypted through the firewall back to my server at home and then out to Google. All I had to do was reconfigure my Jabber client to use localhost as the server and the port 3000 that I had configured.

Linux Security Hole Goes Back Eight Years

Here’s another deep chink in the armor of the braindead zealots who claim Linux is inherently more secure than Windows. Julien Tinnes and Tavis Ormandy have found what could be the widest ranging vulnerability yet discovered in the Linux kernel.

Affected versions include all Linux 2.4 and2.6 versions since May 2001. This spans 2.4.4 up to and including 2.4.37.4 in the 2.4 kernel and every iteration of 2.6 from 2.6.0 up to and including 2.6.30.4.

What is this vulnerability all about? Functions in certain kernel routines are left uninitialized, so pointers aren’t validated before dereferencing. This allows local execution of code (sample POC available in both articles linked above) which compromises the machine. Compromise? Yes, pwnt.

These are known affected modules according to Redhat’s bugzilla:
ipx.ko
irda.ko
x25.ko
ax25.ko
bluetooth.ko
sctp.ko
pppoe.ko
pppox.ko
appletalk.ko

That thread offers mitigation possibilities (and some commenters — see #32 and #48 — explain why those steps won’t work). According to post #27 in that thread, the exploit is already being used (as of about a week ago as I write this) to attack machines: “They entered the system through a web application exploit and then used the exploit to gain a root shell.”

This gets to the bigger problems of security. If you think of Linux as only the kernel or even the kernel plus the utilities that make it a functioning operating system, you’re seeing only one layer of vulnerability. Add another layer of complexity with various software and you’re adding more complexity and, accordingly exponentially more layers of vulnerability. If someone can get in through one door, he can often find “keys” to open other doors. That in a nutshell is what happens in cases like #27 in the Redhat bugzilla thread.

Fedora, Debian, and Ubuntu have reportedly already patched for this kernel issue.