Is Netbios still a big security risk? I forgot all about it, seen a post talking about you should disable it. Should I disable it?
Alright I'm pretty sure I have it disabled now, also if you have a Router firewall wouldn't that technically block people from trying to exploit NetBIOS. Also any others windows sevices that are ran by default that can be turned off that you know of?I have blocked all the Netbios ports (with Kaspersky's firewall) it will be under packet rules, these are the ports to block - 137, 138, 139 and 445. I found this, which explains it in great detail:
What is NetBIOSNetBIOS is a transport protocol that Microsoft Windows systems use to share resources. For example, if a PC running Windows wants to connect to and access a share on a file server, it probably uses NetBIOS. There have been some changes in recent days, however, that allow this connection without it. SMB, the method used to access file and printer shares, can also run independently of NetBIOS over TCP ports 139 and 445. Both of these approaches, however, tend to increase the attack surface of a network.
The ports that we’d have to open to the Internet are UDP/137, UDP/138, and TCP/139. Unfortunately, the most popular attacker target is NetBIOS and against these ports. I’m going to use the vulnerabilities associated with port 139 to demonstrate how an attacker can use NetBIOS to plan and execute an attack against an organization’s network.
Once an attacker discovers an active port 139 on a device, he can run NBSTAT to begin the very important first step of an attack—footprinting. With the NBSTAT command, he can obtain some or all of the following information:
With this information, the attacker has information about the OS, services, and major applications running on the system. He also has private IP addresses that the LAN/WAN and security engineers have tried hard to hide behind NAT. And that’s not all. The lists provided by running NBSTAT also include user IDs.
- Computer name
- Contents of the remote name cache, including IP addresses
- A list of local NetBIOS names
- A list of names resolved by broadcast or via WINS
- Contents of the session table with the destination IP addresses
If null sessions are allowed against IPC$, it isn’t difficult to take the next step and connect to the target device. This connection provides a list of all available shares.
Defending against external NetBIOS connections
If NetBIOS has to be allowed, the first step is to ensure that only a very small number of devices are accessible. As you’ll see, leaving your network open to external NetBIOS traffic significantly increases the complexity of system hardening. Complexity is the enemy of system assurance.
Next, ensure that the exposed systems are hardened by,
So now what
- Disabling the system’s ability to support null sessions
- Defining very strong passwords for the local administrator accounts
- Defining very strong passwords for shares, assuming you absolutely have to have shares on exposed systems
- Keeping the Guest account disabled
- Under no circumstances allowing access to the root of a hard drive via a share
- Under no circumstances sharing the Windows or WinNT directories or any directory located beneath them
- Crossing your fingers
So it’s possible to open the perimeter to NetBIOS traffic—possible but not very smart. In my opinion, the only systems that should be exposed to this type of traffic should be locked down tight. Further, the more systems exposed the greater the chance that something will be missed, allowing an attacker to gain a foothold. I’m not alone in coming to this conclusion.
In an article titled “A Quantitative Study of Firewall Configuration Errors”, Avishai Wool of Tel Aviv University, lists leaving the NetBIOS service open on the perimeter as number eight in his list of the top twelve firewall configuration errors. Wool wrote, “These frequently attacked services are very insecure. Allowing any NetBIOS service to cross the firewall in any direction is an error” (Computer, June 2004, p. 62).
And let’s not omit Microsoft’s position on this. The following is from Microsoft’s “Threats and CounterMeasures Guide”: