The question you posed, "Is it better to disable "anonymous logon" (via GPO security settings) or to block "NTLM V1", is not a very good question, because those two things are not mutually exclusive. You can do both, neither, or just one, and to various degrees. There are lots of shades of grey here and you can't condense it to black & white.
Disabling NTLMv1 is generally a good idea. It is done with the
LmCompatibilityLevel registry setting, or via Group Policy. Beware that the same setting has slightly different behavior depending on whether the machine is a domain controller or a domain member.
The potential risk in disabling NTLMv1 here is breaking backwards compatibility with very old Windows clients, and more likely with non-Microsoft clients that don't speak NTLMv2. You would have to test those. Any reasonably modern and patched version of Windows will handle NTLMv2 w/ Session Security with zero problems (we're talking like anything Server 2000 or better.)
Disabling anonymous logon is a different thing altogether. You can disable the ability of anonymous users to enumerate shares, SAM accounts, registry keys, all or none of those things or a combination. The more you restrict Anonymous logon, you hypothetically increase your security posture, while you lose ease of use and convenience. (e.g. your users could lose the ability to enumerate file or printer shares on a server, etc.)
So you can't really say which one is better. They are both two different mechanisms that do two totally different things.
Event 540 is specific to a "Network" logon, such as a user connecting to a shared folder or printer over the netwok. It's also a Win 2003-style event ID. You can tell because it's only 3 digits. Corresponding events in Vista/2008 were converted to 4-digit IDs:
Eric Fitzgerald said:
I've written twice (here and here) about the
relationship between the "old" event IDs (5xx-6xx) in WS03 and earlier
versions of Windows, and between the "new" security event IDs
(4xxx-5xxx) in Vista and beyond.
In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security
events in WS03.
The exceptions are the logon events. The logon success events (540,
528) were collapsed into a single event 4624 (=528 + 4096). The logon
failure events (529-537, 539) were collapsed into a single event 4625
Other than that, there are cases where old events were deprecated
(IPsec IIRC), and there are cases where new events were added (DS
Change). These are all new instrumentation and there is no “mapping”
possible- e.g. the new DS Change audit events are complementary to the
old DS Access events; they record something different than the old
events so you can’t say that the old event xxx = the new event yyy
because they aren’t equivalent. The old event means one thing and the
new event means another thing; they represent different points of
instrumentation in the OS, not just formatting changes in the event
representation in the log.
Of course I explained earlier why we renumbered the events, and (in
the same place) why the difference is "+4096" instead of something
more human-friendly like "+1000". The bottom line is that the event
schema is different, so by changing the event IDs (and not re-using
any), we force existing automation to be updated rather than just
misinterpreting events when the automation doesn't know the version of
Windows that produced the event. We realized it would be painful but
it is nowhere near as painful as if every event consumer had to be
aware of, and have special casing for, pre-Vista events and post-Vista
events with the same IDs but different schema.
So if you happen to know the pre-Vista security events, then you can
quickly translate your existing knowledge to Vista by adding 4000,
adding 100, and subtracting 4. You can do this in your head.
However if you're trying to implement some automation, you should
avoid trying to make a chart with "=Vista" columns of
event ID numbers, because this will likely result in mis-parsing one
set of events, and because you'll find it frustrating that there is
not a 1:1 mapping (and in some cases no mapping at all).