Berkeley in Kernel Land (part 2)

I've done a lot of work this week! Who needs classes when you can write operating systems?!?! This week I have,

• Written code to run flat binaries from a filesystem
• Got a few basic syscalls working (write() and exit() so far).  write() only outputs to stdout, which is currently always directly to the screen.
• Made my first live-cds and booted real computers!
• Written a scheduler!!

The scheduler is really the biggest step forward here.  I still have some kinks to work out; my first design worked robustly but lacked the flexibility for me to fully implement sleep, waits, etc.  To improve it I mostly needed to reorganize code -- but after refactoring, it lost some stability.  It seems to work find in the bochs vm and on real hardware but the first sign of trouble was qemu-kvm having problems.  After disabling kvm, qemu did okay for a while.  Now qemu is having issues.  I think I need to go back through my subversion history and figure out when everything went wrong...

Although it's really temping to jump ahead, I want to get this scheduler working cleanly on each of my test platforms before I continue.  I'm really excited to implement VFS and many more syscalls to get newlib working -- but it looks like that will have to hold for a while.

Berkeley in Kernel Land (part 1)

Last Wednesday I decided that I wanted to learn more about operating systems. Sure, I've taken UCSB's operating systems class (and done well in it), but operating systems are so huge and daunting that I felt more was necessary.

So I decided to write one. The goal is to build an operating system that works at some basic level; right now I don't have any further objectives. Ideas have crossed my mind, such as building a system that has a little extra support for stage lighting technology (like DMX-512) among other things. Stage lighting is another hobby of mine.

The OS Dev wiki has been an invaluable source of information! It provides the guidance needed for an experienced programmer with a computer science background to start working on an OS.

So far I've done the following:

• Setup GRUB as a bootloader
• a simple page allocator
• Wrote drivers for vga output, keyboard input, the PIT (programmable timer), the serial port and a dummy ramdisk (which disguises a memory mapped image as a hard drive).
• Wrote filesystem support for FAT-32
• Just last night I built a simple shell that you can use to browse a FAT-32 filesystem

Here are some next steps going forward:

• I need a virtual file system to abstract-away the details of FAT-32
• Code to execute user space programs (for now, just flat binaries -- but in the future I'll use ELF).
  
• A scheduler


• a fancier memory allocator


• Port a C library (perhaps newlib?)


• Port GNU core utils


• More drivers: including ACPI, cdrom, networking, and hard disk


• More filesystems: FAT-16 (easy), ext2/3/4 (harder), others?

Long term, I'm thinking about using modules to replace most drivers and filesystems. Unlike modern linux distributions, my goal is to minimize dynamic module loading and compile as little as possible into the kernel. Hopefully extra needed modules can be loaded from a static list on boot. I'd like to stick to a system that's quite a bit meaner-and-leaner than linux, even if it lacks many capabilities.

Right now GUI is off the radar, but it might be a possibility if I really have time...

That's all for now, but I'm going to try to post updates weekly. By the way, I'm still working on a name for this thing...

Under Attack!!

My roommate had a server running in our living room for a few months now.  I became skeptical about how much it was actually being used, so I decided to check out the /var/log/auth.log file and count logins.  After filtering out all the cron jobs, I immediately noticed a few suspicious lines:

    May  2 18:56:29 Mc-server sshd[27075]: Invalid user angela from 58.30.236.115
    May  2 18:56:29 Mc-server sshd[27075]: pam_unix(sshd:auth): check pass; user unknown
    May  2 18:56:29 Mc-server sshd[27075]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.30.236.115
    May  2 18:56:30 Mc-server sshd[27075]: Failed password for invalid user angela from 58.30.236.115 port 58943 ssh2

Ok, um, I don't know of any Angelas who live in my house.  Sketchy.  I ran GeoIP on the IP address, and guess what?  It's Chinese!  Unless my roommate has more international connections than I suspected, this is quite unusual.


    grep /var/log/auth.log 58.30.236.115 | wc

       3807   52210  440164


Huh.  Now we're talking about a small password cracking attempt.  It turns out that we actually were attacked four times within a 24-hour period.  Our logs only date back two days (they were cluttered with CRON entries), so we really don't know what happened before that.


Attack 1
06:16:01 to 06:34:42
From 119.161.145.206
20 attacks against 'root'
212 attacks against other accounts

Attack 2
09:09:26 to 09:10:25
From 125.208.5.78
11 attacks against 'root'
4 attacks against other accounts

Attack 3
17:10:09 to 18:56:30
From 58.30.236.115
576 attacks against 'root'
900 attacks against other accounts

Attack 4
22:49:55
from 125.88.105.43
A single attack without a valid authentication string.  Perhaps trying to exploit some old vulnerability?


SUMMARY:
* A total of 1703 attempted logins
* 607 attempts made against 'root'
* 166 attempts made against 'admin'
* The other 930 attacks were made against 531 usernames that appear to have been chosen from English dictionaries
* They never correctly guessed an active username on the system (other than root and some common system names).

Just for good measure, in the end we brought the system offline and checked for any malware/rootkits.  To no surprise, nothing suspicious was found.

So why did this happen to us?  When the SSH server was setup it was put on the default port 22.  This is just asking for trouble.  Never ever do this.  While we do not believe the system was ever compromised its just an invitation for problems.

What else do you learn from this?  (#1) By default there is no notification system to warn you of suspicious activity.  A cron job would be an easy fix.  (#2) Never give default system accounts (especially "root") SSH access.  This is the biggest target.  (#3) Don't use port 22, or other common service ports, if practical.



Of course, there are far more things you can do to protect your SSH servers. These suggestions really only graze the surface and should get you started on a better configuration for your servers.