Security Showdown

Graph source, http://blogs.zdnet.com/security/?p=135

A recent study by ZDnet reveals Vista has way lesser vulnerabilities and high fixes rate as compared to other OSes like RHEL, MacOS. Vista, is what i would imagine, a begining to what will be of the security enabled operating systems, come fully hardened. There's only getting better from here on..SP1 of Vista will prevail :)

To read more, check out http://blogs.zdnet.com/security/?p=135

Things to consider before going for Citrix or Terminal Services

I had a chance to "play" around with a few virtualization and thin client architectures lately and i must say, before you proceed in spending your big bucks in them, consider the following ..

Top 5+1 things to consider before going for Citrix or Terminal Services

1. Not all applications can work with virtualization. If they work in Terminal Service for instance, they don't necessarily work on other platforms or virtualization thin clients. Test each and every business critical functions with end users (people who will eventually use the app)

2. Will this application be able to run on server platforms. It makes no sense to run them on workstations as workstations software have very limited hardware scalability. Furthermore, Citrix and TS only works on Windows Servers. Ensure you get proper papers to say it does work and fully supported on server platforms.

3. What type of specialized hardware or other related software your application require? Will that hardware/software work with virtualization? Simple example would be, your graphics card, when running graphics intensive applications, will they or not take advantage of this hardware when virtualizing? What if that hardware is required to run the app?

4. Is your application client server based? I don't think it makes any sense if there's no client server architecture involved when using virtualization technologies. Outlook and Exchange example here, you publish Outlook and hence run multiple instances of Outlook on a single server would make absolute sense. In a weird twist, if you publish Exchange and it creates an entire new DB for every new virtual instance, whoa, you need serious hardware power man.

5. Does your application maintenance support complies this sort of deployment? Otherwise, you may end up having the support people say, "sorry, we do not support this sort of configuration"..you're in a little bit of trouble

and just for the heck of it the #6 ...

6. Will it benefit in the sense of the amount of hardware+software+service+maintenance you will achieve vs. decentralizing. Also remember, crucially, availability, if decentralized, one PC goes down, one PC is affected, if in virtualization, one server goes down, 10s of clients are affected. How would you address availability, clustering? NLB? Layer7 switching? Built-in application HA?

Hashbreaker

5b69d4f5b5e7929b5c593e1d63cfc078 - Thats "password" in MD5digest. How to crack more hashes? Try www.hashbreaker.com. Register very quickly and use their free version. If you like it, use their paid service. They use Rainbowtables at the backend, which is an open source hash cracking tool available with gigs of hashvalues in a table. To avoid all that, just use this service. How effective? Well, make a hash value and test it out for yourself. :)

Oh, hashing is no longer secure, by the way, try encrpyting the transport then hashing the secret values, that should be the best.

Windows IPSEC

I was doing lots of testing using IPSEC over the weekend (yea, don't have a life). I must say, in Windows client and server environment, it's really simple to implement it. Unlike popular application, IPSEC can be centrally deployed and managed in Windows through Group Policies.

IPSEC will ensure that wiretapping is literally impossible, data remains intact and assured of it's source and destination. It's like having VPN connections with every device in your network that supports IPSEC.

Note there's overheads. Like any encryption technologies, it will require processing power and lots more overhead in transport. But seriously, thesedays with Gigagbit networks and very powerful computing ends (server/client), it's really not much of an issue. Unless you have a 10bt network and really old computers, you should consider implementing IPSEC across your entire organization.

Since IPSEC works below the TCPIP layer, it can support most of your applications natively, unless they are broadcast or multicast enabled (see more unsupported configuration in this KB http://support.microsoft.com/kb/253169/)

Also, please do test in a non-production environment, setup monitoring tools and enabled logging extensively during your testing to ensure IPSec is correctly working and is compatible to your applications.

Happy IPSECing...

Top 5 reasons why i would like to implement ISA Server 2006 as my outgoing proxy/firewall

1. ISA Server is the ONLY FIREWALL THAT I KNOW today that supports authentication for almost all WINSOCK compliant protocols if you use Windows Operating System.

2. ISA Server stores frequently used caches in memory

3. ISA Server contain out of the box a bunch of application layer filters (http, ftp, smtp, rdp...). Furthermore, if you're kiasu for more, write the filters yourself

4. ISA Server support Cache Array Routing Protocol, Backgroung Intelligent Transfer Service, and HTTP Compression

5. ISA Server works great with Active Directory, Radius, LDAP (running AD), RSA etc.

Multiple Vulnerabilities with Cisco's PIX and ASA

There's a possible bypass for authentication when LDAP is used for Chap/MsChap in Cisco's VPN. An attacker can access your internal network without providing authentication at all.

This is quite serious to those running LDAP on PIXes and ASAes.

So far, as i can remember it, when comparing ISA Server and Cisco's firewalls, ISA Servers have no single type of serious attacks like this on it by far. Go ISA Server!

Refs: http://www.sans.org/newsletters/risk/display.php?v=6&i=19&rss=Y#widely3
http://www.cisco.com/warp/public/707/cisco-sa-20070502-asa.shtml

ISA server's incoming vs outgoing IP (and SMTP Reverse Lookup)

Ok, lets start making it clear who the initiator (SRC) and receiver (DST) are. SRC is the person/computer who wants to talk to you and makes the first attempt to do so. Receiver is the person who will either respond to the attempt made by the SRC or just ignore it.

Now, in ISA, please remember that outgoing IPs are ALWAYS the first external IP of the NIC (if you perform NAT from source internal to external). This is true only in a scenario where ISA is the final hop to reach the internet.

ISA manages outgoing requests through PAT (port address translation) but when it comes to incoming requests such as a published webserver etc, ISA can be reached on any external IPs which you specify in the Wizard.

So in short, if the SRC is internal and the DST is external, ISA will use it's first external IP address and, if the SRC is external and the DST is internal, and if you have a corresponding rule/listener, ISA will accept incoming connections using that IP you specify in the wizard.

This is especially important if you performing reverse dns settings esp for SMTP MX servers. Always to remember to register your ISA's first external IP along with your actual SMTP IP as your reverse DNS settings. Otherwise, your org's email can identified as a potential SPAMMER by reverse lookup checks done by SMTP engines.

URGENT! - Serious security flaws with all Microsoft Exchange versions

In a recent ISA Server 2006 Level 400 class, we discussed a vulnerability on Exchange server that could lead to remote code execution. The particular remote attack is listed in CVE http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0213 and rated high in it's severity. If you have customers or run Exchange of all version, check out the article from Microsoft.

This vulnerability and other not so critical ones are described in MSKB 07-026 (http://www.microsoft.com/technet/security/bulletin/ms07-026.mspx). Apply the fixes stated in article immediately, as highest priority.

REMEMBER, PLEASE TAKE THIS MATTER SERIOUSLY, REMOTE CODE EXECUTION=TOTAL CONTROL OF YOUR EXCHANGE BOX. If you run a domain controller on top of that box, the risks are even higher.

Vulnerabilities on Quicktime and Asterisk

Was doing some reading on my frequently accessed security page, SANS and found these two vulnerabilities that should be of mention.

These two software i use well, often, like Quicktime (for my ITunes) and Asterisk (for my mobile VoIP support).

Quicktime- A vulnerability that allows a an exploit on Windows and Mac machines that have Java and Apple Quicktime installed. This exploitation allows code execution and has been categorized as HIGH alert by SANS institution. Apple has not made a fix but recommends a workaround, yea you guessed it, disable Java on your browser.

Asterisk - There's multiple exploits on the Asterisk box with T38 fax function installed on Asterisk opensource PBX. This exploitation allows code execution and has been categorized as HIGH alert by SANS institution. Successfully exploiting this vulnerability will buffer overflow this fax module on Asterisk and can allow an attacker to execute code running the same process as Asterisk is. Asterisk has confirmed this bug and has provided a fix.

Fring Me (Asterisk and Nokia Symbian special mention)

Here's a piece of software i must blog about, its called Fring. I just got a Nokia N80 recently and of course, i wanted to stuff the phone like what we did to the turkey in Christmas, but with software. The company i work for specializes also in VoIP technology and it was quite difficult to get the N80 to "talk" to Asterisk at first, but eventually got it working.

Nonetheless, i found this very exciting new software (still in beta) called Fring. It combines the capability of VoIP in SIP and other P2P/IM software like GoogleTalk, MSN and Skype. All in one tiny piece of excellent codes.

Currently, it only supports Nokia (Symbian). The best part of it all, its real easy to setup and use. It has all the basic needs for a simple text messaging to voice calls right from your mobile. I did a test with Marco the night i installed it and connected it to my WiFi and the sound quality is pretty decent (i called Marco using MSN). I then tested registering Fring to my SIP UDP Asterisk rental business box and it worked like a charm first time :).

Ok, here are the top ten things i like about Fring:

1. Supports Asterisk (or any IPPBX that supports SIP - UDP)
2. Supports WiFi
3. Works great (stable) on my Nokia N80
4. Works just superbly with MSN, Skype and GoogleTalk
5. Simple, straight forward registration (they're nice enough to send you an SMS on how to install straight onto your phone)
6. Combines all your contacts from the supported services/providers above into one single list
7. You CAN connect to normal landlines and/or mobile phones
8. Their ICON
9. Its FREE
10. Best of all, the voice quality is very decent (and the IM texts are crisp clear :P ), no lags and echoes on most occasions

Download and install now: http://www.fring.com | http://www.fring.com/download/