This isnt your average weblog… more like slightly above average.

System Security

09 5th, 2007

Of all the compromised Linux/Unix systems I’ve come across in my days, I’d say nearly 90% have been converted to IRC bots and added to large bot-nets. What’s sad is this kind of crack is very simple to defend against yet most server admins seem to think they are safe from attack, usually citing the mass effect excuse. You know it, the “No one’s going to crack my system because I don’t have any important information, there are so many other systems out there that are much more lucrative” excuse. Anyone with half a brain can shoot holes right through that statement, hmm lets see, maybe the fact that most of the time they don’t know what the hell you have on your system before they crack it? Or the fact that for bot-net purposes it does not matter what your system does or what it contains, a simple box with Internet access is good enough.

Some History

I’ve been a fairly active member in the IRC community for nearly 10 years now, bots are something I’m very familiar with. Depending on the type of channel, most chanops (channel operators) will leverage the channels resources to lure crackers and script-kiddies into scanning and rooting for them. Usually these resources consist of either music, porn, or other warez (games, applications, movies, etc). The most successful channels operate much like any organized crime institution.

  • Step 1. Lure in naive kids who want to be part of something
  • Step 2. Get them to do all the dirty work and take all the risk, offering respect and goodies
  • Step 3. Profit

I will say, generally, profit consists of access to all the newest warez, movies, etc. On occasion, more will be going on and there will actually be some sort of monetary compensation, usually via renting out the bot-net services to other crackers or shady advertisers/spam merchants.

Anyone who isn’t familiar with how warez works, it all starts with a hacking group breaking some piece of software or media. After that, this is usually the release cycle, i use the term release cycle loosely as its more of a natural progression, not necessarily intentional after the second step.

  • The IRC channel associated with the warez group gets the release first
  • The chanop may or may not repackage it with some sort of trojan/virus/advertising info and make it available for download utilizing their fastest bot-nets
  • The files make their way to warez websites (i.e. warez.com, astalavista.com, etc)
  • Final resting place is torrents and p2p networks

Now, is it possible for a cracked file to hit torrents first and IRC last? Of course it is, there are very few lines and rules for this community and I’m sure they like it that way.

Inspiration

OK, I went off on a tangent, back to the topic at hand. I read this blog post awhile back that inspired me to write this post (yes i know the delay is pretty bad, I’m a busy guy). Read here for the inspiration: Holiday Cracking. Basically this guy runs through detection and cleaning of a bot-net crack on his friends Linux box. He explains how to locate and clean such an issue, but does not go over how to prevent it.

The biggest misconception about being cracked is that its easy to tell when it’s happened. For all intents and purposes most cracks out there are extremely difficult to detect without actually looking for them, the one mentioned in that blog post is a an exception rather then a rule, whoever implemented that crack was either a genius or a moron.

The trick, I’ve found, is to assume your being cracked 24/7 and act like it. You can’t be stealthy and insecure, most people do the equivalent of hiding their car and leaving the doors unlocked assuming no one will find the car. Better safe then sorry, I’d hide my car, turn on my alarm, hook on “The Club”, AND lock the doors.

Prevention

There are a few things any novice sysadmin can do to increase security on his or her server 100 fold. I’ll list them first and talk about each one independently.

  • Change SSH to listen to a non standard port (i.e. 2222 instead of 22)
  • Disallow root login remotely
  • DO NOT use (run) telnetd or insecure ftp servers
  • Install port watching apps and login sentries
  • When logging in remotely (via ssh, sftp, vnc, or any other protocol) be sure of the security of the system your logging in from

Obviously, you must be root on your server to accomplish most of these tasks, if you do not have root access, hope your sysadmin has followed these or similar steps to secure your system.

SSH Ports

This is a biggie, remember i mentioned scanners and rooters earlier. As the name implies, scanners use special applications to scansubnets of ip’s for open ports. It would take forever to scan port 1-65535 for each IP address so they usually just focus on the general use ports i.e. 21, 22, 23, 80, 110, 25, etc. The only systems that end up in the final report are ones with these ports open, depending on what the scanner is trying to accomplish he may just constrain the port check to port 22 and 23 (ssh and telnet) in which case my systems and hopefully yours will be excluded.

On most linux distro’s Open SSH is the ssh daemon of choice, the config file is located at /etc/ssh/sshd_config.

So here’s how you change the listening port:

millenniumfalcon:~# vi /etc/ssh/sshd_config

Look for the Port directive, you should see something like:

Port 22

Change it to read (you can generally replace the port number with anything in the 2000-3000 range safely):

Port 2233

Write and quit the file, if using vi this is ESC+:+wq+RETURN and restart the ssh daemon, depending on the quality of your Internet connection and the speed of your server, it may or may not kick you off your session.

millenniumfalcon:~# service sshd restart
OR
millenniumfalcon:~# /etc/rc.d/init.d/sshd restart
OR
millenniumfalcon:~# /etc/init.d/sshd restart

Hopefully you’ve read this far before doing those steps because there are some things to consider about changing your SSH port. If you’re doing this in a co-located or dedicated server situation, you have to be careful about the firewall or routing setup your provider uses. In some cases, they only forward inbound traffic on set ports and changing your listening ssh port can cause your system to become unreachable and a reboot will not fix it. I recommend before changing anything, you confer with your service provider about their routing setup, make sure they either open the port for you or do not block it to begin with.

Remote Root Login

This is a big no-no. The one thing common to all linux systems: they have a set list of system users, this gives potential crackers a 50% head start on getting into your box, they already know the user name, all they have to do is guess/crack the password. Why make it easy for them? Create your own user, from there you cansu into root or better yet, sudo all root-level commands to keep better logs in the event you mess something up.

To disable root login (into the ssh config file again):

millenniumfalcon:~# vi /etc/ssh/sshd_config

Look for the PermitRootLogin directive:

#Authentication
PermitRootLogin yes

Change it to no, save and quit the file and restart ssh again (see above for instructions on restarting).

Another disclaimer, some dedicated providers’ sysadmins will get very cranky if you disable remote root login, it allows them to stay lazy and not install a kvm-ip solution, or walk up to the box and plug in so you may find it re-enabled later on. If that’s the case, i’d recommend calling up and yelling loudly.

Telnet & FTP

There is no defensible reason to run telnetd on any server, i mean seriously, why would you need unsecured remote access? It’s not just low security, its no security, everything, including your password is transferred in plain text, its no good!

FTP may be a necessary evil in certain occasions, but i almost always require users to connect via secure ftp. The only conceivable reason to use ftp instead of secure ftp is that most ftp servers can use some other form of user management, flat file, xml, database, whereas sftp requires each user to have a real user account on the server with a home directory, etc.

Helpful Apps

There are 2 applications i use to help secure my systems, Fail2Ban and PortSentry. To give you a quick rundown, fail2ban basically watches the error logs for ssh, apache, and any ftp daemons you have running for erroneous login attempts. Based on the configuration, it will allow an ip address a certain number of tries before banning it from connecting to the system, it accomplishes this via iptables. I usually set the config to allow 3 tries before permanently banning the ip. This is somewhat strict and hardcore (as some of my users have put it), i believe the default is to allow 6 tries and ban for 15 minutes. Personally, I believe if someone can’t typetheir password properly after 3 tries they dont need to be on my system anyway. I’ve white listed my ip at work and at home in the event im drunk one night and fat finger the keys in rapid succession not realizing how many tries ive used up. And yes, i have perma-banned myself from my own system before, comes with the territory, never drink and ssh.

Portsentry, on the other hand, helps with keeping your system stealth-ed. It watches for people scanning your ports, if it sees what it thinks is a scanning application, it will not respond to the requests, however, if it is a legitimate connection, it will go through no problem.Portsentry can also be used to ban people trying to scan your system, but i usually just stick with keeping stealth mode on, scan all you want, you get banned if you try tologin.

I’m not going to explain how to install and configure these apps as there is more then enough information on this in the included links above, if you need help however, and can’t find it on their respective websites, e-mail me and ill be happy to lend assistance.

Other Security Precautions

Some thought has to go into every connection you make into your system. You can have the most secure password ever, portsentry and fail2ban installed and configured, ssh changed to a different port and remote root login disabled, but what happens when you connect from your buddy mikes house and his comp just happens to be infected with a key logger giving someone with malicious intent your new secret ssh port and your super awesome password? This is where common sense comes into play. How do you get around using potentially insecure systems to connect to your server? Well, you don’t, truth be told, its very difficult if not impossible to be 100% sure the system your using isn’t infected. The best you can really do is limit the number of systems you connect from. There are some paranoid things you can do to “erase” your tracks, but its neigh impossible to erase them completely, a trained hacker can track you no matter what safety precautions you take.

So basic rules:

  • 1. Do not connect from publicly used computers (i.e. school, library, Internet cafe)
  • 2. When doing file transfers from server to server, try to initiate the connection on your servers’ side so all passwords typed are typed from your (potentially secured) terminal
  • 3. Change your password often, at least once or twice a month, this is the only fool-proof way to stop key-loggers.

Well, that’s about it, there are a million and one things you can do to increase (or decrease) the security of your server, make sure whatever you do, to read all documentation before installing apps, and get all proper updates for your system, nothing is easier to crack then a vanilla linux install.




Flash FTW

08 23rd, 2007

To start off correctly, let me say, my knowledge of all things flash started with flash 4 and ended with flash 6, until recently. When I started off, flash was used for funky cool animations that allowed web designers to sufficiently test the bandwidth and attention span of their visitors. If you detect a hint of contention in my description, your contention detector is working. I’m primarily a server-side programmer/developer/messiah, so I saw no need for this flashy useless waste of time and tube space. Understand it? Yes, but just don’t agree with it, it’s my opinion and is completely founded on my observations of said technology’s developers (and i use the term developer lightly).

Now, fast forward to 2007. I work for one of the premier cutting-edge streaming media/ITV companies in America. When I came on board, naturally I had some preconceived notions of some of the people i would meet and technologies i would encounter. For sure, i knew, these flash developers would be brainless copy-and-paste-from-google coders that I’d come to know and loathe from the dark ages of flash development. Now while i may not always agree with what they have to say, I’ve noticed flash has really come into its own these past few years with the implementation of AS3 and flash 9, not to mention Flex. When i left college, flex builder 1.0 had just been given to my school and we got some time to play with it shortly before i graduated, i was not impressed. At the time, however, i made no connection to flash from flex. They were two completely different entities that did not seem to have anything to do with one another. It wasn’t until recently the wool was pulled from my eyes and i was exposed to the wonderful world that is flex 2.0 and as3, finally a true OOP structure with strong typing and proper data encapsulation. I have Jesse Warden to thank for this, not only is he a top-notch flex developer, he also seems to be the end all, be all of flash and flex history, i never knew anyone paid so much attention to something i had not considered worthy of my time at all.

In the end, I’m glad my preconceptions have been shattered (though those people still exist), i don’t get much time to use flash besides interacting with it via web-services and flash vars, but I’m very interested to see where its going and ill definitely be watching it as it matures further.