Wednesday, January 30, 2008

My own RBL

Today I was trying to figure out how to block spammers' IPs from using my smtp servers. Regardless of your point of view on IP blocking I figure this was an interesting exercise so I'm posting what I found and how I went about finding it.

Exchange 2007 has this functionality where it can check an RBL (I'm not going to spell it out because people can't agree on what it means) before sending a message. The idea is that Exchange knows where the email is coming from (the IP that connected to Exchange's SMTP server) and can basically pass that by a list before accepting the message to see if the IP looks like a "known spammer". This gets all-kinds-of-fun because people who run mail servers for a living have all had an experience where one of their servers is flagged as a "known spammer" and they have to jump through hoops to get their server's IP off someone's list. The lists usually update frequently (if you're not reported to a list within 24 hours your IP usually drops off the list) so a lot of people (and a lot of people's anti-spam programs/boxes) rely on these to cut down on spam.

I thought, as someone who is rather against this practice having had servers I have run be listed on an RBL before, I would rather only block the IPs *I* choose to block and for the amount of time *I* choose to block them. I figured I would search for a program (Microsoft usually supplies me with these type of things) that would set up a list for me that my mail servers could query and I would call it a day. I was surprised when I found vague links to Microsoft Antigen, Exchange itself and Microsoft Forefront. Antigen, as far as I can tell has been absorbed into Forefront in its current iteration and neither Exchange nor Forefront are what I would call "easy" to setup and configure correctly, at least not as easy as I was imagining this project. So I googled my problem and found a nifty little linux app named rbldns. I would've just slapped that on a linux test box but none were handy so I read about it instead. Turns out this program is just a lightweight DNS server...interesting.

So after much thought and a few more specific google searches I figured out what an RBL list really is! What is an RBL list really? It's a DNS server, but it's a very specifically formatted DNS zone that gets you what you want. Here's the meat and potatoes to get you going:

There's an address for the DNS server of the RBL list, that's just the DNS name of your, well, DNS server.

There's a DNS suffix. This is the zone you create your RBL records in. So if my domain were josh.com, hosting www.josh.com, etc. I would create a zone on my DNS server and call it "rbl.josh.com", this is the DNS suffix.

You may see where I'm going with this by now. Your email server queries your RBL server (read: DNS) before accepting a message to see whether the IP connecting to your mail server is there. If it is, the mail server says, sorry, with an error message that's normally configurable but should basically say, "you're a known spammer, if you disagree, contact me here".

Here's the trick. Say I know that 10.20.0.5 is a known spammer and I want to put them on my "RBL", I put it in quotes here because it's more just a "BL" that I manually update, but that's neither here nor there. I go to my dns server to my "rbl.josh.com" zone from before and create the A record (forward lookup) "5.0.20.10.rbl.josh.com" and point it at "127.0.0.1". This is because when a mail server queries an RBL list for an IP, it queries for the IP octets in reverse order followed by the DNS suffix. If it finds that in the RBL list pointing to 127.0.0.1 (or really anything non-routable in theory), then it drops messages from that sender. If it doesn't, it allows the sender to continue the session with the smtp server and send their message on its merry way.

Anyway, this probably isn't so exciting for most folks but I found it interesting and if you need to block specific IPs, this is a really cheap way to do it. It's also really efficient if you have multiple servers that all should have the same block list and you don't trust the big RBL names. If you need me to clarify anything please post a response and I'll do my best to get back to you. I hope this helps those of you in the situation I was in. Oh yeah, one more thing, if you want to block, say the whole class C in the above example, just create the record for "*.0.20.10.rbl.josh.com" and point it to "127.0.0.1". Good luck and happy list-keeping!

Friday, November 16, 2007

New Look

So I'm done with MCSE: Messaging exams and I figured it was time for a cleaner looking blog. I hope everyone likes the changes. I'll be posting about migrating my file servers from DFS to DFSr in the next few weeks. Stay tuned...

Tuesday, August 7, 2007

Microsoft Office SharePoint Server 2007

Setting up SharePoint Server 2007 with remote-SQL isn't exactly easy. I found a web page that has a step-by-step here. You should begin this process from a fresh install of Windows Server as SharePoint tends to take over IIS. Make sure you run the install of SharePoint when logged-in as your SharePoint Administrative account. Double-check everything as you do it. It's really difficult to uninstall and re-install this product.

One last thing before we start, if you're installing SharePoint on one box and have no intention of using remote SQL or a server farm (multiple servers), just go ahead and run through the install like you would with a Microsoft Word, that is, "next, next next," it basically sets itself up.

Below are my comments that you should reference while going through the directions on the page linked above.

Prerequisites:
-Don't worry about Microsoft Windows Workflow Foundation Runtime, I think this was just for the Beta.

Post-Install:
-Create the Shared Services Provider (5) - Change "Description" to "SharePoint Services" and "Port" to "4000"
-Create the Shared Services Provider (9) - Change "Application pool name" to "SharePoint Services"
-You probably don't need to start the Windows SharePoint Services Web Application service as it's probably already started if it needs to be.

Wednesday, July 25, 2007

Windows Server Update Services (WSUS) 3.0

I know it's been almost two months, no excuses, let's get down to business with WSUS 3, the free tool to manage Microsoft Updates to Windows machines on a network. WSUS 3 requires MS SQL 2005 in one flavor or another and I wanted to use the full version (not Express, which is free here) to simplify backups since I use a dedicated SQL server. As such I had to make the upgrade from SQL 2000 to 2005 on that box, more about that in a later blog entry.

Any System Administrator that has to maintain more than 2 Windows servers or workstations who is not using WSUS, this blog entry is for you -- I'm about to make your life easier. If you're using WSUS 2.0 already, upgrading shouldn't be too hard, but that's not the subject of this blog entry -- take a look here *before* you upgrade. One more warning, it's going to be significantly harder to do this if you don't have an Active Directory infrastructure in place.

The install for this product is pretty easy (those who used WSUS 2.0 know what I mean). Make sure you install the prerequisites on the download page (IIS, .NET) and hold onto the Microsoft Report Viewer installer for your administrative workstation. After that you double-click the WSUS installer executable and almost the entire process is self-explanatory. I'll go through the post-install details that I didn't think were completely obvious rather than giving a step by step of "Next>", "Next>" etc. The only two installation details I can think of here are 1) make sure to use the WSUS dedicated site and 2) if you use a standalone sql server and are using the default instance to host your databases, you only need to put in the name of the sql server (as opposed to sql server\instance name).

You *need* to do a few things after running the installer. First you need to either issue or obtain a SSL certificate for the IIS server you are hosting WSUS on. Then you need to attach that SSL certificate to the two Web Sites that WSUS uses. That's right, it uses both the "Default Web Site" and the "WSUS Administration" website. Next, require SSL in the following places (*NOT* at the Web Sites themselves, just the sub directories):
-Default Website
-Selfupdate
-ClientWebService
-WSUS Administration
-ApiRemoting30
-ClientWebService
-DssAuthWebService
-ServerSyncWebService
-SimpleAuthWebService
The above settings (which are more or less the SSL directories defined by Microsoft) imply that you need to open ports 8530, 8531 and 443 (all TCP - it's web traffic) on your firewall to any machines that you want to update with WSUS.