That goes on for about eternity to the tune of about 11 or 12 times a second. Maybe putting that port 1433 pinhole in the firewall wasn't a hot idea. Duh.
And some info on my attacker:
C:\Share\Backups\GRETCHEN\Data\DB\SQL2K5>tracert 71.170.25.99
Tracing route to static-71-170-25-99.dllstx.fios.verizon.net [71.170.25.99]
over a maximum of 30 hops:
1 * * 1 ms 192.168.10.2
2 12 ms 11 ms 12 ms bras1-l0.mrdnct.snet.net [204.60.4.34]
3 10 ms 10 ms 9 ms dist1-vlan60.mrdnct.sbcglobal.net [66.159.184.226]
4 9 ms 9 ms 10 ms bb1-10g2-0.mrdnct.sbcglobal.net [151.164.92.147]
5 13 ms 13 ms 13 ms bb1-p8-0.nycmny.sbcglobal.net [151.164.92.162]
6 17 ms 209 ms 218 ms ex2-p8-0.eqnwnj.sbcglobal.net [151.164.41.246]
7 14 ms 13 ms 12 ms 70.245.63.206
8 13 ms 13 ms 13 ms asn3491.eqsjca.sbcglobal.net [151.164.249.38]
9 14 ms 13 ms 13 ms so-7-1-0-0.BB-RTR1.NWRK.verizon-gni.net [130.81.17.156]
10 18 ms 18 ms 27 ms so-7-3-0-0.BB-RTR1.PHIL.verizon-gni.net [130.81.19.56]
11 22 ms 22 ms 21 ms 130.81.19.118
12 41 ms 40 ms 40 ms so-7-1-0-0.BB-RTR2.ATL01.verizon-gni.net [130.81.19.35]
13 68 ms 68 ms 67 ms so-7-3-0-0.BB-RTR2.DFW01.verizon-gni.net [130.81.19.20]
14 68 ms 68 ms 68 ms P11-0.LCR-02.DLLSTX.verizon-gni.net [130.81.29.179]
15 68 ms 68 ms 68 ms P12-0.LCR-04.DLLSTX.verizon-gni.net [130.81.27.205]
16 70 ms 69 ms 69 ms P1-0.VFTTP-09.DLLSTX.verizon-gni.net [130.81.48.123]
17 70 ms 72 ms 70 ms static-71-170-25-99.dllstx.fios.verizon.net [71.170.25.99]
Trace complete.
C:\Share\Backups\GRETCHEN\Data\DB\SQL2K5>ping 71.170.25.99
Pinging 71.170.25.99 with 32 bytes of data:
Reply from 71.170.25.99: bytes=32 time=74ms TTL=121
Reply from 71.170.25.99: bytes=32 time=71ms TTL=121
Reply from 71.170.25.99: bytes=32 time=70ms TTL=121
Reply from 71.170.25.99: bytes=32 time=70ms TTL=121
Ping statistics for 71.170.25.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 74ms, Average = 71ms
In times past I may have aimed a few servers on different T1 connections to call down the thunder on these folks, but everybody has a broadband connection these days.
Labels: sysadmin
With the release of the iPhone Apple has magnanimously decided to prep your computer for using an iPhone (because they know we all are going to cave in and buy one) if you are an iTunes user. I noticed this extra little service running in
Process Explorer 1 recently after an iTunes upgrade. Thanks Apple!
Fortunately this can be disabled through your Services control panel -- Start -> Control Panel -> Administrative Tools -> Services. It's called "Apple Mobile Device." Set it to disabled or manual and you're all set.
[1] Go, download and replace your regular task manager. Now.
Labels: sysadmin
Okay, so after that
catastrophic failure of the internal hard disk on my church server we purchased a Maxtor One Touch III external unit with 1 TB of storage. It has two internal hard disks in it with 500 MB each. You can configure it in either a RAID 0 or RAID 1 configuration. I wanted data integrity/security, so I opted for the RAID 1 configuration. On top of that, I implemented a weekly backup of the device to Amazon's S3 service.
The joke's on me. Just when you think you have the bases covered, new ways of failure reveal themselves. Not even three days after installing the drive it crapped out on the server, reporting that the volume was corrupt. Since both physical drives appear as one drive on the server, the data went bye-bye. So did my faith in data security.
Fortunately I had just gone through the process of recovering backed-up stuff from DVD, so I was well versed in putting things back where they should be.
After reinitializing the drive it actually behaved as it should for about a month. With my faith a little bit restored in it (thinking maybe I just had a first-time install hiccup) I started moving other things onto it, including the new church database files. See, since the original hard disk blowup the church was still based on a system using some crusty software. The blowup provided a good reason to switch all the data over to the new system we had recently purchased. So we put the new data files on the drive, hand-converted the data from the old system, and then started updating that data in the new system.
So like I said, it was behaving for just over a month, or for a time period known as
just past the store return date. Then it happened again, and of course this time a week or so worth of church data down the drain. So now I'm in the enviable position of having to back up the thing every day as well as going through the fun process of diagnosing the drive through Maxtor's tech support or online forums.
It appears that I'm not the only customer having this problem. When installing this drive (it's actually a USB device) there is software you have to install with it so that the operating system can find it. I also noticed you can't replace the drives with ones of your own, and after a little digging found out that the software in conjunction with the firmware on the device makes sure that only Maxtor drives (or possibly only the Maxtor drives that came with the unit) will work. Some users are claiming that this software/driver installed on the operating system is the point of failure causing the data corruption on the drive. And when I say data corruption, I mean the partition table is either wiped or messed up.
I guess the upside to all of this is that I'm taking data security a little more seriously these days.
Labels: POS, sysadmin
It's called GMail.
For some reason I've been experiencing an explosion of SPAM this week on the email account I've been using for, oh, about 10 years. With my regular GMail account I noticed that they have a wonderful SPAM filter which is just about spot-on with it's filtering.
I'm already hosting the mail accounts for my new LLC there, so finally decided to spend the half hour worth of time switching my kings-x.com domain email over. For some reason the changes "took" pretty quickly. By the end of the half hour the email seemed to be pretty much arriving at Google's servers instead of the GoDaddy servers (I was using the one free email hosting account you get there with each domain).
So far, so good. About 24 hours later you can see that GMail has already trapped well north of 200 SPAM messages. I'm not quite sure why a full fledged business would not use this free service.
Labels: nerdville, sysadmin
I'm putting up this post for my own posterity, as the next time I blow up my Exchange Server configuration I'll hopefully have enough bread crumbs laying around allowing myself to fix the problem in an expedient manner. That is, in less than an hour rather than a whole week. This little story is actually an epoch, so you can either bail out or buckle up.
I had a
bangup week when the church server blew up, because that same week I also messed up my access to my Exchange server. Typically Outlook will talk with Exchange Server over using
RPC (remote procedure call) protocol over the Internet.
RPC allows one computer to pass commands to another computer over the network.
RPC uses port 135 on your computer and is typically blocked by
ISP's as access to port 135 (and therefore the
RPC service on any computers listening) can wreak all sorts of neat havoc, as you can imagine.
So Microsoft introduced HTTP over
RPC, effectively wrapping
RPC calls inside of the same protocol used for web surfing. I won't go into the gory details of how to enable this on an Exchange Server as there are two great how-to articles I've used
here and
here.
In my original setup of this I had deviated from their recommended plan and used plain HTTP rather than HTTPS for the simple reason that I did not want to pay for a server certificate for the box. These can cost anywhere from 75 to 300 bucks per year. Neither of these articles really touched on how to use straight HTTP for
RPC. After sufficiently messing around inside the
RPC folder properties in
IIS I got it to work on a regular basis both in and outside my local network by using
NTLM authentication without also enabling basic authentication. On the client side in Outlook I configured the Exchange account to use
NTLM authentication on the HTTP connection.
Every time I fired up Outlook I would receive a
username/password challenge, and after I passed through that Outlook worked hunky dory.
Until the day I installed a
SharePoint site on the same server using the same default web site that the Exchange server was using for
RPC. After wrestling through a few rounds of
SharePoint installation struggles I told it to can the website it was using in
IIS. Oops. Bye bye HTTP over
RPC, bye bye Outlook Web Access, and bye bye some other projects I was hosting there for client review.
First I had to create a new default app in
IIS including a place for it to live. Then with a little
finagling I was able to reconstitute all the folders Exchange Server had built in the default app with a little help from
this thread. Replacing the
RPC folder was a
sinch, and then I basically just went and redid everything those two aforementioned articles told me to do.
Except this time when I tried to log into Exchange from Outlook I kept getting prompted. Over and over and over. Every once in awhile it would log in, but most of the time not. The authentication just wasn't taking, and I tried six ways to Sunday to fix it either in
IIS or in the account settings in Outlook.
From my research it appeared that it just wasn't going to work without switching the connection over to
SSL and changing the authentication mode from
NTLM to basic. When you do that, Outlook requires
SSL. The nerve.
I'm a complete idiot when it comes to
SSL, certificates, etc. I know I could install the service on my server that would allow me to issue certificates to my own websites (thereby allowing my to connect to them via
SSL) but since my server is not an official certificate authority (CA) I knew that Outlook would choke when trying to log in (it did, I tried). When I used Internet Explorer to surf to the area that Outlook was trying to access, I would get one of those big ugly warning dialogs pop up telling me the certificate looked valid but the CA is not found or trusted. I tried installing the certificate through that dialog into my trusted root certification authorities (through
internet options in your control panel) but it would never stick.
What did finally work was exporting the certificate from the server through
IIS. I viewed the certificate in
IIS for the
RPC site, and then chose export. The certificate export wizard fires up, which for some reason does not appear if you try to export the certificate through the certificate authority control panel. The wizard allows you to include the private key in the certificate, which I did, and this causes the export format to be a personal information exchange (.
pfx) file. I told it to include all certificates in the path, enable strong protection, and to leave the private key after exporting.
After exporting I hauled this key over to my laptop and imported it into the trusted root certification authorities. Bingo, it stuck, and when I tested in IE it worked without popping up a big ugly dialog box. The final test, using Outlook, also passed. It prompts me once the first time I log in, but then connects and is happy. I can also see that Outlook is using HTTPS for the connections to Exchange Server when snooping the Exchange Server connection status window. See, when I had the whole shooting match configured for HTTPS without actually implementing HTTPS, Outlook would fall back to
TCP/
IP on the local network. Great at home, not so much when accessing through the
Internet.
The benefit of going through this pain and anguish is that now my email communication is encrypted. All it cost was about a week of my life and 1/16
th of an inch of my hairline.
Labels: nerdville, sysadmin
Well, I blowed up the server at my church real good. Actually, the hard drive went and I hadn't been keeping religious (ha-ha) backups, so a lot of stuff went bye-bye. The most unfortunate thing of all was that the server was master domain controller for the Active Directory network. In fact it was the only one.
When I resurrected (ha-ha) the server I created a new domain for it to master. I wasn't quite sure what the consequences of bringing a server back under the same domain would be for all the users, so I let them continue to log in with their old credentials.
Once I got the server back up and running I was faced with the daunting task of moving everybody over to the new domain. This generally means recreating their accounts on the server and then copying the contents of their old documents and settings folder over to their new documents and settings folder. This may copy stuff over but generally all the settings will be out of whack -- icons not where they are supposed to be, wallpaper and colors don't look right. I'm not quite sure that Outlook is all the same when you switch over, either.
Then I discovered a
nice little registry hack on the Microsoft web site. After switching a computer or two over using this method I was able to get the entire process down to about ten minutes per computer. A synopsis of the steps:
- Log in on the computer under the local admin account.
- Back up the contents of the docs and settings folder of the old domain account.
- Change the computer identity to be under the new domain. You'll need the domain admin account info to do this, of course. Note -- once you do this, the user will not be able to access their documents and settings folder using their credentials from the old domain.
- After you've successfully joined the new domain you'll be prompted to reboot the computer. Do it.
- When logging in again, log in with the domain admin account.
- Go to the computer management for the computer. Under users and groups, open the "administrators" folder under "groups."
- Add the domain account for the user to the admin group. Sorry, I know this probably violates some folk's domain policies, but if you don't do this the new account has a really hard time getting to the new folder.
- Log out.
- Log on to the computer using the new domain account.
- Log out.
- Log on to the computer using the domain admin account.
- During the last log on using the new domain account a registry setting was added to the computer for that account. Crack open regedit.
- Go here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
- Under this folder you'll see a handful of other folders with cryptic names. These are settings folders for all the accounts that have logged onto the machine. In each of these folders is a setting called "ProfileImagePath." Find the folder that as the location of the old domain account docs and settings folder in there. For example, if the user name is "mavickers" look for %system root%\documents and settings\mavickers. Often times the domain name will have been appended after the username with a period. "mavickers.olddomain", for instance.
- Copy the old ProfileImagePath location to the clipboard.
- Find the folder corresponding to the new domain account you've created. Generally it will be the last or next to last folder in the list.
- Open the ProfileImagePath setting for the folder and paste the value from the old account into it.
- Close regedit.
- Go to the documents and settings folder for the old domain account and open it's properties.
- Go to the security tab.
- Add the new domain account to the list on this tab.
- Give that account full access.
- Click the advanced button and at the next window click that checkbox at the bottom which tell it to apply the security settings to all the children of that folder.
- Click OK until you're back out at the desktop.
- Log off.
- Pray.
- Log in with the new domain account.
- Voila, everything should look just as it did before.
The only thing I've noticed that doesn't work exactly right is that email passwords in Outlook do not carry over -- you have to reenter them. Oh well.
Beyond all of this KEEP GOOD BACKUPS. Since this disaster I've moved all data to an
external RAID 1 enclosure which is backed up nightly to
Amazon's S3 service using
S3 Backup.
Labels: nerdville, sysadmin