Access list syslog correlation

ACL syslog correlation is a Cisco IOS feature which provides the ability to identify which access list entry (ACE) was responsible for a permit or deny action appearing in syslog.
Consider the following access list applied to filter externally-sourced traffic destined for the internal network:

Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log
 999 deny ip any any

Lines 10 through 40 allow miscellaneous traffic types in, and line 50 explicitly denies inbound traffic destined to TCP/22 for the purpose of logging. Line 60 defines an explicit "deny any"; this isn't required, but included here for clarity.
When an inbound packet is matched and discard by rule 50, the following syslog message is generated:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(57289) ->
 10.0.0.1(22), 1 packet  

This log message informs the administrator of the action taken and the ACL which matched the packet, but in some cases we may want more detail readily available. This is where ACL hash correlation comes in handy. We can redefine the ACL rule to include an arbitrary keyword, up to 64 characters in length:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 50 deny tcp any any eq 22 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (tag = Deny_SSH)
 999 deny ip any any

Now when that rule discards a packet, its log message includes our tag:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(54843) ->
 10.0.0.1(22), 1 packet  [Deny_SSH]

These tags can be reused by multiple ACEs. Continuing our example, say we also want to deny traffic to SSH servers running on an alternate port, TCP/2222:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 60 deny tcp any any eq 2222 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
 60 deny tcp any any eq 2222 log (tag = Deny_SSH)
 999 deny ip any any

ACL logging tags are great for readily identifying ACE matches, particularly when you expect certain matches to occur, but manually defining a tag for each ACE isn't always practical. This is especially true when you want to maintain syslog correlation among hundreds or thousands of individual ACL rules. In such cases, automatically generated hashes would be the preferred option. Automatic hashing is enabled globally, and applied to any ACE with the log keyword with no argument following it.
Here we enable hash generation and add a few more ACEs to our ACL:

Router(config)# ip access-list logging hash-generation
Router(config)# ip access-list extended EXTERNAL->INTERNAL
Router(config-ext-nacl)# 70 deny tcp any any eq 1000 log
Router(config-ext-nacl)# 80 deny tcp any any eq 2000 log
Router(config-ext-nacl)# 90 deny tcp any any eq 3000 log
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
 60 deny tcp any any eq 2222 log (tag = Deny_SSH)
 70 deny tcp any any eq 1000 log (hash = 0x594F8697)
 80 deny tcp any any eq 2000 log (hash = 0xE471528C)
 90 deny tcp any any eq 3000 log (hash = 0x34CC0DD6)
 999 deny ip any any

As expected, a trigger by any of the ACEs with a hash appended works just as it does with tags:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(21196) ->
 10.0.0.1(1000), 1 packet  [0x594F8697]

While not immediately useful, a hash can be used to filter an ACL configuration and quickly identify the ACE responsible for an action:

Router# show ip access-lists EXTERNAL->INTERNAL | include 594F8697
 70 deny tcp any any eq 1000 log (1 match) (hash = 0x594F8697)

Use 'configure replace' Instead of 'copy start run'

Newbie Cisco networking admins are typically taught the command copy running-config startup-config, or copy run start, to save their configurations to NVRAM (i.e. Flash memory). (This is in contrast to the older yet much much more convenient write memory command, or simply wr.) Students quickly realize that the corollary of copying the running configuration to the startup configuration is that the startup configuration can likewise be copied to the running configuration. However, this operation doesn't work quite like one might expect. copy run start generates a new configuration file and overwrites entirely the previous configuration file. copy start run, however, acts more like a copy & paste operation: the contents of the startup configuration are processed as though they were issued via the CLI. This means that running configuration lines that aren't in the startup configuration won't be overwritten or removed. The result is usually a messy, incomplete configuration.
As an example, consider the following configuration excerpt from a startup configuration:

interface FastEthernet0/0
 description WAN Uplink
 ip address 172.16.0.2 255.255.255.252
 load-interval 60
 duplex auto
 speed auto
 service-policy input Foo
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto

After a few changes are made to accommodate a new uplink, the running configuration now looks like this:

interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description New WAN Uplink
 ip address 10.0.42.2 255.255.255.252
 load-interval 60
 duplex auto
 speed auto
 service-policy input Foo2

Before writing the new configuration to the startup configuration, the admin decides that the new uplink isn't ready yet and opts to revert the changes using copy start run, which he assumes will restore the running configuration to the startup configuration. Here is the result:

interface FastEthernet0/0
 description WAN Uplink
 ip address 172.16.0.2 255.255.255.252
 load-interval 60
 shutdown
 duplex auto
 speed auto
 service-policy input Foo
!
interface FastEthernet0/1
 description New WAN Uplink
 no ip address
 load-interval 60
 shutdown
 duplex auto
 speed auto
 service-policy input Foo2

We can see that a number of statements under interface FastEthernet0/1 remain from the prior running configuration. Additionally, the shutdown line was not removed from the FastEthernet0/0 interface as the startup configuration does not contain the no shutdown command.
A better alternative is to use the command configure replace, which is provided as part of IOS' configuration archival feature. This operation may take a moment depending on the size of your configuration file.

Router# configure replace nvram:startup-config
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: y
*Mar  1 00:22:03.095: Rollback:Acquired Configuration lock.
*Mar  1 00:22:06.619: %PARSER-6-EXPOSEDLOCKRELEASED: Exclusive configuration lock released from terminal '0' -Process= "Exec", ipl= 0, pid= 193
*Mar  1 00:22:08.627: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:22:09.655: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
The rollback configlet from the last pass is listed below:
********

!List of Commands:
line vty 0 4
 no login
end
********

Rollback aborted after 5 passes
Router#
*Mar  1 00:22:14.995: %PARSER-3-CONFIGNOTLOCKED: Unlock requested by process '193'. Configuration not locked.
Router#

We can verify that our running configuration is now identical to our startup configuration:

interface FastEthernet0/0
 description WAN Uplink
 ip address 172.16.0.2 255.255.255.252
 load-interval 60
 duplex auto
 speed auto
 service-policy input Foo
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto

As you might have guessed, configure replace can be used to load a configuration file from any supported filesystem, not just NVRAM/Flash.

Note:-

Some things worth mentioning.. The list option ( ie Router# configure replace nvram:startup-config list ) will list all commands that will be applied to the router’s configuration. Great for tracking changes that the IOS makes to the current config.
Another thing worth talking about is using this in conjunction with configuration archives.
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtrollbk.html

Cisco Switch Port Security

Port security is a layer two traffic control feature on Cisco Catalyst switches. It enables an administrator configure individual switch ports to allow only a specified number of source MAC addresses ingressing the port. Its primary use is to deter the addition by users of "dumb" switches to illegally extend the reach of the network (e.g. so that two or three users can share a single access port). The addition of unmanaged devices complicates troubleshooting by administrators and is best avoided.

Enabling Port Security

Port security can be enabled with default parameters by issuing a single command on an interface:

Switch(config)# interface f0/13
Switch(config-if)# switchport port-security

Although only a single interface is used for illustration in this article, port security, if configured, is typically configured on all user-facing interfaces.
We can view the default port security configuration with show port-security:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-down
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0000.0000.0000:0
Security Violation Count   : 0

As you can see, there are a number of attributes which can be adjusted. We'll cover these in a moment. When a host connects to the switch port, the port learns the host's MAC address as the first frame is received:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

Now, we disconnect the host from the port, connect a small switch or hub, and reconnect the original host plus a second, unauthorized host so that they both attempt to share the access port. Observe what happens as soon as the second host attempts to send traffic:

%PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/13, putting Fa0/13 in err-disable state
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c on port FastEthernet0/13.
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to down

Inspecting the status of port security on the port again, we can see that the new MAC address triggered a violation:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0021.55c8.f13c:10
Security Violation Count   : 1
Switch# show interfaces f0/13
FastEthernet0/13 is down, line protocol is down (err-disabled) 
  Hardware is Fast Ethernet, address is 0013.c412.0f0d (bia 0013.c412.0f0d)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
...

By default, a port security violation forces the interface into the error-disabled state. An administrator must re-enable the port manually by issuing the shutdown interface command followed by no shutdown. This must be done after the offending host has been removed, or the violation will be triggered again as soon as the second host sends another frame.

Tweaking Port Security

Violation Mode

Port security can be configured to take one of three actions upon detecting a violation:
shutdown (default) ; The interface is placed into the error-disabled state, blocking all traffic. protect ; Frames from MAC addresses other than the allowed addresses are dropped; traffic from allowed addresses is permitted to pass normally. restrict ; Like protect mode, but generates a syslog message and increases the violation counter.
By changing the violation mode to restrict, we are still alerted when a violation occurs, but legitimate traffic remains unaffected:

Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# ^Z
Switch#
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c on port FastEthernet0/13.
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0021.55c8.f13c:10
Security Violation Count   : 3

Unfortunately, violating traffic will continue to trigger log notifications, and the violation counter will continue to increase, until the violating host is dealt with.

Maximum MAC Addresses

By default, port security limits the ingress MAC address count to one. This can be modified, for example, to accommodate both a host and an IP phone connected in series on a switch port:

Switch(config-if)# switchport port-security maximum 2

One also has the option to set a maximum MAC count for the access and voice VLANs independently (assuming a voice VLAN has been configured on the interface):

Switch(config-if)# switchport port-security maximum 1 vlan access
Switch(config-if)# switchport port-security maximum 1 vlan voice

MAC Address Learning

An administrator has the option of statically configuring allowed MAC addresses per interface. MAC addresses can optionally be configured per VLAN (access or voice).

Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 ?
  vlan  set VLAN ID of the VLAN on which this address can be learned
  
Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 vlan access

The configured MAC address(es) are recorded in the running configuration:

Switch# show running-config interface f0/13
Building configuration...

Current configuration : 259 bytes
!
interface FastEthernet0/13
 switchport access vlan 10
 switchport mode access
 switchport voice vlan 20
 switchport port-security
 switchport port-security violation restrict
 switchport port-security mac-address 001b.d41b.a4d8
 spanning-tree portfast
end

Obviously, this is not a scalable practice. A much more convenient alternative is to enable "sticky" MAC address learning; MAC addresses will be dynamically learned until the maximum limit for the interface is reached.

Switch(config-if)# no switchport port-security mac-address 001b.d41b.a4d8
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# ^Z
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

After a MAC address has been learned, it is recorded to the configuration similarly to as if it were entered manually:

Switch# show running-config interface f0/13
Building configuration...

Current configuration : 311 bytes
!
interface FastEthernet0/13
 switchport access vlan 10
 switchport mode access
 switchport voice vlan 20
 switchport port-security
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky 001b.d41b.a4d8
 spanning-tree portfast
end

MAC Address Aging

By default, secure MAC addresses are learned (in effect) permanently. Aging can be configured so that the addresses expire after a certain amount of time has passed. This allows a new host to take the place of one which has been removed. Aging can be configured to take effect at regular intervals, or only during periods of inactivity. The following example configures expiration of MAC addresses after five minutes of inactivity:

Switch(config-if)# switchport port-security aging time 5
Switch(config-if)# switchport port-security aging type inactivity
Switch(config-if)# ^Z
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 5 mins
Aging Type                 : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

After five minutes of inactivity, we can see that the address has been purged:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 5 mins
Aging Type                 : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

At this point, the old address will be re-learned the next time a frame is sent from that host, or a new host can take its place.

Auto-recovery

To avoid having to manually intervene every time a port-security violation forces an interface into the error-disabled state, one can enable auto-recovery for port security violations. A recovery interval is configured in seconds.

Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 600

Ten minutes after a port was error-disabled, we can see that the port is automatically transitioned back into operation:

%PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Fa0/13
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up

This is a great way to automatically clear port security violations after the user has been given an opportunity to remove the offending host(s). Note that is the cause is not cleared, the violation will trigger again after the port comes back up, re-initating the auto-recovery cycle.

Note

Although a deterrent, port security is not a reliable security feature, as MAC addresses are trivially spoofed, and multiple hosts can still easily be hidden behind a small router. IEEE 802.1X is a much more robust access edge security solution.

Barada Open source Two Factor Authentication system

Perhaps you occasionally find it necessary to access your email or login to a remote server from a computer that is not your own. The problem, of course, is that it is often unwise to type your password into computers that are not under your control. Terminals at libraries, internet cafes, or maybe even your less-careful friend's houses could be running keystroke loggers.

There are existing solutions for this, of course. The two obvious choices are a One Time Password system (like S/Key or OTPW) or a Two Factor Authentication system (like RSA SecureID or CryptoCard). We don't like the OTP option because it requires that you carry a list of passwords around with you, there can be logistical problems if you get to the end of your list while you're still traveling, and you have to type your constant "prefix" for each OTP into untrusted computers. So we prefer two factor authentication because there is the security of two factors (something you have and something you know) and it solves the keystroke logging problem in a more convenient way (no lists, no out of date information, no typing of anything but a temporary access code into untrusted computers).

Ironically, then, the problem with systems like SecureID or CryptoCard is that they're often not convenient. They cost money to license, the hardware costs money, and they're difficult to maintain. You have to setup a dedicated Solaris machine with RADIUS support just to deploy SecureID, which isn't really great for someone with a small setup.

And that's why we wrote this. Barada turns your phone into a two factor authentication device. It's an implementation of the HOTP protocol in the form of a PAM module (the server) and an Android applicaton (the client).

Basically, in addition to a normal password, users are also assigned a PIN number and a 128 bit key. Every time you'd like to login using two-factor authentication, you open up the Android application, type in your PIN number, and get back a six character one time password that you can then use to authenticate remotely. The PIN number is not stored on the phone, and the the OTP can only be used exactly once. Thus, the loss of the phone does not result in leaked passwords, and the capture of an OTP does not result in remote access.

This module can be installed above the normal authentication module in the PAM stack, so at any moment you can either use your normal password or Barada's two-factor authentication interchangably. Sitting at a trusted computer, you might choose to quickly type in a password, while you might choose to use two-factor authentication when using a non-trusted or public computer.

Download :- Barada

Big Issue- The Never Expiring Password

It seems that many if not all IT Auditors, CSOs, and IT security staff, live daily with the fear of the “never expiring password” being exposed. It is the unspoken taboo – the wide open back door in every corporate network today. It is virtually certain that there is not a single business critical application in your company that isn’t wide open. Do you ever wonder how it is that information such as credit card details, personal data, intellectual property, seems to always be so vulnerable. You would think that companies had adequate security precautions to stop this happening, and yet it continues to be a problem.

So where is this wide open back door? In every one of your applications.

When, for example, a user accesses a web based application through a Portal, behind the scenes an awful lot of activity takes place to present the information to the user. This information is stored on systems and databases in your organisation. In order to access these resources, the Portal uses service accounts created on the systems to access the data.

The challenge of securing, managing and sharing the service accounts becomes a major overhead issue for IT departments and application managers in your organisation. The Service Account Passwords that enable applications to communicate with each other must also be managed as they present one of the biggest security backdoors.

In order for these applications to get access to data, they have to “logon” to the systems and applications that store the data, and since the credentials to logon are in the application, they are embedded in the code. Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes. So what’s the big deal you might ask? Well there are a number of things.

Firstly you have the problem of the never expiring password on a system which is accessible by administrators and anyone else who might have privileged access to a system. The problem is more acute when a company is relying on hosting services from a third party. Your applications are accessing valuable business critical data thousands of times a day, using the same user ID and password. In fact there might very well be hundreds of applications all accessing using the same credentials. And since the applications do not have any integrated security such as VPN technology, the passwords to these accounts are often stored in clear text (not encrypted), thus becoming visible to developers, support staff and anyone that has access to the application code.

Secondly because these passwords are often hard coded within the applications/scripts, a reset of a Service Account password becomes a complex process involving changes to application code, compilation, and in some cases a long process of transferring the code from development to QA to production. In some cases this change might result in or require downtime for the application, a scenario that is unacceptable in cases of confidential information.

Thirdly auditing is virtually impossible. Because the credentials that are embedded in the application, although in theory only accessible to the application they can actually be used by any developer who has access to the code. So if for example a person was to log in using the credentials, it would be impossible to discover this through a simple audit check.

Finally the most serious aspect of this is that this user ID and password is known by developers and support staff and can be used for personal access to the resources. And in many cases today those credentials are know by off-shore developers who have been contracted to develop the applications for your organisation. So access to your business data is ultimately in the hands of developers who may be thousands of miles away.

It is likely that your organisation has gone to unprecedented efforts to secure your access as a user, using all kinds of innovative technology from tokens to digital certificates, and at the same time forgetting or possibly choosing to ignore that unauthorized personnel including ex-employees, MSP staff, off-shore developers, have the keys to open up your most valuable assets.The good news is that there are solutions available that will allow you to once and for all face up to this unspoken taboo and eliminate this threat.

The solution is digital vaulting technology. It means that no organisation today needs to feel a sense of being exposed to risks in this area. Regardless of the platform, the technology is available today to ensure that all your applications will never again require the never expiring password, but the first step in solving the problem is to face up to the unspoken taboo in your organisation and do something about it.

Beware the Default Password

During the course of a recent security audit I was rather surprised to find a critical system still running with a default password. The default password has long been the bug bear of many the security admin. At the same time it has been the savior of many of us at one stage or another, desperately locked out from that system, urgently requiring access, and no clue as to what the password is, or might be.

The default password is generally installed by the manufacturer, most often on hardware devices such as routers and wireless access points, but also by software application developers and even on some operating systems, although this is becoming less and less commonplace. The default password exists to allow an administrator initial access, for setup and configuration, and you are generally forced, or at least you should be, to change the password to something more complicated as the configuration advances. Unfortunately, this is not a step that everyone takes.

Worse again, there have been numerous accounts of software and hardware products that have 'undocumented' administrative accounts installed. So, even if you took the conscientious step of removing or changing what you thought was the default, you may still be exposed. Take Oracle for example. Pete Finnegan, the self-confessed master of all things Oracle, maintains a web page devoted to the Oracle default password. At the last count, there are more than 600 unique accounts in his list. Mr. Finnegan has some interesting views on how many of these accounts come about to be created in the first instance. He says some "are created by Oracle itself when the database is created. For instance the accounts SYS and SYSTEM, DBSNMP and OUTLN are often created by default when a database is created. If the database is created by using the wizard the problem can be much bigger with 10s 0r 20s of accounts being created simply as part of the database creation".

It is also the case that further Oracle default users can be created when third party software is installed for use such as BAAN or SAP. The same issues of default users being added to the database can occur when third party development or maintenance tools are added such as TOAD or PL/SQL Developer. An excellent tool that will scan your Oracle implementation for signs of default accounts can be downloaded here. If your organization uses Oracle, there is a strong chance that you will be susceptible.

As recently as February this year, researchers at the University of Indiana published reports that show how attackers could take over your home router using malicious JavaScript code. All is required is for the default password to be in place. Once the router has been compromised, victims can be redirected to fraudulent Web sites, the researchers say. So instead of downloading legitimate Microsoft software updates, for example, they could be tricked into downloading malware. Instead of online banking, they could be giving up sensitive information to phishers. At the heart of the problem is the fact that consumer routers ship with simple, well-known default passwords, like "admin," which could be exploited by attackers. "Owners of home routers who set a moderately secure password - one that is non-default and non-trivial to guess - are immune to router manipulation via JavaScript," the paper states.

It is easy to lay some of the blame on the door of the manufacturer. They could be accused of shipping product with poorly configured security settings. Lets face it; it is not hard for them to force the user to change the initial configuration password. But that alone is not enough. What about the 'undocumented' password, the one that you don't even know about?

There are resources available on the Internet that allows you to audit your network devices and software applications. This should be performed as part of your yearly audit schedule. A simple Google search for 'default password list' yields hundreds of sites that claim to have the most comprehensive database of default passwords. One of the oldest, and still reliable, can be found here. It makes for some interesting reading and is regularly updated.Whatever the organization, whatever the choice of software or hardware vendor, the default password is likely to raise its ugly head from time to time. Be proactive and get scanning. You will be amazed at what you may find.