Disable NTLM

Disable NTLM KB ID 0001880

Problem

NTLM (NT LAN Manager) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users in a network. It is an older protocol that has been largely replaced by Kerberos, (since Server 2008 and windows Vista!) In modern Windows environments due to its enhanced security features. NTLM is a challenge-response authentication protocol used to authenticate a client to a resource on a network. It operates in three versions: NTLMv1, NTLMv2, and NTLMv2 Session Security.

Key Components

Authentication Process:

    • Challenge-Response Mechanism: NTLM uses a challenge-response mechanism where the server challenges the client, and the client responds with a value that proves its knowledge of the user’s password.
    • Session Security: Provides confidentiality (encryption) and integrity (signing) for data sent over the network.

NTLM Versions:

    • NTLMv1:
      • Uses DES (Data Encryption Standard) for encryption.
      • The client sends a hashed password, and the server compares it to the stored hash.
      • Known for its vulnerabilities, including susceptibility to replay attacks and weak password hashes (LM hashes).
    • NTLMv2:
      • Introduced to address the security shortcomings of NTLMv1.
      • Uses HMAC-MD5 for cryptographic operations.
      • Provides stronger encryption and better resistance to replay attacks.
      • Supports mutual authentication where both client and server authenticate each other.
    • NTLMv2 Session Security:
      • Provides additional security by creating a session key based on both client and server challenge-response pairs.
      • Ensures integrity and confidentiality for the session.

Components of NTLM:

    • User Authentication: Verifies the identity of a user or system requesting access.
    • Message Integrity: Ensures that messages are not tampered with during transmission.
    • Message Confidentiality: Encrypts messages to protect sensitive information.

Security Weaknesses

  1. NTLMv1:
    • Weak Hashing (LM Hash): The LM hash is derived from passwords in a way that is susceptible to brute-force attacks.
    • Replay Attacks: Can be exploited to reuse valid authentication tokens.
    • Lack of Mutual Authentication: Only the client is authenticated, not the server.
  2. NTLMv2:
    • Improved but Still Vulnerable: While it significantly improves upon NTLMv1, it is still not as secure as Kerberos and can be vulnerable to certain types of attacks, especially in environments where NTLMv1 is still supported for backward compatibility.

Deprecation and Modern Alternatives

  • Kerberos: Introduced in Windows 2000, Kerberos provides stronger security features, including mutual authentication, and is now the default authentication protocol in Active Directory environments.
  • Recommendations: Organizations are encouraged to disable NTLM where possible, particularly NTLMv1, and to use Kerberos or other modern authentication protocols.

In Summary

NTLM played a crucial role in early Windows network security, providing a means of authenticating users and securing communications. However, due to its security vulnerabilities, especially in NTLMv1, it has been largely replaced by more secure protocols like Kerberos. NTLMv2 offers improvements but is still not as robust as modern alternatives, making it advisable for organizations to phase out NTLM in favour of stronger authentication methods.

As of Jun 2024 Microsoft has declared that NTLM (all versions) are depreciated.

Solution : Disable NTLM

Developers are being encouraged to STOP using NTLM, and the advice is to set your systems to ONLY use NTLM if Kerberos is not available. You first challenge is to find out what (if anything) is still using NTLM.

On your server(s) look in the (Security) Event logs for Event ID 4624 That mentions NTLM.

But there’s thousands of Event ID 4624 events, so let’s narrow the search with some PowerShell.

[box]

$query= @"
    <QueryList> 
           <Query Id="0"> 
              <Select Path="Security"> 
                *[System[(EventID='4624')]] 
                 and 
                *[EventData[Data[@Name='AuthenticationPackageName'] and (Data='NTLM')]]
               </Select> 
           </Query> 
    </QueryList>
"@
Get-WinEvent -FilterXml $query

[/box]

Now I can review each of those events (by their time stamp!) and I’ve only got two offenders to investigate.

You can also have a reconnoitre with WireShark, and scan for ntlmssp.

Disable NTLM v1

It’s considered best practice to disable NTLM version 1 first, then wait for a while (a period of a few weeks,) then you can attempt to disable NTLM version 2 also.

Edit the Default Domain Controller Policy and Navigate to.

[box]

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >  
Network Security: LAN Manager Authentication Level

[/box]

Settings;

  • Send LM and NTLM responses
  • Send LM and NTLM (use NTLMv2 session security if negotiated)
  • Send NTLM response only
  • Send NTLMv2 response only
  • Send NTLMv2 response only, Refuse LM: Domain controllers offer only NTLMv2 but still accept NTLMv1 authentication.
  • Send NTLMv2 response only, Refuse LM and NTLM: Domain controllers refuse LM and NTLMv1, accepting only NTLMv2.

To keep NTLM v2 and disable NTLM v1 choose the last option.

WARNING: This will effectively tattoo this setting into registry of the domain controller(s), even if you have a problem and revert the setting back to not defined, it will remain. If that happens to you, you can manually change the setting in the registry at.

[box]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

[/box]

 

There’s six settings (0 to 5) that correspond to the ones in the group policy for further information see this article.

Disable NTLM Completely

Before proceeding its a good idea to enable the “Restrict NTLM: Audit NTLM authentication in this domain” policy then waiting a while longer and reviewing the logs, if something does appear you can simply add it to the “Restrict NTLM: Add server exceptions in this domain” policy

This time in the default domain controller’s policy navigate to.

[box]

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >  
Network Security: Restrict NTLM: NTLM authentication in this domain

[/box]

  • Disable: the policy is disabled (NTLM authentication is allowed in the domain).
  • Deny for domain accounts to domain servers: the domain controllers reject NTLM authentication attempts for all servers under the domain accounts, and the “NTLM is blocked” error message is displayed.
  • Deny for domain accounts: the domain controllers are preventing NTLM authentication attempts for all domain accounts, and the “NTLM is blocked” error appears.
  • Deny for domain servers: NTLM authentication requests are denied for all servers unless the servername is on the exception list in the “Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain” policy.
  • Deny all: the domain controllers block all NTLM requests for all domain servers and accounts.

To stop client computers attempting to connect with NTLM you can edit the Default Domain Policy.

  • Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts
  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all

Related Articles, References, Credits, or External Links

NA

DHCP Scope: Full of BAD_ADDRESS Entries

KB ID 0001651

Problem

I had a client machine struggling to get an DHCP address, and when I looked in DHCP the scope it was full of this;

BAD_ADDRESS This address Is Already in Use

Solution

A tour of Google and forums is full of posts by people with this problem, and other than, ‘Oh I looked in the logs and fixed it’ (with no mention of what log, or where this log was), or ‘Yeah I used Wireshark and located a problem client‘, then no follow up on what they did, or scanned for. So I pretty much had to slog through and work it out for myself. I’ll detail each step I took below, most of which didn’t help, or sent me in the wrong direction, but for you that may be a better solution.

And I will give you enough information to at least be helpful!

Firstly Common Sense Check: If this has just happened what have you changed? Have you added any Wireless Controllers, or Access Points? Have you deployed any new Switches or Firewalls. In my case, it was my test network so it could have been happening for months!

The most frequent cause of this error is simply because someone has setup another DHCP server on the network. That will be easy to diagnose, simply ‘Stop’ your DHCP Server;

Then on a DHCP client, issue an ifconfig /release and ifconfig /renew, If it gets an IP address, issue an ifconfig /all and look for the IP of the DHCP server it’s using, that’s your culprit. However as you can see, mine didn’t get an IP address so this wasn’t my problem.

The next most popular suggestion is to enable ‘Conflict Detection‘, though in most places the information on where to find this, is incorrect, (as it’s been copied and pasted around the forums without actually checking it!) See below, you locate it on the properties of the Protocol not the Server > Advanced Tab > You are supposed to set it between 1 and 6 so I went for 5, (but after deleting all the BAD_ADDRESS entries, they were all back after 30 minutes or so, so this didn’t work for me either).

Look in the logs: Well they were useless also, DHCP creates a new log every day in C:\Windows\System32\Dhcp called ‘DHCPSrvLog-DAY.log’ as you can see it was not helpful.

At this point I put my networking head on, and ‘thought outside the box’, If DHCP is detecting these as BAD ADDRESSES, then they must be in the arp cache on the DHCP server right? Well look at this;

[box]

arp -a

[/box]

Well that’s encouraging, at least now I’ve got a suspect MAC address, lookup up that MAC address online, and it comes back as VMWare (which sent me off in the wrong direction, it was not a VMware virtual machine in my vSphere in the end). Ive got a decent Cisco Switch so I thought I’d see which interface it was connected to, (but it wasn’t there).

[box]

show mac address-table

[/box]

At this point I was still thinking it was a VMware virtual machine, so I used PowerCLI (Thats PowerShell for VMware), to query for that MAC address, but that revealed nothing.

So, my last hope was Wireshark, I fired it up on the DHCP server, and set the filter to;

[box]

bootp.option.type == 53

[/box]

Then I deleted all the BAD_ADDRESS entries, left Wireshark ‘sniffing’, and went for lunch. I returned to this (see below). Now 192,168,100,107 was one of the BAD_ADDRESS entries, and I did not know what it was. The other entries on there for 192.168.100.3 are understandable, (that’s my DHCP server!) So now I had a Layer 3 address to hunt.

When I RDP connected to it, I got prompted for a password, so now I know it’s a Windows box! I hunted all through my VMware virtual machines, it was not there. Just as an afterthought I remembered I have a Hyper-V server, could that be running a virtual machine? BOOM! There is a SCVMM server, I was using for some Zerto testing a couple of months ago! Turned it off, problem solved!

Hope you find your culprit quicker than I did!

Related Articles, References, Credits, or External Links

NA

Cisco IOS – DHCP Helper (DHCP Relay) – IP-Helper Setup

KB ID 0001168 

Problem

Cisco documentation calls this a ‘DHCP Relay’, and uses the command IP-Helper, and I usually call this DHCP Helper, just to confuse everyone. To be fair the term DHCP Relay is an industry standard, it’s not particular to Cisco (as you will see later when I Wireshark the traffic).

So If you are reading this you have a DHCP server and you want to use it to lease addresses to clients that are on a different network segment (layer 2, or layer3).

To do that you need an agent to be on the same network segment as the client listening for DHCP requests, when it receives one it talks to the DHCP server on the clients behalf and gets the correct address.

Solution

Example 1 Cisco Router

Here we need to lease two different DHCP scopes to two different network segments, R1 will act as the IP-Helper for both of those networks, R2 and R3 will get their IP addresses from the correct DHCP scope.

This works because each (client facing) interface on R1 has an IP-Helper address defined that points to the DHCP server.

So How Does It Know Which Scope To Lease From? This is because the Router supplies the IP address of a RELAY AGENT, which is just the IP address of the physical interface that intercepted the DHCP request. When it asks for an IP address from the DHCP server, the Server leases an address from the same range, (again I’ve tracked all this in Wireshark below).

IP-Helper Router Configuration

[box]

R1 Config

!
interface GigabitEthernet0/0
 description Uplink to DHCP Server
 ip address 10.2.2.254 255.255.255.0
 negotiation auto
!
interface GigabitEthernet2/0
 description Uplink to 192_168_2_0
 ip address 192.168.2.1 255.255.255.0
 ip helper-address 10.2.2.10
 negotiation auto
!
interface GigabitEthernet3/0
 description Uplink to 192_168_3_0
 ip address 192.168.3.1 255.255.255.0
 ip helper-address 10.2.2.10
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 10.2.2.10
!


R2 Config

!
interface GigabitEthernet2/0
 description Uplink to R1
 ip address dhcp
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet2/0
!

R3 Config

!
interface GigabitEthernet3/0
 description Uplink to R1
 ip address dhcp
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet3/0
!

[/box]

You can see this works because the DHCP server has matching scopes for both network segments. (Yes one of my test servers is 2003, you’re going to see some Windows XP in a minute!

Well that’s fine for routers, but what about machines? They send a DHCP Discover just like any other client. I’ve replaced one of the routers with an actual machine.

With its network card set to DHCP you will again get a lease from the correct scope, because the Router brokered it for us.

Back on the DHCP server you can see the lease to the windows XP machine entered in the current scope leases, It knows the name of the client because (as you will see below) the relay agent (Router) passed that information (along with the MAC address of the client) to the DHCP server.

Example 2 Cisco Switches

OK, I did the routers first because I find it easier to explain things at layer 3. Not that you can’t create sub interfaces on the router, add those sub interfaces to VLANs, and run DHCP relays from them. But in most cases you will be setting up DHCP helpers on switches. Here the principle is the same but you define the ip-helper on the VLAN, (unless it’s routed port then treat it the same as a router interface). Let’s modern things up a bit, and use a 2012 R2 DHCP server, and some Windows 8 clients.

I need to lease addresses from my second scope to clients in VLAN 200, (the other client and server are in the same VLAN, so that will just work. (Remember a VLAN is a broadcast domain, and DHCP is using broadcasts).

Here’s the two scopes setup on the 2012 server;

And my client, (DHCP Client in VLAN 200) gets the correct IP.

IP-Helper Switch Configuration (VLANS)

[box]

SW1 Config

interface FastEthernet1/0/1
 description Uplink to DHCP Server
 switchport access vlan 100
 switchport mode access
 spanning-tree pordtfast
!
interface FastEthernet1/0/4
 description Uplink 192_168_200_0
 switchport access vlan 200
 switchport mode access
 spanning-tree pordtfast
!
interface FastEthernet1/0/5
 description Uplink 192_168_100_0
 switchport access vlan 100
 switchport mode access
 spanning-tree portfast
!
interface Vlan200
 ip address 192.168.200.1 255.255.255.0
 ip helper-address 192.168.100.10
!

IF YOU HAVE MULTIPLE/FAILOVER IP-HELPERS OR SPLIT SCOPES YOU CAN ADD A SECOND 
ADDRESS LIKE SO;

!
interface Vlan200
 ip address 192.168.200.1 255.255.255.0
 ip helper-address 192.168.100.10
 ip helper-address 192.168.100.15
!

[/box]

Analysing (Packet-Sniffing) DHCP Relay Sequence with Wireshark

Other packet sniffers are available, but I’ve got a soft spot for Wireshark. To filter DHCP traffic you can use the following ‘filter’.

bootp.option.type == 53

DHCP works by using four messages, (which I remember using the acronym DORA: Discover, Offer, Request, Acknowledge). If you sniff the traffic on the DHCP server, you can watch this process being brokered by your DHCP Relay Agent.

Discover

Offer

Request

Acknowledge

And just to prove it’s not all ‘smoke and mirrors’, here’s the client with the leased address, showing a matching MAC address, and hostname.

Related Articles, References, Credits, or External Links

NA

Cisco ASA 5500 – Adding New ‘Different Range’ Public IP Addresses

KB ID 0001006 

Problem

I got an email at work yesterday;

“Hello Pete
I have asked our ISP to give us two additional real IP addresses so that we can progress the following two projects:

  1. Microsoft DirectAccess
  2. Publishing documents to a web server from our internal DMS.

{ISP Name} have come back and said that they don’t have the next available numbers in our current IP address range, but they do have two other numbers we could have from another range.
Would that cause any problems with regard to the firewall configuration etc.”

I’ve been asked similar questions before and my answer was always, “No let’s get a bigger range and re-ip the public side of the network”. But I was sat next to my usual font of all routing knowledge Steve, so I asked him what he thought. “It will just work, just NAT the traffic on the ASA, and as long as the ISP has set the routing up properly, the ASA will just proxy-arp the new public IP. We’ve done that for a few clients”.

I’ve not done this before, so before I put my neck on the block, I decided to build it in GNS3 to prove the concept.

Solution

1. I’ve already got a few basic Labs built for testing, here is the one I will use for this.

Note the ‘Host’ is really a router (this will become apparent later on). The ASA has a ‘public’ range of 11.11.11.1/29 this gives me 8 IP addresses (6 usable). Let’s assume we have exhausted all of those. and my ISP has given me 111.111.111.0/24 (generous eh!). I want to allocate 111.111.111.111 publicly to my host, (because I have OCD and it looks nice).

When I’ve finished I will test that it has worked by opening a TELNET session to my host from its outside IP 111.111.111.111.

2. Lets make sure that the host can get to the Internet, and then on the ASA observe what public IP address it’s getting.

[box] On the ‘Host’ Router

InsideHost#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/164/568 ms
InsideHost#

Observe the results on the ASA

Petes-ASA(config)# show xlate
1 in use, 1 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
ICMP PAT from inside:192.168.1.10/0 to outside:11.11.11.6/41745 flags ri idle 0:00:05 timeout 0:00:30

[/box]

3. Connect to the ASA > Allow telnet traffic to the host > Setup a One-to-One static NAT translation to the new public IP.

[box]

 Petes-ASA# configure terminal
Petes-ASA(config)# access-list inbound extended permit tcp any host 192.168.1.10 eq telnet
Petes-ASA(config)# access-group inbound in interface outside
Petes-ASA(config)# object network OBJ-TELNET-HOST
Petes-ASA(config-network-object)# host 192.168.1.10
Petes-ASA(config-network-object)# nat (inside,outside) static 111.111.111.111
Petes-ASA(config-network-object)# exit
Petes-ASA(config)#

[/box]

4. Allow Telnet on the ‘host’ router.

5. At this point in a live environment you are reliant on your ISP to route those IP addresses to you. Here I’m going to achieve the same by adding a route on the ISP Router, and then (so I can connect to host), putting a static route on my laptop.

[box]ISP-Router(config)#ip route 111.111.111.0 255.255.255.0 11.11.11.6[/box]

6. Now let’s clear the ‘translations’ on the ASA, and repeat the test we did earlier, hopefully the public IP of our internal host should have changed.

[box] On the ASA

Petes-ASA(config)# clear xlate

On the ‘Host’ Router

InsideHost#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/164/568 ms
InsideHost#

Observe the results on the ASA

Petes-ASA(config)# show xlate
1 in use, 1 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
NAT from inside:192.168.1.10 to outside:111.111.111.111
flags s idle 0:00:46 timeout 0:00:00
Petes-ASA(config)#

[/box]

7. Let’s make sure that the correct IP address is being seen, to do that I setup Wireshark to sniff the traffic on the ISP Routers 11.11.11.1 interface.

8. Then if I ping 4.2.2.2 from the internal host, and view the traffic capture, I should see the traffic coming from 111.111.111.111 (NOT 11.11.11.6).

9. Finally I should now be able to telnet from my laptop to the new public IP.

 

Related Articles, References, Credits, or External Links

NA

 

Cisco ASA – Policy NAT

KB ID 0001042

Problem

I’ve been working on a large firewall deployment for a client, each of their DMZ’s have both a production and a management network. nothing particularly strange about that, but each of their DMZ’s has its own firewalled management network and it’s routable from the LAN.

So If I’m an admin and I want to talk to a Linux appliance in their DMZ via its management interface, my traffic leaves the LAN through the management firewall, but the appliance sees my source IP as being on the LAN, and routes the traffic back to me via the clients production firewall.

Now the simplest way to fix it would be to put a static route on the appliance to route my traffic back via the management firewall, which is fine, BUT what if that appliance is the proxy server? Now I can administer it, but I cant get on the Internet!

Note: I’m NOT performing NAT anywhere in this scenario!

Solution

Well I could simply PAT the network my laptop is on, lets say its 172.16.1.0/16 to the DMZ interface of the management firewall.

[box]

object network Admin_PCs
 subnet 172.16.1.10 255.255.0.0
 nat (inside,dmz) dynamic interface[/box]

The problem with that is it will translate all traffic from my laptop’s subnet going into this DMZ and I might not want to do that.

Solution Pre ASA 8.3

We used to have a really simple way of solving this problem, ‘policy based nat’, you specify a set of conditions with an ACL then anything that meets that ACL is tied to a specific NAT rule.

[box]

access-list POLICY-NAT permit ip host 172.16.1.10 11.11.11.11 255.255.255.0
 !
 static (inside,outside) interface access-list POLICY-NAT[/box]

Solution Post 8.3

To do the same now the syntax is a little different. To demonstrate I have built a small lab in GNS3 to demonstrate. If I want the internal host to talk to the DMZ host, I want the traffic when it gets there to ‘appear’ to have come from 192.168.131.1

To demonstrate, if I ‘ping’ the DMZ router from the Host router, and Wireshark the traffic when it gets there, I see its coming from its actual IP address.

To NAT this traffic use the following commands;

[box]

 For a Single IP

object network obj-Host
 host 11.11.11.10 
 !
 object network obj-DMZ
 host 192.168.131.10
 nat (inside,DMZ) source static obj-Host interface destination static obj-DMZ obj-DMZ

For the Entire Subnet

object network obj-Host-LAN
 subnet 11.11.11.0 255.255.255.0
 !
 object network obj-DMZ-LAN
 host 192.168.131.10
 nat (inside,DMZ) source dynamic obj-Host-LAN interface destination static obj-DMZ obj-DMZ

[/box]

Now if we repeat the process, and ping the DMZ host.

Now when I capture the traffic, the source IP has changed accordingly.

Related Articles, References, Credits, or External Links

NA