1

One needs to configure freely a development environment under Linux set up inside a large intranet, with access to the internet.

I am not a Linux Administrator, nor a Network Expert. From what I can collect from the net, however, my understanding is that:

  • security does not mean or necessitate over-restrictive control, rather it is about understanding basic principles, following secure and safe practices
  • the Linux kernel firewall matters
  • the intranet's firewall matters even more
  • remote root access should not be allowed, rather use of ssh key authentication

Are the above and the following questions the appropriate points to discuss and ask, when it comes to security and safety inside a large intranet?

Is it a necessity or best practice to restrict a Linux user from having "sudo" rights in his "own" system, for the sake of security and safety, for protecting from outside threats?

Can security and protection from outside threats be performed with a good set of rules for iptables and adequate maintenance of the intranet's firewall?

Is remote root access to a Linux machine, from inside the intranet, a safe practice?

closed as too broad by Pascal, techraf, CaffeineAddiction, schroeder Mar 16 '17 at 8:57

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    I'm sorry, but this is such a broad question that I can't see how anyone could produce an answer that would cover even just a part of what you want to know. I'm voting to close, and would suggest you talk to one of your administrators, or at least break the question down into multiple separate questions so each can be answered in isolation. – Pascal Mar 16 '17 at 1:18
  • Pascal I would prefer to break down the question. Maybe group some of them? – Nikos Alexandris Mar 16 '17 at 9:57
2

security does not mean or necessitate over-restrictive control, rather it is about understanding basic principles, following secure and safe practices

That is a reasonably true statement, especially when you're describing a development environment. But be aware that the security/administrator's definition of "restrictive" is going to differ from the developer's definition!

the Linux kernel firewall matters

On an intranet Development environment, not so much. Such systems often require loose and flexible port access. In any environment, maintenance of local firewall rules across any number of machines is daunting (read: breaks functionality early and often, ties the administrator down loosening it).

the intranet's firewall matters even more

Absolutely. With a development environment, it often needs to be loose and open internally, so the border has to be more restrictive - definitely inbound, but also outbound.

remote root access should not be allowed, rather use of ssh key authentication

There are couple of best practices in this area which, combined, equal what you're talking about.

  • Direct remote root login is discouraged due to attribution issues. Users, even administrators, should log in as themselves and su or sudo to root so that their actions can be attributed to a person, not a crowd of people with the credentials necessary to log in as root.
  • Remote root logins, if allowed (perhaps for configuration management software) should require SSH keys to make brute-forcing them impractical.

Are the above and the following questions the appropriate points to discuss and ask, when it comes to security and safety inside a large intranet?

They are all good points. However, you've missed the two most important parts of this adventure:

  1. Patching. Patching should be automated, centralized, and vigorously often.
  2. Configuration management. Something like Puppet should be used to centrally manage the configuration of the machines and common software.

Patching is pretty obvious. Configuration management, while less obvious, is just as important. Configuration management means:

  • When you need to tweak configuration, it happens across all your systems without relying upon you to run around doing it everywhere.
  • Developers who tweak their configuration (often with security implications) are swiftly overridden and brought back into compliance.
  • When you bring a new system online, it's quickly brought into compliance with your standards, and doesn't get "missed" or left out.

Is it a necessity or best practice to restrict a Linux user from having "sudo" rights in his "own" system, for the sake of security and safety, for protecting from outside threats?

There must be balance between security and business need. Developers often have a legitimate need for privileged access. To balance that need, security will often restrict privileges (e.g., sudo to particular commands but not a root shell), log for audit (e.g., bash to syslog, available in 4.1+), and limit damage to the pool (e.g., restrictive outbound access through the firewall).

Can security and protection from outside threats be performed with a good set of rules for iptables and adequate maintenance of the intranet's firewall?

No, more than that is needed, as described above.

To quote Gary Larson:

Far Side "Crunchy Igloo" cartoon

Is remote root access to a Linux machine, from inside the intranet, a safe practice?

It is more unsafe than local root access, simply because the authentication of the user responsible for running commands is lost (or, removed 1+ steps). Requiring that privileged commands be tied back to a user, and logged that way, is necessary both in content (now you know) and consequence (developers held personally accountable are less inclined to do things they shouldn't).

  • This answer is pretty much what I was aiming for, an informative overview. – Nikos Alexandris Mar 16 '17 at 10:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.