No, you don't -- technically. But whether you can enter enable mode without one depends on how you log in.
Here's the instant gratification version:
You can enter via the console without an enable password, but you will be stuck in user mode if you use a simple vty login password without an enable password set.
Here's the long-winded StackExchange answerer version:
Cisco authentication is kind of a mess for a beginner. There's a lot of legacy baggage there. Let me try to break this down in a real-world sense.
Everyone that has any business logging into a router or switch pretty much goes directly to privileged (enable) mode. The user mode is basically a front lobby, and serves little more purpose than to keep the draft out. In large organizations where you have vast networks and equally vast pools of labor, it may be justifiable to have someone who can knock on the front door and make sure someone is still there. (That is, to log in and run the most trivial commands just to see that the device is, in fact, responding and not on fire.) But in every environment I've ever worked in, tier 1 had at least some ability to break things.
As such, and particularly in a scenario like yours, knowing the enable password is obligatory to get anything done. You could say this is a second level of security -- one password to enter the device, another to escalate to administrative privilege -- but that seems a little bit silly to me.
As already noted, you can (and many people do) use the same password, which doesn't help much if someone has gained unauthorized access via telnet/ssh. Having static, global passwords shared by everyone is arguably more of an issue than having just one token required to enter. Finally, most other systems (services, appliances, etc.) don't require a second layer of authentication, and are not generally considered insecure because of this.
OK, that's my opinion on the topic. You'll have to decide for yourself whether it makes sense in light of your own security stance. Let's get down to business.
Cisco (wisely) requires you to set a remote access password by default. When you get into line configuration mode...
router> enable
router# configure terminal
router(config)# line vty 0 15
router(config-line)#
...you can tell the router to skip authentication:
router(config-line)# no login
...and promptly get hacked, but your attacker will end up in user mode. So if you have an enable password set, at least you have somewhat limited the damage that can be done. (Technically, you can't go any further without an enable password either. More on that in a moment...)
Naturally, no one would do this in real life. Your minimum requirement, by default and by common sense, is to set a simple password:
router(config-line)# login
router(config-line)# password cisco
Now, you will be asked for a password, and you will again end up in user mode. If you're coming in via the console, you can just type enable to get access without having to enter another password. But things are different via telnet, where you will probably get this instead:
$ telnet 10.1.1.1
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.
User Access Verification
Password: *****
router> enable
% No password set
router>
Moving on... You probably already know that, by default, all your configured passwords show up as plain text:
router# show run | inc password
no service password-encryption
password cisco
This is one of those things that tightens the sphincter of the security-conscious. Whether it's justified anxiety is again something you have to decide for yourself. On one hand, if you have sufficient access to see the configuration, you probably have sufficient access to change the configuration. On the other hand, if you happen to have carelessly revealed your configuration to someone who doesn't have the means themselves, then ... well, now they do have the means.
Luckily, that first line in the snippet above, no service password-encryption, is the key to changing that:
router(config)# service password-encryption
router(config)# line vty 0 15
router(config-line)# password cisco
Now, when you look at the configuration, you see this:
router(config-line)# do show run | begin line vty
line vty 0 4
password 7 01100F175804
login
line vty 5 15
password 7 01100F175804
login
!
!
end
This is marginally better than plain-text passwords, because the displayed string isn't memorable enough to shoulder-surf. However, it's trivial to decrypt -- and I use that term loosely here. You can literally paste that string above into one of a dozen JavaScript password crackers on the first Google results page, and get the original text back immediately.
These so-called "7" passwords are commonly considered "obfuscated" rather than "encrypted" to highlight the fact that it is just barely better than nothing.
As it turns out, however, all those password commands are deprecated. (Or if they're not, they should be.) That's why you have the following two options:
router(config)# enable password PlainText
router(config)# enable secret Encrypted
router(config)# do show run | inc enable
enable secret 5 $1$sIwN$Vl980eEefD4mCyH7NLAHcl
enable password PlainText
The secret version is hashed with a one-way algorithm, meaning the only way to get the original text back is by brute-force -- that is, trying every possible input string until you happen to generate the known hash.
When you enter the password at the prompt, it goes through the same hashing algorithm, and should therefore end up generating the same hash, which is then compared to the one in the configuration file. If they match, your password is accepted. That way, the plain text isn't known to the router except during the brief moment when you are creating or entering the password. Note: There's always the chance some other input can generate the same hash, but statistically it's a very low (read: negligible) probability.
If you were to use the above configuration yourself, the router will allow both the enable password and enable secret lines to exist, but the secret wins from the password prompt. This is one of those Cisco-isms that doesn't make much sense, but it's the way it is. Furthermore, there's no secret equivalent command from line configuration mode, so you're stuck with obfuscated passwords there.
Alright, so we now have a password that can't be recovered (easily) from the config file -- but there's still one problem. It's being transmitted in plain text when you log in via telnet. No good. We want SSH.
SSH, being designed with more robust security in mind, requires a little extra work -- and an IOS image with a certain feature set. One big difference is that a simple password is no longer good enough. You need to graduate to user-based authentication. And while you're at it, set up an encryption key pair:
router(config)# username admin privilege 15 secret EncryptedPassword
router(config)# line vty 0 15
router(config-line)# transport input ssh
router(config-line)# no password
router(config-line)# login local
router(config-line)# exit
router(config)# ip ssh version 2
router(config)# crypto key generate rsa modulus 1024
Now you're cooking with gas! Notice this command uses secret passwords. (Yes, you can, but shouldn't, use password). The privilege 15 part allows you to bypass user mode entirely. When you log in, you go straight to privileged mode:
$ ssh admin@10.1.1.1
Password: *****
router#
In this scenario, there's no need to use an enable password (or secret.)
If you're not yet thinking, "wow... what a clusterfudge that was", bear in mind there's a whole other long-winded post still lurking behind the command aaa new-model, where you get to dive into things like external authentication servers (RADIUS, TACACS+, LDAP, etc.), authentication lists (which define the sources to use, and in which order), authorization levels, and user activity accounting.
Save all that for a time when you feel like getting locked out of your router for a while.
Hope that helps!
Best Answer
technically speaking , ASA allows traffic from higher security level toward the lower level security area unless if u define an explicit ACL to do so. Your local are security level should have higher level than DMZ and DMZ higher than outside area. IF you follow this rule u should not be able to initiate any traffic from DMZ toward yr local area nodes. Based on this rule, nobody from outside have access to yr DMZ area so u should define Static NAT or PAT to allow traffic to yr servers from outside area. I hope this will help you. Thank you.