A program for converting documents into various formats. free online ODF converter

Using outdated protocols without a clear need can be a potential security breach for any computer network. In this regard, the recent hype around simplest defense which consisted of abandoning the use of the legacy SMBv1 protocol by completely . Broadcast protocols NetBIOS over TCP/IP And LLMNR are also legacy protocols, and most modern networks use them only for compatibility purposes. At the same time, hackers have various tools in their toolbox that allow them to exploit vulnerabilities in the NetBIOS and LLMNR protocols to intercept user credentials on the local subnet (including NTLMv2 hashes). Therefore, for security purposes, these protocols should be disabled in a domain network. Let's figure out how to disable LLMNR and NetBIOS using group policies.

First of all, we should remind you what these protocols are.

LLMNR protocol

LLMNR(UDP/5355, Link-Local Multicast Name Resolution - a mechanism for broadcast name resolution) - the protocol is present in all versions of Windows, starting with Vista and allows IPv6 and IPv4 clients to resolve names of neighboring computers without using DNS through broadcast requests in the local L2 network segment server. This protocol is also automatically used when DNS is unavailable. Accordingly, when DNS servers are running in the domain, this protocol is absolutely not needed.

NetBIOS over TCP/IP protocol

NetBIOS over TCP/IP protocol or NBT-NS (UDP/137,138;TCP/139) – is the broadcast protocol predecessor of LLMNR and is used in local network for publishing and searching for resources. NetBIOS over TCP/IP support is enabled by default for all interfaces on all Windows operating systems.

Thus, these protocols allow computers on a local network to find each other when the DNS server is unavailable. Perhaps they are needed working group, but in a domain network both of these protocols can be disabled.

Advice. Before mass implementation of policy data in a domain, we strongly recommend testing the operation of computers with NetBIOS and LLMNR disabled on test groups of computers and servers. And if there are no problems with disabling LLMNR, disabling NetBIOS can paralyze the operation of legacy systems

Disabling the LLMNR protocol using Group Policy

In a domain environment, LLMNR broadcast requests can be disabled on domain computers using Group Policy. For this:

1. In the GPMC.msc console, create a new or edit an existing policy that applies to all workstations and servers.
2. Go to section Computer Configuration -> Administrative Templates -> Network -> DNS Client
3. Enable Policy Turn Off Multicast Name Resolution, changing its value to Enabled

Disabling the NetBIOS over TCP/IP protocol

Note. The NetBIOS protocol may be used by older versions of Windows and some non-Windows systems, so the process of disabling it in your specific environment is worth testing.

You can disable NetBIOS manually on a specific client.

1. Open network connection properties
2. Select protocol TCP/IPv4 and open its properties
3. Click the button Advanced, then go to the tab WINS and select the option Disable NetBIOS over TCP(Disable NetBIOS over TCP/IP)
4. Save changes

You can also disable NetBIOS support for a specific network adapter from the registry. For each computer network adapter there is a separate branch with its TCPIP_GUID inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.

To disable NetBIOS for a specific adapter, you need to open its branch and change the value of the parameter NetbiosOptions on 2 (default value is 0).

To completely disable the NetBIOS protocol, the above operations must be performed for all network adapters on the computer.

On domain clients that receive IP addresses from a DHCP server, you can disable NetBIOS by configuring the DHCP server options.

1. To do this, open the console dhcpmgmt.ms c and select the Scope Option (or Server Options) zone settings
2. Go to the tab Advanced, in the Vendor class drop-down list, select MicrosoftWindows 2000Options
3. Enable the option 001 MicrosoftDisableNetbiosOption and change its value to 0 x2

There is no separate option that allows you to disable NETBIOS over TCP/IP for all network adapters on a computer through group policies. To disable NETBIOS for all computer adapters, use the following PowerShell script, which must be placed in the policy ComputerConfiguration ->Policies ->WindowsSettings ->Scripts ->Startup->PowerShellScripts

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach ( Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose)

Note. For the changes to take effect, you need to disable/enable network adapters or restart the computer.

The simplest way to resolve host names is to maintain a table of these names and their corresponding IP addresses. This task is accomplished by the HOSTS file, an ASCII file that is stored on the local hard drive and contains IP addresses on the left and host names on the right. If a user passes a hostname to an application, that application looks it up in the HOSTS file. If this name is found, the equivalent IP address is used to create a network connection. If the name is not found, then the connection cannot be established.

Although it may be hard to believe, at one time name resolution services for the entire Internet were provided through a single HOSTS table containing thousands of records that had to be regularly downloaded by Internet users to update their file. The problems with using this method are obvious. Inserting names and addresses into a file to register them can only be done manually. Users or administrators must individually modify or update the HOSTS file on each network computer to include the name and address of each host that needs to be addressed by name. In addition, the number of records grows, the file quickly increases in size, which begins to affect the speed of name resolution. Imagine having to manage a HOSTS file with hundreds or thousands of entries to map names to IP addresses. Each change to this file would require an update on all computers on the network, that is, forwarding HOSTS file each of them.

Using the Domain Name System (DNS)

The Domain Name System (DNS) is the most common method of Internet host name resolution because it allows users to connect to any site on the Internet by name. This may seem incredibly difficult, especially in light of the growth of the Internet over the past few years, but DNS uses the domain structure of the Internet's host names and is, of course, the main reason for its use.

The Domain Name System consists of thousands of DNS servers distributed throughout the Internet. If you register any Domain name, then you must specify the primary and backup DNS servers. They are called authoritative servers for your domain. A DNS server is a UNIX daemon or Windows service responsible for maintaining and publishing a database of host names and addresses in its own domain.

A domain's DNS servers do not need to be on its own network, and indeed many Internet Service Providers (ISPs) maintain web hosting services in which they provide the use of their DNS servers for a fee. The important thing here is that authorized body The Internet or other organization that has registered that domain name has an entry for the DNS servers responsible for that domain's hosts.

Because administrators individual networks are responsible for assigning hostnames in their domains, they must also maintain DNS records for those names. Surprisingly, registering a domain's hostnames with its DNS servers is the same manual operation as for the HOSTS file. For example, if you add a new ftp server to your network, you must manually add or change the DNS resource record by specifying the name and address new car.

NetBIOS names

Although NetBIOS is no longer a required component on the network Windows Server 2003, it is important for backward compatibility with previous Windows systems, such as Windows 9x and Windows NT, which use NetBIOS for communication, as well as with applications that use NetBIOS.

NetBIOS is a software interface that has been used for many years to provide networking capabilities to applications. Some features of the original Windows NT architecture built into Windows Server 2003 relied entirely on the NetBIOS naming system for naming other computers on the network.

A NetBIOS name contains up to 16 characters, the last of which is registered by Windows to identify specific features of certain computers, such as domain controllers or browsers. If the NetBIOS service is enabled, each computer is assigned a NetBIOS name by the operating system. This name may or may not be the same as the user's login name or the host name of the computer. You use NetBIOS names when you enter a UNC path name that points to a node Windows network.

NetBIOS is no longer a required component unless you have earlier Windows clients or NetBIOS-dependent applications, but it is still component network Windows tools. Workstation and Server services that run on everyone Windows computers Server 2003/2000, use both NetBIOS and direct hosting to provide basic shared access services to files that are requested by any operating system. Direct hosting is a protocol that uses DNS rather than NetBIOS for name resolution. The default configuration is to enable both NetBIOS and direct hosting, which are used simultaneously when resolving names for new connections to other machines.

Because NetBIOS runs on top of the Transport Device Interface (TDI), it can theoretically use any compatible protocols for its low-level interoperability needs. Initially, operating systems prior to Windows 2000 used the NetBEUI (NetBIOS Extended Use Interface) interface for NetBIOS traffic. However, NetBEUI is not routable, so when TCP/IP was proposed as an alternative, development of an open standard (later published as an RFC) was begun to define a way in which NetBIOS services could be provided using the TCP/IP protocols. IP. This standard is called NetBIOS over TCP/IP, or NetBT.

The NetBT standard defines two types of services: session and datagram services. Session services use TCP to provide a fully reliable connection-oriented messaging service, and datagram services use the UDP protocol, which requires little overhead. official information and does not have very high reliability.

Requests for network services that are generated by the NetBIOS interface use NetBIOS computer names to contact other systems. In order for TCP/IP to transmit requests over a network, NetBIOS names (similar to host names) must first be resolved (resolved) to IP addresses.

Because NetBIOS names are resolved to IP addresses before data is transferred, you can use them instead of host names in internal networks. For example, to connect to an intranet web server, a user can specify the server's NetBIOS name instead of the normal host name. Likewise, you can use the hostname in the UNC path instead of the NetBIOS name.

Node types

There are several various methods, through which computers can register and resolve their NetBIOS names on a Windows Server 2003/2000 network. These methods vary in their capabilities and effectiveness. To find a machine with a specific NetBIOS name, a computer can use network broadcasts, it can contact a NetBIOS Name Server (NBNS) on its network (for example, a WINS server), or it can use a lookup table in a locally stored LMHOSTS file.

The NetBT standard defines several node types that specify which methods a computer should use and in what order. Host types are assigned to clients by the DHCP server or determined by the TCP/IP settings specified in the client configuration. The NetBT standard defines the following node types.

• B-node. The client uses network broadcasts for both registration and name resolution.
• P-knot. The client sends a separate message to register or resolve the name to the NetBIOS name server.
• M-node. The client uses broadcast messages to register names; The client first uses broadcast messages to resolve names, and if this fails, it forwards queries to the NetBIOS name server.
• H-knot. The client sends a separate name registration or resolution message to the NetBIOS Name Server (NBNS); if the NBNS is unavailable, the client uses broadcast messages until the connection to the NBNS is restored.

Operating systems prior to Windows 2000 initially used an extended B-node service for registration and name resolution. The service was considered extended because if the name could not be resolved using broadcast messages, the LMHOSTS file was used as an alternative of this computer. This allowed users to access computers on other network segments if those computers were manually entered into the LMHOSTS file.

Windows Server 2003 continues to include WINS as a NetBIOS name server, which stores NetBIOS names and IP addresses for the entire Internet in its database, making this information available to users throughout the enterprise. Computers running earlier versions of Windows are described as enhanced H-nodes. These computers first try to resolve NetBIOS names using WINS by accessing broadcast messages if WINS fails or is unavailable, and then access the LMHOSTS file if name resolution cannot be achieved using broadcast messages.

Registering NetBIOS names

The NetBT standard requires that when a machine with an earlier Windows version logs on to a network, its NetBIOS name must be registered so that no other computer can use the duplicate name and that the IP address is set correctly. If you move a workstation to a different subnet and manually change its IP address, the registration process ensures that other computers and WINS servers know about the change.

The name registration method used by a workstation depends on its node type. B-nodes and M-nodes use broadcast messages to register names, while H-nodes and P-nodes send registration requests directly to the WINS server. These two methods are described in the following sections. One of these two methods is used by any computer running an earlier version of Windows that connects to the network.

Registering names using broadcast messages

B nodes and M nodes that use broadcast messages to register NetBIOS names do not perform registration in the same way that other types of nodes do. This name is not entered into any table and is not stored on other computers on the network. Instead, a given computer uses broadcast messages to “advertise” its NetBIOS name and check to see if another computer is already using that name.

The registration process begins when this computer enters the network. It broadcasts, using the UDP protocol, a set of NAME REGISTRATION REQUEST broadcast messages containing its proposed NetBIOS name and its IP address. If this name is already in use by some other machine on the network, then that machine sends a separate NEGATIVE NAME REGISTRATION RESPONSE message to the IP address of the requesting computer. This causes the registration request to be rejected. The requesting computer must choose a different name and execute new try registration.

If the computer does not receive any response to repeated attempts to send NAME REGISTRATION REQUEST packets within a specified period of time, it sends a NAME OVERWRITE DEMAND message, declaring that it has successfully registered its name. This computer should now respond to any requests sent by other computers using this NetBIOS name.

Like all broadcast messages, these name registration messages are limited to the local network segment. This means that computers on other network segments can use the same NetBIOS name. This presents an obvious problem. Only careful work by network administrators can prevent name collisions and misdirected packets. This danger, as well as the excessive network traffic caused by sending broadcast messages, are reasons to create a WINS server as a means of registering names.

Registering names using WINS

The WINS client computer begins the name registration process by generating the same NAME REGISTRATION REQUEST packet as it would broadcast. But this time the packet is sent as a separate message directly to the WINS server specified in the WINS Configuration tab of the TCP/IP Properties dialog box. If no other computer is using the name, the WINS server returns a POSITIVE NAME REGISTRATION RESPONSE to the sender and records given name NetBIOS and IP address to your database.

If the WINS server detects that a given NetBIOS name is already registered by another computer, the WINS server sends a NAME QUERY REQUEST message to that computer to "protect" its registered name. If the name owner does not respond or sends a NEGATIVE NAME QUERY RESPONSE, the WINS server registers the name for the new computer and sends it a POSITIVE NAME REGISTRATION RESPONSE message. If the queried name holder sends a POSITIVE NAME QUERY RESPONSE, it means they have successfully "protected" their name. In this case, the WINS server sends a NEGATIVE NAME REGISTRATION RESPONSE message to the new computer, informing it that its registration attempt was denied.

When a WINS server successfully registers a particular NetBIOS name, it assigns a registration expiration date in the form of a TTL (time-to-live) value. Each time the computer logs on to the network, this value is updated. Until this time period has expired, any attempt to register this NetBIOS name will be rejected. But if no logins are made during this period of time, then this NetBIOS name will be released and can be assigned again by the WINS server without asking any computer. If the given name remains unused for specified period time, it is declared obsolete and erased from the WINS database.

Note that the entire transaction is carried out using separate messages sent between computers. There is no flood of broadcast messages to flood the network, and this is one of the main advantages of WINS.

The last protocol we'll look at in this book is the NETBIOS (Network Basic Input/Output System) protocol developed by IBM. This protocol operates at three layers of the seven-layer OSI model: network layer, transport layer and link layer. The communication channel layer provides a mechanism for exchanging messages between programs running at stations within a communication channel or session. NETBIOS can provide an interface more high level than the IPX and SPX protocols.

The NETBIOS protocol is supported on IBM networks (IBM PC LAN), Novell NetWare, Microsoft Windows for Workgroups and other networks. Unfortunately no uniform standard to the NETBIOS protocol, therefore, network software from different companies uses different interfaces for calling NETBIOS commands.

From our point of view, the greatest interest is the use of NETBIOS in Novell NetWare and Microsoft Windows for Workgroups networks. We will look at the main features of NETBIOS related to data transfer between workstations within the same logical network segment.

To work with the NETBIOS protocol on Novell NetWare networks, you need to run a special NETBIOS emulator - the program netbios.exe, included with Novell NetWare. This program emulates the NETBIOS protocol using the already familiar IPX/SPX protocols.

NETBIOS is easier to use than IPX or SPX. However, since Novell NetWare requires a special NETBIOS emulator, the program's performance may be reduced. In addition, the emulator requires additional memory, since it is implemented as a resident program.

4.1. Addressing stations and programs

As you remember, to identify a workstation, the IPX and SPX protocols use the network number, the station’s address on the network, and the socket. The station address is determined at the hardware level and is a number 6 bytes long. The network number takes 4 bytes. Sockets are allocated dynamically by the IPX protocol driver or can be obtained from Novell.

The NETBIOS protocol uses a different mechanism for addressing stations and programs. To address a station, names of 16 bytes are used. Each station has one permanent name(permanent name), which is formed from the hardware address by adding ten zero bytes to it on the left. In addition to the persistent name, the NETBIOS protocol allows you to add (and remove) regular names and group names. Regular names are used to identify a workstation; group names can be used to send packets simultaneously to several stations on the network. The permanent name cannot be deleted, since it is completely determined by the station hardware.

When a common name is added, the NETBIOS protocol polls the entire network to verify that the name is unique. The group name may be the same on several stations, so when adding a group name, the network is polled
is not executed.

After adding a new name, this name is assigned a so-called name number, which is used to transmit data over the network.

Comparing the addressing methods used by the IPX/SPX and NETBIOS protocols, it is easy to see that the addressing method of the NETBIOS protocol is more convenient. You can address data not only to one station (as in IPX and SPX) or to all stations at once (as in IPX), but also to groups of stations that have the same group name. This can be convenient if there are several groups of users on the network who intensively exchange data with each other.

Another advantage of the NETBIOS protocol addressing scheme over the IPX/SPX protocol addressing scheme is the absence of the need to obtain your own socket number from Novell to identify your software. You can come up with your own unique group name, including, for example, the name of the program and your company, and use it to work under the client-server scheme.

4.2. Working with the NETBIOS protocol

The NETBIOS protocol provides programs with an interface for transmitting data at the datagram level and at the communication link level. To call NETBIOS, the program must create a control block in memory, which is called NCB (Network Control Block). The address of the filled NCB block is transferred to the INT 5Ch interrupt, within which the NETBIOS protocol interface is implemented. There is also an alternative interface implemented within the INT 2Ah interrupt, which is supported by the NETBIOS emulator developed by Novell, as well as the Windows for Workgroups operating system version 3.1.

4.2.1. Checking the presence of NETBIOS

The first thing a program that wants to use the NETBIOS protocol must do is check for the presence of a NETBIOS interface on the system.

Below is a program that determines whether the NETBIOS driver is installed.

Using the getvect() function, the program obtains a pointer to the INT 5Ch interrupt handler. This interrupt is used to call NETBIOS. If the segment component of the address is zero or F000h, the interrupt handler is not installed or a stub located in the BIOS is installed. In this case, the program thinks that NETBIOS is missing.