[ I post this *not* because I'm tired of telling so many people the same thing, but rather figure it's interesting info. Considering if one person asks about it, there's probably 10 people who don't ask ] I've recieved a large number of requests, especially in the last 4 days, asking various topics, such as what programming languages I recommend, what books I think are good to start with, and in general how to go about establishing oneself in the security community and acquiring the knowledge to be in that position. Since I have a little different take than the normal suggestions, I'm going to spew them for all to see. Note that a lot of this is various parts I've emailed of to individuals. ------------------------------------------------------------------------ Where to start ------------------------------------------------------------------------ This is where I'm going to offer a very different opinion. If you are just starting, I suggest you *NOT* look at Technotronic, Bugtraq, Packetstorm, Rootshell (is this still active?), etc. Yes, *DON'T* start there (although they're good sites and that doesn't mean you can't visit them. :) The reasoning is simple: if your idea of knowing 'security' is knowing the latest exploits, you're going to find yourself not knowing much. Granted it's nice to know what's broken and what's not, but it's not going to give you a solid foundation of knowledge to build on. Great, you know RDS is the latest rage. You know how to download and run the script. You know how to patch it (maybe). 3 months from now, the patches are widely distributed, the issue becomes old--now what good is the knowledge you have? Let alone how much of the issue did you understand? Was your knowledge of the issue, or the exploit? This is my biggest point to stress, and one that people seem to overlook. So many people figure if they know the latest exploits, they know security. NO! NO! NO! All that happens is that you know 'exploits', *not* 'security'! Example: You know about phf, showcode.asp, Count.cgi, and test-cgi. But do you know in general what makes a CGI vulnerable? Do you know how to go about coding a secure CGI? Would you be able to start guessing at vulnerabilties in other CGIs based on that? Or are phf, showcode.asp, Count.cgi, and test-cgi exclusively all you know about? So I suggest that you *DON'T* start with exploits. Ignore they exist (well, you know what I mean). What you need to do is start by becoming a user. ------------------------------------------------------------------------ Becoming a user ------------------------------------------------------------------------ What I mean by this is that you need casual, general exposure. For instance, if you're going to perform web hacks, do you even know how to use the web? Great, you can open up Netscape or IE....you can type names, know that .html is a webpage. You need to keep along this route...become a power-user. Identify .asp and .cgi as dynamic. What's .php? What's this redirect thing? Cookies? SSL? All these things that a normal user encounters. NO EXPLOITS! Just normal use. You can't be elite++ and ignore the basic (boring) stuff. No free rides. Ok, so you know this stuff inside and out. You have exposure. Before you hack unix, you need to at least know how to login, logout, use the command shell, run your normal set of applications (mail, ftp, web, etc). You need to know the basics. Then you move onto becoming an admin. ------------------------------------------------------------------------ Becoming an admin ------------------------------------------------------------------------ Now you move beyond user realm, into more sophistication. Focus more on, say, the webserver itself. What type of server is it? What's the difference? How do you go about configuring it? Knowing the correct answers to a lot of this means knowing how it works, and what it does. Do you understand HTTP? The difference between HTTP 1.0 and 1.1? What's this WebDAV stuff? Knowing how HTTP 1.1 virtual hosting works helps you setup your webserver. Go deeper. How about OSes. How can you hack NT if you never configured it? You expect to crack an admin password without knowing how to run rdisk, manage user names and passwords, etc? You expect to use RDS (commandline) exploits when all you've used is the GUI? Again, you need to elevate from admin to 'power-admin'. Fine, you can do add users in the GUI. Are there other ways? What about the command line? And hell, what are all these .exe's in your system32 directory anyways? What do they do? Do you know why usernetctl needs to be suid? Do you even need usernetctl? Go deeper. Become intimate. This is key. Don't know enough to get by....know as much as you can find out. Become a guru. But note.... ------------------------------------------------------------------------ You can't know everything ------------------------------------------------------------------------ Alas, it's a sad fact of life. Don't think you can...if you think you do, you're fooling yourself, and you're probably spread thin. What you need to do is pick an area where your interests are most heavy, and learn more. Become a user. Become an admin. Become a guru. Become the de-facto #1 guy/gal on anything to do with that topic. Don't just learn how to use the web, how to write a CGI. Know HTTP. Know what web servers are supposed to do. Know where to look. Realize when they don't do what should be done. By knowing your subject intimately, you'll then automatically know how to exploit it. It's that simple. If you know all the ins and outs, well, security is included in those ins and outs. And not just the latest exploit either...all past, and future exploits. You may even find stuff (while becoming a guru) that's unknown. Wow, you. Finding exploits. Yes. But you have to understand what your looking at and how it works before hand. So put down that copy of whisker, and go learn what CGI actually is, how that affects HTTP, how webservers implement it, etc. Then you'll understand what it does. ------------------------------------------------------------------------ Programing languages ------------------------------------------------------------------------ Couple of things I was recently asked. First one being what programming languages do I recommend: I guess it depends on a few things--mostly how much time you want to sink into it, how useful you want it to be, how fast of a turn-around you want, and the complexity level of which you want to be involved. Choices are, in no particular order: Visual Basic. - Pretty easy to learn, many books on thhe subject, many free code repositories on the net. You should also be able to get the hang of it pretty fast as well. However, there's some glass-ceiling issues with the language, you don't have as much power as, say, c++. You also need to get a copy of VB (warez or legit...but it's not free in general), and you're limited to Windows. And coding exploits and patches is going to be rough. C++ - Probably the most powerful of languagees. Exist on practically all platforms, tons of books and stuff on the net about it. Freeware compilers for all platforms, so you can get the tools to get you started dirt cheap (free). A little more complex than VB, may take some more time to initially get the hang of. Basic stuff is easy, but more complex object-oriented stuff definately requires a little concentration. This is your all-around average choice. Assembly - Ultimate in complexity, will probably be overly-hard to learn as a first language. However, you learn this first, everything else is cake. ;) Some books, support for it is diminishing, but knowledge of asm is crucial for things like buffer overflows and exploits. Pretty much freeware for all platforms, but it's *tough* to get the hang of. Perl - Not a bad language. It's easy like VB,, so pickup on it is relatively quick. Does have glass ceilings like VB, however. But it runs on most platforms (unix and win), so that's a bonus. Lots of books on it (the O'Reilly 'Camel' books kick ass), and it's free. You can code some exploits with it...general stuff, but it's meant more for manipulating text stuff, not binary. So I guess it's all in what you want to do. Safest bet is C/C++. ------------------------------------------------------------------------- Recommended books ------------------------------------------------------------------------ Another question is what books do I recommend: I personally keep the following on hand for reference: Applied Cryptography (Bruce Scheiner) Linux Application Development (Mike Johnson and Erik Troan) Windows Assembly Language and Systems Programming (Barry Kauler) Perl Cookbook (Tom Christiansen and Nathan Torkington) (O'Reilly) Linux Programmer's Reference (Richard Petersen) (Osborne) All the O'Reilly 'Pocket Reference' books, which include vi, emacs, python, perl, pl/sql, NT, javascript, sendmail, tcl/tk, perl/tk I typically always dip into the above on a regular basis. As a general rule of thumb, most O'Reilly books rock. Find one on an interesting topic and go to town. :)