|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|Leadership has been defined as the
ability to hide your panic from others”
One can relish the varied
idiocy of human action during a panic
to the full, for, while it is a time of
great tragedy, nothing is being lost but money”
Network worms exist for a long time. Actually two of the first worms known (REXX-based Christmas greetings worm and Morris worm were network-based). But those were two exotic cases as at this time networks were available only to privileged few. Network worms got into mainstream only with emergence of high speed network including cable-modems and large corporate networks with many often unpacked PCs. That happed around year 2000. Mass epidemics are pretty rate and for the last six-seven years there were only a few of them, approximately one a year. At the same time network worm are more difficult to disinfect as infections are often distributed among multiple sites and expose gross blunders in design of the network and/or configuration of desktops (especially in case of "standard desktops" in which uniformity provides additional attraction for network worms). The most affected classes of PCs are usually semi-abandoned corporate PCs such as laptop for remote users with bad connectivity, various test and regression machines that after initial one time use happily circulate air for a year or more without and single human logging to them, etc.
Contributing factor is low qualification of personnel especially if this type of activities is converted into specialized security position. unlike regular network or desktop support personal people often quickly disqualify in such position. Also such positions often attract power-hungry "good-for-nothing" type of people as anything connected with security provide an opportunity to exercise power not only over the users but also over fellow administrators.
I have several suggestions that I formulated as a set of questions with brief comments. I think that enterprise customers can benefit from discussing at least some of the underling ideas and counter-mesures.
Antivirus software belongs to perishable goods category. That means that we should try to prevent sliding it more then one version behind the current. Or preferably to use the current version. Any AV software which is two version old for all practical purposes cannot be considered a viable antivirus: this is a dinosaur by AV industry standards and the fact that it disinfects something is truly amazing. New viruses often require changes in virus engine and unless the engine is pluggable like in Trend Micro, the update of the software updates might be the only option to keep antivirus current and effective against new worms.
In view of recent experience with worms continuing doing patching "an old way" looks like invitation to troubles. IMHO 60-80% of workstations (depending of the type of large enterprise) can live with automatic updates.
The other 20-40% can be patched individually. I think that this is huge waist of resources to consider each and every workstation so special that it deserves individual patching. Many security conscious employees in large corporation voluntarily switched to automatic updates. It might be a time to institutalize this practice.
Selective patching often leads to random patching of PCs when each PC has slightly different set of patches. The latter creates a permanent security vulnerability that the recent worms like Allaple as well as all previous network worms managed to exploit.
In enterprise environment cashing is usually duplicated by devices like CacheFlow, Squid or other proxy servers anyway. Dome network worms like Alaple exploit large number of HTML files stored in such cashes to ensure re-infected even if registry entries were cleaned.
Among other setting that help to fight worms are making extension visible (this is a very questionable invention by Microsoft to hide extensions and several worms -- mainly mail worms exploited it to full extent putting a huge cake into the face of Microsoft software architects (or in this case pseudo-architects).
It can be done via SNMP, SMTP via a simple script or whatever.
It looks like in large enterprises there is a stable swamp of "PCs with broken AV updates" that is a natural worm habitat for worms epidemics even if the vulnerability expolited is a year or more old.
This swamp usually includes many remote PCs, some lab PCs and some second desktops. IMHO unless large enterprize make conscious efforts to drain at least a part of this swamp they will be always ready for a ride.
IMHO the idea of 7 letters minimum in password length that is used by most large enterprises truly belongs to the last century. I am convinced that with current scope of networks all large enterprises should stick to AOL scheme on Windows and do it fast unless they really want to pay the price.
That means increasing the minimal length of password to 10 or 12 and making mandatory for user using two word concatenation with the second word being the last 4 difits of his phone extension or cubicle number (I think now everybody have phones, but just in case). Friendly-8392 or, better, FriendlY-"8392". This is not that much more difficult for a user to remember but it is impossible for any worm to crack.
There are just too many people who will never learn how to create good password so the increase in the mandatory length to 12 characters might be the best "idiot-proof" way to solve the problem in large enterprize environment, the problem that the latest worms like probably Allaple.B so successfully exploited.
It also creates another huge security vulnerability that the recent worms like Allaple.B and future worms will manage to exploit.
Here is the (somewhat simplified) timeline of major accidents:
SQL Slammer also brought more than 13,000 Bank of America ATMs to a halt by compromising database servers and overloading attached networks. In August, the Nachi worm that exploited RPC DCOM vulnerability and was designed to fight SQL Slammer infected Diebold ATMs at two financial institutions. A patch to close to the RPC DCOM vulnerability exploited by Nachi had been available for more than a month when that incident occurred.
Network worms are probably the most complex type of worms to fight and they often cause considerable panic in corporate environments. And the rule is that "panic kills": in panic some absurd actions like shutting down the whole sites are completely justified. Unfortunately this if often done after the initial splash of activity of the worm after which it is just sitting more or less quietly on infected computers.
Thus the major problem of mass epidemics caused by network worms is that the initial infection is often has a form of chain reaction and it occurs over very short period of time like a huge traffic splash that generates panic many times more destructive then the worm itself, especially if the fighting of the work is delegated to a completely technically incompetent bureaucrat. The generated amount of traffic can overwhelm the network before any actions can be taken. Also if update servers are centralized (or super-centralized) and this for a while AV update cannot reach the targets even if they available. Moreover the fact of updating of the signature in this case can became another attack on the network with AV signature distribution server as the worm Trojan horse.
Automatic tools like automatic disinfection are usually not very effective against such threat as new successful network worm is usually successful exactly because it invents a completely new attack vector. Detection based on traffic anomalies can detect the initial attack but due to the chain reaction character of infections this detection is pretty much useless. Still it is important to have.
One of the effective and rather simple way of fighting network worms is to use automatic patching mechanism supported now by Microsoft for all major flavors of Windows. Microsoft proved to be reasonably good in this area and historically mass infection often accrued after the patch was available. So by enabling automatic installation of patches on a large fraction of corporate desktops (for servers this is a less attractive measure and would generally be weighted against the risks) cuts the critical mass of infected computers. This measure also helps to ensure that the initial spike will be less damaging.
The advantage of automatic patches application is that it just work on many cases. If a problem found this desktop just need to be moved into special "selected" or "security only" patches pool. Some patches can interfere with the installed software. But when the latter occurs, usually it is because problems with the software not patches, for example obsolete version of a popular application. Such cases can be resolved by upgrading software.
While not all PCs in a corporate environment can use this mode, probably 80% of users can be switched to this mode. Remaining 20% still represent a problem as they need to be manually or selectively patched, but even in worst case they represent less critical mass and increase the chances that the network will survive the initial "explosive" propagation period typical for most network worms.
Again I would like to stress that usually it is not network work itself that is dangerous but unqualified and often stupid actions of sysadmins and executives that are caused by panic. Many large corporations suffered multimillion losses due to shutdown of parts of their networks done after any real threat disappeared from the horizon and worms were just quietly sitting on infected computers: in many cases shutdown accrued hours after the peak of traffic was over.
Anyway, it is important to understand that too much zeal in disinfection of network worms is usually more harmful the worms themselves. But this is a pretty rare event as Microsoft tests its parches very well.
How to use the RestrictAnonymous registry value in Windows 2000
This article describes how administrators can use the RestrictAnonymous registry value on a Windows 2000-based computer to restrict access over anonymous connections.
Local Security Policy MMC snap-in
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
Note If you cannot perform this step because "Administrative Tools" does not show up in the Program list, then click Start, point to Settings, point to Control Panel, click Administrative Tools, and then click Local Security Policy. Then proceed to step two.
2. Under Security Settings, double-click Local Policies, and then click Security Options. 3. Double-click Additional restrictions for anonymous connections, and then click No access without explicit anonymous permissions under Local policy setting. 4. Restart the member computer or domain controller for the change to take effect.
RestrictAnonymous registry value
Use Registry Editor to view the following registry key, and then add the following value to this key, or modify it if the value already exists:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Value Type: REG_DWORD
Value Data: 0x2 (Hex)
Restart the computer after any change to the RestrictAnonymous key in the registry.
When the RestrictAnonymous registry value is set to 2, the access token built for non-authenticated users does not include the Everyone group, and because of this, the access token no longer has access to those resources which grant permissions to the Everyone group. This could cause undesired behavior because many Windows 2000 services, as well as third-party programs, rely on anonymous access capabilities to perform legitimate tasks.
For example, when an administrator in a trusting domain wants to grant local access to a user in a trusted domain, there may be a need to enumerate the users in the trusted domain. Because the trusted domain cannot authenticate the administrator in the trusting domain, an anonymous enumeration may be used. The benefits of restricting the capabilities of anonymous users from a security perspective should be weighed against the corresponding requirements of services and programs that rely on anonymous access for complete functionality.
The following tasks are restricted when the RestrictAnonymous registry value is set to 2 on a Windows 2000-based domain controller:
• Down-level member workstations or servers are not able to set up a netlogon secure channel. • Down-level domain controllers in trusting domains are not be able to set up a netlogon secure channel. • Microsoft Windows NT users are not able to change their passwords after they expire. Also, Macintosh users are not able to change their passwords at all. • The Browser service is not able to retrieve domain lists or server lists from backup browsers, master browsers or domain master browsers that are running on computers with the RestrictAnonymous registry value set to 2. Because of this, any program that relies on the Browser service does not function properly.
Because of these results, it is not recommended that you set the RestrictAnonymous registry value to 2 in mixed-mode environments that include down-level clients.
Setting the RestrictAnonymous registry value to 2 should only be considered in Windows 2000 environments only, and after sufficient quality assurance tests have verified that appropriate service levels and program functionality is maintained.
Note Pre-defined "High Secure" security templates set the RestrictAnonymous registry value to 2, and because of this, caution should be used when using these templates. For more information about the RestrictAnonymous registry value, click the following article number to view the article in the Microsoft Knowledge Base:178640 (http://support.microsoft.com/kb/178640/) Could not find domain controller when establishing a trust
RestrictAnonymous is set by changing the registry key to 0 or 1 for Windows NT 4.0 or to 0, 1, or 2 for Windows 2000. These numbers correspond to the following settings:
- 0 None. Rely on default permissions
- 1 Do not allow enumeration of SAM accounts and names
- 2 No access without explicit anonymous permissions
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Datacenter Server
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: July 29, 2012