It's 2017 and someone's probably still using WINS naming. If so, stop Sysadmins should already have purged WINS from their Microsoft Windows Server environments – but if they haven't, there's a new reason to take it for one last walk out behind the shed. Fortinet's Honggang Ren says a WINS Server remote memory corruption vulnerability in the MS-proprietary name server isn't going to get fixed, …
Port 135 is the RPC endpoint mapper. Without it, any RPC-based service won't be discoverable by clients (and there are some). The other are mostly NetBIOS stuff, and unluckily still enabled for "compatibility" reasons. If you enable SMB over TCP and don't use WINS, they can be firewalled. Or you can disable SMB wholly, if you don't need it (but you need to be sure you don't need it truly).
Hang on. If WINS is still available as a service in supported versions of Windows then MS should be fixing it, even if it is a big job, that what they are supposedly providing patches for.
If I were to tell my users that fixing a problem with their systems would be to much work, I would soon be out of a job. it is NOT a reasonable excuse.
He just said that since Microsoft are still supplying it (just checked on Server 2016) then they should be supporting it. If they didn't want to support it they should have retired it for the anachronism that it is.
Can't remember the last time I used it, but it's still there...
Bet that's not what they said when they introduced it.
Once again it comes down to a simple set of questions.
What does this (open) port do?
Why should this service be accessible?
Who should this service be available to?
Any sysadmin who cannot answer those questions for a network they are responsible for (or who lacks the tools to do so) is not even minimally in control of their network.
Windows - and other OSes-, in the old days, didn't run on TCP/IP networks only. Hard to believe today, but NetBIOS (and its implementations over different transports, i.e. NBF, NetBIOS over IPX, etc) was quite common - and NetBIOS was not an only MS protocol.
WINS was an attempt to allow NetBIOS applications to scale to larger TCP/IP networks, avoiding the "broadcast" messages. You will also find a couple of RFCs about using NetBIOS over TCP/IP networks, giving you an idea of how much its use was widespread. You couldn't really migrate everything to a pure TCP/IP network immediately. Really time to remove WINS server, though.
I once had an argument with an MCSE who was adamant that, come ten years time, the Internet would be using WINS naming exclusively, and that DNS would be totally gone because it was "obsolete".
This same MCSE, I should point out, once spent thirty minutes looking for the power switch on a server to switch it on.
I'd love to say it was already on, the VGA had fallen out or something like that, but no. He genuinely didn't recognise the same symbol that was on the front of his video recorder.
And people wonder why I never took any of the Microsoft exams...
My point exactly.
MS love to create "standards." If enough of them take off they continue to force people to stay on MS platforms. "Everyone will be using this in X years. You'd be a fool not to start coding for it" blah blah.
I'd love to find out what proportion do so, and what proportion go down the gurgler and are airbrushed out of the official history.
Quite a lot I suspect. I'm sure we can all think of a few that crashed and burned.
"MS love to create "standards." If enough of them take off they continue to force people to stay on MS platforms. "Everyone will be using this in X years. You'd be a fool not to start coding for it" blah blah."
Well unfortunately that's something virtually all inexperienced programmers do. That's why we have FreeDesktop, PulseAudio or SystemD, or if you think it further, all those new half-baked features coming to new poppular language versions.
Programmers need to learn to restrict themselves to solve problems as simple as possible. Software architecture isn't about using every language feature or every new fancy methodology, it's about choosing the right tools for the job, to make the problem as simple as possible so it can be solved as simple and accurately as possible.
Yes, new programmers do tend to adopt the latest fad in languages. For no reason other than they can. That's bad enough.
But they also insist on using new libraries that they consider funkier than existing ones. The old ones could do the job with perhaps a few extra lines of code scattered throughout the program. But no, they have to use the new library because reasons.
All of which means that 15 years ago I could simultaneously run a diverse mix of applications and relatively few libraries would be in use. These days each application pulls libraries that only it uses into memory, increasing its effective footprint.
A major point of using standard libraries is that they can be shared, meaning that applications using them have a lower effective memory footprint. They also tend to improve start-up time because an application you just fired up may find the libraries it needs are already resident. No longer. These days some applications might just as well be compiled stand-alone because none of the libraries they use are shared with any other application.
You tend not to notice this (on Linux) if installing stuff via a package manager because it will pull in all the dependencies. It's when stuff is not available from a repository and you have to compile it from source yourself that you notice. You notice it then because of all the damned exotic libraries you have to get (and probably compile those from source too). Grrrrrrrrrrrrr.
Back then everybody liked to create "standards". NetBIOS was introduced I don't remember by whom to add some network connectivity to IBM PCs. Novell promoted its IPX protocol, while Apple had AppleTalk. There was also UUCP, Xerox XNS, and something from Banyan IIRC. Despite TCP/IP being older and an independent standard (or maybe because of it), in the 1980s it wasn't widely adopted by commercial systems - and MS was just one among many, back then.
As networks became lager, more distributed, networking hardware cheaper, and internet connections widely available, TCP/IP protocol and related services became the standard - but that started only in the second half of 1990s.
Back then everybody liked to create "standards". NetBIOS was introduced I don't remember by whom to add some network connectivity to IBM PCs.
IBM (may have been a third party). It was IBM's PC-Network. There was also a layer (original NetBEUI before Microsoft nicked the moniker later) allowing you to use token ring as the underlying network and keep using NetBIOS API. Novell also played the game and offered NetBIOS encapsulation with IPX/SPX.
But this was all in 80s ..and my memory isn't what it used to be.
"There was also UUCP, Xerox XNS, and something from Banyan IIRC. Despite TCP/IP being older and an independent standard (or maybe because of it), in the 1980s it wasn't widely adopted by commercial systems - and MS was just one among many, back then."
AFAICR TCP/IP was introduced after the proliferation of multiple networking technologies. I think that, at least at first it was seen as a means of connecting separate networks - remember it's the internet. So you'd have your Token Ring here and your Banyan Vines (you made me dig that out of my memory!) there and something was needed to interconnect them. Only gradually did Ethernet as the physical medium and TCP/IP as the logical one creep in to replace the others. For a long time it was supposed to be ISO/OSI that would be the long term solution - in the end the term turned out to be so long as to be never.
Even as late as the '90s I was running a Unix server with TCP/IP on the same physical network as another group running DecNET. Eventually we had to install DecNET S/W in the Unix box in order to exchange data with the VAXen. They weren't going to sully their VMS with TCP/IP - after all our Unix box was a temporary system only destined to last another 6 months and had been for several years; all things DEC were to be the strategic solution. I wonder how that worked out.
TCP/IP predates many of the other protocols, and it came directly from its own DARPA researches.
It was developed in parallel - by the people working on the Internet - with other protocols implemented by commercial OS for their own networks, which, outside military, big universities and companies were rarely interconnected. and even when they were, there were other widely used protocols like X.25. Only later TCP/IP would become the de facto standard.
And yes, you had several physical layer standards as well, ARCNET, FDDI, Token Ring, Apple one, Ethernet... but once again, IIRC, Ethernet won only when it abandoned coaxial cables and affordable switches became available, in the late 1980s / early 1990s. I worked for a company who was still phasing out Token Ring in the late 1990s (but at least everything was already on TCP/IP).
And people wonder why I never took any of the Microsoft exams...
My thoughts exactly ...
I once saw an MSCD print out her program and stick it to the wall ... the longest program she ever wrote ... 800+ lines of goodness ... after a quick look, I knew I could shrink it to 200 if not less and reduce the length of the lines, crikey, some were very, very, very long ... ohh, the beauty of VBS ... she had, apparently, not been told about [private] sub's and had large chunks of duplicate code ... at least she knew how to copy-paste and indent....
Which goes back to wheather people actually know what they are running and why, at least in terms of software.
These are such basic questions that no one in the 2nd decade of the 21st century who calls themselves a sysadmin should be having to do this manually (or keep it updated manually)
But I strongly suspect there are quite a lot who are. :-(
As Kernigham & Plauger put it in "Software Tools in Pascal" this is (the network equivalent) of literally "Red penciling" a program listing to find where a variable is used.
"Is it really difficult to see a repeat of the WinCry situation coming along Real Soon Now? "
Not at all. Given that in the UK 7 NHS trusts reported they had no budget item for "IT Security" it's looking like a near certainty (although it would be interesting to see how they coped, relative to others who did have such an item).
There are highly unlikely events that are very uncommon and difficult to guard against and hard to recover from. Fair enough. You do your best to plan for them and hope they won't happen, like an airliner crashing on the data center. Something I imagine AIG never gave a second thought to. How could you attack a data center half way up the World Trad Center?
But then there's predictable failure that is completely avoidable with minimal precautions, if some PHB had paid the slightest attention to the consequences of what they were being told.
So... having been using this stuff since 1990 here's the thing, Netbios naming over TCP/IP was addressed, pun intended, in RFC1001 and RFC1002. These RFC's based a solution on DYNAMIC name claiming and release - entirely modelled on DNS. They worked, but in those days, TCP/IP stacks that conformed, cost money. The market for such products tanked when M$ started giving away an IP stack for clients with WINS on NT servers.
WINS was M$ pathetic attempt to reinvent a wheel but in reinventing the wheel, broke it. - when a workstation shutdown it was SUPPOSED to send a name release to the server, proper implementations DID, Microsoft's Netbios over IP stack DID'NT and to this day, probably still doesn't, even with Windows Dynamic DNS.
Can you turn it off? who knows, M$ never understood networking properly and still don't appear to, that's why they multiplexed functions over different ports, wrote buggy stacks that couldn't range check and the whole thing STILL leaks like a sieve...countless patches and vulnerabilities 27 years on.
Look on the bright side, keeps people in jobs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
