If you’re planning to, or are implementing wired 802.1X, wireless security and/or NAC, the contents of this blog may save you hours of time and trouble.

Throughout the implementations I’ve done, for both wired and wireless 802.1X, I’ve developed a procedure for implementing and testing 802.1X each step of the way. Following these steps my seem to be tedious and unnecessarily time-consuming. But, if  you’re just starting with 802.1X, I’m offering a way to implement it in phased pieces that will give you the information to test, confirm and troubleshoot at each step.

To be honest, I frequently skip these steps, but I’ve done many 802.1X implementations and can usually hit the bullseye the first time (unless there’s buggy software or firmware- you guys know who you are). But, if something doesn’t work, I start right back at Number 1 here and I follow this procedure.

1) Configure wired 802.1X
First setup the basic wired 802.1X. Ideally, start with a Windows test, using XP SP3 or a later server edition and PEAP. Provision RADIUS, I recommend Microsoft IAS because it’s well-documented and well supported. Even if you have other future plans, if you’re using Active Directory, start with IAS. You’ll need to setup a test RADIUS group and policy and link to AD. Get a test switch, add it as a RADIUS client, and configure it to talk to your RADIUS. Set up some ports for 1X and enable it on the switch. I recommend testing with PEAP as the authentication method and a Windows credential pass-thru. Note- you’ll need to create a server certificate to use PEAP- a self-signed Microsoft cert is fine.

If this simple configuration doesn’t work, you have some troubleshooting options. First, view the system events log in the RADIUS/AD server and look for informational events from IAS. If the authentication request is making it from the client -> switch -> RADIUS, you’ll see something here. The something you see should tell you if the EAP method is mismatched, or if the credentials were wrong, etc. Your second line of troubleshooting comes if you don’t see any RADIUS log activity. If that happens, throw on a packet capture utility like Wireshark. You want to search for 2 things. First look for conversations from your Test Switch to the RADIUS server (filter on IP or MACs). If you see something here, see where the conversation drops off. If that comes up empty, it means the conversation is terminated between the Test Switch and Test Client. I have some neat tricks for troubleshooting I’ll share with you later.

2) Add in Wireless
If you’re planning to implement 802.1X for wireless, now is the time to throw 802.11 in the mix. It’s harder to sniff wireless traffic for troubleshooting, which is why I recommend starting with wired 1X. Keep it simple, and then start layering. Once you have the wired 1X configured, all you need to do is get your AP ready and configure it just as you did your switch- add it as a RADIUS client and configure it to talk to RADIUS. For wireless, you’ll need to configure encryption also. Note, I recommend (for testing) to begin with your primary VLAN.

If your wireless 802.1X isn’t working, follow our troubleshooting above and re-check settings based on the RADIUS event log contents. If nothing is making it to RADIUS, then most likely something is misconfigured in your AP/Controller and the AP isn’t communicating with the RADIUS server. You know the rest of it’s working (RADIUS, AD, Client) so you can narrow your troubleshooting scope. Once that’s working you can stop if wireless is your goal, or keep going if you’re layering on more security.

3) Replace with Custom Pieces
If you’re planning to use a different RADIUS server or a different supplicant, now would be a good time to start swapping out our vanilla configuration with custom pieces. Replace 1 piece at a time and re-test.

4) Add in NAC or Endpoint Integrity
Most NAC or EI solutions will integrate with your 802.1X infrastructure (if you want them to) and can be ‘consulted’ prior to authenticating and opening the secured port. My suggestion is to always get 1X working 100% before you add any type of integrity or compliance testing.

If you follow these steps, you can turn a complex configuration into a set of simple baby-steps. It may sound stupid, but I promise it’ll work for you every time!

# # #

This customer had a massive application written in ASP classic. Since it was in ASP classic it had massive numbers of SQLi vulnerabilities. Everything from Blind SQLi to the always fun SQL statements in the URL. The customer said this application was roughly 250,000 lines of code with SQL hardcoded throughout. The reason the customer had called WhiteHat is because they where working on a big deal with a potential client and this client was asking for a security report on the application. They where also in the early phases of rewriting the application in .NET (yeah) with an estimated completion date 1.5 years out.

After seeing our report (100+ SQLi and 300+ XSS) and after a protracted developer battle(yes XSS is not good) they where left with two not good options.

1. Lose the customer.
2. Stop the rewrite and spend a few months digging through old code to fix these issues

Now from a business point of view neither of those makes sense. At the time we where in the WAF hater camp but we saw that in this case it made total sense. The customer deployed a WAF, configured it using our vulnerability data, and was able to mitigate the risk in about 3 weeks.

Bottom line and what people continually fail it understand is that every current solution on the market today has its short comings. In security everything does. Is there one magic network solution that will prevent all network attacks? No. You have spent a ton of money protecting your network infrastructure. Let’s take a quick look at the list of things you probably have spent money on today:

1. Firewalls
2. IDS/IPS
3. Network Vulnerability Scanning
4. AntiVirus
5. Configuration and Patch Management
6. Database Scanning
7. Database Encryption

Guess what, none of that protects you from the rush of SQLi, XSS, and other web based attacks. All that money and you still have big gaping holes.

To properly attack the Web Application Security problem you should be doing all of these things:

1. Secure coding practices
2. Source code review
3. Black box testing
4. Web Application Firewalls
5. Developer Training
6. Configuration and change management

The reality today is that people underestimate the size of the problem and therefore do not have the budget to do all these things. You can stretch those budget dollars pretty far with an open source scanner and mod_security (software cost $0). WhiteHat is not that cheap but we are very cost effective, combined with mod_security you can go a long way. Need a more robust solution, WhiteHat + F5 can scale to 1000 of web sites in a very cost effective manner. WhiteHat and our WAF partners can knock items 3-5 off your list while you go work on getting your coding practices in place. Even after you get those practices in place you are still going to find vulnerabilities and having that “instant” mitigation ability is very comforting.

Robert over at cgisec sees the light as well. He has managed and is currently managing web site security for some of the largest most frequently attacked web sites on the planet.

Post from: Grumpy Security Guy

The Business Case for WAFs + Testing

In addition to our Black Hat Blogging time between now and early August, I’m declaring June ‘Ask JJ’ month. I frequently get questions emailed from readers, either in response to a previous post, or with questions on a new subject. It occured to me that others probably have the same questions, so I figured a month of Q&A free-for-all would be a fun way to address all those burning IT and security questions you’ve been bottling up inside…

The plan is to collect questions in June and post replies in July, or perhaps in earlier if I can manage to squeeze in a few extra hours in the day.

What to ask? Whatever YOU want to know about- just ask! If you read my blog, you know my specialties are in network security, NAC and 802.1X as well as general networking and standards and wireless technologies and security. You can ask about a technology, a product, a vendor, even my ‘opinion’, if you really want to hear that.

You can ask other stuff too… If it strikes my fancy and I think it’s interesting enough, I’ll research it and get an answer, or perhaps invite a guest expert to respond. And if it’s not so interesting I may just ignore it, so be prepared for that too.

How to ask? Oh we’re full of options here. Either post a reply/comment to this topic, or use the email form on my blog at www.SecurityUncorked.com to submit a request by email. You can include your name and/or contact info or not- up to you.

# # #

So, if you’re in ‘the rest’ category, here’s a quick overview of how the chain of love works top-down from manufacturers to VARs to you.

Manufacturer -> Reseller.
First it’s important to note that most IT Manufacturers have some level of Partner Programs. These programs are structured agreements between a Reseller and the Manufacturer and are usually based on 1) volume of their product sold and/or 2) technical expertise. Each Manufacturer is different, but they usually offer 2-4 tiers of partner programs depending on those 2 things, and each tier may have a different discount offered to the Reseller.

Commodity items may just require a Reseller to request to be in the Partner Program, and sign a couple of documents. More involved products, such as the network and security products we deal with, usually require the Reseller to demonstrate competencies and a high level of technical expertise with that product. Some product lines or specific products may require a Reseller to have authorization or certification to sell and/or provide services for a product.

When selecting a Reseller or VAR, it’s important to keep these things in mind and be sure your choice is comfortable with that product line- you should be able to ask them for recommendations and help specifying the correct products and possibly help with the installation and integration. If you send a Reseller a list of part numbers and it’s the wrong ‘stuff’- you’re less likely to get help exchanging it for the correct items, from the Reseller or Manufacturer. It’s also nice to know you have a friend to lean on when you’re installing new products.

You’ll see more info from me on understanding the difference between a Reseller and a VAR soon. Your VAR should be able to help every step along the way, and a Reseller should at least be able to help you select the correct part numbers as part of their pre-sales support.

Distributor -> Reseller
There’s another interesting twist in our chain of IT relationships- the Distributor, or Disti for short. Understanding distribution of a product can be advantageous- some products are sold directly from the Manufacturer to Reseller, but most go through a Disti. The Disti can be another advantage for your Reseller to leverage, but the Customer really should not be involved in any way in these transactions. Sometimes Distis offer an additional discount to a specific product line or type. Other times the Distis may be offering a volume discount or bundles. Sometimes the incentives are for the Reseller, and some times they’re designed to pass through to the Customer. It’s a good idea to just ask your Reseller if there are any additional discounts that could be applied.

Reseller -> Customer
A lot of Customers like to get information directly from the horse’s mouth and at times this Reseller-Customer relationship is bypassed at critical times. Keep in mind the Manufacturer sales rep is most interested in selling you something- and they may be interested in selling you a specific something, depending on what their incentives are. If you, as the Customer, call in a Manufacturer directly for pre-sales support, do you really expect them to honestly tell you “Hey Mr Customer, you really don’t need my widget.”? On the other hand, if you call in a trusted Reseller or VAR, they have a more vested interest in your success, and the success of whatever solution is put in place because they’re responsible for making sure it all works.

Another distinct advantage of a good Reseller/VAR -> Customer relationship is the ability to leverage your Reseller’s relationship with the Manufacturer. Maybe you’re a huge buyer of the Manufacturer’s stuff- and maybe you have enough clout with them directly to get what you want. Congratulations if you’re in that position, but for 99% of Customers, that’s not the case. If your Reseller or VAR is in good standing and either moves a large volume or has extensive technical expertise, they can offer you some great advantages, in pricing, services and more. Your VAR can frequently negotiate additional discounts, maybe free training or reduced service costs and competitive trade-ups.

Another tip- don’t discount smaller Resellers. Our company, for example, is not an International online box-pusher, but we have the best pricing tier with most or all of our Manufacturer partners and offer the majority of our product lines at less than you’ll find from those online e-tailers and wholesalers. Surprise!

That’s a very brief overview- you’ll see more on Vendor-VAR relationships coming soon.

# # #

This question of state government's recent origins, and, conversely, of its long failure to originate throughout most of human history, is a fundamental concern for social scientists. Until fifty-five hundred years ago, there were no state governments anywhere in the world. Even as late as 1492, all of North America, sub-Saharan Africa, Australia, New Guinea, and the Pacific islands, and most of Central and South America didn't have states and instead operated under simpler forms of societal organization (chiefdoms, tribes, and bands). Today, though, the whole world map is divided into states. Of course, most of that extension of state government has involved existing states from elsewhere imposing their government on stateless societies, as happened in New Guinea. But the first state in world history, at least, must have arisen de novo, and we now know that states arose independently in many parts of the world. How did it happen?

[...]

...anthropologists, historians, and archeologists tell us that state governments have arisen independently under one of two sets of circumstances. Sometimes external pressure from an encroaching state has placed a people under such duress that it ceded individual rights to a government of its own that would be capable of offering effective resistance. For instance, about two centuries ago, the formerly separate Cherokee chiefdoms gradually formed a unified Cherokee government in a desperate attempt to resist pressure from whites. More frequently, chronic competition among warring non-state entities has ended when one gained a military advantage over the others by developing proto-state institutions: one example is the formation of the Zulu state by a particularly talented chief named Dingiswayo, in the early nineteenth century, out of an assortment of chiefdoms fighting each other.

[...]

We regularly ignore the fact that the thirst for vengeance is among the strongest of human emotions. It ranks with love, anger, grief, and fear, about which we talk incessantly. Modern state societies permit and encourage us to express our love, anger, grief, and fear, but not our thirst for vengeance. We grow up being taught that such feelings are primitive, something to be ashamed of and to transcend.

There is no doubt that state acceptance of every individual's right to exact personal vengeance would make it impossible for us to coexist peacefully as fellow-citizens of the same state. Otherwise, we, too, would be living under the conditions of constant warfare prevailing in non-state societies like those of the New Guinea Highlands.

photo credit: нσвσ

1. Be A Security Cool Cat: Place penguin stickers on every surface in your cubicle. Stick at least 3 on the dual boot company issued laptop (that hasn’t had a kernel upgrade in 6 months). Use BlackHat stickers for bonus points.
2. Be An Undercover Open Source Evangelist: Unfailingly, recommend open source solutions as more secure. Be sure to quote ‘more eyes, less vulnerabilities’. Recite frequently . Always forward security advisories about commercial products to your boss.
3. Walk the Tech Talk: Learn at Least 10 Bash Keyboard Shortcuts. Treat this as a party trick. Perform rapidly in sequence whenever anyone watches your screen. Giggle and pass the keyboard over and say ‘Your turn!’.
4. Be All Knowing, Jedi Warrior!: Say ‘Trust but verify’ whenever you are asked a question you do not understand. Make it clear in meetings that you trust no-one and “verify” solely through a Google/Secunia search.
5. Impress with a Penetration Test!: Download Metasploit, spend 7 hours modifying the web interface: create custom graphics and hack up the CSS files. Start Metasploit running before you leave for the day. Use Camtasia to capture all screen activity so you can review in the morning. If all went well upload to YouTube and link out via facebook.
6. Practice Defense In Depth’: When you are asked ‘What is the Risk?’, grin inanely and say ‘I’ll tell you after I break out the vulnerability scanners’. Run at least 3 vulnerability scanners to get ‘defense in depth’.
7. Latest *Is* Greatest!: Clipboard stealing attacks are *always* a bigger issue than the CISCO infrastructure with default passwords (how did they get there?!).
8. Educate The Great Unwashed with a Deep Dive Security Awareness Program. Educate end-users about Cross Site Scripting and SQL injection attacks. Don’t invite the outsourced developers - they already know this stuff and have deadlines to meet.
9. Impress Your Peers - Perfect the RFC Shoutout: Pick at least 10 common protocols and learn the associated RFC numbers. Intimidate IT colleagues by shouting out the RFC numbers whenever they mention the protocol.
10. Start A Security Blog: What Can I Say?