MagicalTux in Japan

Geekness brought me to Japan!

Archive for March, 2009

IRC, and 90 days to Japan

Mar 20

Posted by MagicalTux in Uncategorized | 2 Comments

As of today, it’s exactly 90 days before I get in Japan. Exciting, but before anything it’s tiring. Still a lot of things need to be done (stopping contracts, selling stuff, finding a way to send the stuff I keep to Japan, etc) and it’s not going to get easier as the date gets close.

Anyway I’ll also introduce a little too I made for the IRC Network: a status image. You just use http://gg.st/status/default/nickname.png in an image and get something nice like:

As you can probably see, it says if I’m online/away/offline, handles nickname groups (with IRC services) and is realtime.

Tags: ,

Leaving France

Mar 9

Posted by MagicalTux in IRL | 3 Comments

Many people around me knew about it. I want to leave France, and I want to leave quickly.

I got various reasons, including the fact that I can’t stay in place, and the fact that the move was interesting.

No final decision was taken before March 6th as I was waiting for a reply (which never came), so the final decision is now taken: I’m moving to Japan.

The deal is pretty simple, the company I work for (Nexway) has agreed on taking me in Japan instead of France. This will greatly help for some projects I’m working on within the company, both in terms of access to documentation/skilled people and in terms of motivation.

The move is planned for June 17th (arriving in Japan next day) and will include my cat, my hard drives (no computer as it’s too big/heavy), and many things.

Tags: , ,

Port knocking, how would I do?

Mar 2

Posted by MagicalTux in Hacking | 1 Comment

As I saw some articles which seems rather unexact relating port knocking, I would like to add some parts of my own idea about this.

First, port knocking is not meant to be used alone…

Even if you use your daemon’s default port (let’s say port 22 for sshd), port knocking can protect you more than you can even imagine. Let’s take the following setup:

  • SSHd running on port 65122
  • Connections to port 65122 are replied with “connection refused” (via an icmp target rule)
  • In order to “open” port 65122, connection attempts must be made to ports 22448, 44228 and 22884 in this order. Any other order will blacklist the IP attempting to connect for 1 hour
  • More than 5 attempts to connect to port 65122 within 20 minutes will result in 1 hour blacklist

Now, if you’re that smart, just try to find your way in without the “passphrase” (which is 22448-44228-22884-65122). If you do too many attempts, you’ll end blacklisted. Let’s say you found out that port 65122 gets you banned when you connect, and have determined that you can make up to 5 attempts in 20 minutes. Let’s also say you know you have to knock exactly 3 ports to be able to connect.
You then have to test 65536^3 = 281474976710656 combinations, and can only test 5 in 20 minutes, that would require 70368744177660 minutes (133882694 years or so).

I can assume no decent system will be up for 133882694 years without any shift into security settings. You can parallelize that with different source IPs, but it will still last too long against people shifting every 3~6 months.

Tags: , ,

The Y2038 bug

Mar 1

Posted by MagicalTux in Uncategorized | No Comments

For those who already played with timestamps, you know that they are limited to whatever you set your time_t type to.

On most 32bits systems, timestamps are limited to 2^31 because time_t is signed (to allow dates before January 1st 1970). This means that you cannot go after a certain date.. which is:
2038-01-19 04:14:07.

I studied a lot this potential problem, the Y2038 problem. It won’t happen just on year 2038, but 19 days later… however some systems are already affected.

I’ll take as an example the case of Orange France, a mobile operator (also ISP and a lot of other things).

Timestamp on orange website

This website claims I have a “multimedia option” available until… January 19th 2038. This looks a lot like Y2038-Bug. The point there is not to have everyone run everywhere because we’re going to run out of timestamps. Nope. Most “recent” UNIX systems now use 64bit signed integers for time_t, meaning this can go for a long long time (I can represent dates in year 35,680,317 without problem). It’s just a matter of stressing people that 32bits is dead, and it’s already time to switch to 64bits if you didn’t yet, because this kind of bug will happen more and more.

Another example would be domain names. You are allowed to renew a domain for up to 10 years. This means that people providing domain names will have to support 64bits integer on January 19th 2028, which is less than 20 years from now. Don’t laugh, it’s going to happen before you even notice it, and we’ll start seeing people’s domain becoming “expired” because they renewed over year 2038.

All my servers are 100% 64bits, and I hope most people will switch to 64bits on servers (if not already done).

Tags: , ,