Risque Management : Integration

Pictures at a VMWare Exhibition

Slav — Mon, 29 Oct 2007 02:30:00 GMT

Not really pictures but few notes from recent VMWare Virtualisation Forum - the regional mini-VMWorld. It started with a lot of pictures - trees, water, animals and I think smiling babies.When an event starts with those, expect a lot of marketing dung - and we got plenty in a day. For example, one of the VMWare keynote speakers said that virtualisation is the only way to manage hardware resources efficiently. Or, in BEA's leaflet words: Virtualization: Same Servers, More capacity. As if the hypervisor and the OS image per each guest take none. Or this apparent inefficiency is compensated by flexibility allocating more resources, should the need be. If you cannot effectively manage resources on physical servers, you're likely to waste those in virtual. Virtualisation just gives a chance for a fresh start - and some different tools.

VMWare's updated product line includes a OS patching solution that will allow patching systems that are shut down. Virtually shut down, of course. I believe this is the industry's first. My concern is that VMWare is losing focus: they shouldn't really go into patching and software delivery.

Both EMC and Network Appliance were presenting their storage offerings. Virtualisation requires shared storage, and those vendors are ready to sell - at premium price. One thing they aren't interested in is storage enterprise commoditisation (despite the fact that commoditisation will allow them to enter mass market). But NetApp mentioned something that is definitely worth noting: good old NFS provides solid and viable alternative to Fibre Channel- and iSCSI-conected storage. This blog explains why: VMWare over NFS. Suddenly NFS is making a comeback. Enterprise-class virtualisation with commodity and/or open source storage is coming.

Also both storage vendors presented their backup offerings. Two main points: direct-from-storage backups and data de-duplication. Watch the space - backups may finally become reliable and usable!

IBM was touting new server. While doing that they have admitted that big-iron, multi-CPU approach is much better than using blades. Surprisingly many people believe that blade servers are the best for virtualisation - in fact, the opposite is true.

Wyse and HP pushed their desktop virtualisation solutions - e.g. thin clients. After so many failures, will thin client solutions succeed? I'm sceptical. Virtual desktops tend to be more expensive than traditional desktops. But the functionality is less crippled this time around - thanks to full dedicated OS image per client.

Overall, virtualisation drive is a welcome shakeup of the industry. But promises - and expectations - tend to be overblown.

How to stop Skype using ISA server, and why

Slav — Sat, 25 Aug 2007 07:18:00 GMT

Skype is a good example of how defying open standards can result in a better product. H.323, the first attempt at VoIP standard, failed miserably. SIP stands much better chance but there are numerous issues with SIP operator interconnections and crossing organisational perimeter. Skype doesn't have any of these issues: it doesn't interconnect with third parties, using PSTN as the only interface available; and it supports HTTP proxy for connectivity, effectively eliminating difficulties sending voice/video traffic to external parties.

Of course, Skype is scary (as in: buy a firewall, and may it protect you against Skype). It is the perfect backdoor, can only slow down the exploitation of it, and may protect a 0-day - Desclaux Fabrice of EADS does a decent research only to come to wrong conclusions. What's certain - Skype is a perfect target for hacking.

Some security people hate Skype and want to stop it. rootn0de provides a smart way of doing that (see Blocking Skype Using Squid and OpenBSD). Skype doesn't rely on DNS resolution for contacting its supernodes (because Internet DNS resolution may not be available on semi-isolated networks) - so rootn0de configures Squid proxy to block CONNECT tunneling connections to destinations represented by IP address. You cannot even modify the list of supernodes so that DNS resolution will work - so this is a really good hack. It doesn't require OpenBSD.

What about numerous organisations using Microsoft ISA Server as their Internet connection gateway? The solution is even easier. Configure ISA to require Windows integrated authentication and Skype will not work. Just checked - that's fixed recently in Skype for Windows 3.2 hotfix. Back to square one - no easy solution for ISA. You can be creative with Winsock client, or write custom filter, or channel traffic through Squid (defying the purpose of ISA to an extent). Besides, getting arount restriction to use Windows integrated authentication only can be relatively easily worked around - by modifying the client.

Solution, did I say? No. Trying to block Skype on the Internet access gateway is an example of wrong approach taken because of wrong problem definition. Skype is just a videophone with chat, that can also send files - most of potential Skype users on corporate network have Web access that allows chatting, sending files and placing telephone calls. If you don't want users to run software that you don't approve - don't let them by strictly controlling their operating environment (thin client solutions help here). If you don't want them to share information - don't give access, or protect it (RMS solutions help with this). But don't try to cripple the functionality that is already given to the users - they may as well have business need for it.

VoIP Scaremongers

Slav — Sun, 05 Aug 2007 09:26:00 GMT

DEF CON, an "underground" information security conference (appropriately held in an upscale hotel in the entertainment capital of the US) is on, together with sister Black Hat Briefings, and the fresh crop of FUD is already making it to the business press worldwide. There's nothing like a catchy headline, and Forbes has got one of those: VoIP Vandals. Let's see what it's about:

Security professionals at the Black Hat conference in Las Vegas spent Wednesday outlining the exploitable vulnerabilities in voice over Internet protocol technology, or VoIP. In a series of presentations, they demonstrated ways in which cybercriminals can eavesdrop on VoIP calls, steal data from Internet telephony devices, intercept credit card numbers from VoIP connections and shut connections down altogether.

I wonder if there's something radically new. Some details:

"VoIP is about convergence. The idea is that you save money and resources and time," said Barrie Dempster, a senior security consultant at Next Generation Security Software who made a presentation at the conference. "But convergent systems give you more avenues of attack, more ways in. It's not a secure environment." Because VoIP connects telephone calls via the Internet, it shares the Internet's weaknesses, Dempster argued. Those include vulnerability to denial of service attacks, which overload servers with thousands of simultaneous requests for data, as well as basic hacking tactics like guessing the password of users who fail to change default settings.

Environments become secure if and when we chose to secure them. VoIP set of technologies gives countless ways to achieve integrity and privacy of communications. It's much better in that regard that POTS, the pretty old telephony service it's replacing. And by the way - many people who witnessed major disaster, or attended a sports event, or just tried to call relatives in a developing country on a public holiday, know of limitations of POTS is its susceptability to load-based denial of service. Plus, legacy telephones don't have passwords to speak of, so there's nothing even to guess.

Well Mr. Dempster may have said FUD without substance, but other guys conducted cool demonstrations. They have shown weaknesses resulted in insecure iplementation of MGCP, and lack of touch tone protection in ZRTP, o VoIP protocol invented by Phil Zimmermann of PGP fame. Nice hacks they may be. Pity no one's using the protocols. SIP and proprietary protocols like Skype have won the protocol race.

Of course, Microsoft's embrace of the realtime communications and VoIP is considered no less than upcoming doom:

Eric Winsborrow of Sipera Systems says that the wave of threats has been brought on by VoIP's new popularity in the business world as well as the technology's growing connection to the Internet at large, instead of smaller networks. He also points to plans at Microsoft to introduce VoIP applications into upcoming software as a sign that the technology's security issues are reaching a tipping point.

I don't know where Mr. Winsborrow has spent last several years, but conf.exe is a part of Windows for a long while, and we are long past the tipping poing. There will be no VoIP crash boom bang. It is secure. Mr. Winsborrow and his squad managed to crash a BlackBerry handheld and a D-Link phone by injecting packets into Wi-Fi network (as if you couldn't crash any of those networks entirely with a microwave), and simulated the theft of private data via VoIP from a laptop. I invite them to exploit a setup with Kerberos authentication and SIP signaling secured with TLS. That is common in Microsoft world and is used to interconnect organisations as well as internally.

VoIP scaremongering is pathetic.

Virtual infrastructure v Terminal servers

Slav — Sat, 14 Jul 2007 23:42:00 GMT

Virtual infrastructure based on products like Microsoft Virtual Server, VMWare and Xen is the flavour of the month. People are talking about reduced cost of ownership, energy consumption and increased security risks resulting from use of virtualisation - all of which is questionable. But without a doubt virtual infrastructure, especially in the datacenter space, will change the way we do things today. System deployments will take much less time. Recovery procedures will change dramatically. In enterprise space, virtualisation will change networking and storage architecture as well: IP subnets will span multiple physical sites, and storage will become more flexible. I'm doing my reading on iSCSI - IP-connected storage is the way to go.

There are other effects of the emergence of vitualisation. Blade servers won't ever become mainstream solution because of it, and possibly will die off altogether. And there will be a very interesting clash with terminal server solutions - technology space dominated by Citrix Systems, History of terminal servers is interesting: developed as a way of enabling multiuser access to systems, it evolved into bandwidth-saving way of using legacy applications, then to the core of thin client infrastructure (remember Oracle's Network Computer?) and now it's all of the above plus secure remote access mechanism and software distribution application delivery system. Virtual infrastructure hosting any modern OS has all the same features - but approach is different. Some may argue that terminal servers are utilising less resources since htey are using single OS image for all clients - which is probablu true, but becomes less of an advantage as both VM resource management ans sytems' awareness of the virtual infrastructure improves. And terminal servers can become legacy systems themselves.

Integrating Java, JDBC and Kerberos

Slav — Tue, 05 Jun 2007 09:09:00 GMT

This notes are to help integrating Java applications into Kerberos environments (most likely Active Directory-based). It's not a cookbook but gives few pointers that I find useful.

Background

I have integrated Windows Kerberos environment with alien platforms before. See, for example, my notes on Configuring Apache on Linux for Kerberos Authentication. So when I faced the need to configure Java environment to use Kerberos for Microsoft SQL Server authentication, I was excited. As it turns out, Java is as bad as Linux - if not worse

Problem

There's a Windows-based Java environment and a Microsoft SQL Server database. The task is to configure Java to connect to SQL Server database using Kerberos authentication in the current user security context - that is, without specifying the account name or keytab file. Not changing Kerberos encryption types for the account in Active Directory highly desired.

Solution

For this particular solution I was using DataDirect JDBC driver for Microsoft SQL Server. Other options are OEM versions of the same (that are cut-down, with the cut including some authentication features), and Microsoft SQL Server JDBC driver (that does support integrated authentication but only on Microsoft Windows operating systems - I naturally want to go multiplatform). DataDirect provides two testing tools - WATest for basic Kerberos functionality testing and ConnTestWA for JDBC specifically , as well as testforjdbc utility included with the driver distribution set.

The steps of the solution include: installation of Java Virtual Machine, configuration of Kerberos, and configuration of login parameters for particular connection. On Windows you can choose not to use keytab files; on UNIX/Linux you have to.

The success criteria was successful run of testforjdbc, with Kerberos ticket for SQL Server service added to the local ticket cache. You can check the cache using Kerbtray GUI or klist.exe command line utility, from Windows Resource Kit utilities and support tools respectively. On UNIX and Linux, you have to run klist. If the connection works and uses Kerberos, a service ticket is added to the cache.

Caveat

Don't take for granted that Kerberos authentication is available on the server, even if it comes from Microsoft and is using Windows integrated authentication. In case of SQL Server, you need to refer to Q319723 - How to use Kerberos authentication in SQL Server. Note that you need to use service account, and there are some specifics when you use cluster; also note that delegation settings are only required if there is an intermediary point in the communication (like IIS in the KB article scenario). IIS configuration for Kerberos has similar caveat(s).

Installing the JVM

Remember Wirite Once, Run Anywhere capability (see INDEPENDENT TESTS DEMONSTRATE WRITE ONCE RUN ANYWHERE CAPBILITIES OF JAVA)? Well, that doesn't quite work any more. For that reason you have different constraints with each version of JVM. Pure Java (that is, without using native platform calls and only JVM in-built features) Kerberos failed for me using Sun's JVM 1.4. With JVM 1.5, Windows default encryption types for Kerberos (namely, RC4-HMAC) are not yet supported, so you have to use DES encryption types for Kerberos (using AD Users and Computers GUI in the service acccount properties - and see 833708 for issue with Windows 2003 domain controllers). Only Java 1.6 comes with RC4-HMAC support. Use the latest version if you can.

Configuring Kerberos in Java

Just like in UNIX/Linux, java is using krb5.conf file and exactly same format. On Windows, the file is renamed to c:\winnt\krb5.ini (if c:\winnt\ directory doesn't exist, you have to create it). Details about the location of the configuration file and search order please find here. here's my configuration file:

[libdefaults]
default_realm = EXAMPLE.COM
default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
permitted_enctypes = rc4-hmac arcfour-hmac-md5

[realms]
EXAMPLE.COM = {
kdc = DC.EXAMPLE.COM
}

Important: RC4-HMAC is not enabled by default, so it needs to be on the list.

Configuring login parameters

Kerberos requires configuration file for every connection using Kerberos login. The one for DataDirect JDBC driver is by default named JDBCDriveLogin.conf (akternative configuration file can be specified by changing java.security.auth.login.config Java environment variable), and should look like this:

JDBC_DRIVER_01 {
com.sun.security.auth.module.Krb5LoginModule required debug=true useTicketCache=true doNotPrompt=true;
};

Explanations: debug=true is self-explanatory, and it's essential during the configuration. The "useTicketCache=true doNotPrompt=true" pair chieves using Windows ticket cache (as opposed to useKeyTab, which is another option); it's addressing a potential "No CallbackHandler available to garner authentication information from the user" error.

The rest

...is well documented in DataDirect KB article Setup of pure Java approach for Windows Authentication with DataDirect Connect for JDBC.

Point solutions

You can as well avoid the hassles of pure Java just by using Type 2 (Windows native) integration for DataDirect driver. All that ise required is connection string like jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Type2 or jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=auto (as opposed to jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Type4 or jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Kerberos required for pure Java Kerberos authentication). Make sure that java.library.path includes path to DDJDBCAuth04.dll supplied with the driver. Or you can use Microsoft JDBC driver. Both will integrate with Windows.

Troubleshooting

1. Verify SPN in question. In AD, use ADSIedit to check the SPN. The LDAP attribure you are looking for is "servicePrincipalName";
2. Enable Kerberos logging on the DCs (http://support.microsoft.com/kb/262177/) and look for relevant information in the logs;
3. Capture traffic on the client requesting Kerberos ticket and see Kerberos communications and error codes in the capture;
4. Review Q326985 (http://support.microsoft.com/kb/326985) -it's about troubleshooting Kerberos with IIS but gives good idea about other services.
5. Did I mention enabling Java debugging where possible?
6. And if you use Java security policy, there's a whole new world for stuff-ups.

Good luck with the integration, and don't hesitate to post your own experiences on the Internet. Scenarios are plentiful, documentation scarce, and every piece of information helps.

Smart card logon error 0xC00000BB

Slav — Sun, 03 Jun 2007 01:25:00 GMT

When you implement smart card logon on a Windows domain, sometimes you may receive the following error message:

The system could not log you on. The server authenticating you reported an error (0xC00000BB). You can find further details in the event log. Please report this error to the system administrator.

There is a Microsoft KB article (891849) describing the issue. However, the sAMAccountName and userPrincipalName prefix mismatch aren't always the cause.

Users receive same error when the domain controller doesn't have a DC certificate installed. That can happen if a manual procedure or a 3rd-party CA are used for domain controller certificate enrollment - you can miss some of the DCs.

For information about domain controller certificates read Advanced Certificate Enrollment and Management on TechNet and MS Knowledgebase article 291010 - Requirements for Domain Controller Certificates from a Third-Party CA.

SPF and Sender ID won't help fighting email abuse

Slav — Sun, 25 Mar 2007 06:15:00 GMT

Email abuse - spam and phishing - is a big problem. There are different methods of fighting those. SPF and Sender ID propose standard of authenticating emails using DNS records: owners of certain email domain will publish information about legitimate email servers for that domain, and recipients (that support SPF/Sender ID) will check that information and mark/reject emails that come from wrong source. For example, if IP address of email server that sends emails for example.com is 10.0.0.25, then there will be the following record in the example.com DNS zone:

example.com. IN TXT "v=spf1 ip4:10.0.0.25 -all"

The recipient will check if an email that claims being sent by someone@example.com has originated from 10.0.0.25, and will reject if it hasn't. That is overly simplified overview, but gives an idea.

Sender ID will fail. There are several reasons for that:

It is not clear what is real difference between SPF and Sender ID. Both claim they implement RFC 4406, an experimental Internet standard for email authentication, and its sister RFCs. However, the SPF supporters are trying to distance themselves from Sender ID (read: Microsoft) - without much success (see for yourself), and resulting in added confusion;
We cannot detect if certian recipient supports Sender ID or not. Because of that, there is no credible measure of Sender ID adoption or efficiency, which results in a worse case of catch 22: people are waiting on other people to adopt the standard, yet they don't know how's that going;
Spammers don't need to spoof source email address. That may add credibility but ultimately spam relies on the "From:" field and recklessness of the users.

There will be more issues - from operational ("Why some of my emails aregetting lost?") to conceptual: what is the right way to align identity with IP address and DNS space? In some ways, DNS is better than PKI, and definitely can help a lot. For example,(I'd love to see public keys published in DNS, for example. But SPF and Sender ID attack the problem of email abuse from a wrong angle. Meanwhile, my desktop spam filter - SpamBayes - is so accurate that I don't need and assistance from SPF. I think I know what's the answer to spam issues.

Update on SSL VPN standards

Slav — Tue, 20 Mar 2007 04:31:00 GMT

I recently wrote that adopting PPP over SSL as common standard would be the best apporoach to standardasing SSL VPN. I must have been living on Mars: no other than Microsoft is already putting effort right into that!

They call it SSTP - the Secure Socket Tunneling Protocol. Microsoft RRAS team blogs quite a bit about it, and the beta is coming soon. The implementation is coming in Vista SP1 and Longhorn Server. I guess Microsoft will make it a standard in the Forefront Edge security products (next versions of ISA Server and the IAG) too. They should backport the protocol to Windows 2003 and XP. Microsoft won't implement the protocol on Linux and MacOS, but that should be rather trivial; what can delay the implementation is closed beta.

I'll look into testing SSTP ASAP.

Architecting enterprise for federated identity

Slav — Sun, 18 Mar 2007 03:44:00 GMT

InfoCard is the way to go. The concept is very well engineered. It is commonly accepted by various influentials of the IT industry, and some other industries (think of showbiz); it has a number of open-source implementations, as well as Microsoft one (known as Windows CardSpace); and Kim Cameron is a legend. The missing layer of the Internet - the identity - is now found.

So where are the adopters?

Today, there aren't any of importance (measured by monetary value). The reason is the enterprises, and their ways of architecting their systems. There are two issues - actually, two sides of the same problem:

Enterprises are designing their identity management systems and applications assuming they will be in full control of the client identity; and
Application service providers are not ready to accept identity assertions issued by other parties - instead, they issue their own, sometimes providing limited delegation.

When talking about the application service providers (commonly referred to as just ASPs), I don't mean it in the pure dot-com sense. Taking into account various B2B scenarios, there are much more ASPs than most of you think - in reality, most enterprises provide access to their applications to other parties.

And we have a problem right there. If I'm an organisation that is using a 3rd-party application for my staff and customers, I still need to be in control of their access to the application. If I give access to a 3rd-party, I want a way that allows that party to manage their access the way they do that, and I don't want to carry the burden of co-managing and supporting access control for other organisations. InfoCard solves the problem. Enterprise applications and identity management systems should be designed for the Identity Metasystem.

They aren't yet. Enterprise architects must adopt the new paradigm, ditch few utopian concepts (i.e., single customer view) in process, and actively confront empire building and control freakdom that plague enterprises today. The outcome is worth it. Think of simplified B2B relationships and acquisitions. Think of new ways of doing outsourcing.

Support from big names is needed. Big business looks at Oracle and SAP to make the first step and make their products (and, not less important, hosted solution offerings) compatible with InfoCard. Microsoft has to walk the talk and start offering support in the server and business software (I'll be looking at the Intelligent Application Gateway and Hosted Messaging and Collaboration and CRM solutions). And those offering identity management solutions - Microsoft, IBM, Sun, BMC - should also provide support.

But for now we have a catch 22 situation - everybody's waiting for everybody else. Well, Microsoft is in front again, but that's clearly not enough. Alternatives to the Identity Metasystem look solid - just like SNA looked good compared to TCP/IP some 25 years ago (scalable, secure and supporting QoS - yet mainframe is required). Alas, you'll be making a mistake if your solution isn't compatible with the Identity Metasystem today.

Release Windows Vista Service Pack 2 now!

Slav — Mon, 12 Mar 2007 22:44:00 GMT

I'm surrounded by Microsofties right now. While at it, I have a serious thing to ask: Microsoft, please, release Vista Service Pack 2 ASAP!

Too many people are waiting for it - even to start looking at Vista. So give them what they want:

A 500MB+ download;
Must break something (I suggest FoxPro 2.5 applications); and
Changes the version strings and adds an obscure but useful utility.

That will remove the biggest obstacle for Vista adoption. I let Microsoft figure out an excuse for skipping SP1.

The most secure modern OS, Part II

Slav — Wed, 07 Mar 2007 09:29:00 GMT

Part I was about the OS with zero known vulnerabilities and no real trend towards worse situation. Mind you, source code for that OS's kernel is available, so it must be really hard target indeed.

My next favourite provides the best platform for security solutions - standards support, rich set of APIs that make integration an easy task, and an excellent sofware stack on top of that as a proof.

The OS in question is Windows. I haven't seen better support for security yet. there are attempts. I've come across this one (on Slashdot, of all places), which is rather impressive:

I believe I have one of the most advanced LDAP/Kerberos/Samba/Bind "Open Directory" setups. I have two Samba 3 Domain Controllers, both Kerberos and Bind Enabled. with OpenLDAP and MIT Kerberos. I have no
need for NFS.

My OpenLDAP stores:

POSIX User Attributes
Samba User Attributes
Radius User Attributes
eGroupware User Attributes (Egroupware accounts.)
DNS Information for our internal DNS Server
DHCP Lease information.

I use Kerberos with ssh-agent to distribute software RPMS for Mandriva Linux to mass distibute RPMs with a single command.

I have Samba Kerberos enabled so that Samba will not repeatedly ask for usernames and passwords, and requires zero configuration.

I have had the code to Egroupware modified so that eGroupware, and Nagios can use Apache's mod_auth_kerb addon to authenticate eGroupware users with a single click instead of a whole second login process.

I'm currently workong on creating a Samba Authenticated gateway with NTLM-SPNEGO support so that kerberos will handle Squid too.

All I need now is for someone to make the modifications nesessary to eGroupware's XMLRPC so that Kontact could use Kerberos and I would have the "Exchange Killer" I always wanted.

All of my users use Samba for network browsing under KDE's Konqueror, with Kerberos and LDAP, it just works.

I consider this my shining accomplishment. I like to have myself believe that I accomplished "Active Direrctory" under Linux now. I don't use Windows at all in this network, so keep that in mind. The eGroupware people can attest to what a past I am. bugging them to include Kerberos detection in session management. But it all works.

That is rather impressive. As a qualified Linux engineer, I can attest the big scale of assembly required to achieve this.

Which is exactly my point. On Windows, I'm used to similar kind of setup since 2000. Plus, we have robust smart card support integrated with Kerberos. Pluse, we use IPsec in transport mode - also with Kerberos authentication. All within the reach of an average MCSE. Life is good. Windows is by far the best security platform.