So maybe the title of this article is really a bit overkill. Or maybe It’s true. Maybe you should decide….

See, Bruce runs the fancy email newsletter known as “Cryptogram”. It’s actually a very good newsletter, so props to Bruce for that. It’s really just a monthly conglomeration of stories that relate to security, be it software, hardware, social, or otherwise. I have enjoyed the newsletter thoroughly for a while now, so I’m not just complaining about something after my first experience with it.

And congress, well, they seem to run the country. Which is funny, but we’ll get to that later.

Bruce made an interesting claim in his email newsletter a little bit ago – that the Chinese Government was developing some sort of secret and powerful operating system hellbent on attacking the critical computing infrastructure of the United States of America. To be fair, however, he did put this bit of text in quotation marks. Apparently this is not his doing. The backstory seems to follow that a briefing was given to congress not too long ago about this very subject. Apparently it’s called “Kylin”, and as a member of the IT community, we’re supposed to fear it.

Well lo and behold, the other day at work, I was setting up a snort Intrusion Detection System, and what did I see? Some very weird packets bouncing to-and-fro around the network. I mean _weird_ packets. Combinations of SYN/ACK/RST/FIN flags, sometimes there was an URG/PSH flag set just to throw off any sensors that might be listening. Fortunately, I log ALL packets to pcap data files, so I fired up tcpdump and extracted the relevant data. Insert this data into wireshark for some nice analysis, and the weirdest patterns were showing up. Scans like I really have not seen ever, but ones that make logical sense. Some ACK packets were being sent across the wire in the hopes to solicit an RST packet from a listening port. There were just strange packets everywhere, highly anomalous packets, some were even SYN/ACK/FIN packets. Not quite a christmas tree, but something that will never occur in nature. So I did what I could, and traced the packets back to their source. The funny thing was, they were bouncing all around the world. Africa, Asia, South America — nearly every country was seemingly scanning the network. And as quick as it started, it was over. I realized what was going on… A massive distributed reconnaissance mission just took place on our network. Combinations of weird packets and different sources all came together in harmony to do a full 65536-port scan on the network, and almost all without sending off a single alert from snort. Properly collated, this raw data could be put into a map of every open service on the network, and if it weren’t for a single seemingly benign alert, I would have not even known something just happened. The most chilling thing is, the possibility certainly exists that this has happened before and will happen again, but I just happened to be lucky enough to catch it this time as it happened.

I needed a lead. This was too strange. So I started analysing the packets that were sent across the wire. The ICMP packets looked very familiar, and upon further investigation, I noticed that these ICMP packets were somewhat verbatim from the FreeBSD kernel. The actual data portion of the packets vary from OS to OS… don’t believe me, then look it up! Suddenly I noticed that some packets were coming from China. I don’t know why I noticed this, but it just seemed like a pertinent detail. I think it was my subconscious telling me exactly what I feared – I was facing this “new and secret” Chinese operating system. I google’d “Kylin” and, rather unsurprisingly, the first page of results were all the same fear-mongering based on the briefing that was given to congress. But what if I changed the search a little bit maybe someone has seen this before? In this light, I google’d “Kylin FreeBSD”.

WELL WHAT HAVE WE HERE?

Kylin is not some secret Chinese government project to destroy America. It’s not even a secret. It’s a state-sponsored project to secure a common open source product. It’s absolutely no different than the US NSA’s SELinux. For crying out loud, YOU CAN DOWNLOAD THE ISO’S! It’s almost disappointing – I was secretly hoping deep down inside that I was the first person to encounter Kylin’s doings first-hand. Not so much. So I gave Bruce’s newsletter a once-over again. Looks like I was wrong all along, Bruce didn’t believe it either. He even made the conjecture that it was just over-hyped nonsense. But why even write about it as if it COULD be legit if a simple google search shows it’s all just overhyped garbage reporting? Like I said, Bruce needs to learn to use the Interwebs a little better!

And as for congress, well, they do too. I’m tired of the fear-mongerting that occurs so very, very often. I’m tired of the irresponsibility of it all. What does it accomplish? Maybe it pushes your own agenda a little faster? Why not do the right thing and report the facts, then maybe we can have some time to plan things out and do it right the first time. I’m all for a national Cybersecurity initiative, in both the public and private sectors. It’s truly a great thing that this is happening. I would just really hate to see it all go as wasted effort because proper time and resources were not allocated ahead to keep the project alive. Perhaps I’m just an idealist this way, but it’s the only way that (IMHO) works.

Now, in the light of sharing and freedom, here’s the Kylin ISO’s. Use responsibly, and above all else, use them to learn! This is no different than SELinux, and maybe the Chinese government will continue to sponsor open source projects like this, something from which we surely can ALL benefit. And don’t believe everything you read, I know I’ve learned my lesson this time around…

And as for the scans I was seeing? Who knows, it could have been one person all along, or it could have just been coincidence. It’s really hard to say, but that’s the nature of the beast we call the Internet. Surely, nothing that was done is out of the reach of some clever SSH’ing and NMapping. If there’s more to the story, I’ll make an update. But for now, I’m content with the facts that I have, no more, no less.

DOWNLOAD LINKS:
DISC ONE: [KYLIN-2.1-1A.iso]
DISC TWO: [KYLIN-2.1-1B.iso]
MD5SUMS: [KYLIN-checksum-2.1-1.md5]

Server is now running much faster, if you can’t already tell. The images may still kinda load slow, but that’s not necessarily the fault of the machine! The upgrade actually went as planned, just plugged in the network and power cables, powered her on, and it all worked first shot. On second thought, nothing ever works perfectly like that the very first time, so please contact me if anything strange is found on this server. Let’s hope all is well with it, though!

It’s now pushing 3 GHz with a good hunk of RAM and the newest version of my favorite Linux distribution.

Look for some good blog articles coming soon. 🙂

Ok so the server this website sits on? It’s terrible. 550 MHz. I think 384 Megs of RAM. It’s time for an upgrade, to say the least!

That’s why shortly a new server will be taking this one’s place. A much better server, without such things as a slow processor…

Anyway, expect some downtime this weekend (if you actually follow this blog) so that the server can be replaced.

I have a lot of good ideas for blog entries to write, but I’m really sick and tired of this site taking literally minutes to load.

See you soon!

Okay so as part of being a Linux sysadmin, I’ve run into the need to rebuild a software RAID (mdadm) array. This process usually takes forever, and in an effort to make sure it won’t take any longer than necessary, I usually leave the volume in question unmounted during the resync/reshape. I know, I know, you can read/write to an array during the process safely, otherwise anaconda (the most superior Linux installer) wouldn’t be able to move forward with the install for a long while. But I still like the reshape to go faster. I’d rather not use the system for an hour and have it be perfectly fast afterwards than have the machine crawl along all day.

Long-winded ideals speech beside, I want to monitor how long the rebuild is going to take in quasi-realtime. Details of the software raid can be found in the file /proc/mdstat. You can cat this file once in a while to see the progress. But that wasn’t ever good enough, too much of that whole keyboard-button-pushing thing in order to get the statistics to update. So I would usually type this in real quick:

while [ 1 ]; do clear; cat /proc/mdstat ; sleep 1; done

It’s just a simple loop that keeps the information fresh on the screen. Well boy did I just find out something today that helps greatly with that dilemma. Enter the Linux “watch” command, courtesy of the procps package. The watch command automatically updates the information on the screen in the command that follows the binary on the shell. For example, the command:

watch cat /proc/mdstat

will update the file exactly like the loop does. But watch does it even better, as it prints a clock in the corner and lets you know how often it is updating. Plus, watch doesn’t make the screen flicker for a millisecond like the shell clear does. The default delay in updating is 2.0 seconds, but you can change that easily via the -n flag. For example, to update every second, as in the custom loop above, try the command:

watch -n 1 cat /proc/mdstat

and be amazed. It would seem at first glance that the delay can be set as low as 0.1 seconds. Pretty neat. It’s an interesting tool, and certainly one that is very useful for these sorts of things. Check out the man page for more information on the command.

Quick tip. You’re working on setting up a server late at night. It’s dark out. Your roommate is sleeping. And every time you push the damn tab button, the computer makes a beeping sound. WHAT THE HELL?!

Silence the PC Speaker with “rmmod pcspkr”. Make it loud again with “modprobe pcspkr”.

Your roommate will thank me for this… whether he/she knows it or not 😀