Tag Archives: security

Review: The Hacker’s underground Handbook

Last week I was contacted by David Melnichuk to offer me a partnership/affiliate account for his ebook "The Hacker's underground Handbook". I said to David that I would prefer to see what's it all about before I would promote anything, but I would be willing to write a review and maybe promote it if he sends me a copy. He did that so here is my review ...

The pitch

I recently created the eBook: The Hacker’s Underground Handbook. It is targeted more towards people that are new to the hacking/security scene and still don’t know where to start. Although it is mainly targeted towards newbies, it also has content that will be valuable for intermediate skill levels. The product is completely legal. Once the product is purchased, the user will be taught to not abuse the knowledge gained, and the penalties if he/she chooses too.

After looking over the book briefly I completely agree that this is an ebook for newbies.

Also the phrase "learn what it takes to crack even the most secure systems" from the cover, over estimates the content. You would most likely not be able to crack the most secure systems only with the information in this book, but the author advices the reader to learn more and not rely only on the information in the book and even provides some links to more resources.


I think the term hacker applies more to someone like Richard Stallman, Alan Cox, Linus Torvalds, etc then to someone like Kevin Mitnik. So in my opinion the book is more about cracking then hacking, but most people(newbies) don't know the difference so I'm not going to insist on this.

The book covers topics from  installing a linux distribution (with screenshots  a la howtoforge ) and password cracking to packet sniffing, using exploits, web site cracking, wifi cracking and social engineering ( which IMO is not really cracking but just a nerdier/l33t word for "lying" )

I like the fact that the book also offers some advices / countermeasures even if in some cases it doesn't present the most secure or all options.


If you're into cracking and you already know how to do a lot of stuff I would not recommend the book as there are no advanced techniques in the book but if you're new to this or you would just like to know how some things are done and how you can prevent some security incidents then the book offers a good collection of common cracking techniques.

The ebook comes with a bonus ebook named "1000 Hacking Tutorials Leaked", so for the price of $18.89 is probably a very good deal.

Click here to get the ebook ( yeah that's my affiliate link )

Have you read this book? I'd love to read your impressions about it in the comments.

Squid 2.5 digest authentication

More then a year ago I wrote a post where I explained how to set up secure digest authentication for Squid proxy server so passwords would not be sent in plain text to the server when authenticating.

That post was written for squid 2.6 but recently I had to set up the same thing on Squid 2.5 and I found out that the setup was a bit different.

Squid 2.5 is really very old and fewer and fewer will be using it in the future as even Squid 2.6 becomes obsolete with the release of Squid 3.0 .
So if you are considering setting up a new proxy server using squid please use Squid 2.6 and take a look at how to set up digest authentication in squid 2.6

The differences are really minor but here there are listed in case I or someone else needs to still set up squid 2.5 with it.

The first difference is in the way you have to specify the "digest program" auth param.

for squid 2.6 it has to be like this :

auth_param digest program /usr/lib/squid/digest_pw_auth  -c /etc/squid/digest_passwd 

but for squid 2.5 it has to be :

auth_param digest program /usr/lib/squid/digest_pw_auth  /etc/squid/digest_passwd 

The second difference is in how the passwords are stored. In Squid 2.6 the passwords are stored securely as an md5 hash but in squid 2.5 they are stored in plain text in this format "username:password" . ( one more reason to make sure /etc/squid/digest_passwd can't be read by anyone other then squid user )

So for squid 2.5 what you gain in security over the network transmission of the password you lose in security at the password storage. This may still be a good deal if your local security is high but there isn't any way you can control the security of the network between you and the proxy server.

No browser supporting socks5 authentication?

If you're trying to use a socks server with Internet Explorer , Firefox, Opera or Safari everything will work just fine, except for authentication.

From my point of view this is a big problem. Who in the world would leave such a proxy server unprotected? Yeah of course you can always limit access to a proxy server based on ip address, but in some cases ( see NAT ) this is just not going to work.

Internet explorer supports only the socks4 protocol which doesn't even support full password authentication ( only username and it defaults to the current logged in username ) .

Firefox supports socks5 but no authentication mechanism so supporting socks5 is pretty much useless. I think I saw some ticket in bugzilla about this but no one managed to commit a fix yet.

Opera doesn't even support socks protocol but I thought I should mention all major browsers 🙂

Safari supports SOCKS5 and even allows you to set a username and password to access the SOCKS server but it does not use them.

I tried Konqueror, but I was unable to specify the Socks server, I guess this is because it was not compiled with a socks library.  Has anyone had any success with Konqueror and Socks ?

qmail and DKIM

DomainKeys Identified Mail (DKIM) is a method for validating the identity associated with a message using using public-key cryptography and key server technology. DKIM is an enhanced version of Yahoo's Domain Keys and Cisco's Identified Internet Mail methods. As of February 2007 an IETF draft was accepted as "Proposed standard", it may take some more time till this will be a standard but the current version is stable ( according to dkim.org ).

Implementations of DKIM in email servers is not available as much as DomainKeys.
For qmail there is a patch that uses libdomainkeys to implement a replacement for qmail-queue that will verify and sign messages but this only works for DomainKeys not DKIM. I have developed a solution for qmail to be able to verify and sign messages with DKIM. Continue reading qmail and DKIM

Qmail with smtp-auth and DomainKeys on FreeBSD

I tried to set up qmail with tls and smtp auth on freebsd. I have configured my server with SMTP-AUTH so that I can use it to relay messages for me and other authenticated users. I would like qmail to sign the messages that the authenticated users send through my server.

I compiled qmail-tls from ports, checked the smtp-auth and qmailqueue options, then I compiled qmail-dk and selected the SMTP-AUTH patch. I set up my private and public keys, I set up bin/qmail-dk for qmailqueue as described on this page : http://jeremy.kister.net/howto/dk.htm but still not results. It just does not want to add the DomainKeys signature but instead it tries to verify the messages. Continue reading Qmail with smtp-auth and DomainKeys on FreeBSD

squid digest authentication

If you use authentication in squid you have several mechanisms ( authenticators ) to chose from. The Basic authenticator is the easiest to set up and the most insecure because the client sends the username and password in plain text to the proxy server.

Instead of using the basic you would consider using the digest authenticator. This authenticator does not require the client to send the user and password in plain text but encoded in an MD5 hash so that an attacker that captures the data between the client and proxy server will not be able to use the user and password.

Continue reading squid digest authentication

squid 2.6 transparent proxy

In case you used squid 2.5 to create a transparent proxy and you decided to switch to 2.6 or this is the first time you try to set up a transparent proxy and most/all of the tutorials out there are for squid 2.5 here is a brief howto for this setup.

In squid 2.6 the configuration options:
are not defined anymore ( see squid 2.6 release notes ), so if you are using them in your config file squid will give you an error like "parseConfigFile: line 41 unrecognized: 'httpd_accel_host virtual'" and will refuse to start.

To activate transparent proxy in squid 2.6 all you have to do is use the "tranparent" option on http_port. Something like:

http_port 3128 transparent

Of course squid has to be compiled with transparent proxy support for netfilter (iptables) by adding --enable-linux-netfilter to the ./configure line, the linux kernel needs to be compiled with netfilter and you will also need a rule in iptables that will redirect packets from your local network interface with a destination port 80 to the port squid is listening on.

Assuming your local network interface is eth1 and squid listens on port 3128 here is the rule that has to be added to iptables:

iptables -A PREROUTING -i "eth1" -p tcp –dport 80 -j REDIRECT –to-port 3128

drbd 8.0 released

DRBD ( Distributed Replicating Block device ) is a Linux block device that is designed to mirror a whole block device over a network link. Today the team developing DRBD released version 8.0

Among many bug fixes and improvements in the new version we find support for primary/primary ( two way synchronization ) for distributed file systems such as OCFS2 and GFS, optional peer authentication with a shared secret and improved tunable after-split-brain recovery strategies.

Continue reading drbd 8.0 released


On my previous post about wildcard ssl I was complaining that you have to use a different ip for each domain that needs ssl/https and I wondered why there is no TLS feature like there is in SMTPS where you have STARTTLS. Well it seems I was wrong. There is such a feature, actually there are two different features one is described in RFC2817 and the other in RFC3546. Rfc 2817 specifies how a plain text connection can be "upgraded" to a secured connection over SSL:

This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address

RFC 3546 various extensions to TLS and one of them is an extension for server name indication . This extension will allow a client to tell the server which domain is contacting.
That's just great, but there's one problem. Not only that few web server software implement any of the two rfcs but also few web browsers support them.

Apache implements rfc 2817 in mod_ssl since version 2.1 and mod_gnutls implements the server name indication extension in TLS described in rfc 3546.
It seems that IE7 has support for RFC 3546 and firefox may have support for rfc 2817.