Windows Internals covering windows server 2008 and windows vista- P20

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

0
52
lượt xem
7
download

Windows Internals covering windows server 2008 and windows vista- P20

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Windows Internals covering windows server 2008 and windows vista- P20: In this chapter, we’ll introduce the key Microsoft Windows operating system concepts and terms we’ll be using throughout this book, such as the Windows API, processes, threads, virtual memory, kernel mode and user mode, objects, handles, security, and the registry.

Chủ đề:
Lưu

Nội dung Text: Windows Internals covering windows server 2008 and windows vista- P20

  1. ■ Authority For secure clients (which have their name records signed by a certifying authority), the authority is identified by an SHA-1 hash of an associated public key, while for unsecured clients, it is zero. If a client is secure, PNRP validates the name record before publishing it. ■ Classifier The classifier uses a simple string to identify a service provided by a peer, which allows multiple services to be provided by the same device. To create a PNRP ID, PNRP hashes the P2P ID and combines it with a unique 128-bit ID called the service location, as shown in Figure 12-21. The service location identifies different instances of the same P2P ID in the same cloud. (PNRP uses two clouds: a global cloud, which corresponds to all IPv6 addresses on the Internet, and the link-local cloud, which corresponds to IPv6 addresses within a single subnet.) PNRP Resolution and Publication PNRP name resolution occurs in two phases: ■ Endpoint determination In this phase, the requesting peer determines the IPv6 address associated with the peer responsible for publishing the PNRP ID of the desired service. ■ PNRP ID resolution In this phase, once the requesting peer has located and confirmed the availability of the peer associated with the IPv6 address, it sends a PNRP request message for the PNRP ID of the service being requested. The peer providing the service replies to confirm the PNRP ID and can supply a comment and up to 4 KB of additional data, such as context information related to the service. During the first phase, PNRP iterates over nodes while locating the publishing node, such that the node performing name resolution will be responsible for contacting nodes that are successively closer to the desired PNRP ID. Each iteration works as follows: Once a peer receives a request message, it performs a lookup in its cache for the requested PNRP ID. If a match is found, the request message is sent directly; otherwise, it is sent to the next closest PNRP ID (by seeing how much of the ID matches). When a node receives a request message for which it cannot find a PNRP ID, it checks the distance of any other IDs in the cache to the target ID. If it finds a node that is closer, the requested node sends a reply to the requesting node, where the reply contains the IPv6 address of the peer that most closely matches the target PNRP ID. The requesting node can then use the IPv6 address to send another query to that address’s node. If no node is closer, the requesting node is 940 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  2. notified, and that node sends the request to the next closest node. Assuming PNRP IDs of 200, 350, 450, 500, and 800, Figure 12-22 depicts a possible endpoint determination phase for an example in which peer A is trying to find the endpoint for PNRP 800 (peer E). To publish its PNRP ID(s), a peer first sends PNRP publication messages to its closest neighbors (entries in its cache that have IDs that are in the lowest levels) to seed their caches. It then randomly chooses nodes in the cloud that are not neighbors and sends them PNRP name resolution requests for its own PNRP ID. Through the mechanism described earlier, the endpoint determination phase will result in the seeding of the PNRP ID across the caches of the random nodes that were chosen in the cloud. . 12.5 Location and Topology Today’s networked computers often move between networks that require different configuration settings, for example, a corporate LAN and a home-based wireless network. Additionally, today’s networks are complex, often spanning multiple devices across different topologies. Windows includes the Network Location Awareness (NLA) service to enable the dynamic configuration of network applications and settings based on location, and Link-Layer Topology Discovery (LLTD) to enable the intelligent discovery and mapping of networked devices. Network Location Awareness (NLA) The NLA service provider is implemented as a Winsock Namespace Provider (NSP) and provides the necessary framework for allowing computers and devices that move across different networks to select the most appropriate configuration settings. For example, an application taking 941 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  3. advantage of NLA can detect when the user moves from a high-speed LAN to a high-latency wireless network and fine-tune its bandwidth use appropriately. NLA can also detect when a home computer on a LAN may also have a secondary VPN connection to the office and select the proper configuration options. Instead of having developers rely on manual network interface information to figure out the type of network, and the IP addresses or DNS names associated with them, NLA provides a standardized query API for enumerating all the local network attachment information and correlating it with network interface information. The NLA API also includes notifications that enable applications to respond to changes when they occur. NLA provides applications two pieces of location information: ■ Logical network identity This identity is based on the logical network’s DNS domain name. If one does not exist, NLA uses custom static information stored in the registry together with the network’s subnet address as the identity. ■ Logical network interfaces For each network that a device is attached to, NLA creates an adapter name that identifies interfaces such as NICs or RAS connections in a unique fashion. Applications use adapter names with the IP Helper API (%SystemRoot%\System32\Iphlpapi.dll) to query interface information and characteristics. Each logical network is implemented as a service class with an associated GUID and properties. NLA creates instances of that service class when it returns information about a logical network. Service classes are schemas that describe a namespace; they define the name, identifier, and namespace-specific information that is common to all instances. These classes are then used in combination with the WSALookupService* API when performing name resolution. Link-Layer Topology Discovery (LLTD) The LLTD protocol operates over both wired and wireless networks and enables applications to discover the topology of a network. For example, the Network Map functionality in Windows uses LLTD to draw the local network topology for the connected devices that support the LLTD protocol. Additionally, LLTD supports Quality of Service (QoS) extensions, which allow applications to diagnose network problems such as low signal strength on a wireless network and bandwidth constraints on home networks. Because it operates on the OSI Data-link layer (2), LLTD works only on a single subnet, and therefore can’t cross routers, but its capabilities make it suitable for most home and small-office networks. The LLTD Mapper I/O and the LLTD Responder components implement LLTD. The former is responsible for the discovery process and for generating network maps. Because it uses a protocol different from IP, the LLTD Mapper uses NDIS APIs to directly send commands to the network via the network adapter. The LLTD Responder listens for and responds to discovery commands with information about the computer. As mentioned earlier, only devices that have a responder are shown in the network map. 942 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  4. 12.6 Protocol Drivers Networking API drivers must take API requests and translate them into low-level network protocol requests for transmission across the network. The API drivers rely on transport protocol drivers in kernel mode to do the actual translation. Separating APIs from underlying protocols gives the networking architecture the flexibility of letting each API use a number of different protocols. The Internet’s explosive growth and reliance on the TCP/IP protocol has made TCP/IP the preeminent protocol in Windows. The Defense Advanced Research Projects Agency (DARPA) developed TCP/IP in 1969 specifically as the foundation for the Internet; therefore, TCP/IP has WAN-friendly characteristics such as routability and good WAN performance. TCP/IP is the preferred Windows protocol and is installed by default, although it can be removed. However, the 4-byte network addresses used by the IPv4 protocol on the legacy TCP/IP stack limits the number of public IP addresses to roughly 4 billion, which is a limit that will be pressed as more and more devices, such as cell phones and PDAs, acquire an Internet presence. For that reason, the IPv6 protocol, which has 16-byte addresses, is gaining adoption. Windows includes a combined TCP/IP stack, called the Next Generation TCP/IP Stack, which supports both IP and IPv6. When operating on IPv6 networks, the stack also supports coexistence with IPv4 networks through the use of tunneling. The Next Generation TCP/IP Stack offers several advanced features to improve network performance, some of which are outlined in the following list: ■ Receive Window Auto Tuning. The TCP protocol defines a receive window size, which determines how much data a receiver can accept before the server requests an acknowledgment. A higher size favors low-latency networks with high throughput, while lower values work better on networks such as Wi-Fi. The Windows TCP/IP stack is capable of analyzing the conditions of a network and choosing the optimal receive window size, adjusting it as needed if the network conditions change. ■ Compound TCP (CTCP). While automatically changing the receive window size allows more data to be received, CTCP aggressively increases the amount of data that can be sent by a machine, while monitoring bandwidth, latency, and packet loss. Using CTCP on a high-bandwidth, low-latency network can significantly improve transfer speeds. CTCP is disabled by default. ■ Explicit Congestion Notification (ECN). Whenever a TCP packet is lost, the TCP protocol assumes that the data was dropped because of router congestion and enforces congestion control, dramatically lowering the sender’s transmission rate. ECN allows routers to explicitly mark packets as being forwarded during congestion, which is read by the Windows TCP/IP stack as a sign that transmission rates should be lowered. Lowering rates in this manner results in better performance than relying on congestion control. ECN is disabled by default. ■ High-loss throughput improvements, including the NewReno Fast Recovery Algorithm, Enhanced Selective Acknowledgment (SACK), Forward RTO-Recovery (F-RTO), and Limited Transit. These algorithms reduce the overall retransmission of acknowledgments or TCP segments during high-loss scenarios while still maintaining the integrity of the TCP stream. This allows for greater bandwidth in these environments and preserves TCP’s reliable transport semantics. 943 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  5. The Next Generation TCP/IP Stack (\%SystemRoot%\Drivers\Tcpip.sys), shown in Figure 12-23, implements TCP, UDP, IP, ARP, ICMP, and IGMP. To support legacy protocols such as NetBIOS, which make use of the deprecated TDI interface, the network stack also includes a component called TDX, which creates device objects that represent particular protocols so that clients can obtain a file object representing a protocol and issue network I/O to the protocol using TDI IRPs. The TDX component creates several device objects that represent various TDI client–accessible protocols: \Device\Tcp6, \Device\Tcp, \Device\Udp6, \Device\Udp, \Device\Rawip, and \Device\Tdx. eXPeriMeNT: Looking at TCP/iP’s Device Objects Using the kernel debugger to look at a live system, you can examine TCP/IP’s device objects. After performing the !drvobj command to see the addresses of each of the driver’s device objects, execute !devobj to view the name and other details about the device object. 1. kd> !drvobj tdx 2. Driver object (861d9478) is for: 3. \Driver\tdx 4. Driver Extension List: (id , addr) 5. Device Object list: 6. 861db310 861db440 861d8440 861d03e8 7. 861cd440 861d2318 861d9350 8. lkd> !devobj 861cd440 9. Device object (861cd440) is for: 10. Tcp6 \Driver\tdx DriverObject 861d9478 11. Current Irp 00000000 RefCount 7 Type 00000012 Flags 00000050 12. Dacl 8b1bc54c DevExt 861cd4f8 DevObjExt 861cd500 13. ExtensionFlags (0x00000800) 14. Unknown flags 0x00000800 15. Device queue is not busy. 16. lkd> !devobj 861db440 17. Device object (861db440) is for: 18. RawIp \Driver\tdx DriverObject 861d9478 944 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  6. 19. Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000050 20. Dacl 8b1bc54c DevExt 861db4f8 DevObjExt 861db500 21. ExtensionFlags (0x00000800) 22. Unknown flags 0x00000800 23. Device queue is not busy. 24. lkd> !devobj 861d8440 25. Device object (861d8440) is for: 26. Udp6 \Driver\tdx DriverObject 861d9478 27. Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000050 28. Dacl 8b1bc54c DevExt 861d84f8 DevObjExt 861d8500 29. ExtensionFlags (0x00000800) 30. Unknown flags 0x00000800 31. Device queue is not busy. 32. lkd> !devobj 861d03e8 33. Device object (861d03e8) is for: 34. Udp \Driver\tdx DriverObject 861d9478 35. Current Irp 00000000 RefCount 6 Type 00000012 Flags 00000050 36. Dacl 8b1bc54c DevExt 861d04a0 DevObjExt 861d04a8 37. ExtensionFlags (0x00000800) 38. Unknown flags 0x00000800 39. Device queue is not busy. 40. lkd> !devobj 861cd440 41. Device object (861cd440) is for: 42. Tcp6 \Driver\tdx DriverObject 861d9478 43. Current Irp 00000000 RefCount 7 Type 00000012 Flags 00000050 44. Dacl 8b1bc54c DevExt 861cd4f8 DevObjExt 861cd500 45. ExtensionFlags (0x00000800) 46. Unknown flags 0x00000800 47. Device queue is not busy. 48. lkd> !devobj 861d2318 49. Device object (861d2318) is for: 50. Tcp \Driver\tdx DriverObject 861d9478 51. Current Irp 00000000 RefCount 167 Type 00000012 Flags 00000050 52. Dacl 8b1bc54c DevExt 861d23d0 DevObjExt 861d23d8 53. ExtensionFlags (0x00000800) 54. Unknown flags 0x00000800 55. Device queue is not busy. 56. lkd> !devobj 861d9350 57. Device object (861d9350) is for: 58. Tdx \Driver\tdx DriverObject 861d9478 59. Current Irp 00000000 RefCount 0 Type 00000021 Flags 00000050 60. Dacl 8b0649a8 DevExt 00000000 DevObjExt 861d9408 61. ExtensionFlags (0x00000800) 62. Unknown flags 0x00000800 945 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  7. 63. Device queue is not busy. Windows Filtering Platform (WFP) Windows includes a rich and extensible platform for monitoring, intercepting, and processing network traffic at all levels in the network stack. Other Windows networking services extend basic networking features of the TCP/IP protocol driver by relying on the WFP. These include network address translation (NAT), IP filtering, IP inspection, and Internet Protocol Security (IPSec). Figure 12-24 shows how the different components of the WFP are integrated with the TCP/IP stack. These include: ■ Filter engine The filter engine is implemented in both user mode and kernel mode and performs all the filtering operations on the network. Each filter engine component consists of filtering layers, one for each component of the network stack. The user-mode engine, responsible for RPC and IPSec keying policy, among other things, contains approximately 10 filters, while the kernel-mode engine, which performs the network and transport layer filtering of the TCP/IP stack, contains around 50. ■ Shims Shims are the kernel-mode components that reside between the network stack and the filter engine. They are responsible for making the decision to allow or block network traffic based on their filtering behavior, which is defined by the filter engine. A shim operates in three steps: it parses the incoming data to match incoming values with entries in the filter engine, calls the filter engine to return an action based on the incoming values, and then interprets the action (drop the packet, for example). ■ Base filtering engine (BFE) The BFE is a user-mode service (%SystemRoot%\System32 \Bfe.dll) that manages all WFP operations. It is responsible for adding and removing filters from the WFP stack, managing the filter configuration, and enforcing security on the filter database. ■ Callout drivers Callout drivers are kernel-mode components that add custom filtering functionality outside the basic support provided by the WFP. Callout drivers associate callout functions with one or more kernel-mode filtering layers, and the WFP enables callout functions to perform deep packet inspection and modification. Network address translation (described next) and IPSec, are implemented as callout drivers, for example. 946 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  8. Network Address Translation Network address translation (NAT) is a routing service that allows multiple private IP addresses to map to a single public IP address. Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet. NAT allows one computer of the LAN to be assigned an IP address and the other computers to use private IP addresses and be connected to the Internet through that computer. NAT translates between private IP addresses and the public IP address as necessary, routing packets between LAN computers and the Internet. NAT components on Windows consist of a NAT device driver, \%SystemRoot%\System32 \Drivers\Ipnat.sys, that interfaces with the WFP stack as a callout driver, as well as editors that can perform additional packet processing beyond address and port translation. NAT can be installed as a routing protocol component with the Routing And Remote Access MMC snapin or by configuring Internet Connection Sharing (ICS), although NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in. IP Filtering 947 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  9. Windows includes a very basic IP filtering capability with which a user can choose to allow only certain ports or IP protocols into or out of the network. While this capability can serve to protect a computer from unauthorized network accesses, its drawback is that it is static and does not automatically create new filters for traffic initiated by applications running on the computer. Windows also includes host firewall capability, called Windows Firewall, that goes beyond the basic filtering just described. Windows Firewall uses WFP to provide a stateful firewall, which is one that keeps track of traffic flow so that it distinguishes between TCP/IP traffic that originates on the local LAN and unsolicited traffic that originates on the Internet. When Windows Firewall is enabled on an interface, one of three profiles can be applied—public, private, and domain. By default, when the public profile is chosen (or until a profile is selected), all unsolicited incoming and outgoing traffic received and sent by the computer is discarded, other than traffic from network services and other system applications. A user or application can define exceptions so that services running on the computer, such as file and printer sharing or a Web site, can be accessed from other computers. The Windows Firewall service, which executes in a Svchost process, uses the BFE to pass exception rules defined in the configuration user interface to the IPNat driver. The WFP filter engine executes the callback functions of each registered callout driver as it processes both inbound and outbound IP packets. A callback function can provide NAT functionality by modifying source and destination addresses in a packet, or as a firewall by returning a status code to TCP/IP that requests that TCP/IP drop the packet and cease processing for it. In kernel mode, Windows Firewall uses a driver (%SystemRoot%\System32\Drivers\Mpsdrv.sys) that provides support for PPTP and FTP filtering, since those protocols provide their own Network Address Translation Network address translation (NAT) is a routing service that allows multiple private IP addresses to map to a single public IP address. Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet. NAT allows one computer of the LAN to be assigned an IP address and the other computers to use private IP addresses and be connected to the Internet through that computer. NAT translates between private IP addresses and the public IP address as necessary, routing packets between LAN computers and the Internet. NAT components on Windows consist of a NAT device driver, \%SystemRoot%\System32 \Drivers\Ipnat.sys, that interfaces with the WFP stack as a callout driver, as well as editors that can perform additional packet processing beyond address and port translation. NAT can be installed as a routing protocol component with the Routing And Remote Access MMC snapin or by configuring Internet Connection Sharing (ICS), although NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in. IP Filtering Windows includes a very basic IP filtering capability with which a user can choose to allow only certain ports or IP protocols into or out of the network. While this capability can serve to protect a computer from unauthorized network accesses, its drawback is that it is static and does not automatically create new filters for traffic initiated by applications running on the computer. 948 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  10. Windows also includes host firewall capability, called Windows Firewall, that goes beyond the basic filtering just described. Windows Firewall uses WFP to provide a stateful firewall, which is one that keeps track of traffic flow so that it distinguishes between TCP/IP traffic that originates on the local LAN and unsolicited traffic that originates on the Internet. When Windows Firewall is enabled on an interface, one of three profiles can be applied—public, private, and domain. By default, when the public profile is chosen (or until a profile is selected), all unsolicited incoming and outgoing traffic received and sent by the computer is discarded, other than traffic from network services and other system applications. A user or application can define exceptions so that services running on the computer, such as file and printer sharing or a Web site, can be accessed from other computers. The Windows Firewall service, which executes in a Svchost process, uses the BFE to pass exception rules defined in the configuration user interface to the IPNat driver. The WFP filter engine executes the callback functions of each registered callout driver as it processes both inbound and outbound IP packets. A callback function can provide NAT functionality by modifying source and destination addresses in a packet, or as a firewall by returning a status code to TCP/IP that requests that TCP/IP drop the packet and cease processing for it. In kernel mode, Windows Firewall uses a driver (%SystemRoot%\System32\Drivers\Mpsdrv.sys) that provides support for PPTP and FTP filtering, since those protocols provide their own Internet Protocol Security Internet Protocol Security (IPSec), which is integrated with the Windows TCP/IP stack, helps protect unicast (IPSec itself supports multicast, but the Windows implementation does not) IP data against attacks such as eavesdropping, sniffer attacks, data modification, IP address spoofing, and man-in-the-middle attacks (as long as the identity of the remote machine can be verified, such as a VPN). You can use IPSec to provide defense-in-depth against network-based attacks from untrusted computers; certain attacks that can result in the denial-of- service of applications, services, or the network; data corruption, data theft, and user-credential theft; and the administrative control over servers, other computers, and the network. IPSec helps defend against network-based attacks through cryptography-based security services, security protocols, and dynamic key management. IPSec provides the following properties for unicast IP packets sent between trusted hosts: ■ Data origin authentication, which verifies the origin of an IP packet and ensures that unauthenticated parties cannot access data. ■ Data integrity, which protects an IP packet from being modified in transit without being detected. ■ Data confidentiality, which encrypts the payload of IP packets before transmission. Data confidentiality ensures that only the IPSec peer with which a computer is communicating can read and interpret the contents of the packets. This property is optional. ■ Anti-replay (or replay protection), which ensures that each IP packet is unique and can’t be reused. This property prevents an attacker from intercepting IP packets and inserting modified packets into a data stream between a source computer and a destination computer. When 949 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  11. anti-replay is used, attackers cannot reply to captured messages to establish a session or gain unauthorized access to data. You can use IPSec to help defend against network-based attacks by configuring host-based IPSec packet filtering and enforcing trusted communications. When you use IPSec for hostbased IPSec packet filtering, IPSec can permit or block specific types of unicast IP traffic based on source and destination address combinations and specific protocols and specific ports. In an Active Directory environment, Group Policy can be used to configure domains, sites, and organizational units (OUs), and IPSec policies (called connection security rules) can then be assigned as required to Group Policy objects (GPOs) through Windows Firewall with Advanced Security configuration settings. Alternatively, you can configure and assign local IPSec policies. Active Directory–based connection security rules are stored in Active Directory, and a copy of the current policy is maintained in a cache in the local registry. Local connection security rules are stored in the local system registry. To establish trusted communications, IPSec uses mutual authentication, and it supports the following authentication methods through AuthIP, Microsoft’s extension to Internet Key Exchange (IKE): ■ Interactive user Kerberos 5 credentials or interactive user NTLMv2 credentials ■ User x.509 certificates ■ Computer SSL certificates ■ NAP health certificates ■ Anonymous authentication (optional authentication) ■ Preshared key If AuthIP is not available, plain IKE is also supported by IPSec. The Windows implementation of IPSec is based on IPSec Requests for Comments (RFCs). The Windows IPSec architecture includes Windows Firewall with Advanced Security, the legacy IPSec Policy Agent, the IKE and Authenticated Internet Protocol (AuthIP) protocols, and an IPSec WFP callout driver. ■ Windows Firewall with Advanced Security In addition to the filtering functionality described earlier, the Windows Firewall service is also responsible for providing the security and policy configuration settings for IPSec, which can be configured through Group Policy either locally or on an Active Directory domain. ■ Legacy IPSec Policy Agent The legacy IPSec Policy Agent runs as a service. In the Services snap-in in the Microsoft Management Console (MMC), the IPSec Policy Agent appears in the list of computer services under the name IPSEC Policy Agent. The IPSec Policy Agent obtains legacy IPSec policy from an Active Directory domain or the local registry and then passes IP address filters to the IPSec driver and authentication and security settings to IKE. These policies are honored for compatibility with older versions of Windows, which implement IPSec management through Active Directory. 950 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  12. ■ IKE and AuthIP IKE is a protocol that supports the authentication and key negotiation services required by IPSec. For outgoing traffic, IKE waits for requests to negotiate security associations (SAs) from the IPSec driver, negotiates the SAs, and then sends the SA settings back to the IPSec driver. For incoming traffic, IKE receives a negotiation request directly from the remote peer, and all other traffic from the peer is dropped until the SAs have been successfully negotiated. SAs are a combination of mutually agreeable IPSec policy settings and keys that defines the security services, mechanisms, and keys that are used to help secure communications between IPSec peers. Each SA is a one-way or simplex connection that secures the traffic it carries. IKE negotiates main mode SAs and quick mode SAs when requested by the IPSec driver. The IKE main mode (or ISAKMP) SA protects the IKE negotiation. The quick mode (or IPSec) SAs protect application traffic. AuthIP is an extension to IKE supported by Windows Vista and later versions. It adds a secondary authentication mechanism to increase security and simplify maintenance and configuration of IPSec. ■ IPSec WFP callout driver The IPSec WFP callout driver is a device driver (\%SystemRoot%\System32\Drivers\Ipsec.sys) that is bound to the WFP and that processes packets that pass through the TCP/IP driver. The IPSec driver monitors and secures outbound unicast IP traffic, and it monitors, decrypts, and validates inbound unicast IP packets. The WFP receives filters from the IPSec Policy Agent and invokes the callout, which then permits, blocks, or secures packets as required. To secure traffic, the IPSec driver uses active SA settings, or it requests that new SAs be created. You can use the Windows Firewall with Advanced Security (Wf.msc) snap-in that is available in MMC to create and manage connection security rules by using the New Connection Security Rule Wizard, shown in Figure 12-25. This snap-in can be used to create, modify, and store local connection security rules or Active Directory–based connection security rules, and to modify connection security rules on remote computers. Alternatively, you can use the Netsh utility with the netsh advfirewall consec command to manage connection security rules. After IPSec-secured communication is established, you can monitor IPSec information for local computers and for remote computers by using the Windows Firewall with Advanced Security snap-in or the Netsh utility with the netsh advfirewall monitor command. 951 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  13. 12.7 NDiS Drivers When a protocol driver wants to read or write messages formatted in its protocol’s format from or to the network, the driver must do so using a network adapter. Because expecting protocol drivers to understand the nuances of every network adapter on the market (proprietary network adapters number in the thousands) isn’t feasible, network adapter vendors provide device drivers that can take network messages and transmit them via the vendors’ proprietary hardware. In 1989, Microsoft and 3Com jointly developed the Network Driver Interface Specification (NDIS), which lets protocol drivers communicate with network adapter drivers in a device-independent manner. Network adapter drivers that conform to NDIS are called NDIS drivers or NDIS miniport drivers. The version of NDIS that ships with Windows Vista SP1 and Windows Server 2008 is NDIS 6.1. The NDIS library (\%SystemRoot%\System32\Drivers\Ndis.sys) implements the NDIS boundary that exists between network transports, such as the TCP/IP driver, and NDIS drivers. The NDIS library is a helper library that NDIS driver clients use to format commands they send to NDIS drivers. NDIS drivers interface with the library to receive requests and send back responses. Figure 12-26 shows the relationship between various NDIS-related components. Instead of merely providing the NDIS boundary helper routines, the NDIS library provides NDIS drivers with an entire execution environment. NDIS drivers aren’t genuine Windows drivers because they can’t function without the encapsulation the NDIS library gives them. This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers don’t accept and process IRPs. Rather, protocol drivers such as TCP/IP call a function in the NDIS library, NdisAllocateNetBuffer, and pass the packets to an NDIS miniport by calling an NDIS library function (NdisSendNetBufferLists, for example). Additionally, to make development simpler, all components of the Windows Next Generation TCP/IP Stack make use of net buffers, including TCP/IP and WSK, which streamlines communications with NDIS. NDIS includes the following features: 952 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  14. ■ NDIS drivers can report whether or not their network medium is active, which allows Windows to display a network connected/disconnected icon on the taskbar. This feature also allows protocols and other applications to be aware of this state and react accordingly. The TCP/IP transport, for example, will use this information to determine when it should reevaluate addressing information it receives from DHCP. ■ NDIS drivers can be paused and resumed, which enables run-time reconfiguration, such as during a response to a Plug and Play event. This allows dynamic operations such as binding and unbinding a protocol driver without requiring a reboot. ■ TCP/IP offloading, including task and chimney offloading. Task offloading allows a miniport to use advanced features of a network adapter to perform operations such as packet checksums and IPSec. NDIS includes support for IPSec Task Offload Version 2, which includes support for additional cryptography suites used in IPSec, such as AES, as well as IPv6 support. Chimney offloading provides a direct connection (the so-called chimney) between network applications and the network card hardware, enabling greater offloading and connection state management to be implemented by the network card. These offloading operations can improve system performance by relieving the CPU from the tasks. ■ Receive scaling enables multiple processors to perform packet receive operations and appropriate scaling to be selected based on the most efficient use of available target processors. NDIS supports the receive-side scaling (RSS) interface at the hardware level and queues DPCs to the appropriate processors. ■ Wake-on-LAN allows a wake-on-LAN-capable network adapter to bring Windows out of a suspend power state. Events that can trigger the network adapter to signal the system include media connections (such as plugging a network cable into the adapter), the receipt of protocol-specific patterns registered by a protocol (the TCP/IP transport asks to be woken for Address Resolution Protocol [ARP] requests), and, for Ethernet adapters, the receipt of a magic packet (a network packet that contains 16 contiguous copies of the adapter’s Ethernet address). ■ Header-data split allows compatible network cards to improve network performance by splitting the data and header part of an Ethernet frame into different buffers and subsequently combining the buffers into smaller regions of memory than if the buffers were combined. This allows more efficient memory usage as well as better caching because multiple headers can fit in a single page. ■ Connection-oriented NDIS (CoNDIS) allows NDIS drivers to manage connectionoriented media such as PPP devices. (CoNDIS is described in more detail shortly.) The interfaces that the NDIS library provides for NDIS drivers to interface with network adapter hardware are available via functions that translate directly to corresponding functions in the HAL. eXPeriMeNT: Listing the Loaded NDiS Miniports The Ndiskd kernel debugger extension library includes the !miniports and !miniport commands, which let you list the loaded miniports using a kernel debugger and, given the address of a miniport block (a data structure Windows uses to track miniports), see detailed information 953 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  15. about the miniport driver. The following example shows the !miniports and !miniport commands being used to list all the miniports and then specifics about the miniport responsible for interfacing the system to a PCI Ethernet adapter. (Note that WAN miniport drivers work with dial-up connections.) 1. lkd> .load ndiskd 2. Loaded ndiskd extension DLL 3. lkd> !miniports 4. NDIS Driver verifier level: 0 5. NDIS Failed allocations : 0 6. Miniport Driver Block: 86880d78, Version 0.0 7. Miniport: 868cf0e8, NetLuidIndex: 1, IfIndex: 9, RAS Async Adapter 8. Miniport Driver Block: 84c3be60, Version 4.0 9. Miniport: 84c3c0e8, NetLuidIndex: 3, IfIndex: 15, VMware Virtual Ethernet Adapter 10. Miniport Driver Block: 84c29240, Version 0.0 11. Miniport: 84c2b438, NetLuidIndex: 0, IfIndex: 2, WAN Miniport (SSTP) 12. ... 13. lkd> !miniport 84bcc0e8 14. Miniport 84bcc0e8 : Broadcom NetXtreme 57xx Gigabit Controller, v6.0 15. AdapterContext : 85f6b000 16. Flags : 0c452218 17. BUS_MASTER, 64BIT_DMA, IGNORE_TOKEN_RING_ERRORS 18. DESERIALIZED, RESOURCES_AVAILABLE, SUPPORTS_MEDIA_SENSE 19. DOES_NOT_DO_LOOPBACK, SG_DMA, 20. NOT_MEDIA_CONNECTED, 21. PnPFlags : 00610021 22. PM_SUPPORTED, DEVICE_POWER_ENABLED, RECEIVED_START 23. HARDWARE_DEVICE, NDIS_WDM_DRIVER, 24. MiniportState : STATE_RUNNING 25. IfIndex : 10 26. Ndis5MiniportInNdis6Mode : 0 27. InternalResetCount : 0000 28. MiniportResetCount : 0000 29. References : 5 30. UserModeOpenReferences: 0 31. PnPDeviceState : PNP_DEVICE_STARTED 32. CurrentDevicePowerState : PowerDeviceD0 33. Bus PM capabilities 34. DeviceD1: 0 35. DeviceD2: 0 36. WakeFromD0: 0 37. WakeFromD1: 0 38. WakeFromD2: 0 39. WakeFromD3: 1 40. SystemState DeviceState 954 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  16. 41. PowerSystemUnspecified PowerDeviceUnspecified 42. S0 D0 43. S1 PowerDeviceUnspecified 44. S2 PowerDeviceUnspecified 45. S3 D3 46. S4 D3 47. S5 D3 48. SystemWake: S5 49. DeviceWake: D3 50. WakeupMethods Enabled 2: 51. WAKE_UP_PATTERN_MATCH 52. WakeUpCapabilities: 53. MinMagicPacketWakeUp: 4 54. MinPatternWakeUp: 4 55. MinLinkChangeWakeUp: 0 56. Current PnP and PM Settings: : 00000030 57. DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT, 58. Translated Allocated Resources: 59. Memory: ecef0000, Length: 10000 60. Interrupt Level: 9, Vector: a8 61. MediaType : 802.3 62. DeviceObject : 84bcc030, PhysDO : 848fd6b0 Next DO: 848fc7b0 63. MapRegisters : 00000000 64. FirstPendingPkt: 00000000 65. DriverVerifyFlags : 00000000 66. Miniport Interrupt : 85f72000 67. Miniport version 6.0 68. Miniport Filter List: 69. Miniport Open Block Queue: 70. 8669bad0: Protocol 86699530 = NDISUIO, ProtocolBindingContext 8669be88, v6.0 71. 86690008: Protocol 86691008 = VMNETBRIDGE, ProtocolBindingContext 866919b8, v5.0 72. 84f81c50: Protocol 849fb918 = TCPIP6, ProtocolBindingContext 84f7b930, v6.1 73. 84f7b230: Protocol 849f43c8 = TCPIP, ProtocolBindingContext 84f7b5e8, v6.1 The Flags field for the miniport that was examined indicates that the miniport supports 64-bit direct memory access operation (64BIT_DMA), that the media is currently not active (NOT_MEDIA_CONNECTED), and that it can dynamically detect whether the media is connected or disconnected (SUPPORTS_MEDIA_SENSE). Also listed are the adapter’s system-to-device power-state mappings and the bus resources that the Plug and Play manager assigned to the adapter. (See the section “The Power Manager” in Chapter 7 for more information on power-state mappings.) 12.7.1 Variations on the NDIS Miniport 955 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  17. The NDIS model also supports hybrid network transport NDIS drivers, called NDIS intermediate drivers. These drivers lie between transport drivers and NDIS drivers. To an NDIS driver, an NDIS intermediate driver looks like a transport driver; to a transport driver, an NDIS intermediate driver looks like an NDIS driver. NDIS intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers. Software that provides fault tolerant and load balancing options for network adapters, such as Microsoft’s Network Load Balancing Provider, are based on NDIS intermediate drivers. Finally, the NDIS model also implements lightweight filter drivers (LWDs), which are similar to intermediate drivers but specifically designed for filtering network traffic. LWDs support dynamic insertion and removal while the protocol stack is running. Filter drivers have the ability to filter almost all communications to and from the underlying miniport adapter because they’re not associated with a particular protocol driver. They also have the ability to select only certain services for filtering and to be bypassed for those that they are not interested in. Just like insertion and removal, these service bindings are also dynamic and can change at run time. 12.7.2 Connection-Oriented NDIS Support for connection-oriented network hardware (for example, PPP) is native in Windows, which makes connection management and establishment standard in the Windows network architecture. Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through established network connections rather than place them on the network medium. In addition to miniport support for connection-oriented media, NDIS includes definitions for drivers that work to support a connection-oriented miniport driver: ■ Call managers are NDIS drivers that provide call setup and teardown services for connection-oriented clients (described shortly). A call manager uses a connectionoriented miniport to exchange signaling messages with other network entities such as network switches or other call managers. A call manager supports one or more signaling protocols. ■ An integrated miniport call manager (MCM) is a connection-oriented miniport driver that also provides call manager services to connection-oriented clients. An MCM is essentially an NDIS miniport driver with a built-in call manager. ■ A connection-oriented client uses the call setup and teardown services of a call manager or MCM and the send and receive services of a connection-oriented NDIS miniport driver. A connection-oriented client can provide its own protocol services to higher levels in the network stack, or it can implement an emulation layer that interfaces connectionless legacy protocols and connection-oriented media. An example of an emulation layer fulfilled by a connection-oriented client is a LAN emulation (LANE), which hides the connected-oriented characteristics of ATM and presents a connectionless media (such as Ethernet) to protocols above it. Figure 12-27 shows the relationships between these components. 956 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  18. eXPeriMeNT: using Network Monitor to Capture Network Packets Microsoft provides a tool named Network Monitor that lets you capture packets that flow through one or more NDIS miniport drivers on your system by installing an NDIS lightweight filter driver (Netmon). You can obtain the latest version of Network Monitor by going to the Microsoft Support Knowledge Base Article http://support.microsoft.com/kb/955998. When you first start Network Monitor, you’ll see a window similar to the one shown here: In the Select Networks pane, Network Monitor lets you select which network connection you want to monitor. After selecting one or more, start the capture environment by clicking the New Capture button on the toolbar. You can now initiate monitoring by clicking the Start button on the toolbar. Perform operations that generate network activity on the connection you’re monitoring (such as browsing to a Web site), and after you see that Network Monitor has captured packets, stop monitoring by clicking the Stop button. In the Frame Summary pane, you will see all the raw network traffic during the capture period. The Network Conversations pane will display network traffic isolated by process, whenever possible. By clicking on the Iexplore.exe process in this example, Network Monitor shows only the relevant frames in the Frame Summary view, as shown next. 957 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  19. The window shows the HTTP packets that Network Monitor captured as the Microsoft Web site was accessed through Internet Explorer. If you click on a frame, Network Monitor displays a view of the packet that breaks it apart to show various layered application and protocol headers in the Frame Details pane, as shown in the previous screen shot. Network Monitor also includes a number of other features, such as capture triggers and filters, that make it a powerful tool for troubleshooting network problems. You can also add parsers for other protocols, as well as view and modify their source code. Network Monitor parsers are hosted on CodePlex, the Microsoft open source project site. 12.7.3 Remote NDIS Prior to the development of Remote NDIS, a vendor that developed a USB network device, for example, had to provide a driver that interfaced with NDIS as a miniport driver as well as interfacing with a USB WDM bus driver, as shown in Figure 12-28. If the vendor’s hardware supported other buses, such as IEEE 1394, the vendor was required to implement drivers that interfaced with each specific bus type. Remote NDIS is a specification for network devices on dynamic Plug and Play I/O buses such as USB, IEEE 1394, Bluetooth, and Infiniband. The specification eliminates the need for a hardware vendor to write an NDIS miniport driver at all by defining bus-independent messages 958 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
  20. and the mechanism by which the messages are transmitted over various buses. Remote NDIS messages mirror the NDIS interface and include messages for initializing and resetting a device, transmitting and receiving packets, setting and querying device parameters, and indicating media link status. The Remote NDIS architecture, in Figure 12-29, relies on a Microsoft-supplied NDIS miniport driver, \%SystemRoot%\System32\Drivers\Rndismp.sys, that translates NDIS commands and forwards them to a bus transport driver for the bus on which a device is located. The architecture allows for a single NDIS miniport driver to be used for all Remote NDIS drivers and a single bus transport driver for each supported bus. Currently, Remote NDIS for USB devices is included on Windows. While Remote NDIS on IEEE 1394 is fully specified, Windows does not yet support it, nor does it support it over Infiniband. 12.7.4 QoS If no special measures are taken, IP traffic is delivered over a network on a first-come, firstserve basis. Applications have no control over the priority of their messages, and they can experience bursty network behavior, where they occasionally obtain high throughput and low latencies, but otherwise receive poor network performance. While this level of service is acceptable in most situations, an increasing number of network applications demand more consistent service levels, or quality of service (QoS) guarantees. Video conferencing, media streaming, and enterprise resource planning (ERP) are examples of applications that require good network performance. QoS allows an application to specify minimum bandwidth and maximum latencies, which can be satisfied only if every networking software and hardware component between a sender and a receiver supports QoS standards such as IEEE 802.1P, an industry standard that specifies the format of QoS packets and how OSI layer 2 devices (switches and network adapters) respond to them. Windows supports QoS through a policy-based QoS implementation that takes full advantage of the Next Generation TCP/IP network stack, the WFP, and NDIS lightweight filter drivers. The implementation allows for managing or prioritizing bandwidth use based on different conditions, such as the application, the source or destination IP address, the protocol being used, and the 959 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

CÓ THỂ BẠN MUỐN DOWNLOAD

Đồng bộ tài khoản