An interview regarding the book was posted on net-security.org:

http://www.net-security.org/article.php?id=1286

Please ignore the photo of me... not my best profile   

Since we've been talking about the book in the last couple days, sales at Amazon have shot up. The book is now ranked in 8th place in the Security category, and 13th place under Hacking. Since I've only been talking about it here, I have to contribute the spike in sales to the members of this forum.

Therefore, I would sincerely like to extend my gratitude to the staff of Ethical Hacker, and my overwhelming "thanks!" to its readership. This is all your doing!

- Tom W.

As a quick list, here's what I had to do, or suggestions:

1) Create proposal for book, which required marketing research of competitive titles, market size, and educational institutional interest. I also needed to provide background information about myself, create my own quick marketing pitches (used at places like Amazon, which were expanded on by the publisher), and identify each chapter and sub-topics. The actual proposal submission is undoubtedly different for each publisher, and probably can be found online somewhere. The more information you can provide, the better. Turns out, they take your proposal as-is, and submit it through a review process (involving multiple approval steps)... so the more professional the submission and research, the better.

2) Wait for the rejection email. If it's close to being accepted, the email will tell me what the problem area is, so I can fix it. Otherwise... tough luck; maybe next time.
 
3) If accepted, finish contract negotiation... which really means take what they offer if this is the first book.  ;-) (we'll see if there's any flexibility on book #2).

4) Once everything is signed, my first deliverable was the chapter outline, down to three layers (instead of just two, like in the proposal). Hint: Make sure you do your research on this before submitting it... they will hold your feet to the fire if you decide to alter your chapters once submitted).

5) Write your ass off. Cloister yourself in a room for months, with no weekends, and no leisure time after work. I am not kidding about this. Writing the book took multiple revisions, and the sooner you can knock out the material, the better. I barely made the deadline with no additional days to spare, plus I had to take a quarter off from my PhD schooling. Writing a book consumes a lot of time.

6) Get good feedback from people you trust to be brutally honest (preferably others who have already written something). People who massage your ego are doing you a disservice. Take the good advice and do what they tell you. I was lucky to have a friend that provided me with excellent advice, who has also written before. His advice saved me a lot of hardship.

7) Re-write your ass off.

8 ) Re-write your ass off again. Seriously. It sucks re-writing the entire book, over and over again, but it'll be worth it.

9) MAKE YOUR DEADLINES!

10) One my book was submitted, I was passed off to a production editor, who oversaw the editing and production of the final book. I received feedback from the technical editor, and had to incorporate his suggestions, or find really valid reasons to reject them. If you reject the suggestions and the technical editor doesn't agree, you end up in mediation    Yep, you will end up in a phone call until a compromise is decided on.  In other words, you can't BS your way through the book - know your shit. (FYI, I didn't have to go through mediation, but was made clearly aware of the process).

11) Re-write your ass off, taking into account what the technical editor suggests. This can be substantial. Also, the technical editor is not going to correct grammar or spelling errors. It's important to be a good writer (technical writing does not count)... after all, that's pretty much what you're getting paid to do - write, and write well. Knowledge isn't everything, or everyone would be an author.

12) Illustrations and screenshots are critical to get correct. You may think you're doing them right... but you're wrong. The publisher has some very strict guidelines that have to be followed in order to get the images to print correctly.

13) Eventually, I was done with revisions (sort of), and received copies of the chapters in PDF form, which I had to check for accuracy (stuff will always slip through...). Also, I had to check for syntax (for codes). I have no idea how many times I had to read my own book.

14) In my case, I wanted to include a DVD with video tutorials and ISO images, so the reader could replicate everything discussed in the book. Originally, the DVD was going to be dual layer. What a mistake and headache. In the end, we trimmed the disk down to a single layer. I will never attempt to do a dual layer DVD with a book release again. Never.

15) Eventually, I was done. Next, it was waiting, until I received an email telling me they were sending me an advance copy of my book. Oh, JOY!

16) Throw a book release party. Everyone needs closure, especially after a difficult event, and writing a book definitely qualifies as difficult. The writing of the book was overwhelming and stressful for the whole family, and we needed a reason to celebrate. Having the final product in hand made it all feel worthwhile. However, I'm finding out the real stressful part is worrying how the readers feel about the book. Just like a new father, there is the fear that others will think my new kid is "ugly," despite my own bias viewpoint. I honestly believe the book provides a wealth of information for readers of all skill levels, engineers and managers alike... but I have to wait to see what you all think, and that's tough. Real tough.

I've written chapters for other books through syngress (my favorite was "the dark side of netcat" for Netcat Power Tools), but this is the first book I wrote cover to cover. Others have said that writing a book is a lot of work, and they understate that fact - not only is it an enormous amount of work simply writing it, there is a ton of editing work that needs to be done, including feedback from the technical editor, publishing editor, the typesetting editor... I probably spent as much time editing the book as I did writing the first draft.

Despite the effort required to write a book, and the loss of time with my family, the experience was worth it. Not only did I learn a lot about the whole publishing effort, I learned a lot about myself, and improved both in writing skills, time management, and organization (hint: write up the references as you go - and use a well-known format, such as APA... going back and doing it later is a serious pain in the ass... no lies).

I definitely plan on writing more - I think the publisher was happy with my work, especially since they sold so many advance copies of the Professional Penetration Testing book already (I basically earned my advance and more in royalties before a single book went out the door... which is awesome, I guess).

Hope that answers your original post... I have more answers if you have more questions.

- Tom W.

Amazon is shipping the books now (in the US at least), so hopefully the book will appear in your local neighborhood bookstore soon, so you can take a peek before purchasing it. I hope it meets everyone's expectations, and would really like to hear any feedback people might have (send it to my email at twilhelm [at] heorot [dot] net if you don't mind).

As for competitive book titles, I think you'll find this book distinctly different and worth owning. I'm trying to temper my enthusiasm for the book, but I have to admit I am quite excited about it.

- Tom Wilhelm

Not trying to push my own courses, but I would like to inject into the conversation that the Heorot.net courses are currently discounted, which will only last a couple more weeks. The link to the discounts are at http://www.securityaegis.com/?page_id=339.

I wouldn't hesitate to look for intermediate-level security positions.  It would be beneficial if you had additional certs to get past HR filtering, but if you look for smaller companies you can often get past that - large  companies are a completely different beast.

The 6 years of experience doing IDS is enough to qualify you for something other than entry-level slots, even if it was part time.  Getting into a Sr. position is much tougher, though... just keep that in mind and keep improving your skill set.  Also, load up on HR fodder (disclaimer:  I don't think certs prove anything, but it does get interviews, whether people like to admit it or not... so just bite the bullet and get the certs).

I would rather use the best tool for the job, and if that means going through hoops, so be it.


Telnet has a nasty habit of intercepting characters it considers to be commands intended for the telnet application, thus corrupting the data stream.  Also, it will inject data into the stream as well.  With netcat, none of this happens - what you see is unadulterated.

When dealing with a switch, you won't see much difference using telnet over netcat.  However, once you proceed pass simple shell account access activities, netcat really shines.  As to the use of netcat within the context of this topic, I did state outright that the use of netcat was a tangent to this discussion.  Sorry if you thought I implied it was related to the discussion... my bad.


If all we're talking about is shell access, than I will definitely fall back to the original argument that ssh should be implemented.

Yeah, so did I - my solution was to use a VM to get around the AV.

As geekyone posted, netcat can be excluded from anti-virus rules.  Plus, I think symantec is the only av company that's put it on it's default quarantine list (I may be wrong on that one).

The argument still stands, though, that netcat is a better tool than telnet, especially with the ability to process raw traffic.

I'm curious what you see as the advantages telnet have over netcat.

FTP itself may or may not be a threat, depending on the contents of the FTP files and exploitability of the FTP app from within.  You can also set up FTP to be anonymous, in which case this argument is dead.

Telnet itself isn't necessarily a threat - it's the use of telnet to log into a system (ok, technically, it's the transmittal of username and password in cleartext, but you get the idea).  If you intend to allow remote logins, you might as well dictate in the corporate policy that ssh be used.  And if you go that route, you might as well require putty to be used for file transfers.

FTP and telnet (for logging in) are obsolete protocols in 90% of the cases today, and the alternatives are certainly not difficult to implement.  Also, on a tangent, I am baffled why people continue to use telnet in the first place - netcat is much more powerful, and doesn't have the problem of data manipulation that telnet has (...steps off soap box).

I see the incognito mode invaluable on public systems, especially schools, libraries, etc.  It may not do much for privacy across the network, but when someone is done at a public terminal, they'll feel a lot more secure walking away from an incognito session than what happens currently.

The Chrome EULA is being changed:

http://www.mattcutts.com/blog/google-chrome-license-agreement/

Strange that I haven't bumped into this site before - Kev's post hit google, which is how I found it.  I'll definitely be around, and will certainly keep everyone up on the latest pentest livecd releases.

- Tom W.