Friday, September 24, 2004
L2, L3 and L4 switching
With the rapid development of computer networks over the last decade, high-end switching has become one of the most important functions on a network for moving data efficiently and quickly from one place to another.
Here’s how a switch works: As data passes through the switch, it examines addressing information attached to each data packet. From this information, the switch determines the packet’s destination on the network. It then creates a virtual link to the destination and sends the packet there.
The efficiency and speed of a switch depends on its algorithms, its switching fabric, and its processor. Its complexity is determined by the layer at which the switch operates in the OSI (Open Systems Interconnection) Reference Model (see above).
OSI is a layered network design framework that establishes a standard so that devices from different vendors work together. Network addresses are based on this OSI Model and are hierarchical. The more details that are included, the more specific the address becomes and the easier it is to find.
The Layer at which the switch operates is determined by how much addressing detail the switch reads as data passes through.
Switches can also be considered low end or high end. A low-end switch operates in Layer 2 of the OSI Model and can also operate in a combination of Layers 2 and 3. High-end switches operate in Layer 3, Layer 4, or a combination of the two.
Layer 2 Switches (The Data-Link Layer)Layer 2 switches operate using physical network addresses. Physical addresses, also known as link-layer, hardware, or MAC-layer addresses, identify individual devices. Most hardware devices are permanently assigned this number during the manufacturing process.
Switches operating at Layer 2 are very fast because they’re just sorting physical addresses, but they usually aren’t very smart—that is, they don’t look at the data packet very closely to learn anything more about where it’s headed.
Layer 3 Switches (The Network Layer) Layer 3 switches use network or IP addresses that identify locations on the network. They read network addresses more closely than Layer 2 switches—they identify network locations as well as the physical device. A location can be a LAN workstation, a location in a computer’s memory, or even a different packet of data traveling through a network.
Switches operating at Layer 3 are smarter than Layer 2 devices and incorporate routing functions to actively calculate the best way to send a packet to its destination. But although they’re smarter, they may not be as fast if their algorithms, fabric, and processor don’t support high speeds.
Layer 4 Switches (The Transport Layer)Layer 4 of the OSI Model coordinates communications between systems. Layer 4 switches are capable of identifying which application protocols (HTTP, SNTP, FTP, and so forth) are included with each packet, and they use this information to hand off the packet to the appropriate higher-layer software. Layer 4 switches make packet-forwarding decisions based not only on the MAC address and IP address, but also on the application to which a packet belongs.
Because Layer 4 devices enable you to establish priorities for network traffic based on application, you can assign a high priority to packets belonging to vital in-house applications such as Peoplesoft, with different forwarding rules for low-priority packets such as generic HTTP-based Internet traffic.
Layer 4 switches also provide an effective wire-speed security shield for your network because any company- or industry-specific protocols can be confined to only authorized switched ports or users. This security feature is often reinforced with traffic filtering and forwarding features.
Here’s how a switch works: As data passes through the switch, it examines addressing information attached to each data packet. From this information, the switch determines the packet’s destination on the network. It then creates a virtual link to the destination and sends the packet there.
The efficiency and speed of a switch depends on its algorithms, its switching fabric, and its processor. Its complexity is determined by the layer at which the switch operates in the OSI (Open Systems Interconnection) Reference Model (see above).
OSI is a layered network design framework that establishes a standard so that devices from different vendors work together. Network addresses are based on this OSI Model and are hierarchical. The more details that are included, the more specific the address becomes and the easier it is to find.
The Layer at which the switch operates is determined by how much addressing detail the switch reads as data passes through.
Switches can also be considered low end or high end. A low-end switch operates in Layer 2 of the OSI Model and can also operate in a combination of Layers 2 and 3. High-end switches operate in Layer 3, Layer 4, or a combination of the two.
Layer 2 Switches (The Data-Link Layer)Layer 2 switches operate using physical network addresses. Physical addresses, also known as link-layer, hardware, or MAC-layer addresses, identify individual devices. Most hardware devices are permanently assigned this number during the manufacturing process.
Switches operating at Layer 2 are very fast because they’re just sorting physical addresses, but they usually aren’t very smart—that is, they don’t look at the data packet very closely to learn anything more about where it’s headed.
Layer 3 Switches (The Network Layer) Layer 3 switches use network or IP addresses that identify locations on the network. They read network addresses more closely than Layer 2 switches—they identify network locations as well as the physical device. A location can be a LAN workstation, a location in a computer’s memory, or even a different packet of data traveling through a network.
Switches operating at Layer 3 are smarter than Layer 2 devices and incorporate routing functions to actively calculate the best way to send a packet to its destination. But although they’re smarter, they may not be as fast if their algorithms, fabric, and processor don’t support high speeds.
Layer 4 Switches (The Transport Layer)Layer 4 of the OSI Model coordinates communications between systems. Layer 4 switches are capable of identifying which application protocols (HTTP, SNTP, FTP, and so forth) are included with each packet, and they use this information to hand off the packet to the appropriate higher-layer software. Layer 4 switches make packet-forwarding decisions based not only on the MAC address and IP address, but also on the application to which a packet belongs.
Because Layer 4 devices enable you to establish priorities for network traffic based on application, you can assign a high priority to packets belonging to vital in-house applications such as Peoplesoft, with different forwarding rules for low-priority packets such as generic HTTP-based Internet traffic.
Layer 4 switches also provide an effective wire-speed security shield for your network because any company- or industry-specific protocols can be confined to only authorized switched ports or users. This security feature is often reinforced with traffic filtering and forwarding features.
Friday, September 17, 2004
rss
Implementing and Troubleshooting Account Lockout
Keep your activation status intact when reinstalling XP
Have you ever wanted to reformat the hard disk and reinstall Windows XP on a system but you didn't want to mess around with Microsoft's Product Activation after the reinstall? Fortunately, you don't have to.
As long as you aren't making any hardware alterations, you can back up the activation status files before you reformat the hard drive and then restore them after you reinstall the operating system.
To perform the backup, follow these steps:
Use Windows Explorer to open the C:\Windows\System32 folder.
Copy the Wpa.dbl and Wpa.bak files to a floppy disk or CD.
To perform the restore, follow these steps:
Decline the activation request at the end of the installation procedure, and restart Windows XP.
During bootup, press [F8] to access the Windows Advanced Options menu.
Choose the Safe Mode (SAFEBOOT_OPTION=Minimal) option.
Use Windows Explorer to open the C:\Windows\System32 folder.
If they exist, rename the new Wpa.dbl and Wpa.bak files to Wpadbl.new and Wpabak.new.
Copy the original Wpa.dbl and Wpa.bak files from the floppy disk or CD to the C:\Windows\System32 folder.
Restart the system.
As long as you aren't making any hardware alterations, you can back up the activation status files before you reformat the hard drive and then restore them after you reinstall the operating system.
To perform the backup, follow these steps:
Use Windows Explorer to open the C:\Windows\System32 folder.
Copy the Wpa.dbl and Wpa.bak files to a floppy disk or CD.
To perform the restore, follow these steps:
Decline the activation request at the end of the installation procedure, and restart Windows XP.
During bootup, press [F8] to access the Windows Advanced Options menu.
Choose the Safe Mode (SAFEBOOT_OPTION=Minimal) option.
Use Windows Explorer to open the C:\Windows\System32 folder.
If they exist, rename the new Wpa.dbl and Wpa.bak files to Wpadbl.new and Wpabak.new.
Copy the original Wpa.dbl and Wpa.bak files from the floppy disk or CD to the C:\Windows\System32 folder.
Restart the system.
Wednesday, September 15, 2004
Windows routing tables
Below is the syntax to add a new route:
ROUTE ADD MASK METRIC IF
Here's an example:
ROUTE ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
In this example, 192.168.0.9 is the gateway for all traffic to the destination 192.168.1.0/24. The metric is 2, and the interface number is 2.
When you add a route using this syntax, the route doesn't persist across restarts of the computer. To make a route persist, add the -p switch to the command, as shown below:
ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
To delete a route, use the DELETE keyword and the destination address. Here's an example:
ROUTE DELETE 192.168.1.0
ROUTE ADD
Here's an example:
ROUTE ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
In this example, 192.168.0.9 is the gateway for all traffic to the destination 192.168.1.0/24. The metric is 2, and the interface number is 2.
When you add a route using this syntax, the route doesn't persist across restarts of the computer. To make a route persist, add the -p switch to the command, as shown below:
ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
To delete a route, use the DELETE keyword and the destination address. Here's an example:
ROUTE DELETE 192.168.1.0
Sunday, September 12, 2004
Handle basic password management on your Cisco router
Tuesday, September 07, 2004
Deciphering Authentication Events on Your Domain Controllers
Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. This article will explain how to decipher authentication event on your domain controllers.
Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. (You can view and configure your domain controllers’ audit policy from the Default Domain Controllers Security Policy shortcut in Administrative Tools. Use Event Viewer to view your security log.) Prior to Windows 2000 all you had was the “Audit logon events” category which didn’t work the way most people expected. When you enable “audit logon events” on NT and later domain controllers, the only logon events you’ll see in the domain controllers’ security logs are users and computers logging on to the domain controller itself. With “audit logon events” enabled, domain controllers do not record any activity related to domain users logging on at their workstations or other servers. The reason is that the concept of a logon is different than authentication. When you logon at your workstation with a domain account – you are logging into the workstation – not the domain controller. The domain controller is simply performing the authentication check. Therefore the old “audit logon events” audit policy doesn’t do you much good for tracking domain user logon activity or failed logon attempts. You’d have to enable “audit logon events” on each workstation and server on your network and then monitor those logs and you still wouldn’t see failed logon attempts by attackers using their own workstation. Thus, the need for the new audit policy introduced with Windows 2000 – “audit account logon events”. When you enable this policy on Windows 2000 or 2003 domain controller this policy records all domain account authentication that occurs on that domain controller in that domain controller’s security log. This activity is categorized as “Account Logon” in the security log as opposed to “Logon/Logoff” for the “audit logon events” policy. When you analyze the combined “Account Logon” activity of all your domain controllers you now how a complete picture of the logon activity of all domain accounts in your domain regardless of where the logon attempts are initiated from – computers of the local or trusted domain or even unknown computers completely outside your AD forest and external trusted domains.
Windows 2000 and 2003 domain controllers support Kerberos and NTLM authentication protocols. When a Windows 2000 or later computer needs to find out if a domain account is authentic the computer first tries to contact the DC via Kerberos. If it doesn’t receive a reply it falls back to NTLM. In an AD forest comprising computers running Windows 2000 and later all authentication between workstations and servers should be Kerberos. Windows 2000 and later domain controllers log different event IDs for Kerberos and NTLM authentication activity so it’s easy to distinguish them. In an AD forest of Windows 2000 or later computers, any NTLM authentication events you see on domain controllers can only have a few explanations. First, Windows will fall back to NTLM if routers for some reason block Kerberos traffic (UDP port 88). Second, if your domain trusts another domain outside your forest (defined in Active Directory Domains and Trusts) you’ll see NTLM events on you domain controllers since Kerberos doesn’t work for external trust relationships. (Note: Windows Server 2003 supports a new type of trust call cross forest trusts. A cross forest trust is a transitive, 2-way trust between 2 Windows Server 2003 domains. Cross forest trusts use Kerberos – not NTLM.) The third explanation for NTLM events on your domain controller’s security log are rogue computers.
Contrary to popular misconception, Windows does not prevent a user at a computer from an un-trusted domain or stand-alone computer (Windows computer that doesn’t belong to any domain) from connecting to a server in your domain using a domain account. To prove this just map a drive to a computer in an untrusting domain using the “net use” command. For instance in the below example I connect to a file server called NYC-FS-1 in the NYC domain using the domain Administrator account and a password of #dk32HE4.
net use \\nyc-fs-1.nyc.acme.local\c$ #dk32HE4 /user:nyc\administrator
If you have an application such as an IIS web application that uses NTLM authentication you will see NTKM also. About the only other explanation for NTLM events on your domain controller security logs is more mundane - you just have some pre Win2k computers somewhere in your local domain or in the overall forest.
The bottom line is that if an outsider is attacking accounts in your domain you will most likely see them as NTLM authentication errors – not Kerberos. Windows 2000 logs just 2 event IDs for all types of NTLM authentication activity – 680 and 681. A successful NTLM authentication yields an event ID 680 and a failure produces event ID 681. Both events list the user name that failed authentication as well as the name of the computer from when the authentication attempt originated (usually the user’s workstation). To determine why the authentication failed you need to look at the error code in event ID 681’s description.
See figure 1 for a listing of NTLM error codes. NTLM yields an authentication event whenever a user logs on to a computer interactively or over the network. For instance, imagine a user logs on to his NT workstation with a domain account and then uses a share folder on server A and server B. On whichever domain controller(s) that handles those authentication requests you’ll see a total of 3 event ID 680s – one for the interactive workstation logon and 2 for the network logon at server A and server B.
Things are a little different on Windows Server 2003 however. Annoyingly, in Windows Server 2003 Microsoft eliminated event ID 681 and instead uses event ID 681 for both successful and failed NTLM authentication attempts. So on Windows Server 2003 don’t look for event ID 681 and be sure to take into account the success/failure status of occurrences of event ID 680.
So turn on auditing for “audit account logon events” on your domain controllers and keep an eye out for event IDs 680 and 681 – they might reveal some computers that have missed being upgraded or worse an attack from an outsider. If you have multiple domain controllers and servers it helps to have a tool like this site’s sponsor – GFI’s LANGuard SELM – that can merge all that activity into one database and provide centralized alerts and reporting.
While tracking NTLM authentication is important, don’t forget about Kerberos authentication which will likely be the bulk of authentication activity in your domain controller security logs. We’ll look at Kerberos security events in my next article.
Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, is the creator and exclusive instructor for the 5 day Ultimate Windows Security seminar at ultimatewindowssecurity.com.
http://www.windowsecurity.com/articles/Deciphering-Authentication-Events-Domain-Controllers.html
Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. (You can view and configure your domain controllers’ audit policy from the Default Domain Controllers Security Policy shortcut in Administrative Tools. Use Event Viewer to view your security log.) Prior to Windows 2000 all you had was the “Audit logon events” category which didn’t work the way most people expected. When you enable “audit logon events” on NT and later domain controllers, the only logon events you’ll see in the domain controllers’ security logs are users and computers logging on to the domain controller itself. With “audit logon events” enabled, domain controllers do not record any activity related to domain users logging on at their workstations or other servers. The reason is that the concept of a logon is different than authentication. When you logon at your workstation with a domain account – you are logging into the workstation – not the domain controller. The domain controller is simply performing the authentication check. Therefore the old “audit logon events” audit policy doesn’t do you much good for tracking domain user logon activity or failed logon attempts. You’d have to enable “audit logon events” on each workstation and server on your network and then monitor those logs and you still wouldn’t see failed logon attempts by attackers using their own workstation. Thus, the need for the new audit policy introduced with Windows 2000 – “audit account logon events”. When you enable this policy on Windows 2000 or 2003 domain controller this policy records all domain account authentication that occurs on that domain controller in that domain controller’s security log. This activity is categorized as “Account Logon” in the security log as opposed to “Logon/Logoff” for the “audit logon events” policy. When you analyze the combined “Account Logon” activity of all your domain controllers you now how a complete picture of the logon activity of all domain accounts in your domain regardless of where the logon attempts are initiated from – computers of the local or trusted domain or even unknown computers completely outside your AD forest and external trusted domains.
Windows 2000 and 2003 domain controllers support Kerberos and NTLM authentication protocols. When a Windows 2000 or later computer needs to find out if a domain account is authentic the computer first tries to contact the DC via Kerberos. If it doesn’t receive a reply it falls back to NTLM. In an AD forest comprising computers running Windows 2000 and later all authentication between workstations and servers should be Kerberos. Windows 2000 and later domain controllers log different event IDs for Kerberos and NTLM authentication activity so it’s easy to distinguish them. In an AD forest of Windows 2000 or later computers, any NTLM authentication events you see on domain controllers can only have a few explanations. First, Windows will fall back to NTLM if routers for some reason block Kerberos traffic (UDP port 88). Second, if your domain trusts another domain outside your forest (defined in Active Directory Domains and Trusts) you’ll see NTLM events on you domain controllers since Kerberos doesn’t work for external trust relationships. (Note: Windows Server 2003 supports a new type of trust call cross forest trusts. A cross forest trust is a transitive, 2-way trust between 2 Windows Server 2003 domains. Cross forest trusts use Kerberos – not NTLM.) The third explanation for NTLM events on your domain controller’s security log are rogue computers.
Contrary to popular misconception, Windows does not prevent a user at a computer from an un-trusted domain or stand-alone computer (Windows computer that doesn’t belong to any domain) from connecting to a server in your domain using a domain account. To prove this just map a drive to a computer in an untrusting domain using the “net use” command. For instance in the below example I connect to a file server called NYC-FS-1 in the NYC domain using the domain Administrator account and a password of #dk32HE4.
net use \\nyc-fs-1.nyc.acme.local\c$ #dk32HE4 /user:nyc\administrator
If you have an application such as an IIS web application that uses NTLM authentication you will see NTKM also. About the only other explanation for NTLM events on your domain controller security logs is more mundane - you just have some pre Win2k computers somewhere in your local domain or in the overall forest.
The bottom line is that if an outsider is attacking accounts in your domain you will most likely see them as NTLM authentication errors – not Kerberos. Windows 2000 logs just 2 event IDs for all types of NTLM authentication activity – 680 and 681. A successful NTLM authentication yields an event ID 680 and a failure produces event ID 681. Both events list the user name that failed authentication as well as the name of the computer from when the authentication attempt originated (usually the user’s workstation). To determine why the authentication failed you need to look at the error code in event ID 681’s description.
See figure 1 for a listing of NTLM error codes. NTLM yields an authentication event whenever a user logs on to a computer interactively or over the network. For instance, imagine a user logs on to his NT workstation with a domain account and then uses a share folder on server A and server B. On whichever domain controller(s) that handles those authentication requests you’ll see a total of 3 event ID 680s – one for the interactive workstation logon and 2 for the network logon at server A and server B.
Things are a little different on Windows Server 2003 however. Annoyingly, in Windows Server 2003 Microsoft eliminated event ID 681 and instead uses event ID 681 for both successful and failed NTLM authentication attempts. So on Windows Server 2003 don’t look for event ID 681 and be sure to take into account the success/failure status of occurrences of event ID 680.
So turn on auditing for “audit account logon events” on your domain controllers and keep an eye out for event IDs 680 and 681 – they might reveal some computers that have missed being upgraded or worse an attack from an outsider. If you have multiple domain controllers and servers it helps to have a tool like this site’s sponsor – GFI’s LANGuard SELM – that can merge all that activity into one database and provide centralized alerts and reporting.
While tracking NTLM authentication is important, don’t forget about Kerberos authentication which will likely be the bulk of authentication activity in your domain controller security logs. We’ll look at Kerberos security events in my next article.
Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, is the creator and exclusive instructor for the 5 day Ultimate Windows Security seminar at ultimatewindowssecurity.com.
http://www.windowsecurity.com/articles/Deciphering-Authentication-Events-Domain-Controllers.html
