June 27, 2005

Knocking on the Door and Account Lockout Policies

Susan wrote today about "the knock on the door" that occurs when attackers bang on accounts on an SBS network. She pointed out that Steve Riley and Dr. Jesper Johansson in their book on Protecting your Windows network say that if you have the proper passwords...[great passwords are akin to great strong locks on your doors].... you can let them bang on those doors all you want because you are snug behind those locks.

As an information security professional, I think this is a rather FLAWED view of things. It is the difference between a PAPER TIGER in the field, and those who actually have to live it every day. I mean no disrespect to Steve or Jesper, as they are completely correct on the surface of their writings, but they are ignoring a VERY critical component of our REAL WORLD. The weakest link in security is the human factor. We need to EXPECT that some users will use weak passwords. When not forced to use stronger authentication types such as two factor auth, users will always choose simplicity over security... each and every time. It's human nature. And even though people are starting to realize that writing passwords down isn't as stupid as you would think, the reality is their is a HUGE disconnect between the practical and the theoretical.

So what is the right answer? Well that will all depend on your environment, the profile your system has, and the tolerance of risks you are willing to accept.

As an SBSer who is an information security professional, let me give you my take on it. Windows Server 2003 (the OS behind SBS 2003) has a bunch of configuration options to mitigate the risks of "door knockers" with account lockout policies. There are three critical settings which you can configure:

  • Account Lockout Duration
  • Account Lockout Threshold
  • Reset account lockout counter after

Lets first talk about "Account Lockout Duration". This is a setting that determines the length of time before an account is unlocked and a user can log on again after it has been locked. By default, this is normally not defined. If you set it, it will determine how long (in minutes) it will take before the account is unlocked. Here is an interesting tidbit... setting it to 0 does NOT unlock the account... it forces accounts to REMAIN locked until an admin unlocks them. I recommend you turn this setting ON, and set it to 15 minutes.

The second setting is the "Account Lockout Threshold". This settings determines the number of failed attempts that a user can make before the account becomes locked. Now careful consideration needs to be taken when configuring this setting. To little, and you can plague yourself with the possibility of a denial of service attack, or just regular lockout from users who forget their password after a reset. You would be amazed, but it's quite easy to do that, especially after a forced password change. And its why in large networks that a LOT of cost is in password management on Windows networks. If you set it to high, then the setting becomes useless... not being effective at all. The NSA and Microsoft recommend that in high security environments that you set this to 10 invalid login attempts. I think that should be doubled on SBS. That's right, you should ENABLE this setting and set it to 20 invalid login attempts.

Why so many? Because in SBS environments, a single login attempt with Exchange may cause for double login attempt failures. In other words, when doing a failed login to things like OWA, depending on your settings you would actually get TWO failed login attempts in the eventlog... both which causes the lockout counter to go up.

Finally there is the "Reset account lockout counter after" setting. This setting determines the length of time (in minutes) before the "Account lockout threshold" resets itself to 0, and the account is unlocked. When you define the "Account lockout threshold", then this reset time MUST be less than (or equal) to the value you set for the "Account Lockout Duration". Without this setting configured, administrators would be FORCED to manually unlock all locked accounts. I recommend that you set this to the same timeout as whatever you set in "Account Lockout Duration". In our case, that's 15 minutes.

So doing this, what happens?

People are welcome to "rattle at the door". If a user fails to log in 10 times (up to a maximum of 20 if double printing isn't occuring) the account will be locked out for 15 minutes. After that 15 minutes, the counters reset, and the user can try again. In this scenario, it's an acceptable timeout that can block out the baddies, but also reset when valid users make one to many mistakes. And its all automated so the SBSer doesn't have to be part of the account management process until its time to do so. And it comes with a side benefit. In your daily SBS report you will be able to audit this by looking at the "Critical Events" section of your report. You can review which accounts seem to be having problems and address it in a more proactive manner by re-educating users if they seem to be constantly causing bad login attempts. Or force them to reset their password. Or watch the account more closely in the future. At this point it's a user management issue... and something you can more address.

YMMV. But this strategy has been very successful for me. Of course, I have to be honest here. I use two factor authentication where ever I can now, so I don't get much "door knocking", since users can't SEE anything until they have already authenticated to the network. However, this strategy still works effectively as I watch internal users log into LOB terminal servers. Being able to protect against the internal threat is just as important, and this strategy works well to add another layer of defense of our systems.

Posted by SilverStr at 08:29 AM | TrackBack

June 20, 2005

The truth behind the DHS Advisory System?

Uncanning resemblance to the US's Department of Homeland Security (DHS) Threats & Protection Advisory System?

Posted by SilverStr at 07:21 AM | Comments (1) | TrackBack

June 19, 2005

Why Bloglines is the best RSS aggregator for people on the move

Everyone has their favorite RSS reader. There is HUGE polarity on what tool is the best. Many base it on what other A-list bloggers use. Others base it on the core tool they use for reading email or browsing the web.

But I have a favorite reader which has nothing to do with the technology I use, but HOW I USE the technology. Does that make sense? Let me explain.

I am a man on the move. In my regular day-to-day operations I move between 3 primary internet enabled devices:

  1. My primary dual head development desktop system
  2. My Acer TravelMate C111TCi-G TabletPC
  3. My Audiovox SMT5600 Smartphone

I use one tool to manage all my feeds across all my devices. And that tool is Bloglines. Now let me explain WHY Bloglines works so well for me. I never have to sync myself to know what feeds I have, and have not read. I have about 250 distinctive feeds in Bloglines (well tuned over the last year... I used to read over 400 until I found some good link blogs that manage cross posts well), on average giving me about 500 to 1000 entries to review each day. I have grouped them in a way that lets me look at important stuff (friends blogs, competitor information etc) on a regular basis, and catch up on the rest when I have time. And what makes this work so well is I can literally keep up to date ANYWHERE that I am. What could easily take me 6 to 8 hours a day to read and manage typically takes me less than an hour or two.

Bloglines works well across all my devices, being smart enough to know when I am "mobile", even giving me a simple interface when I am on my phone. The Audiovox SMT5600 uses Pocket IE which renders Bloglines layout and text amazingly well and allows me to review feeds while I wait in between meetings, or pretty much any other extra time that I have available, maximizing my productivity. When I am at a wireless hotspot, my TabletPC easily picks it up and shows me the feeds I haven't read yet. That's right. I can be reading a feed on the phone, and the TabletPC is automatically updated and aware of what I haven't read yet. Then when I am at my desk, FireFox just carries on and continues where I left off while on the road. Wondering if I am keeping up with your latest podcast feeds? No worries, Bloglines has enclosures built in nice and neat, allowing me to easily keep up as I need to.

Then there are the times where I try to free myself from the shackles of this sort of technology and end up over at a friends. If I am bored I can always sneak into their computer room and continue catching up as I need to.

Now you know how I can stay so informed. I have streamlined my feeds to give me the information I truely care about, and use Bloglines to organize, manage and present the information in a useful manner that keeps up with me. I need not worry about software tool updates across my devices, nor do I have to manage OPML feeds as I subscribe, unsubscribe or tune my feeds. It just works. Across any device out there. And THAT'S an effective use of technology to maximize productivity.

Now, before I end this I must point out that Bloglines is not PERFECT for mobile reading. I really wish Bloglines had a way to collapse the individual feeds when in "mobile" mode, so you could read complete categories without having to scroll through all the subfeeds. In the full mode Bloglines this exists in the "My Feeds" pane. Hopefully someday that will exist in mobile mode.

But that is a small complaint in comparision of how useful Bloglines is. Many thanks to Mark Fletcher for making my life easier. Now take some time yourself and subscribe to Bloglines. It's absolutely free. Tell them Dana sent ya!

Posted by SilverStr at 01:15 AM | Comments (6) | TrackBack

June 15, 2005

Services and Service Accounts Security Planning Guide

Today Microsoft released a special guide that helps in planning strategies to run services securely under the Microsoft Windows Server 2003 and Windows XP operating systems. It addresses the common problem of Windows services that are set to run with the highest possible privileges, which an attacker could compromise.

The Services and Service Accounts Security Planning Guide is a practical support document for business and information technology (IT) professionals who are planning a strategy for running services more securely. Its primary goals and objectives are to:

  • Introduce the concepts of running services more securely.
  • Describe the importance of running services more securely.
  • Describe the principles and strategies to apply when planning a program to run services more securely.
  • Describe the best practice guidelines to follow to run services more securely

It is well worth the read, and follows the principles you should be using when deploying software as part of SD3+C.

You can download the zip with the PDF here.

Posted by SilverStr at 09:59 AM | TrackBack

June 07, 2005

Windows 2000: Microsoft's Most Successful Failure

Over at SecurityFocus, Mark Burnett wrote an EXCELLENT article on "Microsoft's Most Successful Failure". Quite frankly, I wish I would have written this. So many things ring true to me.

You have to read Mark's article. Here is a teaser of what you can expect:

I think that Windows 2000 has probably been one of Microsoft's greatest sources of bad press in the entire history of the company. But it also defined the company into what it is today. Windows 2000 was meant to be their most secure operating system ever but it turned out to be an absolute security disaster. Somehow Microsoft managed to not only recover from that disaster but also to turn security into one of their greater assets. It turns out, then, that Windows 2000 was their most successful failure so far.

The rest of the article shows how Microsoft has been turning around since then. Good article Mark!

Posted by SilverStr at 07:28 AM | TrackBack

Locking down Remote Access to Small Business Server 2003

Recently I have been asked by a few people on and off the blog about an update on our SBS deployment in the office. As some have pointed out to me in comments and email, my Audiovox post explores the fact we are indeed using it in the office now.

And I noticed Susan recently discussed "agility" about strong authentication, and asked:

We want security, but we want simplicity...oh an can you make it cheap?
I can answer that Susan. The answer is YES. So I guess its time to update the saga that is our SBS deployment so you can see how.

If you recall, in our last installment on this topic, I had a few requirements that had to be met before I would deploy SBS in the office.

I had a need for a SBS 2003 machine that is hosting Outlook Web Access (OWA) and Outlook Mobile Access (OMA) for external parties, clients and virtual employees around the Net. The idea was that I can create a virtual office in our DMZ without having to expose critical business resources not needed by these users to the outside. SBS 2003 looks like a perfect solution for this.

To reduce the attack surface of machines connecting remotely while ensuring strong audit trails, I required that ALL connections coming into these services (actually ALL services except incoming SMTP) be authenticated to Active Directory. My goal was to eliminate the potential compromise of unknown threats that may be exposed from vulnerable code or services that may exist along the code execution path between the OWA front end with IIS to the Exchange backend. It also reduced the risks of poorly configured or unknown services that may be running when they shouldn't be. Since the circle of trust for this group of users is quite small, I have a relative level of assurance that I can mitigate most risks by simply removing the ability to connect to the server anonymously and do bad things that they shouldn't. By removing the ability for an adversary to even throw a connection request to the IIS box without authenticating, I could get that assurance level.

It didn't quite work out as planned. I so wanted to use ISA as the front end to this box right on SBS, while offering extended functionality such as two factor authentication. In the end, ISA 2000 was NOT capable to do what I wanted. And ISA 2004, which had the POTENTIAL for a work around was not available until SP1, which wasn't released at the time. And even now, in further tests it looks like ISA 2004 wouldn't quite do what I wanted anyways.

So now that we know what failed, lets discuss how I met my requirements.

I moved the firewall off the server, and used a hardware firewall that supported all the functionality I wanted. I still use the built in ISA firewall on the SBS box as a second line of defense, mostly to deal with filters and proxies that can do some application level filtering for me. For the hardware firewall, I evaluated WatchGuard, Checkpoint, Secure Computing, Cisco, NetScreen, NetMaster and Sonicwall. I demanded that the firewall offer:

  • Both ingress and egress filtering
  • RADIUS authentication with groupings on the WAN interface
  • Clean NAT, not NAPT. (Network address port translation, as used in Linux ipmasquarading was NOT enough)
  • Stateful Packet Filtering
  • SNMP or Syslog logging to external devices for log consolidation
  • Built in 5 port switch
  • SME pricing

Funny enough, the last item seemed to be a kicker. Once filtered down on reasonable costs, only WatchGuard and Sonicwall were left. Although Cisco now owns Linksys and they offer dirt cheap NAT devices (some around $50, wow), none of them could properly handle ingress AND egress filtering while offering RADIUS auth on the external interface. You will see why RADIUS auth is important in a moment.

In the end, I selected the Sonicwall TZ170 with the Sonicwall Enhanced OS. It was around $500, but offered much more scalability for my "Virtual Office" DMZ network than other solutions.

With the firewall now in place, I wanted to configure the absolute minimum attack surface to the outside world. So, from the outside you simply see two ports. The first being the SMTP port for the Exchange server and the second being the authentication port, to allow remote users to authenticate to the network. I could have went with a multidrop offsite POP solution to a Unix server running postfix to remove even the SMTP port, but I decided to go with Exchange 2003 directly, and use the ISA mail proxy filters to deal with some of the obvious door rattling. Exchange 2003 has matured alot from its earlier versions, and I am willing to accept the risks that are exposed with the SMTP service. Time will tell if that was a good call.

Here is where things got fun. Because I cannot trust the machines entering the network, I simply refused to allow a Layer3 connection in. Even with a VPN quarantined tunnel and new technology like NAC (Network Admission Control from Cisco) or NAP (Network Access Protection from Microsoft), I don't wish to expose the business to such unnecessary risk. So IPSec and PPTP were out of the question. And these SSL VPNs are just to weird in what they can really offer.

In comes Remote Web Workplace (RWW) for Small Business Server. It provides a passive conduit to Exchange through Outlook Web Access (OWA) over SSL, and offers a private intranet through Sharepoint. It gives me shared contacts and calendaring, while offering no need to configure any hosts to use it. It ALSO offers a secure tunnel to an internal Terminal Server through a special bridging RDP control directly in the browser. This allowed me to install a separate Windows Server 2003 box behind the firewall with some line of business apps we have. The result, I have to open up a few ports:

  • Port 443 for Remote Web Workplace (OWA/OMA)
  • Port 444 for Sharepoint
  • Port 4125 for secure Remote Desktop to a Terminal Server

Now, although these ports are not always open, I simply did not wish to risk it at all. Remember, I want to reduce the attack surface so people cannot even fire requests to these services until I know who they are. On top of that, because I cannot trust the hosts connecting in, there is a risk that it may have installed viruses, malware, keystroke loggers etc which could expose the company to even more risk.

The solution? Find a two factor authentication solution that would work here. At that point, even if a keystroke logger recorded the passwords, it wouldn't matter. With a one time password (OTP), the information is useless to them. They can never use it to log in.

I evaluated quite a few solutions. The ones worth talking about were from RSA (SecurID), Authenix (A-Key) and CryptoCard (CryptoServer). In the end, it came down again to a combination of cost, and comfort. As an old RSA SecurID user, I was VERY familiar with their keyfob tokens. But they are ridiculously expensive, forcing you to buy a 25 user license to get started. (I only need to deal with 5 users initially) Authenix didn't have a keyfob, but had a neat OTP generated in a window on a USB key. But I ended up going with Cryptocard, as the server natively installed into the SBS box and hooked directly into the Active Directory tree to manage the tokens for my users. That's right... on installation it ties nicely into Active Directory on SBS. And it has a keyfob similar to RSA, but WITHOUT a 3 year expiry timeout. In other words, I never have to buy new tokens for my users, unless they lose the token. Oh, and to boot... they have AWESOME SMB pricing, with an initial 5 pack of tokens and the server coming in around $500.

So, the final result? From the outside world you see two ports. Well, sort of. Sonicwall has a nice stealth mode to help reduce pentest style scans, and in many cases you won't even find that unless you know what to look for. You can log into the auth port with a browser, which challenges you for credentials. You enter in your AD username and a passcode which is a combination of a 4-8 digit alphanumeric PIN along with a 6 digit OTP. Using RADIUS, the firewall then pops a request over to the SBS box, verifies that the user is in Active Directory and that the OTP matches for the token. If so, it sends an ACCEPT response to the firewall. The firewall then prompts the user with an "Acceptable Use" dialog, which the user must accept. After accepting the "Acceptable Use" policy, then, and ONLY then, the firewall will open up the port forwards for the IP you are currently at that are needed for Remote Web Workplace. You can now use the regular RWW login stuff to go about your business. If you idle for more than 15 minutes, the firewall immediately locks that back up, and all the ports are blocked until you relog in.

Oh, and a nice side affect of RADIUS groupings. I can control what ports trusted users can access, and at what time of day. So I can further limit service exposure to business hours, and only services that are needed. As an example, I have added a Linux server behind the firewall that uses RADIUS and the Cryptocard webagent to allow source control check-ins and check-outs. My "dev" group is permitted access to that server to do secure checkouts of code, only after authenticating with a OTP. Talk about wicked add-on with no extra cost. Nothing beats the ability to check out a piece of code securely on your TabletPC while at a Starbucks, make a fix and check it back in, all over the free Wifi. Or accessing your email while at an airport web terminal, and not worrying about the vile filth that might be installed on there.

Using this scenario, I can consolidate my auth logs through RADIUS against my login services with RWW. In this way, I know WHO is coming in, from WHERE at WHAT time, and WHAT they are doing. And since I have a strong audit trail on the SBS box, my daily reports with SBS show me when people try to do things they shouldn't. Walla... I met all my objectives, reduced the attack surface to something I find acceptable, and did it all for around $1000 for 5 users. And to scale more users, I simply buy more 5 packs of the Cryptocard tokens and SBS User CALs as needed.

Now the solutions is NOT perfect. I would prefer to have RWW use two factor authentication natively, so I can force an OTP login scenario. The difficulty with this is that things like OWA would break, since they use a cached password from the RWW login. Further to this, Microsoft currently has no intentions to add RADIUS support to the RWW login. Susan and I are currently taking this up the chain of command and hopefully we can rattle the right chains to get something done about that.

Oh, and OMA doesn't work well yet. The problem is a limitation on the Smartphone 2003. The Sonicwall login page uses some neat javascript which PocketIE just can't handle. One solution is to use a static IP on GPRS; not a practical solution if you know much about wireless telco providers and their cell networks. Right now I am talking with level 3 support at Sonicwall and will probably write a simple login app for the Smartphone to deal with this. If I do that, I will publish it so other can use it if they so desire. For now I am just using ActiveSync to keep my Smartphone in sync with the Exchange server, only after authenticating the machine using Activesync with my cryptocard token.

So there you have it. That's what I had to do to get an SBS Virtual Office Extranet setup to allow remote users to access resources around the world. It was a struggle to find all the right bits, but the fact I was able to deploy enterprise-level two factor authentication for my SBS network for under $1000, it IS possible for the SME. Is it overkill? I don't think so. Does it scale. Absolutely. The SBS box will reach its critical mass before this solution does. And at an ammortized cost of approximately $125/user, it's well within budget if you consider the risks it mitigates, and the protection it offers. And I would do it again in a heart beat.

Posted by SilverStr at 12:23 AM | TrackBack

June 06, 2005

Rootkits : Subverting the Windows Kernel

As I was writing about Mark's webcast tomorrow, it got me to thinking about Greg Hoglund's rootkit.com site. I knew it was recently DDOS by some immature kids that didn't like being questioned/insulted on the site, and I was curious to see if it was back up.

As I was checking on the site, I came across an interesting discovery. Looks like Greg is almost done his next security book, entitled Rootkits : Subverting the Windows Kernel. According to Amazon it should be out sometime in July. From what I have read in the TOC, this is one of those books you will love to hate. On one side it shows you how to:

  • Understand the role of rootkits in remote command/control and software eavesdropping
  • Build kernel rootkits that can make processes, files, and directories invisible
  • Master key rootkit programming techniques, including hooking, runtime patching, and directly manipulating kernel objects
  • Work with layered drivers to implement keyboard sniffers and file filters
  • Establish covert channels for retaining control over systems with installed rootkits
  • Detect rootkits and built host-based intrusion prevention software that resists rootkit attacks
  • Discover legitimate uses for rootkits by law enforcement and security organizations

As you can see, a LOT of potential for misuse. On the other hand, the only way to defend against such attacks is to fully understand how they are performed. And all this information has been in the underground for years anyways, so this book isn't giving away any major secrets.

So, looks like another book I will have to pick up. God I wish I could read using osmosis. Then I could just stack a pile of books on my head when I go to bed and keep up!

Posted by SilverStr at 07:54 AM | TrackBack

Understanding and Fighting Malware: Viruses, Spyware and Rootkits

If you don't get a chance to head down to TechEd this week in Florida, all is not lost. There are a few of the sessions that are going to be webcasted.

One of the webcasts I think security professionals should be checking out is the one Mark is doing on Understanding and Fighting Malware: Viruses, Spyware and Rootkits.

I believe Mark has the insight to actually make this both a useful and entertaining webcast on the subject. Besides the fact he wrote the RootKit Revealer for Sysinternals, he has an in depth knowledge of the Windows kernel far beyond most people in the industry. Don't believe me? He is also co-author of Windows Internals, a great book that dives into revealing what really goes on in the Windows kernel. I haven't had a chance to pick up the latest version (maybe Mark will send me a signed copy some day :) ), but if its as good as Inside Windows 2000, it will be well worth it.

Anyways, if you have time in your schedule tomorrow at 2pm PST, I suggest you sign up for the webcast. Actually, if you don't have time, make some anyways. I will bet you won't be disappointed.

Posted by SilverStr at 07:32 AM | TrackBack

June 02, 2005

My Audiovox SMT5600

Since we cut over to using Remote Web Worksplace on our Small Business Server (SBS2003) at the office, I have been having difficulties syncing my Motorola MPX200 to Exchange over SSL. Although contacts would sync, the shared calendar would not.

I have also been having cell reception problems since my phone is dual band, which leaves me with NO SERVICE at home, and almost no service at my desk. So after missing one of the most important phone calls of my career today, I decided to do something about it.

Rogers finally has a smartphone in their offerings in Canada, which is the Audiovox SMT5600. Robert has been talking about the Audiovox SMT5600 since last October (aka Scoblephone), but I have learned not to fully trust when he evangelizes technology. Why? Because he seems to always talk about it from a gee-wiz factor, and not from a real productivity standpoint. I have had the pleasure of hanging with Scoble when he has been in love with a piece of technology, but I rarely see him using it to truly maximize the productivity benefits on a day to day basis:

  • Longhorn Evangelism at PDC. Enough Said.
  • TabletPC evangelism. He RARELY ever uses his Tablet when I am around, except to read email/blogs. A few times when we were on campus together, his Tablet wasn't even working. To be fair, we don't do a lot of work together, so perhaps this isn't a good assessment.
  • Scoblephone. Um, he lost his.

He's an uber-geek. He likes to play. But I buy things as tools, not toys. Especially when I typically pay a LOT more than he does for them. (Still trying to figure out how that *cough* free trade agreement *cough* works when there is a premium on almost ALL technology up here). Anyways, long story short, it was time to get the Audiovox... and Robert was right. It's a great phone.

Besides the fact it fully syncs with my Exchange server and has 4 full bars everywhere I go now, its bluetooth. As I am typing this up on my TabletPC, I am currently connected via bluetooth to my Audiovox to access the Internet via GPRS. At the same time, I am having a Skype call over my bluetooth headset on the TabletPC, through the smartphone, onto the GPRS network, bridging to the Internet. In the middle of nowhere, where there is no wireless Internet access. Talk about being productive. Or maybe that should read "shackled".

Anyways, I flog Robert for his techno-geekness, yet seem to be following in his shadow. First he got me hooked on the TabletPC. Now on the Audiovox SMT5600. What's next? It better not be Longhorn.

Posted by SilverStr at 09:50 PM | Comments (7) | TrackBack