I havd to admit, it is a real penetration, for the first time
 I learnt how to make a report

I also gotta say, learning aside that the logo and color scheme for eLearnSecurity is pretty awesome.  Whoever came up with it is a darn good social engineer / marketeer.

Congrats!  And thanks for your feedback!

eternal_security

I would definitely recommend the web part for the novice students (as I was). The course is taking you from the beginning and it teaches you a lot. Each chapter contains theory and then the tools that help you automate the attacks.
The videos of the tools are very useful, too.
This course opened a new world for me, in an easy way. I will try to continue the exploration by myself, but it is always easier when you have a “master” that points you on the good direction.

I just have to add my $.02 after reading these posts. I purchased this course from eLearnsecurity and, being a beginner pentester, I find that it is MUCH more challenging to actually do this stuff than first thought. In my duties and speaking to many of the folks in the business, we spend the bulk of our time searching for vulnerabilities. This course "does" teach that, but it also attempts to focus on exploiting the vulnerabilities. In a typical engagement, I have not been asked to attempt to exploit a production system.

That being said, I have found that I was better off mentoring with a senior pentester than what I got from the slideshow that is this course. I never could get any of the exploits to work and honestly did not feel that I got much help, nor did I feel that it was worth $600 bucks for slides. Use your best judgment - it's especially tough with not too much on the market of this type of on-line training.

Good luck!

He may be referring to vulnerability scanning. Many companies perform scanning, but do not allow full on penetration testing.

Sorry I have to disagree with this MaXe and ultimately it all boils down to your SOW between you and your client. Trying to mimic a target is a bad move since you will unlikely be able to obtain an exact replica, patch revisions, installed software, system configurations.

In the last 4 years that I remember with clarity, I've performed to the tune of 50+ active zero knowledge tests with the vast majority of those have the go ahead to perform full exploits. Want to know how many services I crashed? None. This is because of me testing parameters in labs time and time again. Prior to going on a clients machine blindly, I know which tools are noisy, which tools consume a lot of resources (HP Webinspect anyone?) and when to use them.

From my point of view: "You wouldn't use a sledgehammer to drive a nail would you?" It boils down to understanding what tools do what, which are good alternative tools to use, how to attack your target.

The whole: "you may crash the server" is a moot point and it needs to be understood by the client: "Do you think an attacker from China (Advanced Persistent Annoyance) is going to worry about crashing your server?" A good tester from my POV will illustrate the risk of NOT being allowed to perform a REAL test. A good tester will also know what works and what doesn't. What offsets to use (timing variables, iffy exploits, etc.)

Most of the exploits one can find or write on their own will often contain information about the exploit and whether or not USING the exploit will leave a service unusable. It's up to the tester to weed out those exploits and NOT use ones that will crash services. This is my two cents.

Long ago it was a common popular belief that: "well if I clone their W2K, NT4 machine, run this exploit in my lab... It should run on their machine... Autopwnage!" This would be inconsistent with reality. You could never know what say Windows Updates a server has on it, what's in their IIS/ASP/C# pages to mimic a machine to exactness. What you'd be doing is selling them a pentest of YOUR server under the theory that: "if it affects mine, it can affect yours"

Hey,

I agree with both of you. I generally test web applications in a dev environment. I would normally find quite a few vulnerabilities. Once the developpers are done fixing them, I check again in dev before giving my "ok". Then, once in production, I test the application again in order to check the "production" problems and validate the whole package.

Being not experienced like sil, I was glad twice so far that I was working in dev... 

But on the other end, I always found something in prod after (mainly configuration issues).

So for me, test a clone/copy image first (if you have this luxury) then validate in prod.