Conficker is quickly becoming a mainstream news story as April 1 approaches, the date that the worm is programmed to “phone home” for further instructions. It has been discussed in various news outlets, even garnering a primetime spot on 60 Minutes this past weekend. The worm has been a great source of concern for IT execs the past couple of months, though the actual severity is yet to be determined. There are several mitigating factors that are supposed to minimize the chance for compromise, and a number of ways to detect and remove the virus. Another potential weapon against Conficker that should be considered is the use of OpenDNS to block the worm from communicating with command and control servers for further instructions.

In analyzing the virus, engineers have found that Conficker uses an algorithm to determine a number of different domains to contact for further instructions beginning on April 1. The algorithm was used to determine the exact list of domains that would be used. OpenDNS recently added a feature which would block access to these domains: “We’ve teamed with Kaspersky Lab to identify those domains, and stop resolving them. This means if you’re using OpenDNS, Conficker will do your network no damage“. From a management perspective, this is a much less intensive solution than attempting to block the domains on your local DNS servers and dealing with the overhead involved.

While using OpenDNS might not be feasible for larger enterprises, this is a great solution for SMB’s and home users. I’ve used it personally for some time now; the amount of centralized control available and ease of use makes it extremely attractive. A wealth of reporting features are also available, including one to specifically identify requests to known malware sites (like Conficker). Steps still need to be taken to ensure that Conficker is identified and removed from your network, but this is a good way to ensure that if any instances go undiscovered, they won’t be able to cause further harm.

Related Links:

OpenDNS
In depth analysis of Conficker
Subscribe to TechScrawl.com

Microsoft’s NLB Clustering is kind of to High Availability Load Balancing what Natural Light is to the beer world. Both will basically get the job done, and on the cheap, but in the long run they might leave you with a wicked headache and wishing you spent a few extra dollars for a Sam Adams.

A lot of my time at work recently has been spent researching and testing load balancing and fail-over solutions for a group of Windows based application servers. Having never had load balancing requirements before, an NLB clustering solution sounded good at first, especially being included free with the OS. However, I found that unless your environment exactly meets requirements, you may be better off not going down the MS NLB road. This brief overview of my lessons learned may help others also considering NLB solutions.

* Basically MS NLB works by assigning a virtual IP address (VIP) to the network adapter of each cluster member. Traffic is sent to the VIP, received by all cluster members, accepted by one, dropped by the rest.

* MS NLB supports two configurations: unicast mode, or multicast mode. Unicast mode replaces the existing MAC address of all cluster members with a new cluster MAC address, which is shared by all nodes. Multicast mode adds the cluster MAC address to the node adapter, but also leaves the original one. With both methods, the nodes share an IP and MAC address, so that when a client asks “who has this IP address” (an ARP request), all nodes respond.

* Unicast mode aims to be simple, and has the advantage of working across routers with no problems. However, this method has the negative side effect of flooding switch ports. MS-NLB hides the MAC address of outgoing cluster traffic, switches never learn what ports cluster members are attached to, so traffic destined for the cluster is flooded out all ports. This effectively turns a switch into a hub as far as cluster traffic goes, which can cause network issues with busy clusters. This can be overcome by adding static ARP entries on the switch (if supported), but that can quickly become a management nightmare. Another possible drawback to unicast mode is that cluster members cannot directly communicate with each other without adding a 2nd NIC.

* Multicast mode attempts to address switch flooding by using IGMP Multicast support, which tells the switch to direct cluster traffic only to those ports with cluster members attached. However, this assumes the switch supports IGMP snooping and has it enabled. Also, many routers & layer 3 switches do not support this mode because ARP replies associate a unicast IP with a multicast MAC, which may or may not be against standards depending on whether you ask Microsoft or Cisco. No IGMP support means switch flooding. And no IGMP router support means no cluster access outside of that subnet unless a static ARP entry is used.

* Planning to implement NLB in a virtualized environment adds complexity. The only one I can speak to from experience is VMWare ESX. They support both modes, however unicast is not recommended. By default, unicast doesn’t work because the virtual switches learn MAC addresses despite the cluster masking outbound traffic, which breaks clustering. This can be overcome by disabling the NotifySwitch feature, but that in turn breaks operations like VMotion. Multicast works, but is subject to the same problems as mentioned above, and made more complex by the many different physical / virtual topologies.

I certainly don’t intend to demean Microsoft (or Natty Light) on their products. Microsoft could have easily not included it with the OS, leaving the only option as an expensive hardware load balancer. MS NLB does work, and providing you are aware of and can address its limitations, you may find it to be an effective low cost load balancing solution in your environment. On the flip-side, if you find that the management and overhead is too much and you need a hardware LB device, there are a number of powerful and relatively inexpensive possibilities. The ones from Barracuda Networks are a good choice. There are also other factors not covered here that need to be taken into account; session support, affinity, and redundant network topologies to name a few. So make sure to do adequate research, up to and including packet captures to prove intended operation.

Related Links:
Network Load Balancing Clusters – TechNet
Selecting Unicast or Multicast – TechNet
Implementing NLB in a Virtualized Environment

Random Tech-Bits is a periodic roundup of interesting technology related links & news stories.

• SSL bypass method described at Black Hat D.C. – Link here to the actual presentation. SSLStrip will be posted here within a few days.
• Security Assessment of TCP – Comprehensive assessment of TCP weaknesses and vulnerabilities, from the UK’s CPNI.
• Call for DNSSEC deployment – Dan Kaminsky pushes for DNSSEC adoption: “It’s time to sign the root and be done with it.“  Check out my DNSSEC related posts here: DNSSEC 101 and Enabling DNSSEC on BIND.
• Recent legislation introduced into the U.S. House and Senate will apparently require service providers maintain all access logs for 2 years. It has interesting implications: “not just public Wi-Fi access points, but … individuals, small businesses, large corporations, …every employer that uses DHCP for its network”. Full story here.
• Thwarting an Internal Hacker – WSJ article by Bruce Schneier analyzing insider threat protection; the recommendations are mostly common sense.
• Conficker / Downadup worm variant, Conficker B++ spotted in the wild.

Question: If someone were to obtain your credentials for a “non-critical” web site, could they be used to gain access to accounts on critical sites such as email, online banking, etc? Many people would likely have to answer yes to that question, even security minded IT professionals.

Identity management can easily be a complicated subject. The average Internet user maintains dozens of accounts across an array of sites with varying levels of importance and security. Credentials for those accounts can be obtained a number of ways. Many sites still don’t use SSL login encryption, leaving passwords vulnerable to sniffing. Others store passwords in the clear, leaving them vulnerable to breach (like the recent Monster.com one). The most secure solution might be to maintain a separate password for every site, but that isn’t very user freindly. Maintaining security has always been a trade-off between security and usability. Greater minds than mine are working on this problem, trying to come up with solutions like the OpenID initiative. Until a better solution is universally adopted, here I’m presenting the technique I use for personal password management.

This password management strategy attempts to meet three goals. 1) Find a decent compromise between usability and security. 2) Categorize sites into three tiers, aligning services by security and importance, and assigning unique passwords to each tier. 3) Discovering credentials in one tier should not lead to discovering those in another.

Tier 1 sites are the most critical; email and online banking. Besides containing personal information, email is considered critical because it is usually tied to accounts on other sites. Based on that fact, I recommend making the online banking password slightly different than email. This kind of a one-off, and maybe should be considered a 4th tier? SSL is required for Tier 1 sites. Tier 2 sites are those that are of medium importance, other financial (credit accounts, Amazon, etc) and personal identity sites (social networking, etc). SSL is still a requirement for Tier 2. Tier 3 is for all other trivial accounts like forums, newsletters, or any site that doesn’t implement SSL login encryption. Each of the tiers gets assigned a unique password that meets best practices. This requires remembering three (or four) different passwords, but they can be a variation on the same base to make this easier.

Other factors need to be taken into account for a total password management solution. Attention needs to be given to site SSL status. Passwords should be complex, not contain words in the dictionary, and ideally changed on an annual basis. Also password reset procedures for accounts should be evaluated to prevent unauthorized access like the kind Sarah Palin fell victim to last year. Passwords typically shouldn’t be written down, but as a memory aide, a site-to-tier mapping could be saved in an encrypted spreadsheet, using something such as TrueCrypt.

Ultimately there is no such thing as 100% secure identity management and access control. Even with (theoretical) rock solid security in Layers 1 through 7, Layer 8 weaknesses will always be exploitable. In my view this solution accomplishes a reasonable balance between security and still being something that is manageable. It does have weaknesses, for example a breach similar to the Monster.com one, which would have been a Tier 2 site, would require resetting passwords for all other Tier 2 sites. However, email would have remained secure, so ultimate control over Tier 2 password resets should have remained intact. There are numerous other variations on the personal password management theme. Let me know in the comments section what methods you suggest or what weaknesses you see with this solution.

Just a quick heads up related to disabling Autorun to protect against Downadup / Conficker. While the worm continues to spread and receive more media coverage, IT personnel are working to make sure their systems are protected. One of several ways this worm spreads is by taking advantage of the Autorun feature in Windows systems. Disabling this feature via Group Policy is a logical decision, but it turns out it may not actually work like it should.

Disabling Autorun via GPO currently only disables Autoplay on media insert. However, if there is an Autorun.inf file present on a CD, USB, or network drive, the program will still run when double clicking that drive in Windows Explorer. This vulnerability was announced by the U.S. CERT team on January 20, and later updated to provide patch details from Microsoft. Follow the links below for full details on the problem and where to get the patch.

US-CERT Alert
Microsoft KB953252
UPDATE: Microsoft released KB967715 on March 10 to address this autorun problem in all versions of Windows.

My previous post was an overview of DNSSEC and how it secures DNS transactions. This one covers how to enable DNSSEC on zones running on the BIND DNS server. Specifically, this example will involve setting up DNSSEC on a parent and child zone, and confirming successful operation.

An important concept to grasp is that BIND sort of takes on two different roles pertaining to DNSSEC. One is that of providing signed data for a zone for which it is authoritative. The other is that of a validating resolver for external zones. If you only want to set up your BIND server as a DNSSEC validating resolver and not sign any of your own zones, you can skip down to the “Resolver Validation” section.

The majority of this post’s content will be the actual instructions for enabling DNSSEC (the “how”), and very little explanation (the “why”). My preferred way of learning usually consists of diving in head first and tinkering, and then once I’m familiar enough, going back and learning the intricacies, and that’s how I’ll write this. There are links at the end of the post should you want more thorough documentation. I also suggest reading my previous DNSSEC 101 post if you haven’t already. Some of the steps in the post involve editing important configuration files, so as a precaution I recommend creating a backup copy of any file before editing it.

REQUIREMENTS

The requirement for signing a zone with BIND is at least version 9.3; I’m using v9.4 here. Bind v9.6 supports NSEC3 records, but I won’t be going over that. An important thing to be aware of is that a DNS server acting as a resolver will not validate data from a zone for which it is authoritative. The data is coming from the server’s own local disk, so is considered valid. This means if you follow along with this, you’ll need at least two BIND installations, one authoritative server for the zones, and one resolver for confirming operation.

Another requirement is the installation of OpenSSL libraries, which are needed for DNSSEC signing. If you compile BIND yourself it should be compiled with openssl support. Installation of this software is beyond the scope of this article, but a good package manager is always helpful. Exercises here are done using SuSE Linux Enterprise Server 10 with the YaST package management software. This example starts off assuming a correctly installed basic BIND 9.4 setup, with two zones configured: example.com & child.example.com.

PREREQUISITES

The first prerequisite is to DNSSEC enable the server by editing the named.conf file. Add the following entry to the options section of the file, then restart BIND:

dnssec-enable yes;

Before signing a zone, you need to make a decision regarding what signing algorithm and key strength you will use. The currently supported algorithms are RSA/MD5, RSA/SHA1, and DSA. The most widely used is RSA/SHA1; it’s also recommended in RFC’s and U.S. government guides. The next choice to make is key size.  I generally use 1024 bits for a zone signing key (ZSK), and 2048 bits for the key signing key (KSK). Your choice can depend on several factors, RFC 4641 has some recommendations for choosing a key size. Generating the keys can take a while depending on system resources, so for testing purposes you may want to use the smallest size of 512 bits.

GENERATE KEYS

As discussed in the DNSSEC 101 post, the first step in signing is to generate two key pairs for the zone, the ZSK (signs the zone) & KSK (signs ZSK). This is done using the dnssec-keygen BIND utility. Following along with this example, to create a ZSK for the example.com domain with the RSA/SHA1 algorithm, and a key size of 1024 bits, the following command is run (run from the directory housing the zone files, on SuSE this is /var/lib/named/master):

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com

When this completes, two new files will have been created: Kexample.com+<alg>+<id>.key (the public key) & Kexample.com+<alg>+<id>.private (the private key). Next, to create the 2nd key pair, the KSK with a 2048 bit key size, run this command:

dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK example.com

This will create two additional files with the same naming format. Now the public key portion of the ZSK and KSK need to be added to the zonefile. This enables validators to retrieve the keys. The easiest way to do that is to just pipe the contents of the files into the zonefile, using the following command (good time to make sure you have a backup):

cat Kexample.com+*.key >> example.com

You should now be able to see two new records in the zonefile, of type DNSKEY. After restarting BIND, you should also be able to query for these new records:

dig @localhost example.com DNSKEY

At this point, go back through the entire process in this section to generate keys for the child.example.com zone, making sure to replace “example.com” with “child.example.com” in all of the commands.

SIGN THE ZONE

With the steps above completed, the zones are now ready to be signed, a process done with the dnssec-signzone command. In this case, the child.example.com zone needs to be signed first, I’ll describe why shortly. To sign the zone, run this command:

dnssec-signzone -N INCREMENT child.example.com

The -N option updates the SOA serial number (note this option isn’t supported with BIND 9.3). When this completes you will have 3 new files: dsset-child.example.com, keyset-child.example.com, and child.example.com.signed. The child.example.com.signed file is the new zonefile, with records canonically ordered and new RRSIG & NSEC records added. Take note of the size difference compared to the original zone file. The dsset file is the Delegation Signer (DS) record for the zone, which needs to be added to the parent zone in order to facilitate chain-of-trust validation. This is the reason we signed the child zone first, if the parent zone was first, it would have to be re-signed after adding the DS record.

To add a DS record for the child zone into the parent zone, you import the contents of the dsset-child.example.com file into the zonefile for example.com. The easiest way to do this is the following:

cat dsset-child.example.com >> example.com

With the DS record in place, you can now sign the parent zone:

dnssec-signzone -N INCREMENT example.com

When complete, you will see the new keyset and dsset files and the example.com.signed file.  At this point the zones are signed, but BIND needs to be told to load the signed zonefiles instead of the original un-signed ones. Edit named.conf, and add the “.signed” suffix to the zone names. In my environment:

zone "example.com" in {
file "master/example.com";
};

is replaced with:

zone "example.com" in {
file "master/example.com.signed";
};

The same applies for child.example.com. Now restart BIND, assuming no errors (they are usually due to syntax), you are now serving DNSSEC signed zones.

RESOLVER VALIDATION

DNSSEC validation can be tested by adding “+dnssec” to dig queries. One might think you would be able to try that at this point and get validated data (have the “ad” response flag set), but it won’t work. Dig currently doesn’t perform validation, it just asks for it. It’s the job of a DNSSEC aware resolving server to validate. Fortunately BIND 9.3 and above is capable of that, simply by editing named.conf. If you only wanted to configure a DNSSEC validating resolver without hosting any signed zones, you could pick up here without doing any of the steps above.

If you did follow along, these steps need to be completed on a 2nd BIND installation. Configure this installation to use the first server as a forwarder. This is done because, as mentioned above, BIND will not validate zone data for a zone for which it is authoritative. To set up BIND as a validating recursive server, edit the options section of named.conf to have these entries:

dnssec-enable yes;
dnssec-validation yes;

Note: the dnssec-validation option is only supported on v9.4 or above, on v9.3 the dnssec-enable option covers validation as well.

BIND will now attempt DNSSEC validation, but one more piece is missing. You’ll recall from the previous post that DNSSEC validation relies on climbing a chain-of-trust until it reaches a trusted authority. These trusted authorities are configured by setting a trust-anchor in named.conf to a zone’s Secure Entry Point (SEP), which is the KSK. Ideally you want a trust-anchor configured as high as possible in the chain, which would be the root zone, but this currently is not signed, and neither is .com. In this example, the highest possible point would be example.com.

Obtaining a zone’s KSK (SEP) is fairly easy. Recall that the public key info is added to the zonefile before the signing process (as a DNSKEY record type), so you can simply query for it:

dig <domain.com> DNSKEY

The two public keys created for a zone have a flag field which will be set to either 256 or 257. 256 is the ZSK, 257 is the KSK, which is the SEP, and the one you want to configure as a trust anchor. I’ve found it easiest to pipe that to a file, trim it down to only the SEP record, and import to named.conf.

You’ll then need to edit the named.conf file to format the data correctly, because the way it was imported isn’t complete, but it’s still much easier than manually typing everything. Find where the data was added (at the end of the named.conf file), then remove the necessary text and format it to match this example (pay attention to quotes and semi-colons, and note I’ve truncated the key here):

trusted-keys {
"example.com." 257 3 5 "AwEDSFASDF......";
};

I should mention that using DNS to obtain a DNSKEY for trust anchor configuration is not considered secure ( you can’t be secure until you have a trust anchor, chicken before the egg kind of situation ). However you can use DNS to obtain the info and verify it via another channel.

Once you’ve got that done, restart BIND. You now have a validating DNSSEC recursive name server.

CONFIRMING OPERATION

BIND is now a validating resolver and is configured with a trust anchor, so you should be able to confirm operation by requesting a DNSSEC validated query (against the recursive server) of your zones:

dig +dnssec example.com

dig +dnssec child.example.com

If the data was successfully validated, you will see “ad” listed as one of the flag options in the response, meaning the data returned was Authenticated Data (see previous post for examples). The fact that authorized data is returned for the child domain when you only have a trust anchor configured for the parent confirms the delegation (DS) record was added correctly.

Further testing can be done against other DNSSEC signed zones on the Internet simply by obtaining their SEP key information and adding a trust-anchor.

MAINTENANCE AND KEY STORAGE

As mentioned, the goal here was just to show how to configure DNSSEC on BIND. Further research should be done if implementing in production. A few other things are worth mentioning though. It is recommended that the private keys be stored securely offline, or locked down tightly on a primary server that isn’t publicly accessible. Also, record signatures have a default lifetime of 30 days. This can be lengthened, but at some point they will expire. This requires the zone be re-signed before that happens otherwise the zone will no longer validate. A final factor to consider is key rotation, which for security purposes should be done at certain points. RFC 4641 has some suggestions on this subject.

LINKS:

DNSSEC 101
DNSSEC in 6 minutes – Excellent Reference
RFC4641 – DNSSEC Operational Practices
Subscribe to TechScrawl.com

DNSSEC is something you’ve no doubt heard of, especially this past summer with the discovery of the Kaminsky DNS bug which led to a small panic and widespread patching from vendors. DNSSEC (sometimes called DNSSECbis) has existed as a proposal for about 10 years, but has undergone significant changes as recently as March 2008, and has only lately seen a major push to implementation. This post discusses both the need for DNSSEC and tackles the complex topic of how it works, as simply as possible. Though this really only scratches the surface, it should serve as a good intro for those who want to know more. A fundamental understanding of DNS is assumed.

WHAT DNSSEC DOES (AND DOESN’T) DO

DNSSEC provides three basic things:

• Data Origin Authentication – assures that data was received from the authorized DNS server; can protect from impersonation attacks like the Kaminsky bug.
• Data Integrity – assures that data received matches data on the origin DNS server, and was not modified during transit; protects from MITM type pollution attacks.
• Authenticated Denial of Existence – assures that a “Non-existent” response is valid.

DNSSEC provides these services by securely signing DNS records. This requires the addition of four new zonefile record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). Signing is done via the use of public key / private key pairs. If you are familiar with the concept of PKI, this is similar. However, DNSSEC is not PKI. There are no certificates or certificate authorities. The records in a zone are signed with the private portion of a zone signing key (ZSK), and this signature is returned along with the standard response to a DNS query.

The public key can then be used to validate the data. DNSSEC also provides a method to verify the signature’s authenticity, by signing the ZSK with a key signing key (KSK). DNSSEC does not provide any form of encryption services, so data can still be sniffed, but this typically isn’t considered a threat for DNS traffic. DNSSEC also does not provide any additional protection of zone transfers. DNSSEC is fully described in RFC’s 4033, 4034, and 4035. To allow for the additional record types, support for DNS Extension Mechanisms (EDNS0) is required, as described in RFC 2671.

At this time DNSSEC is supported on only a few DNS servers, ISC’s BIND being the most popular. Signing a DNSSEC zone with BIND requires v9.3 or later. Microsoft products do not support DNSSEC at this time, but it will be integrated with Windows 7 and Server 2008 R2. Updates to provide support in older OS’s may be released around that time as well. Microsoft’s DNS server is, however, able to load DNSSEC signed zones, meaning it does have the capability to act as a secondary for a signed zone on a BIND primary. That fact highlights an important point, that DNSSEC signing applies to a DNS zone, not a DNS server.

WHY DNSSEC IS NEEDED

DNS security is vital because nearly everything relies on it for name resolution at one stage or another. DNS has done very well scaling to support the growth of the Internet, but security was unfortunately not a factor in the protocol’s design. Numerous vulnerabilities have been identified in DNS going as far back as 1990. These problems are typically addressed as they arise. However, despite workarounds, there is still no way for a resolver to be certain that DNS data was returned uncorrupted, or that it even originated from the queried DNS server. DNSSEC helps to address these issues.

HOW IT WORKS

To secure a zone with DNSSEC, a DNS administrator will generate ZSK & KSK keys, add the public portion of each of the keys to the zonefile as a new record type (DNSKEY), and then sign the zone which will create additional record types (RRSIG & NSEC) for each authoritative record in the zone. The RRSIG record is the signature of a corresponding record. The NSEC record type provides the next secure record in the zonefile, which is how authenticated denial of existence is done. (If you already see a potential security problem with the NSEC record, you’re right, keep reading.) Another RRSIG record is created for the purpose of signing the NSEC record. In addition to adding these new records, the process of signing a zone also organizes it in canonical order. This entire process can significantly increase the size of the zonefile, often 8 to 10 x the original size.

The final step in the signing process is to provide the parent zone with the DS (Delegation Signer) record to create a chain of trust, assuming the parent is DNSSEC aware and the zone is signed. A DS record in the parent zone is signed by the parent’s ZSK, and points to the child’s KSK. The KSK is also referred to as a zone’s Secure Entry Point (SEP) because it is the first key used to form a chain of trust for that zone. In cases where the parent zone is not DNSSEC aware, the signed zone is referred to as an Island of Security. Look for an in-depth post in the future which will go over the steps of enabling DNSSEC on BIND.

Once the steps above have been completed, the zone being served is now protected with DNSSEC. However, in order to utilize the capabilities of DNSSEC, a resolver needs to be DNSSEC aware and know how to ask for the new record types in order to validate the data. To ultimately validate data, a resolver needs to be able to climb the chain of trust until it reaches a known good, trusted, authority (again similar to PKI). This is done by configuring validating resolvers with a “trust anchor” to the highest zone below which validation is desired. For example, if you have a trust anchor configured to .com, and DNSSEC is configured properly on all zones, you can validate example.com, child.example.com, etc. The best case scenario would be configuring resolvers with a trust anchor to the root zone, however, the root zone is not signed at this time, nor are most of the TLDs. Until that time, multiple trust anchors are required.

When a resolver attempts to validate DNSSEC signed zone data, 1 of 4 potential states will be determined:

• Secure – resolver has trust anchor and is able to validate all signatures.
• Insecure – resolver is able to validate to a point in the chain of trust, but at some point a delegating DS record is non-existent, meaning data below that point cannot be validated.
• Bogus – resolver has a valid chain of trust but data fails to validate (missing signatures or data, unsupported algorithms, expired signatures, etc.).
• Indeterminate – no trust anchor available to validate data; this is default mode.

Currently there are very few true client resolvers that are capable of validating DNSSEC. Until the time when that client support is more widespread, most DNSSEC validation takes place between supporting recursive servers (acting as resolvers) and authoritative name servers.

Several organizations operate open recursive servers on the Internet for testing DNSSEC, Comcast is one of them. Below are examples of queries against one of these Comcast resolvers using the Linux dig utility. The first one is a standard query/response. The second is the same query but this time asking for DNSSEC validation. Note that some extraneous info has been removed for brevity.

#> dig @68.87.68.170 www.ripe.net
; <<>> DiG 9.4.1-P1 <<>> @68.87.68.170 www.ripe.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5769
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2

;; QUESTION SECTION:
;www.ripe.net.                  IN      A

;; ANSWER SECTION:
www.ripe.net.    446     IN      A       193.0.19.25

;; AUTHORITY SECTION:
ripe.net.               172625  IN      NS      ns-pri.ripe.net.

;; ADDITIONAL SECTION:
ns-pri.ripe.net.        172625  IN      A       193.0.0.195

#> dig @68.87.68.170 +dnssec www.ripe.net
; <<>> DiG 9.4.1-P1 <<>> @68.87.68.170 +dnssec www.ripe.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14945
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.ripe.net.                  IN      A

;; ANSWER SECTION:
www.ripe.net.    227     IN      A       193.0.19.25
www.ripe.net.    227     IN      RRSIG   A 5 3 600 20090112060009 20081213060009 58440 ripe.net. Yo8OYqzmR3eDzM6OV0+3dVS7RWFpGR6xhH6GTwe+k8w/PPya+KAm8oaM dArOto4E2DVDJp4XV7wyeWmZujl3tDG4FLCnDSpLgMgAULtxRhtZCPY/ injY/JX1K+fibea3ChE/jSZnaX7oSjNHCYoYzYoSux92K2EkeYC4hy4I lljADsvFhilCaJE7UF4n6XkrWBS8u6OF

;; AUTHORITY SECTION:
ripe.net.               172406  IN      NS      ns-pri.ripe.net.
ripe.net.               120093  IN      RRSIG   NS 5 2 172800 20090112060009 20081213060009 58440 ripe.net. O7O3A9AUOqOMU5/BCG+7rNjqT/7V4qsDtW0GYu+WJuULdGQ1/g+HY4W0 rooQoNTws3BIhs9ZlvD+i6+gtexidx9ePSwigGPrf4lL3Ls6hXm6orAu HK9vrSfuRCd2aoh42naLpiSn4kl3iPyQv8EznSctROr2O+/H6nmbmdTk n+BTJz8T7rD9tXG11n+vbvkBNtc/0TD+

;; ADDITIONAL SECTION:
ns-pri.ripe.net.        172406  IN      A       193.0.0.195
ns-pri.ripe.net.        172406  IN      RRSIG   A 5 3 172800 20090112060009 20081213060009 58440 ripe.net. n7/rTrlOG7yPXW+Fi9lw2fphb9TsSK8TwYCjrcUdnhJvpQ3NcqHaqhec SIse2GuSJ/cpNN6WGIwpGEiC/dHX+4zwnzkWhVTn7XpAnQSUj7289/TE ++v6/6QrfUjRVWqb+VU8RWhrCWhj69zhhRohyjg3e2mideyXmqU0B+rh KhGDHojavw0uukHjCrBHFISXRgW383fX

Notice the only difference in the query was the addition of the +dnssec option. The key thing to note in the 2nd query response is the inclusion of the “ad” flag. This indicates that Authenticated Data was returned – DNSSEC validation worked. The other obvious difference is the inclusion of the RRSIG records, these are the signatures. This example worked because the Comcast recursive server has a trust anchor configured for the ripe.net. domain, which is a DNSSEC signed zone.

DNSSEC ADOPTION ISSUES

DNSSEC does not come without problems. As mentioned, the root and many TLD zones have yet to be signed. This is a primary reason that DNSSEC has not taken off yet; it needs to start at the top to be feasible and manageable. In an effort to kick start deployment, the U.S. government’s Office of Management & Budget released a memo in August 2008 requiring the top level .gov domain to be signed by January 2009, and sub-domains by December of ‘09. The Defense Information Systems Agency has said they will meet the same requirements on the .mil domain.

Directly related to the above problem is the issue of trust anchor configuration not currently being scalable enough to support mass DNSSEC usage. You can sign your company.com zone, but until .com and the root are signed, and a full chain of trust to your domain implemented, resolvers will need a trust anchor configured specifically for your domain. As a temporary workaround, the concept of a Domain Lookaside Validation (DLV) registry has been put in place. With DLV, if a resolver cannot find a DS record in a parent zone, it will attempt to look in a pre-configured DLV registry. The ISC runs a DLV registry; following the above example, the DLV registry would be company.com.dlv.isc.org. For this to work you must register with the DLV registry, the resolver must be DLV enabled, and it must have a trust anchor for the DLV registry.

Mentioned previously, the NSEC record is associated with a zone record and lists the next record in the zone, based on canonical ordering. This enables one of DNSSEC’s goals, authenticated denial of existence, but was quickly identified as being a security threat, as it allows for zone enumeration. This ultimately amounts to a zone transfer, something admins typically work to lock down. To address this issue, RFC 5155 was drafted in March 2008 to describe the NSEC3 resource record, in which a hash of the next record’s name is returned rather than the actual name. This still allows a resolver to authoritatively determine that a record does not exist, while not allowing it to enumerate zone records. NSEC3 is supported in BIND v9.6 or higher.

There are a number of other issues related to DNSSEC that need to be taken into account. I won’t delve much further into them here, but additional research is advised for those considering a DNSSEC deployment. Some of the issues include:

* Dynamic updates: A dynamic update enabled zone will require re-signing when new records are added, which takes time and, if automated, will require the ZSK private key to be accessible – a potential security risk.
* Limited client support: Until DNSSEC support is more wide-spread and at the application layer, signing zones arguably does little to increase security. However, it is advantageous for traffic between recursive and authoritative servers, especially in the case of a trusted internal recursive server. Deploying DNSSEC doesn’t negatively affect current DNS deployment (except for possibly the below point).
* DNSSEC overhead: DNSSEC increases the size of response packets and the workload on resolvers. This is worthy of consideration for both performance and availability reasons. The potential to mount a denial of service attack against either resolver or server is greatly increased.
* Loose time synchronization: A requirement between a validating resolver and DNS signing authority. This is due to the fact that DNSSEC signatures have a validity period, similar to a TTL on DNS records, but rather than relying on elapsed time, these are absolute and expire at a certain time & date.
* Local policies: Configured policies can affect the ultimate security of DNSSEC in an environment; as an example, how should applications handle a DNSSEC lookup failure? Should it prompt the user for acceptance, similar to what Internet browsers do with SSL certificates, or fail outright? This introduces a number of usability issues.

SUMMARY

At this stage if DNSSEC still feels a bit kludgy and pieced together, it’s because it is, but most technology progresses this way. While DNSSEC doesn’t address every DNS security issue, it is a decent start and with the backing of government and other DNS power players, the industry will soon begin making the move to adoption. There is a good deal of confusion regarding the capabilities and implementation of DNSSEC, anyone who may wind up in a supporting role should begin getting familiar with it and consider a trial deployment.

DNSSEC won’t take off en masse until client support is more wide-spread (and the root gets signed). At the risk of sounding like a Microsoft zealot, it really won’t take off until their systems start to support it. Once its usage does increase though, DNSSEC combined with other security technologies will help to increase the overall security posture of the Internet. For more info on DNSSEC, take a look at the links below and check back soon for a post on enabling DNSSEC on BIND.

LINKS

Enabling DNSSEC on BIND
DNSSEC Information Site
RIPE DNSSEC Training Course – good info but old (2005)
Comcast DNSSEC Trial Site
DNS-OARC Resolver Info
Port 53 – Windows DNS Blog, some DNSSEC info
Subscribe to TechScrawl.com

Because it’s the holiday season, when my creativity and free time are both at their lowest, I’m going to take a method from the television world (the clip show) and do a “best of” post. These are the top TechScrawl posts of 2008 based on visitor count and reader feedback.

1) VMWare ESX / Microsoft Hyper-V Comparison – This is by far my most popular post to date. Written in August (before the release of Hyper-V Server standalone) it gives a good feature summary of these two releases. It also got me quoted in the Sept. edition of Computer Business Review magazine.

2) BackTrack 3 Tips – A fairly short post with 3 networking related tweaks, it nonetheless got a ton of hits, owing to the popularity of this security distro. Look for more BackTrack related posts in the future.

3) Simple SOHO IDS with Snort & a DIY Network TAP – One of my first posts after starting this blog in April, it discussed Snort placement in the network and constructing your own network tap.

4) Analyzing Windows Crash Dumps in 3 Easy Steps – Getting started with crash dump analyzing can be difficult. While it can be much more complex than the description in this post, I simplified it down to 3 steps that will be adequate for most troubleshooters.

5) Top 10 IT Security Tasks To Complete Before You Die – A post from early December, but still very popular, partly due to TechScrawl’s recent inclusion in the Security Bloggers Network.

See you in 2009.

Subscribe to TechScrawl.com RSS Feed

Friday Link Round-Up:

Ethical Hacking Course Launched in UK – “students will be taught how to run denial-of-service attacks…tricks of social engineering…as well as how to create viruses“.  I can’t decide if this is a good or bad thing, I guess the info is already out there anyway, so why not?

What Your Computer Does While You Wait – Great post delving into internal architecture and component interaction.

Personal Branding Tips To Avoid Getting Fired – Non-technical but timely article. Tip #9: write a blog, check.

U.S. Unprepared For Cyber-Attack – “The war game simulated a dramatic surge in computer attacks… revealed flaws in leadership, planning, communications and other issues.”

Secure Data Transmission Within Windows Networks – Interesting encryption solution from Unisys facilitating secure data sharing between “communities of interest” in Active Directory based networks. Designed to meet DoD security challenges, but  should see some private sector use.

In this post I describe a recent investigation of suspicious network traffic on an organization’s network. Although the traffic ended up not being malicious, the hope is that the basic investigation methodologies described may be helpful to those in similar situations. The tools used include Wireshark network monitor, select Sysinternals utilities, and those built into the Windows OS.

The Issue

Suspicion was raised by an admin who, while troubleshooting another issue using the netstat command, noticed connections to his workstation from a machine that should have no reason to communicate with him. The connection would close, but seemed to reappear at regular intervals, usually only being seen in the CLOSE_WAIT state.

Investigation

The initial step I attempted in the investigation was to identify the user of the offending workstation using the Sysinternals psloggedon utility, which revealed that no one was currently logged onto the machine. Not knowing the exact physical location of the machine, the next step taken was to start a packet capture in an attempt to further identify the nature of the traffic. Wireshark was used to log packets, and after about an hour a session from the suspect machine was logged. Examining the packets showed that the machine was initiating an SMB connection to TCP port 445. It would first connect to the IPC$ share, then attempt a null session connection to the named pipes \srvsvc (server service RPC server) and \wkssvc (workstation service RPC server), both of which would fail with “STATUS_ACCESS_DENIED” SMB messages. This pattern would repeat several times a day.

While there are valid reasons a null session MSRPC connection would be attempted, it could also be a sign of malicious intent. Needing more information, a remote command prompt was opened on the machine using psexec. This allowed for running netstat with the -o switch which shows the ID of the process associated with any open sockets. After repeating this command a number of times, a connection with the suspect traits finally appeared and the originating process ID was found. Once this was obtained, the tasklist command was used to get the process name associated with the PID. The process was identified as “rssensor”. The final step to identify the process was to search the hard drive for an executable by this name. This was done using the dir command to list directory contents then piping that output to the find command to only display files matching the search string: dir /s /b c:\ | find /I “rssensor”. Had this not yielded any results, a simple Google search likely would have worked.

The Culprit

The final step above found an ressensor.exe binary, and based on the installation path revealed that it was the McAfee Rogue System Detection software, a policy compliance option that had been deployed by an IT security group elsewhere in the organization. The software was supposed to be passive, but further research revealed that it “performed NetBIOS calls on systems to obtain additional information”, which is what we were seeing.

The methods used in this case were only several of many that could have been used to explore this issue further. The goal here was to show the ease with which such investigations could be conducted using a simple and readily available tool set. What other methods of identifying the source of this traffic may have been considered?

Originally published at TechScrawl.com

Subscribe to TechScrawl via RSS

Allow me to get this out of the way first, I’m not a book reviewer, as I’m sure will be evident from reading this post. However I do work in IT, and I do deal with security issues, which makes me one of the potential target audiences for Bruce Schneier’s latest book. If you don’t know who Schneier is, this description from his website sums it up well:

“Schneier is an internationally renowned security technologist and author. Described by The Economist as a security guru… best known as a refreshingly candid and lucid security critic“. He is also the Chief Security Technology Officer of the BT Group.

I received a copy of Schneier on Security several weeks ago, and have read with interest since then his opinions on security. The book is a collection of previously published blog posts and print & newsletter articles written by Bruce over the past few years, so if you’ve been a regular reader of his work this may be nothing new for you.

A recent review of the book on PC Pro makes the claim that Schneier’s “high-level, populist approach … means little in this book will be of practical use to professionals“. I disagree with that statement. There is much in the book that does not pertain to information security, and Schneier’s vantage point on security is certainly from a 30,000 foot view; I won’t argue those points. However, the real value of this book is gaining an insight into the mindset of one of the best security practitioners in the industry. So much of what is done in the name of security is done almost mindlessly without consideration of whether or not it truly improves security, part of what Schneier terms “security theater“. The utility of this book for the average IT professional is in the opportunity to adopt that security mindset, seeing security and vulnerability from a different perspective, and not just adopting a policy because a white paper labels it a best practice, but examining it from an analytical perspective.

As mentioned, there are topics that don’t pertain directly to InfoSec. In the book you’ll find articles on terrorism, airline security, personal privacy, government abuse of power, psychology, etc. As you read these essays though, you’ll begin to see how certain points made could apply to the InfoSec world, and you’ll find yourself starting to rethink your perception of security. Some of Schneier’s main themes throughout the book, security being about trade offs, and security being more a feeling than a reality, are strikingly obvious yet often overlooked. You likely won’t agree with all of the opinions (running open wireless as Bruce claims he does at home? Definitely not.), but I believe that most in the IT field would find this book eye opening and one of the better non-technical security books around.

This book is not for you if you’re looking for a step-by-step guide or specific list of best practices. However, if you’re an IT professional with anything more than a passing interest in information security, I highly recommend picking up this book and/or becoming a regular reader of Schneier’s.

Related Links:

Schneier on Security Blog

Crypto-Gram Newsletter

Subscribe to TechScrawl via RSS

A popular subject in recent books and articles has been the “top x things to do before you die” topic. In that vein, I’ve put together the “Top 10 IT Security Tasks To Complete Before You Die” (you may not want to wait that long though).

1. Have a Security Program

This can be the most difficult one to implement simply because of the planning required, but it can have the biggest long term payoff. The program should include regular contact with users to educate about current threats, social engineering tactics, etc. It should address security policies and procedures, threat escalation and incident response. The program should also include a DR plan. There are many other considerations that need to be taken into account, but the bottom line is that not having a formal security program is a huge mistake.

2. Encrypt Critical Data

There was a time when a company could get away with not encrypting important data. In today’s environment of security breaches, corporate espionage, stolen consumer information, and ubiquitous online transactions, that time is gone. So what should you encrypt? If public exposure would embarrass or be detrimental to your business, encrypt it. Credit card data, consumer PII (personally identifiable information), trade secrets, health care data, internal memos, etc. And laptops and backups. It does no good to encrypt valuable information only to have it stolen outside of the office on a laptop or backup tape. This level of data protection will soon be moving from a “should do” to a “must do”, as evident by recent legislation like 201 CMR 17.00 in Massachusetts.

3. Understand & Control Information Leakage

One of the first things a potential attacker will likely attempt is information gathering for details about your environment and network. Information leakage from areas like Internet email headers, web services banners, carelessly configured DNS, and document metadata makes that task easy for them. This isn’t a super critical subject that needs immediate attention, but it is something that should be addressed to contribute to a good security posture. Take on the role of an external attacker and see what sort of information could be gathered, then get rid of the low hanging fruit. A good example is this 2002 Internet-based Counter-Intelligence study that Matta Security did against the CIA.

4. Harden Authentication

There are organizations that claim to take security seriously, yet still have clear text credentials going over their wires, or easily cracked authentication methods. The biggest offender is a web site with unencrypted authentication, but it’s also not uncommon to find LM Hashes needlessly enabled, critical routers being remotely managed with telnet, FTP access tied to AD credentials, or any number of similar offenses. This subject is much too in-depth to fully address here, the point is to make sure you have a grasp on how authentication is handled in your environment and that it is secured.

5. Monitor Logs

This one is obvious, but still doesn’t always get the attention it deserves. Besides an all out denial of service, log files are typically your first indication of a problem. Keeping up with event logs can be a dull and time consuming process, but there are many excellent solutions available for central monitoring and alerting.

6. Monitor Traffic

While monitoring log files is important, it doesn’t always give a full picture of what is happening on your network. This is where a good traffic monitoring solution comes into play. If you currently have nothing, even something basic that will show deviations from normal patterns (like traffic spikes) is an improvement. Better would be a full fledged IDS solution such as Snort or something comparable. Being able to monitor traffic in real time and alert on suspicious traffic is key to a secure environment. Related to this, making sure you know how to interpret packet captures is a key skill for incident investigation.

7. Implement Checks and Balances

What would be the impact on your business if email was down? How about Active Directory / DNS, your public website, primary storage, routers? The IT infrastructure in most organizations is taken for granted; the fact is that if all or a portion of it were down, business operations might cease. Almost all organizations suffer from the fact that a single person has the capability to cause severe damage to operations (remember the San Francisco Admin?). This can never completely be overcome, but where possible, roles should be separated, strong authentication & access control implemented, and actions audited. Measures such as these help protect not only against malicious intent but also accidental.

8. Implement Fundamental Wireless Security

Most companies have some form of wireless connectivity available. Besides being a convenience, it is often integral to business function. It also can be the entry point for potential attacks. If you have a wireless access point on your network, the only thing keeping the bits and bytes from an attackers computer in the parking lot away from your data in the server room is what you hope is good access control. The best way to combat potential threats is to keep up to date with wireless standards. No one should use WEP, and WPA with TKIP is on the way out. The current recommendation is WPA2 with AES encryption, but the day will come when that is found to be vulnerable too. Address the developments as they come. One of the better implementations for corporate wireless is to keep access points physically separate from the internal network, allowing only Internet access after authenticating, and requiring VPN to then access internal resources.

9. Stay On Top Of Emerging Threats

One of the things that keeps the field of information security so interesting is that it changes rapidly. That fact also contributes to its complexity. New threats arise constantly, and while keeping up with every one of them is not necessary, keeping an “ear to the street” is. You should remain on alert for new zero day exploits, vulnerabilities, or tactics that may be a threat to your particular environment. If, for example, you run an e-commerce site, you should pay attention to SQL injection and XSS vulnerabilities. Host virtual machines with VMWare? Alerts such as this one should be on your radar. This is also where having a good patching strategy comes into play. An excellent way to keep up with emerging threats is to subscribe to a reputable notification list. My personal favorite is the @Risk Consensus Security Alert from the SANS Institute.

10. Pen Test

Penetration testing is still considered by some to be a “hacker” pastime, but the reality is that it is vital for rooting out potential vulnerabilities on your network. Pen testing is also a compliance requirement for certain standards like PCI-DSS. It’s always better to find and resolve holes before some external party finds them for you. There are plenty of consulting companies that will take your money for a good pen test, and for truly comprehensive results you should bring in a professional. However, basic pen testing is also something internal IT staff can do with adequate research. Remember, just because a developer or a large software company says it’s secure, doesn’t mean it is. Trust, but verify.

There you have it, my thoughts on 10 important areas that will contribute to your organization’s overall security. As with any good top 10 list, this one is incomplete and completely subjective.  There are a number of other important information security tactics not mentioned here. Leave a comment and tell me what I left out or what you think does not belong in this list.

This post originated at TechScrawl.com

I’ve used the Snort Intrusion Detection System for about two years, and while I’m far from an expert and my experience with other IDS platforms is limited, I believe Snort to be one of the best solutions out there, especially for the price (free). There is definitely a learning curve associated with it, but Snort is highly configurable and its extensibility means it can be suited to fit the needs of almost any environment.

Like most, I usually run Snort on a Linux system. However, win32 binaries are offered, and I’ve never been able to find any compelling reason against running it on a Windows system. This post documents the steps required to configure a Snort sensor to run on a Windows Server 2008 Server Core platform. With its stripped down environment, Server Core is ideal for running Snort. In addition to Snort, I also hoped to be able to use one of the many popular front-ends for reporting and alerting services. One of the best Windows Snort front-ends is IDSCenter, but it’s a GUI application that won’t run on Server Core, so I decided to go with another favorite, the Basic Analysis and Security Engine (BASE). BASE is a PHP application based on the ACID project. Being written in PHP means it’s platform independent and can run on any web server that supports PHP.

Prerequisites

In order to start this project, a basic Server Core installation of Windows Server 2008 is required. The IIS Web Server role needs to be activated, and PHP needs to be installed. I also wanted to log alert data to a MySQL database, so that needs to be installed as well. I documented those steps in my previous post, if you haven’t seen that, go follow those steps to get the server set up then return here to get started with Snort. There are several requirements for the php.ini file mentioned in that post, so even if you already have a PHP web server running, double check your settings against those in the post.

Snort Setup

The first step obviously is to obtain the Snort install files. I used the most recent release, v2.8.3.1, click here for the download link. While on the Snort site go ahead and download the current rule files too (v2.8 link is here ). This will require a free site registration. Snort on Windows also requires the WinPcap packet capture libray. I used v4.1 beta 4, which supports Server 2008, downloadable from here. The Snort installer will run on Server Core, however the WinPcap installer will not, so you’ll need to use another system (XP works) for that install, then manually copy the required .dll files.

On Server Core, run the Snort_2_8_3_1_Installer.exe file, installing Snort to c:\snort. Next, extract the contents of the zipped up rule file into c:\snort, overwriting any files or folders already present. On your non-Server Core system, run the WinPcap installer. When that completes, copy the following files to the Server Core box, making sure to keep the files in the same directories.

From / To c:\windows\system32 : Packet.dll, WanPacket.dll, WPcap.dll, npptools.dll
From / To c:\windows\system32\drivers : npf.sys

At this point, Snort should be ready for basic functionality. Test this by running the following command, which will show available interfaces:

c:\snort\bin\snort.exe -W

You should see a list of interfaces, make note of the interface number for the one on which you want Snort to listen, you will need it later. Snort is pretty good about letting you know when something is wrong, so if there is a problem, like a missing .dll, you should see that here, which is how I figured out which WinPcap .dlls were needed.

Now that we know Snort works, it needs to be configured for database logging and set up to run as a service. Log in to your MySQL database then run the following commands which will create a database called “snort”, grant privileges to a new MySQL user account, also called “snort”, and create the DB table structure. I’m using username ’snort’ and password of ‘password’ for example purposes.

mysql> create database snort;
mysql> grant all privileges on snort.* to snort@localhost identified by ‘password’;
mysql> use snort;
mysql> source c:\snort\schemas\create_mysql
mysql> commit;
mysql> show tables;

The output of the final command should show a listing of tables in the newly created snort database. Now you’ll need to edit the c:\snort\etc\snort.conf file to work in the Windows environment and direct Snort to log to a database. The file is ugly in Notepad, so I suggest using the DOS edit utility to make the following changes, then save the file.

Under “Step #1: Set the network variables”:
MODIFY:
var RULE_PATH c:\snort\rules
under “Step #2: Configure dynamic loaded libraries” section:
MODIFY:
dynamicengine c:\snort\lib\snort_dynamicengine\sf_engine.dll
ADD:
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_dcerpc.dll
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_dns.dll
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_ftptelnet.dll
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_smtp.dll
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_ssh.dll
dynamicpreprocessor file c:\snort\lib\snort_dynamicpreprocessor\sf_ssl.dll
Under “Step #4: Configure output plugins”:
ADD:
output database: log, mysql, user=snort password=password dbname=snort host=localhost

If that was all done correctly, you should now be able to confirm full Snort operation by running the following:

c:\snort\bin\snort.exe -i 1 -l c:\snort\log -c c:\snort\etc\snort.conf

Modify the -i (interface number) argument to the correct interface number for your system. The -l argument tells Snort to also log alerts to a flat file (required when running on Windows), and -c tells Snort where to get its configuration settings. You should see several screens of info during initialization, after which you should see the text “Initialization Complete” along with some version info. If you see that, you are ready to make Snort a service, if not, address any errors you receive.

To run Snort as a service, you run the previous command, but with the /SERVICE and /INSTALL arguments, for example:

c:\snort\bin\snort.exe /SERVICE /INSTALL -i 1 -l c:\snort\log -c c:\snort\etc\snort.conf

This should complete successfully. You can verify status by running “snort.exe /SERVICE /SHOW” The final two tasks for Snort are to set the service to automatically start, and to actually start it. In the first command, note the space between the equals sign and ‘auto’, this is required.

c:\> sc config snortsvc start= auto
c:\> sc start snortsvc

Upon successful service start, the Snort IDS is now running and monitoring traffic on the selected interface.

BASE Setup

Now that Snort is running and logging alert data to MySQL, we can use the BASE front-end to easily view that data and set up alert notification. I won’t go too deeply into post-install BASE configuration, but the following steps will get it running on your Server Core system. Download the current BASE files here, I used v1.4.1. BASE also requires the ADODB PHP database abstraction library, which you can get here. I used v5.0.6a.

There isn’t much to installing these. Simply extract the contents of the BASE file to c:\inetpub\wwwroot\base. Extract the contents of the ADODB file to c:\php\adodb. Configuration is a little more in depth, but the process is almost complete. First, the following extension needs to be enabled in your c:\php\php.ini file, after which the IIS service (w3svc) needs to be restarted:

Uncomment: extension=php_gd2.dll

There are other php.ini requirements, but if you followed the suggestions in my previous post, they’re already done. Next up is the set up of the BASE configuration file. First, make a copy of the c:\inetpub\wwwroot\base\base_conf.php.dist file named base_conf.php, in the same directory. Make the following modifications based on your setup.

set $BASE_urlpath = ‘/base’
set $DBlib_path = ‘c:\php\adodb’
set $alert_dbname = ’snort’;
set $alert_host = ‘localhost’;
set $alert_user = ’snort’;
set $alert_password = ‘password’;

BASE also requires some additions to the Snort database, so to make those, use mysql.exe with the -D argument (specifies database) to run the following script:

mysql.exe -D snort -u root -p < c:\inetpub\wwwroot\base\sql\create_base_tbls_mysql.sql

The final step is to download additional PHP graphing packages from PEAR used by BASE. This step is optional if you don’t intend to use the graphs that BASE offers. On the Server Core box, cd to c:\php then run the following:

go-pear.bat

At the prompt, press Enter to install system-wide, press Enter on the next prompt (taking defaults), finally accept the suggestion to update php.ini include path, if offered. When complete, run the following commands, one at a time:

pear install Image_Color
pear install Log
pear install Numbers_Roman
pear install http://pear.php.net/get/Image_Canvas
pear install http://pear.php.net/get/Numbers_Words-0.15.0
pear install http://download.pear.php.net/package/Image_Graph-0.7.2.tgz

The End

You can now browse to http://server/base/base_main.php to interact with the BASE webpage. If Snort has been running for a while you may have some alerts in the database already. If not, you can easily create one by browsing to the http://server/phptest.php file mentioned in the previous post.

A lot of configuration options for both Snort & BASE were not covered in this post. This was intended to be a how-to on getting these running on Windows Server Core 2008. There are many other considerations to take into account such as where to place the IDS sensor on the network, further configuration of Snort and Snort rules, setting up SMTP alert notifications in BASE, security implications, etc. Should you want further information, the resources at the links below will assist you.

Snort.org
BASE
Snort IDS & DIY Network TAP

Subscribe to TechScrawl via RSS

Interesting IT & InfoSec related links this week:

30 Skills Every IT Person Should Have – InfoWorld Article. This is one of the better lists like this I’ve come across.

Security Vulnerabilities in SOHO Routers – Very interesting paper discussing a number of the weaknesses found in SOHO routers.

Breaking WEP & WPA – Paper covering the recent WPA TKIP attack.

Roughly 25% of DNS Servers Still Vulnerable – Article covers a recent study showing many DNS servers still vulnerable to cache poisoning attacks.

One of the Server Core roles of Windows Server 2008 that will likely get the most usage is that of IIS Web Server. Already the second most popular web server behind only Apache (see most recent Netcraft survey), IIS running on Server Core may end up being a winning combination for Microsoft. Apache is typically run on top of the Linux OS in tandem with MySQL and PHP, a setup referred to as a LAMP server (Linux, Apache, MySQL, PHP). I had the need for such an environment in a recent project, and with the reduced attack surface, smaller footprint, and the improved IIS 7, I decided to see if Server Core could take the place of Linux in that equation. It’s a setup called a WIMP server (Windows, IIS, MySQL, PHP)… okay, so maybe the acronym needs some work.

Step 1 – Server Core

The first step is to install Server Core and configure it to your liking. I’m not going to cover those details in this post, but if you need assistance see my previous post on Server Core administration. Do the obvious stuff: give it a name, a static IP, configure time/date, etc.

Step 2 – IIS Server Role

The next step is to install the roles required to run web services. Installing IIS 7 is a bit different than IIS 6; doing so in Server Core with no GUI adds some complexity. I researched the steps for doing so and will show them here without explaining them in depth (not sure I could anyway). If you want to learn more, I suggest IIS.net or TechNet.

You use ocsetup to install the required roles with the following command:

start /w ocsetup IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel;IIS-CGI

Once that completes, you should have a functioning web server which you can verify by connecting to your server with a web browser. You should see the IIS7 splash page. You can also drop a basic test HTML file in c:\inetpub\wwwroot and browse to http://server/test.htm to confirm operation.

Step 3 – Install PHP / Configure IIS PHP Support

Installing PHP isn’t nearly as difficult as it used to be just a few years ago. With better native support, IIS 7 also makes things a bit easier. I used the current PHP release (ver 5.2.6) with no problems. You’ll want to download the zip package from here and extract the contents to c:\php on your Server Core box.

Once the files are in place, make a copy of the ‘c:\php\php.ini-recommended’ file, and name it ‘c:\php\php.ini’. Configuring the php.ini file can be a daunting task if you’ve never done so before. I suggest researching the various settings to understand the implications, however, the settings below will get PHP working on IIS. Open php.ini in notepad, make the changes, then save the file. Where I’ve written “Set” means to change the variable’s value, “Uncomment” means to remove the semi-colon preceding the variable.

Set: error_reporting = E_ALL & ~E_NOTICE
Set: extension_dir=”c:\php\ext”
Uncomment, Set: cgi.force_redirect = 0
Uncomment: fastcgi.impersonate = 1
Uncomment: fastcgi.logging=0
Uncomment: extension=php_mysql.dll

You now need to create a PHP handler so IIS knows how to interpret .php files. This is done with the appcmd.exe tool located in %windir%\system32\inetsrv (not in the PATH, so run it fully qualified). The following commands are case sensitive!

appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php\php-cgi.exe']

appcmd set config /section:system.webServer/handlers /+[name='PHP-FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='c:\php\php-cgi.exe',resourceType='Either']

Both commands should return a message stating that config changes were applied. You should now have a functioning web server capable of handling PHP pages. This can be confirmed by creating a test PHP file in your wwwroot directory with the following contents:

<?php
phpinfo();
?>

You should then be able to browse to http://server/phptest.php and see a page showing the descriptive output of the phpinfo() function. Further configuration of the php.ini file may be necessary depending on the web applications you decide to run.

Step 4 – Install MySQL

Again, this is a task that isn’t nearly as difficult as I remember it being several years ago when I first worked with MySQL. There are different versions and different editions of MySQL, I used the most recent version, v6.0.7 Community Edition, Essentials package. The Essentials package is about half the size of the Complete Package as it doesn’t include many optional components. The download link for it is here.

Once downloaded to your Server Core box, run the .msi installer and proceed through the GUI setup. You’ll want to choose the typical settings. When installed, choose the option to run the configuration wizard, choose the Standard configuration, choose to install it as a Windows service, and choose the option to include the bin directory in the Windows path. Set the root dba password, execute the configuration settings, and you’re done. The MySQL service will have started, but a reboot here wouldn’t hurt to confirm service auto-start and to make the change to %PATH% take effect.

Verify MySQL operation by logging in using the mysql.exe command. From the command prompt type:

mysql -u root -p

You’ll be prompted for the root password configured during installation. Once logged in type the following command at the mysql prompt:

mysql> show databases;

You should see a list of system databases, confirming that MySQL is running. You can create a database using the “create database <dbname>;” command.

Congratulations, if you completed these steps, you now have your own WIMP server. I’m not going to go into working with MySQL or writing PHP as they’re both beyond the scope of this article, but if you need assistance check out the MySQL Reference Manual or PHP.net. Of course you can also run this setup with a slightly different configuration, using a different DBMS like SQL Server or Oracle, or even using Apache instead of IIS.

Check back soon for my next post where I’ll discuss the project that required this setup in the first place, running the Snort IDS and BASE security analysis engine on Server Core 2008.

Subscribe to TechScrawl via RSS