118

Removing the GUI is useful and recommended. It will remove unused components, a lot of libraries, and makes the install size smaller. How does this make it less vulnerable? Fewer components equal less attack surface. A vulnerability on a GUI component will not affect you. Attacks relying on GUI components won't work either. So, when designing a server, ...


115

Here's one data point from a software company that has an interest in security. I know this is common in similar organisations. There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables. Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email ...


90

I believe that Teamviewer is a proxy service for tunnelled VNC connections. Hence, the first security consideration with regard to that service is that it is MITM'ed by design. There have been suggestions that the service was compromised a couple of months ago. (Note that although VNC uses encryption, the entire exchange is not, by default, encapsulated - ...


71

Edit: According to the comments there seems to be combination of configuration options in the enterprise edition of TeamViewer which might reduce my concerns. Since I have never used those, I cannot give an assessment about those and how well they work. According to the comments it might to be a buggy solution. I am a server admin (Windows and Linux) and I ...


71

In my experience, it is common for developers to have admin access on their own machines. It is also common for them not to have admin access on their own machines. However, in the latter situation some accommodation is generally made so they can get their jobs done without too much friction. One very common accommodation is access to a Hypervisor on the ...


47

I work for a fairly large investment management firm (~6000 employees) and developers are one of the groups that we approve for local admin access. We tell them not to install any software, as that is handled by local desktop/software compliance. We also have a Developers AD Group that allows members to change the execution policy on their machines without ...


42

Removing the GUI also has the side effect of making it a bit more "human safe" because put bluntly, it makes the OS more idiot proof. There are countless stories of small businesses having users reading mail and browsing the internet on the company DC. The user opens a bad attachment and suddenly everything is on fire. Simply removing the GUI from server ...


36

In addition to the other great answers, TeamViewer offers less physical security because it requires that the screen is unlocked in order to facilitate a remote session. That is, anyone walking past a keyboard and monitor of a remotely administered session can observe it and possibly take over the session should the remote user not be paying attention. ...


31

In my career, with rather small companies (less than 100 people), we always had local admin rights. We either have real desktop machines which are maintained by IT, but got the rights, or we were allowed to have virtual machines of all sorts that we completely managed by our own. If we had not local admin access, we would try all sorts of bad "solutions" ...


29

In a rather small department of a larger organization (~100 in department, ~3500 in full organization) we chose an in the middle solution: sysadmins had 2 accounts, one (non administrator even for the local machine) that was used for non administative tasks (mail, document edition, etc.) and one with AD administrator priviledges that was supposed to be only ...


27

Local Admin access means that it is easier for the attacker to establish persistent control of the host, to install software and modify system settings, and to take actions like sniffing the network that may allow it to move laterally onto other systems. So, yes, it is a danger to the network, in that it provides the attacker with more stable access to a ...


26

To begin, I know nothing about TeamViewer, so I won't attempt to comment on it. Historical RDP servers used "RDP Security", which is indeed a broken protocol and vulnerable to MITM. Don't do that. Even 2003r2 can do TLS for RDP, so there is no modern reason you should be forced to use RDP Security. Modern Servers will support TLS, so the security of ...


26

In my experience allowing and disallowing local admin access is common, just as common as dirty workarounds for the latter. - So you should ask yourself: Which threat to your network is made worse by local admin rights? To which the answer shoud be: NONE - The access to resources in your network should be restricted on a per user basis, completely ...


16

Assuming that you're using a modern version of RDP and configure it correctly (e.g. enable NLA, sort out proper certificates) the main risk of exposing it directly to the Internet tends to be the problem of exposing a username/password authentication system to the Internet, which is that you're allowing attackers to attempt to brute-force Active Directory ...


13

In my experience working for larger organizations, it is absolutely not common for developers to have full rights to anything other than development specific resources. It seems like your organization is on the border of small and large, so... It sounds like it's time for your organization to develop some more mature development practices. To be fair, ...


11

First of all you need to learn that it does not matter what "is common" or "typical" because: typically such situations are handled horribly. You are making the best case for this statement. If local admin access is needed for a person (be it a contractor or an employee) then it is the obligation of the security team/person - whoever is in charge of that ...


11

Danger is a bit of a strong word. I would say that local admin access presents additional network risks over non-admin access. Admin access allows the user to run a packet sniffer in promiscuous mode. That can present additional risks if the network in question is vulnerable to MiTM attacks, or other unencrypted, sensitive information goes across the ...


10

I'll expand on Daniel Bungert's explanation of protocols involved and why they work together. Having written a MitM proxy for RDP, I'm very familiar with the inner workings of most protocols involved. (More than I'd like to be...) You can configure it to only operate over TLS. This offers great security in it's own right, every message is wrapped with TLS ...


10

Patching addresses known risks while introducing unknown risks, like new unknown vulnerabilities, bugs, performance issues, etc. That's why places like banks wait a while to quantify the unknowns before patching. Patching is not something that should be done without a risk assessment. Do you leave known vulnerabilities in place because you fear ...


8

It is very good advice to not use the web browser for Internet traffic on the server. It's our policy (I work in cyber security for a federal agency) to never use a web browser (for Internet, or external websites) for any sort of Internet traffic even if it's to download a file that will be used on the server. As another user mentioned in their answer, it ...


8

The basics for protection against ransomware is : Update frequently (OS, AntiVirus, ...) Don't open phishing / infected emails which usually convey the ransomware (user awareness) Backup, backup, backup (and check them!) The majority of the ransomware risk is cancelled by a proper backup strategy. If your data are safe in some offline place, they can crypt ...


8

I've seen two approaches that work. Give developers admin access to their machines. This is the easiest and most common approach. It is usually the best choice Create a team in the organisation whose whole Job is to ensure that developers can work without admin access. This team will usually be 3-4 people. You will find that developer's hardware ...


8

This fundamentally depends on context, and in particular on your threat model. In some organisations, it's common to give developers complete control over their development workstation, to the point of enabling them to install their own OS on it. In some organisations, all development must be done in an airgapped environment, that no electronic devices can ...


8

The problem you actually have is competent IT are attempting to enforce a boneheaded rule. You really only have one choice, give developers effective admin access. I keep seeing the same advice being repeated over and over again, that boils down to a second machine that the developer has admin but no internet. If you want to have swiss-cheese security that'...


7

I worked for some time for a company that really believes in security (or so they think). Every once in a while they would organize a social event, like playing bowling. Joining was free, but you had to add your name to a list in an Excel file, placed in a shared folder. That folder was dedicated to social events, nothing else. So, you want to play bowling?...


7

It is far more danger than most people guess. When we debated how much someone could do from Local Admin (local account, not domain account) on one domain-joined machine, I said "Would you like to find out?" Nobody did. Turned out they wanted to debate the theory but not put it to the test. I argued on the other question what are you defending against. Well ...


6

I'd go with some kind of VPN from the user's remote computer to a firewall at work, and then run RDP over that encrypted link. Problem with leaving a port open is that eventually it is found, and you'll have brute-force login attempts. Either that will just slow your environment down, or it will lead to accounts being locked out, or they find a username ...


6

This started as a comment. It's important to point out the "Who's at fault question". If you use a third party service and they fail to provide it's their failure to provide. If you use something in house and it fails, now it's the house's fault. Such distinctions carry a lot of weight. It might not mean anything to actual security, but that can sometimes ...


5

Use someone else's PEM bundle. You can not use the Windows certificate store directly with OpenSSL. Instead OpenSSL expects its CAs in one of two ways: Many files: In a special folder structure. One file per certificate with regular names like Verisign-CA.pem. (This is so that humans can understand the cert store.) And then a symlink to each such file. And ...


5

I believe you've answered your question yourself correctly. Users and Guest accounts should not have the "Allow log on locally" rights on servers, only Administrators (and Backup Operators if necessary). Here is a MS KBA in which security countermeasures are described: https://technet.microsoft.com/en-us/library/dn221980.aspx Quote: "For domain ...


Only top voted, non community-wiki answers of a minimum length are eligible