Unauthorized installationsWithin this discussion we will be consid-ering “rogue servers”. This term will beused to refer to a number of different situations, but all represent some form ofunauthorized installation of either physi-cal hardware or software to create a local(usually) IT facility within the existing,managed, supported network/host envi-ronment. Examples of this will typicallyinclude:

• Server platforms installed locally, e.g.by departments, to provide dedicatedfacilities such as file storage orIntranet (Web) application servers.

• Server software applications installedon existing physical platforms toextend their functionality, such asinstalling/enabling IIS on a W2Kserver or putting a Web or FTP serverapplication on someone’s desktop PC.

• Server software applications whichhave been installed by default (but arenot required) on existing/newlydeployed servers that are within the“management framework”.

• Third party application servers thatare not installed by the IT department(e.g. systems deployed to supportphone switches or E-banking applica-tions).

There are a couple of other types to con-sider:• Servers that have been “formally”

deployed but have subsequently beenconverted to RAS servers by the addi-tion of a modem. This sometimes alsoapplies to the third party deployedsystems which often have modemsconfigured to allow dial-upsupport/diagnostics, but outside ofthe “official” remote access facility.

• Existing servers, particularly externalfacing ones, that have been compro-mised and have had server software,Trojan control software, unauthorizedcontent or distributed attack toolsinstalled.

“Unauthorized”We have used that word a lot in the sec-tions above. It is a word that has to bedefined specifically for each particularorganization. Most people would notargue that the above scenarios are unde-sirable, but unless there are explicit policystatements and supporting standards andprocedures in place it may be difficult tocategorise any such installation as “unauthorized”.

Starting at the top down then your pol-icy should include some set of statementsas follows:

• Installation of physical hardware andsoftware on the corporate network must

only be performed by the IT departmentand according to defined configurationstandards.

• Deployment of additional hardwareand software on existing server or work-stations must be subject to approval of[IT Manager/Head of Security] andmust be undertaken by the relevant ITsupport team.

• Where the modifications are judged tohave a potential impact on other net-work systems, applications or data (atthe discretion of the [IT Manager/Headof Security]) the installation must firstbe successfully tested.

• All changes to the hardware, softwareand configuration of the network or theconnected systems must be conductedunder a managed Change Controlprocess.

Obviously, following on from this youmay have some work to do to actuallydefine and establish the standards andprocesses.

You will at the very least need thedevelopment of a set of standard config-urations for each server types (e.g. W2K,Unix), you must also have in place atesting and approvals mechanism fornew developments or procurements.Finally this must be governed by achange control requesting and manage-ment process to enable the impacts ofdeployments, their scheduling/planningand regression steps to be approved priorto implementation.

Problems with “Rogueservers”The exact nature of the problem thatunofficially deployed systems presentwill inevitably vary depending on yourperspective.

For an outsourcing agency orFacilities Management (FM) companythey represent not only lost revenuefrom the support of IT systems but alsothey are potential points of an attackwhose effect could be wider than the

16

rogue servers

Rogue Servers

Piers Wilson, Insight Consulting

Rogue servers are a constant threat and pose a variety of problems for the IT securi-ty team. This article summarises the threats that come from not managing rogueservers and gives prevention and detection tips.

Figure 1 – A typical example of a serv-er in an office environment,

totally outside the control of the ITdepartment.

system itself and encroach on formallymanaged systems where service levelsexist.

For corporate procurement and ITdepartments they are often untraceable/unregistered/unmanaged assets in variousstates/locations.

From an information security perspec-tive, not only do they present a riskthrough providing a jumping off point forexternal or internal attackers, but with anysystems that have been deployed to fill abusiness function there is a clear risk toongoing operations (albeit of the depart-ment concerned) and more seriously, a riskthat the system is used as a data storagefacility for operational data or contactdetails, documentation etc. which hasimproper access controls, weak authentica-tion and exists outside of the normal back-up and security management process.

In general however the following list ofissues may be faced:

Data storage/sensitivityThe system may have been deployed tohost a database used for some businessfunction such as invoice tracking, payroll,contact management or document man-agement. This data storage may not haveappropriate security controls applied toits access or use. As it will probably be aseparate platform, the authentication mayexist on the local system (under the man-agement of the business users, a thirdparty or within the application) and secu-rity access control settings (e.g. to restrictaccess to data, particularly personal datacovered by the data protection act) maynot be appropriate.

BackupThere is risk associated with centralisedbackup facilities that exist in many envi-ronments which operate over the networkusing either a SAN or tape based system.Although the department, business usersor local IT “expert” may be happy to livewith the risk, this “head in the sand”approach does not sit well in any environ-ment where responsible IT security andbusiness continuity practices are supposed to be followed.

Lower security configurationThe systems deployed at a corporate levelby the “official” IT department or FMcompany should have a secure configura-tion which includes a structured buildprocess where insecure default settings areturned off, security features are enabledand access rights are tightened. Out of thebox these settings are typically at theirmost insecure Servers deployed by a localIT-knowledgeable person or businessmanager will, in the vast majority ofcases, not have been configured accordingto either best practice or the local stan-dard. This means the systems will have anumber of weaknesses which would oth-erwise have been addressed.

Versions/support/patchingAny server or workstation will need con-stant support in terms of the roll out ofsecurity patches to fix new vulnerabilities.In a corporate environment this can bevery hard to keep on top of, but there aresolutions – patches can be downloadedcentrally and then deployed or aserver/platform list can be used to makesure relevant patches can be applied (sim-ilar to an asset inventory).Of course a server that has been deployedby a department or business unit inde-pendently of this will most probably bepassed over when new patches or updatesare deployed. The department, not being“IT professionals” may not even realisethe importance of this – and if they do, asbusiness users, they may not have thetime/resource to undertake the kind ofpreventative maintenance that all modernoperating systems requires. The end resultis therefore a single point at which anattack could be successful – however oncecompromised such a system might thenallow other systems to be compromised.

External connectivityMany “unofficially deployed” servers areused to address a specific business appli-cation or non-IT requirement. In manycases this solution, server included, hasbeen procured from a third party appli-cation provider and is often delivered

and installed by them on behalf of theprocuring department. Ironically, as thissystem is not an officially supported ITserver the department will buy supportfrom the provider. In my experience Ihave come across a number of thesetypes of systems and almost inevitablythe support is for the application, OSand hardware.

How does this support operate? Youguessed it, the third party company dialup into the server using an attachedmodem and fix things, upload changesetc. This is of course an unauthorized net-work connection and may stomp all overa carefully designed secure remote accesspolicy.

In one case recently the remote supportfunction relied on an ISDN router thatwas provided by the support firm andeffectively (when connected) allowed arouted connection onto the client net-work. In that particular instance themethod of support was chiefly usinganonymous FTP to upload patches, bina-ries and any modifications direct to theprogram directory.

Domain/address conflicts (masterbrowser)The domain structure and IP addressingis almost always under the control of theIT department. As such when an “unoffi-cial” or rogue server is deployed the host-name, domain membership and IPaddressing tends to be largely left tochance. I have seen at least one instancewhere an IP address was used that had notbeen removed from the DHCP scope (allthe main servers were in a specific addressrange) and caused problems for worksta-tion users with address conflicts. The factthat systems may not be within the exist-ing domains often tends to lead to theproblem of separate sets of credentials(described more fully below), but also, ina Windows environment we have seenproblems with the browsing service(available in network neighbourhood –not what you do with Internet explorer)where a new system has repeatedly causeda browser election to decide on a network

17

rogue servers

master browser. This caused a substantialamount of additional network traffic andaffected all the users in the office, andadditional fault finding work for the ITdepartment.

Unmanaged credentialsWhere systems are deployed outside of anestablished domain the username/pass-words will be managed separately, withpolicies on password lifetime, length, histo-ry etc. unlikely to be applied as stringentlyor updated as regularly as required by thecorporate security standards, or even bestpractice. There is a risk that users on theserver will set the passwords to be the sameas their main network login – this poten-tially exposes these sensitive credentials onan unmanaged, unsecured system.

Asset tracking (software licensing)Although the costs of licences may havebeen included in the procurement cost,auxiliary software required may not havebeen. Also where a corporate licence forWindows platforms exists the organisationmay have inadvertently paid for unneces-sary licences. The migration to a newerflavour of operating system also typicallywill not happen, thus an environment mayupgrade all supported servers to a newerversion of Windows with the extraneoussystems being left on an older version.

Anti-virusThis final issue hardly needs explanation.The anti-virus software, if installed at all,may not be properly configured to collectupdates from a corporate central point oreven from an external source. As the serv-er is not managed by IT they are unlikelyto even notice if the signatures are neverupdated. Clearly the results of this couldbe disastrous.

Detection, audit and prevention

As with most IT security issues, the poli-cy level controls described right at thestart of this article are vital. You candefine what you mean by “unauthorized”and prohibit the use of such systems.

Of course, you may need to then retro-spectively or periodically audit your net-works to try to find these systems.

A good way to identify rogue servers isto establish a naming convention for theauthorized systems. This often will not befollowed by a standalone departmentalserver so if you adopt a standard includ-ing an incremental number you can easi-ly tally the expected servers against anynew arrivals like “mktg-intranet”.

There are of course ways to enforcethis, many of the network scanning toolsare capable of very quickly auditing a net-work to discover systems. These includenmap (which is freeware), GFI’sLANGuard (which is excellent value formoney and able to audit a network rangevery quickly) right up to many of themore expensive network mapping/man-agement tools (including the likes of HPOpenview, which has an auto-discoverymode).

Many of these tools can generate outputthat can be subsequently used to comparefuture scans against reference scans thushighlighting any of these changes to thelandscape. Ideally of course you would rec-oncile this against the change controlrecord or asset inventory.

The allocation of IP addresses (and IPaddressing scheme) can also be used tocontrol assets. One organization used aspecific scheme using a 16-bit mask inter-nally and then using the third octet todenote the system type. In addition, allservers were kept in defined subnets, sep-arate from printers or DHCP pooladdresses.

For example, configure all server IPaddresses as x.y.100.z/16, where z was anindex number and also included in thehostname (e.g. 172.16.100.35/16, host-name SVR035). This makes it easy toidentify server systems that are not in thisrange but have been configured to get aDHCP address or on some other free IPaddress by some departmental user.

In some cases the extent of the problemhas all but escaped the IT department’sability to catch up, at that point considerembarking on a finite network mappingexercise — you may be surprised what

systems you find and what devices orsoftware they have installed.

ConclusionsThe issue of unofficial IT equipment anddevices being attached to the corporatenetwork is a very real one. The potentialproblems and costs are frighteningly realand within a properly managedIT/Information security environmentthey must not be allowed to proliferate.

Steps can be taken to identify thesesorts of systems when they are presentand also to prevent, or make it exceeding-ly difficult to achieve their establishment– thus forcing people down the properprocurement and support route.

However, to be fair to the users anddepartments, the mechanisms by whichIT systems are procured and supportedmust be made sensible enough that theoverhead in “buying a server through IT”is not so great that the unofficial routesare taken.

For third party deployments, the ITservice provided internally must beallowed to provide and configure a basic,standardized server onto which the appli-cation provider can perform the install.Where remote support mechanisms mustbe established steps must be taken tosecure these — as with any third partyconnection.

As with so many issues, it is alwaysbest to treat the causes rather than thesymptoms.

rogue servers

18

Useful links:• Nmap (network mapping, OS

checking and port scanner), free-ware - www.nmap.org <http://www.nmap.org>

• LANGuard (very good networkmapping/reconnaissance tool - canalso be used to deploy hotfixes),$295-$895 - www.gfi.com <http://www.gfi.com>

• NetworkView (excellent value graph-ical mapping and system monitoringtool), $59 - www.networkview.com<http://www.networkview.com>

• HP Openview - www.openview.hp.com <http://www.openview.hp.com>