Blog

When you think of your production servers, you need to imagine them as your car sporting a new stereo in a parking lot with a bunch of would-be burglars milling around outside constantly checking each window and door to make sure you locked it tightly the last time you had it open. Every door, window, or keyless entry system is a potential point of invasion that can fail you. Why do you think those brinks trucks have no windows and the only way in the back is a single, beefy, padlocked door. A Brinks truck may not be convenient to access, but that isn't their goal. You need to control the ways into your server with the same gusto.

This is a really cool feature of ColdFusion 8 that I had totally missed but I stumbled across an article on Ray Camden's blog today. (Thanks Ray!) Basically, you can modify your ColdFusion Administrator menus to include custom tools of your own choosing. Several pre-built ones out there including SpoolMail, a nifty util to re-copy your undeliverable mail back into the spool folder; and Cache Clearer, an easy way to clear out specific folders of trusted cache.

I went to add a custom tag path onto my dev server this morning. Feeling a little lazy and not wanting to type in the full path by hand, I clicked the "Browse Server" button. There are similar buttons for adding ColdFusion mappings and searching for file-based databases while adding data sources. The Browse Server page uses an applet to let you choose directories or files off your server. I was greeted with an error message:
Server Error
IO error on server communication

I feel like a dork. I posted a tip last night on remotely managing services on your Windows servers. I wondered why it didn't get many hits, and I finally realized tonight that an inadvertent change in my server's time this morning effectively unpublished the post so no one could get to it. Doh. You can read it here now: http://www.codersrevolution.com/index.cfm/2009/2/11/View-ServicesManage-Your-Servers-Without-Ever-Remoting-In

If you are using Windows, chances are you find yourself remoting into one server or another on a regular basis to start and stop services or to take a gander at the event logs to figure out why the box mysteriously rebooted the other day at 2 am. You may not realize it, but you can access anything in the Computer Management console for your servers without ever remoting into them. This includes, users/groups, IIS, SQL Server, and device manager.

I am not just a programmer, but to some extent a sys admin. Because of that responsibility (and the fact I have had servers compromised before) I am always interested in security. I think to stop crackers; you've got to think like them. When was the last time you tried to hack into your own server? If you don't know what your vulnerabilities are, how can you close them?

If you are using MS SQL Server and ever want to just obliterate your transaction log, you can use the following SQL (where your database name is "foo"): BACKUP LOG foo WITH TRUNCATE_ONLY DBCC SHRINKFILE(foo_log,2) Don't ever do this to a database you care about like, say, production. I wanted this because I am screwing around creating rainbow tables of SHA-1 hashes. The Cartesian product of joining a table to itself on 1=1 is very handy for producing all possible combinations of a set of characters. Inserting a few million records can put a lot of crap in your transaction log though.

It has been mentioned in several places that MySQL 5.0.1 has a NO_BACKSLASH_ESCAPES mode it can be run in to prevent backslashes from being an escape character. Thanks to Azadi Saryev for pointing it out on my blog and Mark Krugers as well. Jake Munson even posted instructions for applying the setting to your SQL server at startup. For the record, you can also use this setting on a specific data source.

Well, after a brief hiatus, the SQL Injection attacks have reconvened with a small change. They have modified the capitalization of a couple words in the URL. "DECLARE" has become "DeCLARE", and "EXEC" has become "ExEC". This is obviously to get around people who employed case-sensitive filtering mechanisms.

So as the SQL injection attacks have rained down on my server for the past few days, my logs have been steadily filling up with data about the requests. Frankly, the data probably can't be trusted, it's all totally un-scientific, and doesn't really lead me any closer to the people responsible for the attacks. Regardless, I think it's pretty interesting. I've compiled some graphs and stats here.