Archive for July, 2009

Stateful inspection firewalls Vs. NIPS

July 20th, 2009

Yesterday I wrote about “What makes a system vulnerable?” and had someone call me on this comment here:

Both NIPS and UTM firewalls are based on the same underlying technology (stateful inspection) so the same problems arise here as well.

The individual was confused as they thought these were two distinctively different technologies.

I’m sure at some point in your life you’ve heard the phrases “Don’t judge a book by its cover” or “A rose by any other name would still be a rose”. Both are directly applicable here. Let’s look under the hood to see what we mean.

A stateful inspection firewall is a pattern matching device which has the ability to match on pre-defined patterns in both the header and payload of passing packets (sort of like what Anti-Virus does when checking files). Typically these are IP packets, although its possible to do it with IPX, NETBEUI, etc. as well.

What distinguishes stateful inspection from stateful packet filtering is the ability to analyze the payload. Stateful packet filtering can only analyze header information. You may have head the term “deep packet inspection”. This is vaporware created by one or more marketing people who have probably watched too many porn videos. Once you are inspecting the payload there is nowhere deeper to go in the packet, except maybe the Ethernet CRC check which would provide zero security value from Internet based attacks.

A Network Based Intrusion Detection System (NIPS) also leverages stateful inspection to pattern match on passing packets. Typically it uses a number of signatures, or pre-defined patterns the device has been programmed to for, in order to flag and screen out known malicious patterns. Both the header and payload of IP packets can be screened for these known patterns. So NIPS pattern matches on the header and payload, just like a stateful inspection firewall.

Consider the following products:

Check Point UTM-1 or Power-1
TippingPoint (3COM) 10 or Core Controller

While Check Point is considered to be the classic firewall and TippingPoint represents the cool new NIPS technology, both offer similar features for screening out known malicious patterns on the wire. In fact both offer subscription services for keeping these signatures up to date. Check Point calls it “SmartDefense” while TippingPoint calls it “Digital Vaccine”. So both product lines are levering stateful inspection to check headers and payload (although the TippingPoint product does not seem to maintain state as often as Check Point, but that’s a topic for another post ).

So if its the same underlying technology, why don’t we simply call NIPSs stateful inspection firewalls? This was one of the best marketing slicks I’ve ever seen in the security industry. Think of it this way, pretend you are the security manager for your company (or maybe you already are, in which case you don’t have to pretend that hard ), I’m a sales person who walks into your office and says:

“Hi, I have this great new stateful inspection firewall I want to sell you”

What is your reply going to be? Probably something like:

“No thank you. I already have one I’m happy with”.

Now, I walk in and say:

“I have this spiffy new network based intrusion prevention system I want to sell you”

Now the response is more along the lines of:

“Wow! I don’t have that yet. Can I buy two?”

You get the idea. By changing the name we make it sound like its a new bleeding edge “must have” technology, which makes it easier for the sales people to generate a commission. When it comes to what happens on the wire however, its just a repackaged familiar tool.

Hope this clarifies the topic!

No comments »

Posted in 2-alert, Network Security

Tags: firewall NIPS signature detection stateful inspection

What makes a computer system vulnerable?

July 19th, 2009

Consider the following five systems:

A Web server
A desktop system
A “Next Gen” or Unified Threat Management (UTM) firewall
A Network Based Intrusion Prevention System (NIPS)
An isolated system only used to process Web server logs

Here’s the $42 question; if we assume the above network has an Internet connection, which of these systems are susceptible to remote attack (meaning over the wire from the Internet, not via direct access to the keyboard)?

Seriously, don’t just skim the question, give it some serious thought. Your answer is obviously going to have a direct impact on how you implement a security posture or assess network risk. Pretty major stuff.

Let’s talk about each system individually before we say exactly how many are vulnerable to remote attack. The Web server has at least TCP/80 exposed to the Internet. This provides a socket that a remote attacker can connect to in order to interact with code running on the Web server. Its this interaction with local code that makes the Web server susceptible to potential attack. Consider this the classic view of risk as we’ve known these system are vulnerable for many years.

So let’s talk about the desktop. While desktops usually do not have sockets exposed to access from the Internet, they do initiate communication sessions with remote servers. Java, ActiveX, etc. can be leveraged by those remote servers in order to interact with code running on the desktop itself (think Conficker and you’ll get the idea). So as it turns out the desktop is vulnerable as well because a remote system can interact with locally executing code via these outbound sessions.

So what about the UTM firewall? If it has no open ports and does not originate outbound sessions, surly it must be safe, right? Think about how a UTM firewall operates. The IP header and payload is scrutinized in order to provide Malware, content, SPAM, etc. checking. In other words, the packet is read into memory and processed by local code in order to provide these services. “Processed by local code” means of course we’re interacting with it. So its entirely possible that a remote attacker could leverage this level of access to whack the system (usually this takes the form of a simple DoS attack, but remote code execution has shown up in the wild).

OK, what about the NIPS? That one is easy. Both NIPS and UTM firewalls are based on the same underlying technology (stateful inspection) so the same problems arise here as well. The NIPS is also vulnerable to remote exploit.

So that leaves us with just the isolated system which is parsing Web server logs. Safe or not? Turns out, this system can be remotely whacked as well, the attacker just has to be a bit more clever. Let’s follow the path from the attacker’s system to this internal host.

The attacker hits the Web server, which dutifully writes what it sees to a log file. If I can embed malicious code in the log file, that will get passed to the isolated internal system when it parses the Web logs. Mike Poor told me of an interesting hack he ran into at a client where a remote attacker injected Java code in the user agent field as they visited his client’s Web site. When the local Admin used a Web browser to view their Web server logs (of course running as an Administrator equivalent!), the browser saw the Java code and executed it locally. The code then attempted to create a reverse socket connection so the attacker could gain remote access to the box.

So for those who are keeping score, every system listed above is vulnerable to remote attack.

What’s the moral of the story? Exposure to remote attack is not about “open listening ports on the local system”, its about “permitting a remote system to interact with code running on the local system”. This can either be directly as in the first four examples, or indirectly as in the last one. Once we realize that remote code access is the true root cause of the problem, we also realize our exposure to risk is a lot higher than we thought.

1 comment »

Posted in 3-err, General Security

Tags: exploits host security vulnerabilities

The ideal scientific test for finding a compatible geek match

July 18th, 2009

While mundanes may think we geeks are happy with a significant other that simply has a pulse, we the initiated understand that it takes a truly unique spirit to be compatible with our life style choice. Dating is hard; and while there are certainly good dating sites out there for common folks, none really address the needs of the true geek. They rely on psycho-babble questioneers to check for imaginary attributes like “cognitive mode” and “relationship skills”. As a geek I don’t need a service that will check 29 dimensions for my perfect match. I’m only interested in a significant other that occupies this specific space/time.

So what we geeks need is a pure scientific test that will validate to within a satisfactory margin of error, say +/-0x0A%, our perfect compatibility mate. Preferably the testing will include sparks and cool technology, because we are geeks after all.

In order to define a proper testing methodology, we first need to delineate the criterion our test would be attempting to validate. I humbly suggest these test items should include:

Subject has a pulse
Subject has a neutral personality to deal with our obsessive behavior
Subject plays well with IC’s and other ESD sensitive equipment
Subject assumes we are smart and will trust us even when their common sense tells them otherwise
Subject is capable of generating an ion stream from their fingers for those “sexy” times

It is this author’s opinion that the only scientific device capable of properly testing all of these attributes is a Van de Graaff generator. Luckily, a typical home model in the 350,000 to 400,000 volts range should be perfectly sufficient. If your generator is currently unavailable because you are leveraging Tesla’s wireless energy transmissions, borrow one from a close friend. If neither you nor your close circle of friends owns a Van de Graaff generator, well, you’re not really a true geek and this post will not apply to you anyway.

A Van de Graaff generator perfectly suited for home use

One of the benefits of this method of testing is that it does not require a single or double blind testing methodology. Just smoothly drop into the conversation “So would you like to touch my Van De Graaff?”. Even if the subject suspects that you are testing them for compatibility, it will have no impact on the final results (assuming they have not mastered the Zen art of changing their salinity ratio).

What you will need:

A Van de Graaff generator (AKA “Love Meter”)
A high resistance platform
Exactly 42 pieces of Rice Krispies
A recently calibrated laser angle measurement device
A sonic distance measurement device

Testing is relatively straightforward. Simply have the test subject stand on the platform and place one hand on the Van de Graaff generator. Now turn on the power and BACK AWAY VERY QUICKLY. At this point the test subject has already passed test item #4. Their common sense must be screaming that this is a bad idea. We are off to a good start.

Now, wait exactly 31.4159×10^-1 seconds and observe/measure the angle of inclination of their hair strands. The ideal candidate will show a deflection rate of no more than NCC-17.01 degrees. A deflection rate of NCC-17.01A and certainly NCC-17.01B is NOT acceptable. Figure 2 shows a common example of a failed testing condition. Note the expression indicates the test subject probably already realizes they have failed our test.

This test subject clearly fails the first part of our Van de Graaff testing

If the subject passes the first test, we have validated test item #2. They clearly have a well grounded personality to put up with this type of activity. It is now time to move on to the next part of our testing.

Have the test subject remove their hand from the Van de Graaff and then power it down. Place the 42 Rice Krispie pieces in their other hand. Note the subjects hand must be dry for this portion of the testing. This can be difficult to achieve as its not uncommon for test subjects to heavily perspire from their palms when in the presents of a true geek. Enact level 1 containment and clean up procedures. If the problem persists complete the testing from behind a one way observation screen. If the problem still persists hang up a copy of the Periodic Table and point out the elements you feel are the most attractive.

With Rice Krispies in hand, have the test subject stand on the platform and place their other hand on the Van de Graaff. You did remember to discharge the Van de Graaff after the last test…right? If not the test subject will receive a relatively harmless 300,000 volt shock but it will probably be sufficient for them to mandate the conclusion of testing.

If you did remember to discharge the device, wait the appropriate 31.14159×10^-1 seconds and have them extend their hand as shown in Figure 3. Note the test subject in Figure 3 easily passes the first testing. Now we simply need to determine how many Rice Krispies fly out of their hand in a projectile fashion. A maximum of two Rice Krispies travelling a distance of no more than .5 meters is considered acceptable. This will validate test item #3. Passing this test indicates the test subject exhibits a high resistance to channelling an electrostatic discharge.

Subject passes initial testing. A final Rice Krispie count must be taken for final validation.

If the subject has passed all of the previous testing, its now time to move on to the final, and arguable the most important test, test item #5. The importance of the test subject being able to generate an ion stream during “sexy” time can not be over stressed. Luckily this is also one of the easiest tests to perform. While touching the Van de Graaff generator, simply have the test subject point at the center of your body. If this produces a tingling sensation in that area, then a sufficient ion stream has been generated and the test can be deemed a success.

Please note that this author has received reports from other geeks that the application of a wedding ring appears to interfere with a test subjects ability to generate the ion stream. Experts in the field are currently investigating a resolution to the problem, but it appears that the installation of a wedding band causes the ion stream to be dispersed. Sonic signatures from this discharge may resemble the song You Lost That Lovin’ Feeling. Its also not uncommon for test subjects to exhibit chronic headaches. If you install a wedding ring on the test subject the above testing becomes void and you do so at your own risk!

I hope you have found this testing procedure helpful.

6 comments »

Posted in 5-info, Humor

Tags: geek date test geek humor

What does the little lock icon mean in my browser? – Part 3

July 17th, 2009

In the first two parts of this post, I described what goes on when creating an HTTPS connection to a Web server. In this third and final part I’ll get into what can go wrong.

What can go wrong if I trust the rabbit hole?

For the sake of argument let’s assume we “feel” the HTTPS process is trustworthy all the way down to the bottom of the rabbit hole. Our first problem is we never actually go there. Check out Figure #1. This shows some of the configurable options for Internet Explorer 8. Note the two circled lines.

The first one, “Check for Publisher’s certificate revocation” attempts to validate the locally stored digital certificate. Its on by default, but all its really doing is checking to see if the trusted third party has identified their signing server as being compromised. If they have not figured it out yet, or if an attacker is able to compromise this session, all bets are off. In other words, in part 2 I described a path all the way down the rabbit hole to a self signed digital certificate. What this option is tells us is that we are never going to check down that far. We’ll do a quick check one level deep and stop there.

Now, look at the second line which is circled, “Check for server certificate revocation”. Note this option is turned off by default. So while you could be checking to see if the Web server your talking to had it’s digital certificate revoked, you don’t bother because of an options setting. The concept is “Hey you can trust Verisign because they never mess up”. In part 2 we also discussed how this is not always the case.

Does SSL and TLS always encrypt my data?

As mentioned in part 1 of this post, SSL and TLS are a framework. They pull together a lot of possibilities for securing your data but leave the particulars to the negotiation between the client and the server. Consider the picture shown in Figure #2. These are the SSL and TLS options for a Firefox Web browser. Note the lines within the red box.

Firefox let's you select which privacy options to support

The first option says “Use RSA for initial authentication and HMAC-MD5 to authenticate each packet”. The second option says the same thing, but to use HMAC-SHA for packet level authentication. Notice anything missing? Like… how should we be encrypting the data? Both of these options specify authentication without any kind of encryption.

Why is this even a possibility? Because sometimes its enough to know your datastream can not be changed in transit. You might not be worried about people seeing the data or it may be possible that you are located in a country which does not let you encrypt your information. If either is the case, SSL and TLS can still help you out.

Now, remember back to part 1 of this post I said that in an SSL/TLS handshake we go with the highest level of data privacy supported by both ends of the connection. With this in mind, you hopefully will never see “no encryption” negotiated in the wild. If however this is all the remote server wants to support we may be in trouble. Luckily Firefox has both of these options disabled by default. But what about other browsers? That’s the kicker. Most browsers will let you select the version of SSL and/or TLS you want to support. They will not let you drill down to specific protocols. So this could be on and you would never even know it.

And now back to that little lock icon

I have a love/hate relationship with the little lock icon. I like the idea of making it simple for users to figure out when their data is being secured. I hate the idea that the accepted implementation is a little graphic that it very easy to duplicate. For example, have a look at Figure #3. Note the bank has placed a copy of the lock icon right on the logon page. Does this really tell us the data is being secured? Absolutely not! It could just as easily be a picture of a cute kitty cat. In this context the lock icon is nothing more than a display graphic.

Note the lock icon within the HTML page

OK, so let’s look around our browser window a bit. In older browsers I got used to seeing the lock icon at the bottom right of the screen. Hey look at figure 3 again, there’s a lock icon at the bottom right of the window! So that tells us our data is secure, right? Nope. In IE8 Microsoft changed the browser layout. That specific lock icon will tell me if the browser is filtering content coming from the Web site. So a user who does not do their homework will probably think every site on the Internet has been secured. Why didn’t they use another graphic to avoid this confusion???

Look to the right of the URL. Hey, there’s the lock icon! Yup, so this is where the user is suppose to look. There is just one problem however. If you are reading this post directly from my site you will notice you also have a lock icon to the left of the URL. All I did was mess with favicon. So by drawing the users eye to the URL to look for the lock icon we just made it easier to fool people into thinking their data is secure when its really not. Will the typical end user notice/care that the lock icon is before or after the URL? Yuck.

So where are we at

To summarize what has been discussed so far:

Liberal use of the lock icon can fool users into thinking their data is secure
Our security protocols support transmission of data without encryption
Digital certificates have a server at the bottom of the rabbit hole saying “trust me because I say its OK. Here, have some candy little geek” (OK, the candy bit is not part of the spec )
The rabbit hole really is not a problem because we never look all the way down it anyway
We have security checks we choose not to use
We produce error screens that end users have become accustom to ignoring
If an attacker can break initial authentication, the integrity of the whole session falls apart
Security experts keep figuring out how to forge certificates and are finding new exploits all the time

Sanity check time

OK, so its easy to feel like the whole thing is insecure and we should run away to Vermont and build a moat around our house (inside joke, I know someone who has done this). Here’s some simple advice for the non-cipher- wienies that will help keep you relatively secure on the Internet. If you want full protection, disconnect now and build your own moat.

1) Look for HTTPS in the URL

Forget about lock icons and other fancy stuff. If you see “HTTPS” instead of “HTTP” then you know you are using SSL or TLS to secure the datastream. Remember this does not guarantee data privacy, so we still have more to do.

2) When in doubt, check the connection

Take a look at Figure #4. When I connected to this site and saw “HTTPS” I double clicked on the lock icon. That produced this dialog box. There is some real useful information here, like what level of encryption is being used to provide data privacy. This will tell me if my data is “safe” (encrypted).

Double click the lock icon during an HTTPS session to produce this screen

This will also identify who issued the digital certificate. Remember the bottom of the rabbit hole is warm fuzzy. This means you really have to ask yourself if you think the issuing company has a clue about security, because you have little ability to check for yourself. Personally I never trust a server or company that signs their own certificates (this means you American Express!) because your options for verification are even more limited. They are just begging to get their client’s data compromised in order to save a few $$$ by not purchasing a certificate from a well known authority (note: Its OK to sign your own certs if you manage both ends of the connection, but this is not the case when we visit an e-commerce site).

3) Tweak your browser options

Finally, leverage what ever options your browser gives you to lock down your HTTPS sessions. I mentioned initial authentication comes down to a subjective judgment call, and the security of the rest of the session teeters on this point. If you sleep better verifying all certificates, go for it. If you feel comfortable just verifying with local info, that’s fine too (its your data after all). Yes SSL and TLS have some issues, but its the only game in town so do the best that you can with it.

4) Leverage your common sense

Last December I logged on to my bank site to pay some bills. When I was redirected to the payment server, I was presented with a self signed certificate. I’ve used this bank for years and know they use Verisign to sign their certificates. I immediately told my browser “no thank you”, and found out a day later the site had been hijacked.

The best way to keep your data safe is to use your head. If things do not look right, there is probably a reason why. While it can sometimes be hard to wrap your brain around the intricacies of technology, good old fashion street smarts can go a long way towards keeping you out of trouble.

That’s about it. Hope you found this info useful and don’t forget to tip your waiter!

1 comment »

Posted in 2-alert, VPN

Tags: best practice digital certificates HTTPS lock icon SSL TLS

What does the little lock icon mean in my browser? – Part 2

July 16th, 2009

In my last post I started talking about why your data might not be as secure as you think during an HTTPS session. We made it as far as the mandatory handshake requirements with SSL and TLS. In this post I’ll get into the optional features which is the start of where things can go wrong.

Optional portions of the SSL/TLS handshake

After the initial client/server exchange, the two end points are free to choose which options they feel are appropriate, depending on how the administrator has configured them. Next we could:

Client can check the authenticity of the server using local info
Client can go back to the trusted authority and check the certificates authenticity
Client can check the authenticity of the trusted authority’s issuing server
Client can send a copy of its digital certificate to the server
Server can validate the client’s digital certificate if it has one
Server can require the client to have a valid digital certificate

Wow! Lots of possibilities. We typically don’t implement the last three unless we have control of both ends of the connection (like with a VPN). For a secure connection to a Web server, we’re typically looking at just the first three possibilities.

How digital certificates work

First, let’s talk about those digital certificates. A digital certificate contains the public key for the entity described within the certificate. So the server is basically saying “This is who I am and here is my public key for asymmetrically encrypted communications”. The way you know you can trust this certificate is that it has been digitally signed by a mutually trusted third party, like Verisign. Specifically, its been signed using the private key of a certain server under Verisign’s control. The concept is you can use the public key of the Verisign server to check the signature created by its private key. If the hash validates, you know the digital certificate has not been messed with.

OK, here’s our first problem. The information we use to validate the web server’s certificate is actually a copy of the Verisign server’s digital certificate stored on the local system. Hummm. So if the client becomes compromised, we can fool it into thinking a bogus digital certificate is actually legitimate, right? Absolutely. However this would only be useful in specific situations. If I can compromise the client there are probably easier ways to get access to the information I’m looking for.

If we want to ensure we’re safe however, we can go with option #3 above and check the validity of the locally stored Verisign certificate. This would send us out to Verisign server #2 to get its digital certificate. If we want to insure that our copy of Verisign server #1′s digital certificate is OK, we can use Verisign server #2′s public key to check the hash. If the hash validates, we know the digital certificate for Verisign server #1 is valid.

Hummm. So how do I know an attacker didn’t mess with the transfer of Verisign server #2′s digital certificate? Because that has been digitally signed by Verisign server #3. Go get that server’s public key and check the hash. How do I know Verisign server #3′s cert has not been messed with? You guessed it. Go get the digital certificate from Verisign server #4. While this sounds pretty complex (and it is!) this gives us sound math we can work with. In other words, smart crypto people can look at this math and predict how safe it is to use. Cool. I’m a geek so trusting math is a natural. The problem however occurs at the bottom of the rabbit hole.

Why should I trust you?

Eventually we will run into what is called a self signed digital certificate. This is basically a server’s way of saying “trust me because I say so”. In other words, there is no math to calculate if we should trust this server or not. All we have is “warm and fuzzy”. In other words, we need to sit in a Buda pose, sign Kum Ba Yah, get in touch with our inner child, pointy up our ears, and ask ourselves “How do we feel?”. Really, that’s all we’ve got, and there is no wrong answer because its subjective. If we “feel” that final system is secure, then it is. If we “feel” it is insecure than it is. There is no math to help point us in one direction or the other.

What if the trusted third party messes up?

So you may be asking yourself “All that sounds great, but what if the trusted third party makes a mistake and gives a digital certificate to the wrong party?”. First of all, that could NEVER happen. Oh wait, it has happened. Seriously, this is a valid concern as the chances of catching this after the fact are minimal.

Its possible to “revoke” a digital certificate. This is a trusted third party’s way of saying “Oops, we screwed up. You really should not trust that digital certificate we said is trustworthy”. So the concept is, when you get the Web server’s digital certificate you can go back to the issuing server to see if its been revoked.

OK, that’s set the groundwork for our HTTP session. In the next installment we’ll talk about what can specifically go wrong if we trust the security of the rabbit hole.

1 comment »

Posted in 2-alert, VPN

Tags: digital certificates HTTPS SSL TLS

What does the little lock icon mean in my browser? – Part 1

July 15th, 2009

You’ve been lied to, or at the very least mislead. Most sources will tell you:

If you see the little lock icon in your browser
If you see “HTTPS” instead of “HTTP” in the URL
If you see the URL background change from white to yellow (depends on the browser)

Then your data is secured. By “secured”, most of us assume this means “The session is authenticated, encrypted and the authenticity of the server has been verified”. Unfortunately, this is not always the case. All the little lock icon tells you is that SSL and TLS is in use. Depending on where you actually see the little lock icon, even that much may not be true.

What is SSL and TLS?

Normally communications on the Internet take place in clear text. This means that anyone looking at your traffic can read it, and just as importantly, change it in transit. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are attempts to provide some level of protection for TCP based communications. When you see “HTTPS” in your URL, what that really means is you are running an HTTP session secured by either the SSL or TLS protocol.

We started off using SSLv1. Today we are up to SSLv3 and moving towards TLSv1. What’s the difference between SSL and TLS? For the most part, SSLv3 and TLSv1 are pretty much the same thing. The big difference is that Netscape created and owns the rights to SSL. TLS is an open specification. On the Internet we like to use open standards as often as possible.

Both specifications can be considered “sticky frameworks”. By that I mean the real job of SSL and TLS is to meld together a bunch of other specifications for the purpose of securing a datastream. For example neither defines specifically how to authenticate each packet, they simply point to HMAC-MD5 and HMAC-SHA and say “use that”. Neither specifically tells you how to encrypt the data, they just point to other specifications like RC4, DES and AES and say “use that”. This modular structure is pretty cool as it makes the specifications very flexible. It also ensures that these specifications will not easily be outdated. For example most of us know that DES uses far too small a key size to withstand a modern day brute force attack. No problem for SSL or TLS, just change to another encryption algorithm.

How SSL and TLS work

Both SSL and TLS are pretty lose frameworks. By that I mean that while some things are mandatory, a lot of what goes on in the communication session is optional. Let’s look at a typical session to see what we mean:

The client initiates communications with the server and starts the negotiation. The conversation goes something like this:

Client to server:

“Hi, I can fall back as far as using SSLv2 but would really prefer to use TLSv1. Here are the methods of securing the datastream I support …”

Server to client:

“No problem, I can support TLSv1. Out of the data protection methods you support, here’s the highest one we have in common…”

Server to client:

“Here’s a copy of my digital certificate.”

A couple of things to pull out of this exchange. The client identifies which security protocol it wants to use, but gives the server the option of falling back if required. This help with backwards compatibility, but its key to understanding why your session can end up being less secure than you thought it would be. The same thing happens with the methods or authentication and data privacy. The client identifies what it wants to use, but gives the server less secure options in case they are needed. Finally, the server sends the client a copy of its digital certificate for initial authentication purposes.

All of the above negotiations are required under the SSL and TLS protocol. What happens next however is optional. This is where our problems begin, and I’ll discuss that more in part 2 of this post.

No comments »

Posted in 3-err, VPN

Tags: HTTPS lock icon SSL TLS

Test your network security skills

July 15th, 2009

As mentioned on the About page, I spend a bit of time teaching computer security via SANS as well as directly to clients. When people ask me if they would get anything out of taking my SANS course, I point them to this quick test. If you can score 12/15, you are in good shape. Less than that, and you need to cut the knowledge curve. I’ll put the answers in a different post so its less tempting to cheat.

Note: I’ve messed with the submission dates so the answers do not appear before the questions on the main page.

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.
B) 2
C) 4
D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

A) Ping run on a Windows system.
B) Ping run on a Linux system.
C) hping using the “-C 8” option.
D) nmap using the “-sP” option.

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.
B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.
C) Advertise all portions (even unused) of your IP address space via BGP.
D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point
B) Cisco
C) Netscreen
D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable
B) ip[12:2] = ip[16:2]
C) ip[2:2]<0x1F4 and ip[6]&32!=0
D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.
B) nmap “idle” (-sI) scan.
C) nmap “decoy” (-D) scan.
D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.
B) All data to and from the Web server is at least encrypted.
C) All data to and from the Web server is encrypted and the digital certificate is fully verified.
D) All data to and from the Web server is authenticated and encrypted.
E) All data to and from the Web server is authenticated, encrypted and the digital certificate is fully verified.

8 ) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

A) Problem with the firewall state table time-out being set too low.
B) Automatic update checking for new patches.
C) Attacker retrieving a toolkit.
D) A secure HTTPS session.

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

A) TCP transmission from a Windows system.
B) SMTP transmission from a Windows system.
C) Spam or Phishing attempt from a Windows system.
D) SMTP transmission from a Linux or UNIX system.

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

10) Given the following netstat output, which of the answers best describes the situation:

A) The system has potentially been compromised.
B) The system needs a restart to install updated software.
C) The system is configured as a typical Windows desktop.
D) The system is configured as a typical Windows server.

Proto Local Address          Foreign Address        State           PID
TCP    0.0.0.0:80           0.0.0.0:0              LISTENING       2648
TCP    0.0.0.0:80               0.0.0.0:0              LISTENING       2292
TCP    0.0.0.0:135               0.0.0.0:0              LISTENING       1204
TCP    0.0.0.0:445               0.0.0.0:0              LISTENING       4

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.
B) A desktop with Internet access.
C) A firewall or Network Based Intrusion Prevention (NIPS) system.
D) All of the above.
E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.
B) Stateful inspection based firewall.
C) Neither, it is its own unique technology.
D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.
B) A remote site is having connectivity issues connecting to our Web server.
C) The state table time-out value on our firewall is set too low.
D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK
Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5
Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53
Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53
Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN
Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.
B) 192.168.1.22 is downloading patches.
C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.
D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

15) Analyze the following network drawing. How many potential paths does an attacker have available in order to gain access to the internal network?

A) 1
B) 2
C) 3
D) 4

Answers will be posted tomorrow!

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.

B) 2

C) 4

D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

A) Ping run on a Windows system.

B) Ping run on a Linux system.

C) hping using the “-C 8” option.

D) nmap using the “-sP” option.

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.

B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.

C) Advertise all portions (even unused) of your IP address space via BGP.

D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point

B) Cisco

C) Netscreen

D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable

B) ip[12:2] = ip[16:2]

C) ip[2:2]<0x1F4 and ip[6]&32!=0

D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.

B) nmap “idle” (-sI) scan.

C) nmap “decoy” (-D) scan.

D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.

B) All data to and from the Web server is at least encrypted.

C) All data to and from the Web server is encrypted and the digital certificate is fully verified.

D) All data to and from the Web server is authenticated and encrypted.

You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

A) Problem with the firewall state table time-out being set too low.

B) Automatic update checking for new patches.

C) Attacker retrieving a toolkit.

D) A secure HTTPS session.

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

A) TCP transmission from a Windows system.

B) SMTP transmission from a Windows system.

C) Spam or Phishing attempt from a Windows system.

D) SMTP transmission from a Linux or UNIX system.

10) Given the following netstat output, which of the answers best describes the situation:

Proto Local Address Foreign Address State PID

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2648

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2292

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1204

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

A) The system has potentially been compromised.

B) The system needs a restart to install updated software.

C) The system is configured as a typical Windows desktop.

D) The system is configured as a typical Windows server.

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.

B) A desktop with Internet access.

C) A firewall or Network Based Intrusion Prevention (NIPS) system.

D) All of the above.

E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.

B) Stateful inspection based firewall.

C) Neither, it is its own unique technology.

D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.

B) A remote site is having connectivity issues connecting to our Web server.

C) The state table time-out value on our firewall is set too low.

D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK

Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5

Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53

Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53

Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN

Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.

B) 192.168.1.22 is downloading patches.

C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.

D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

No comments »

Posted in 2-alert, General Security, Network Security

Tags: computer security network security security training

Test your network security skills – Answers

July 15th, 2009

In yesterday’s post I gave you a quick network security test to try. Here are the answers:

1) D

There are six different techniques that can be used to sniff in a switched environment. ARP cache poisoning, ARP cache flooding, DHCP spoofing, Port stealing, ICMP redirect attack and ICMP route discovery attack. High end vendor switches can be configured to block all of these except the ICMP redirect attack. That must be addressed on a per host level.

2) D

Ping on both Windows and Linux encapsulate data in the payload of their Echo-Request packets. The above packet has a length of 28, which is just an IP and ICMP header. When hping generates Echo-Request packets, it uses an initial sequence number of 0 and then increments by +256. The above sequence number of 21446 is not evenly divisible by 256. This makes nmap the most likely candidate as it generates empty payload Echo-Requests with random sequence numbers.

3) B

When your address space is spoofed as part of a SYN flood attack, you will see a high number of unsolicited SYN/ACK packets being sent to your network. Quietly dropping this traffic makes your address space highly attractive to attackers spoofing packets because it maximizes the amount of time their attacking SYN packets fill up the remote connection queue. By returning an ICMP error for these packets, your IP address space becomes less desirable as you are quickly removing the attacking SYN packets from the remote connection queue.

4) C

All three products prevent source route packets (both loose and strict) from being bounced off of the firewall itself. Netscreen however will pass loose source route packets targeting a host on the other side. So to be safe from redirection attacks in a Netscreen environment, you must ensure source routing is disabled on all exposed hosts.

5) C

The first portion of the filter, “ip[2:2]<0x1F4” checks to see if the packet is less than 500 bytes in size. The second portion of the filter, “ip[6]&32!=0” checks to see if the more fragment flag is turned on. So the complete filter will catch non-last fragments smaller than 500 bytes. All non-last fragments will express the smallest topology Maximum Transmission Unit (MTU) they pass through. The smallest LAN or WAN MTU used in the Internet is 512 bytes. So fragments smaller than 500 bytes are being crafted, most likely to obfuscate an attack pattern and avoid detection.

6) B

An idle scan leverages the predictable IP ID’s being used by a secondary system in order to make it appear that all the scanning packets are originating from that host. Since all the scan packets use the spoofed IP address of this secondary host, the attacker’s true IP address is not revealed to the host being targeted. nmap’s stealth and decoy options still transmit packets using the attacker’s true source IP address.

7) A

The protocol HTTPS and the little lock icon being activated on a Web browser simply means that the SSL or TLS protocol is being used to secure the data stream. Both specifications require that every packet be authenticated. Both specifications make encryption an optional feature. So its possible to use either SSL or TLS to communicate without encrypting any of the data passing between the systems. The only way to prevent this is to disable these options in your browser. Further, digital certificates are typically checked against a locally stored public key, but the browser does not check to see if the certificate has been revoked. This can also be changed through the browser’s options.

8 ) C

The traffic in question is an outbound attempt to connect to a TFTP server. Since Web servers do not use TFTP, this is not a problem with the firewall state table. Also, vendors do not make fixes available via TFTP, so this is not a check for new patches. The most likely candidate is that an attacker has compromised the system and is attempting to move their toolkit onto the box.

9) C

The TTL value in this packet is 112. Linux and UNIX use a starting TTL of 64, so this packet most likely did not come from one of these systems. Windows uses 128 as a starting TTL so this could likely be a Windows host located 16 hops away. This is a TCP packet headed to port 25, so it is most likely the start of an SMTP session. The system is using a very small window size (8192 bytes) and does not support the TCP windowing option (this would be listed in the output as “wscale” followed by a numeric value), which indicates that it is an older Windows desktop system. Since most organizations do not rely on old Windows desktops as their SMTP servers, this is most likely a compromised host transmitting spam or phishing attacks. A firewall such as pf or Netfilter would be able to filter these packets by passively identifying the source operating system.

10) A

Within a Linux or UNIX environment, ports can only be opened exclusively. This means that only one application can hold open a TCP or UDP listening port at any given time. While most Windows applications open ports exclusively as well, Windows permits applications to listen with non-exclusive access. The result is that one application will service most inbound sessions but if that port is busied out, connections are then passed to the second application. This can permit an attacker to open a back door on a system that is undetectable during port scans of the system.

11) D

The classic view is that only systems with open listening ports exposed to Internet access are susceptible to attack. The point of risk is in fact permitting unknown entities to interact with code running on the local system. All of the indicated systems permit some level of code interaction with untrusted IPs on the Internet. With this in mind, all can potentially be remotely compromised.

12) B

Network based intrusion prevention systems leverage stateful inspection technology to analyze both header and payload information, same as a stateful inspection based firewall. Sometimes NIPS provides more signatures to look for hostile patterns, but most high-end stateful inspection firewalls provide multiple signatures as well, but typically at a lower cost.

13) A

There are many suspicious patterns in these log entries. To start, the Time To Live (TTL) in the first packet is 2. Given modern OSs use a starting TTL of 64 or higher, and most systems are about 15 hops away from each other on the Internet, we should never see a TTL this low. Most likely this is someone running a TCPTraceroute variant to map our network through the firewall.

Look at the length of the first three TCP packets; its 40 bytes. This means no TCP options have been set. All modern day operating systems support some number of TCP options, so these looks like crafted packets. Also, the TTL of 44 is indicative of a Linux or UNIX variant, but the increment of the IP identification (ID) looks like a Windows system. The Echo Request recorded in log entry four is also suspicious, as a Linux/UNIX variant would use an initial Echo-Request sequence number of 0 or 1, not 5.

So what’s going on? Look at the source port in the first two packets. Based on the response (if any) from these probes a smart attacker can tell what technology the firewall is based on (proxy, static filtering or stateful filtering). If you know which firewall products leverage each technology, its now just a matter of further reducing the possibilities.

The second packet would identify if the source port is being restricted, which is done by some firewall products but not others. The third packet would identify if an ACK can create a new state table entry, which again is done by some products but not others. The rest of the pattern is similar. Based on what replies come back from each of these probe packets a smart attacker may be able to identify what vendor firewall product we are running.

14) D

The log entries claim this is normal HTTP 1.1 traffic. The issue is that normal HTTP traffic would include additional fields of information such as the full URI visited (we just see the target IP address 1.2.3.4) and the host identification field (what OS is being used, name and version of the browser, etc.). Both of these pieces of information are missing, which makes the log entries very suspicious. The GET and POST nature of the traffic implies that an exchange of information is taking place. While we would want to confirm via additional investigation work, it is very likely our internal system (192.168.1.22) has been compromised and is calling home for instructions.

15) C

There are three potential paths into the internal network; through the firewall, through the VPN gateway and through the switch. The firewall may be attacked directly or via data replies from a malicious site. The VPN gateway has exposed ports with no trusted system to monitor them, so it is susceptible to direct attack. Finally, the switch is a potential path as it is VLANing across multiple security zones. Features like auto trunk negotiation may be leveraged to gain access to the internal network from the DMZ, thus bypassing the firewall’s filtering capability between these two security zones.

So how did you do? The benchmark is being able to answer (meaning you knew the answer, not just a lucky guess ) 12/15 questions. If you scored below that point its time to hone the old skills.

No comments »

Posted in 2-alert, General Security, Network Security

Tags: computer security network security security training

Dealing With Malware On Windows (Part 2) – Long Live Application Control

July 13th, 2009

Application control, sometimes called application white listing, gives you granular control of which applications are permitted to run on each of your systems. Not only can this replace your A/V solution, it can keep rogue users and license issues in check as well.

How does application control work?

The concept is relatively straightforward. You identify which application you want each of your users to be able to run and the software takes care of enforcing that policy. One of the nice things about application control software is that you usually get far more customization capability than A/V. For example with many A/V solutions I may be forced to completely disable A/V in order to run an application listed as malicious in the signature database (say I’m an Auditor that needs to do port scanning or password cracking). With application control, I can usually get as granular as writing policies on a per user, per system, per location level (for example the Auditor can only run the port scanner from a specific system when its attached to one specific network segment). This is cool because unlike A/V I don’t have to disable the software, thus exposing myself to risk, just to simply do my job.

What to look for in application control software

There’s a couple of things you need to look at when evaluating an application control product. First, you need to look at how files are identified. Are they simply looking at file names stored in a specific location, or are they running multiple hash algorithms to authenticate the file is in fact properly identified? You also want to look at what’s involved with approving files for use and how the system deals with patches.

For example, one of my favorite products is Parity from Bit9 Software. They start by referencing a file database with over 6 billion entries and counting. While that might seem like overkill, think of how many file are involved if you just want to approve Microsoft Office for use and include all versions and all patch levels. All of a sudden 6 billion entries does not seem that far-fetched.

Unfortunately a file database is not going to be enough. You need some way to approve custom scripts and executables, as well as deal with real time patch files. For example Adobe checks for patches whenever a user launches the application. If they happen to do this right at the exact minute a patch is released, the patch file info will not yet be propagated into the file database. What Parity does is permit you to approve software based on it being digitally signed. For example we can create an exception that says, “If the file is not in the database but has been digitally signed by us or Adobe, it’s OK for use”.

Protecting Supervisory Control And Data Acquisition (SCADA) Networks

This is a very cool solution for control networks. For example those networks running the grid, municipal services, military stuff, etc., which are not suppose to be connected to the Internet. The lack of connectivity creates a catch-22. You’ve disconnected from the Internet to help protect the network but how do you update your A/V signatures with no Internet access? With Parity this is a non-issue. You simply digitally sign all software required on the control network, write a rules saying only digitally signed software can be executed, and you are done. No signatures or updates to worry about, just re-sign new software as you wish to deploy it on the network.

Parity has some other cool features as well like the ability to track file execution or the ability to control which removable drives can be used (by model, by user and by level of access). I’m starting to feel like a sales person however, so I’ll leave it to the reader if they want to learn more.

The dirty little secret

So why is it we are not seeing A/V vendors dump their signatures and jump on the application control bandwagon? I do not work for an A/V vendor so I can only speculate. I do however own stock in a few of them and will say that as soon as I see this trend occur I’m selling my stock. Think of it this way, where is the true cost in your A/V solution? Is it in the initial purchase price of the client, or is it in the monthly/annual subscription fee you pay for signatures? Companies loooove reoccurring revenue streams because they mean predictable income with zero sales effort. Stockholders (like myself) love reoccurring revenue streams because “higher income + less up front costs = higher profit”. Note in the last example I discussed protecting a network without the need for signature updates. If users went this route it would have a serious financial impact on each A/V vendor’s bottom line.

The bad stuff

Now some caveats. You would probably want to use the file database if available, even if this means paying for a different subscription service. Digitally signing everything is fine on a network where the applications are infrequently changed (like SCADA) but in a typical corporate environment your job title would turn into “the Admin who’s always signing software”.

Also, application control simply regulates which applications are run on the system. Its not very helpful if an approved application gets whacked via a buffer overflow or the like. So patching is still a must and you will probably want to run a Host-based Intrusion Protection System (HIPS) to be completely locked down. Still, with application control you end up with a far more secure posture than sticking with that old carburetor A/V software.

No comments »

Posted in 3-err, Malware, Windows Security

Tags: anti-virus application control application whitelisting attack mitigation host security Malware Windows security

Uber Geek Your Windows Laptop

July 12th, 2009

Thought some folks might find this useful. I’ve noticed that over the last few years working with the Windows command line has become a bit of a lost art. This is too bad as you can do some really cool stuff. This instructional is geared towards those folks that do not know the power of working from “the dark place”. There are general tips for setup, how to perform common task, common error codes and how to resolve them, as well as batch file basics.

This is relatively low level material, but IMHO its a great primer for those who have not spent a lot of time working at the command line.

Enjoy!

Uber Geek Your Windows Laptop

No comments »

Posted in 4-notice, Windows Security

Tags: batch files common tasks error codes windows command line Windows security