5 Things a System Administrator Should Never Do - Network Security No-Nos!
- Nov 13, 2017, 09:31 AM
- Ben Gane
A system administrators job is tough. There’s the myriad of daunting tasks, a constant need to update your knowledge as technology moves forward, not to mention the long hours you have to put in. Dealing with finicky hardware, obtuse software, and demanding users is not easy. As well as the things a system administrator needs to do there are also certain things that a system administrator should never do.
It isn’t that admins do things they know they shouldn’t. The fact is that sometimes we all “break a rule” now and then just to get the job done. For instance, the sales manager calls up and needs access to a series of sites for a presentation he is doing in the conference room in three minutes and the sites are blocked. You don’t have time to find out why these sites are blocked and open them up in the firewall or web filter rules, so… you simply make a rule for the device being used for the presentation that gives it unabated access to anything and everything. The sales manager is happy and the meeting goes on without a hitch. Unfortunately, you have a million other emergencies like that to deal with and you forget about the hasty workaround you did. Consequently, that computer remains wide open to malware and other nasty gremlins throughout the Internet. Two months later, someone downloads ransomware from a known malware deployment site and all of the company data becomes encrypted. The road to disaster is paved with the best of intentions.
And so, we have devised a short list of things that admins sometimes do (either knowingly or unknowingly) but should resist doing to avoid that potentially “bad” day.
1. Never make firewall and web filter exemptions for machines
First off, these rules involve the IP address of the designated machine, which is often assigned by DHCP. This means that a different machine may have that address tomorrow, one managed by a user that you may never want having that level of freedom. In order to avoid scenarios like the one mentioned, create a company policy concerning access requests that specifically state how much lead-time is required to service the request. Review your firewall and web filter exemption lists on a periodic basis and delete any such rules that have been configured.
2. Ignoring outgoing firewall rules
We all know the importance of configuring the perimeter firewall for incoming traffic but often times we overlook the importance of outgoing traffic as well. Sometimes outgoing traffic rules are ignored because the process of securing egress traffic is more intricate and involved than ingress, as we have to ensure that our rules do not infringe on authorized traffic and applications that require Internet access. This requires timely research and knowledge of just what our users do. Egress traffic filtering is important not only for your own enterprise, but for the protection of the IT community as well. If a device is compromised within your network, it can then be used by its remote handlers to generate spam, deploy malware or host zone data for a malicious domain. Proper egress filtering can prevent these occurrences. For examples, you should make rules that restrict outgoing email and DNS traffic to authorized internal servers only. Just as there should be no incoming ports open, there should be none going out as well.
3. Placing Internet accessible resources on the internal LAN
Any enterprise capable firewall allows for multiple zones. These include the public zone (the internet) the internal LAN (where users and their devices, services and data reside) and a DMZ. The purpose of the DMZ is to provide a special zone for servers and devices that need to be accessible from the Internet such as email servers, FTP servers and terminal servers. The DMZ zone needs to be less restrictive in nature than the internal LAN, which makes the devices located within it more vulnerable. Many potentially bad things can happen when Internet accessible devices are placed within the internal LAN. Should a device become compromised, it is easy for malware or some type of exploit to spread throughout the LAN, putting company resources in jeopardy. This is the purpose of the DMZ, to limit the compromising of an Internet accessible device. This also requires that the traffic between the DMZ and Internal LAN are tightly controlled and secured. Too often, the DMZ has open access to the internal LAN because no one has taken the time to lock down its separation.
4. Allowing DNS zone traffic to any server
Many enterprises allow this, out of either convenience or inexperience. If you allow zone transfers to any server, all resource records in the zone are viewable by any host that can contact your DNS server. This includes rogue DNS servers located within your network. In order to prevent this, make sure that zone transfers are only allowed for AD integrated servers if you have a Windows AD network. If not, then specify the IP addresses of all authorized DNS servers and restrict zone transfers to only them. This takes more time to do but it is worth it to ensure the integrity of your DNS zones.
5. Checking your email or surfing the web using your admin account
Yes, we all know this, and yet it is one of those little shortcuts that we do sometimes. Perhaps we are expecting an important email while we configure a new server or we just want to browse the web to kill a few minutes waiting for an application install or update to finish. Don’t, it is not worth the risk. Admin accounts are the keys to the kingdom that every black hat wants. Malware is installed under the user account that downloaded it. Admin accounts are like steroids for malware, allowing it total access to the network at large.
6. Host more than Active Directory on a domain controller
A domain controller is a machine that runs Window Active Directory; it goes without saying that it should be properly secured. The first step on the road to domain controller security is total isolation. The machine hosting Active Directory should only be used to host Active Directory and nothing else.
Hosting anything else on that machine is an invitation to test Murphy's Law. In information security, different assets should always be isolated. Should one asset be compromised, the others would remain safe for the time being. If on the other hand, one was to run a backup server on the same machine –should your backup server be compromised, how long do you think it would take the attacker to notice what else is running on that machine? Why take the risk?
7. Re-use the same password
This rule seems simple and obvious. That being said, common sense is not so common. A System Administrator should never re-use the same password for two different (or more) machines or services. If they do and an attacker decides to try that password on any service or machine that the system administrator connects to, they will have easy access.
8. Use Administrator credentials to log on to a workstation
If you use your administrator credentials to log onto the machine that is not a domain controller, you are literally handing your credentials to the next attacker. There are now really easy ways of getting your cached credentials. And for Local Admin, it takes less than 20 seconds to elevate privileges from Local Admin to Domain Admin using code freely available on the Github platform.
9. Deploy open Wi-Fi networks
There is no need for open Wi-Fi networks in corporate spaces. If you need a guest network, assign a password to it and change it regularly. If people complain that they always have to get the new password, ask yourself the following question: will those people be complaining when you're busy cleaning the mess caused by a compromise? One thing is for certain, when it goes wrong, you will be blamed for the mess. With technology like WebTitan WiFi you can easily provide a fast and secure Wi-Fi experienceto people accessing your network. You can block malware and enforce acceptable browsing policies across locations.
Security should never be sacrificed at the altar of convenience. The majority of system administrators would never dream of doing the no-no’s listed in this article. It’s clear network administration is difficult and challenging. Every network is different - so network configuration, security and troubleshooting remain highly specialized and valued skills. And so it shall continue to be at least until someone develops networks and devices that can read users minds.
Source: TitanHQ Blog