In message <[EMAIL PROTECTED]>, Darrin Chandler writes:
> On Thu, Nov 23, 2006 at 12:24:38PM +0100, Igor Sobrado wrote:
> > First of all, I understand that remote root logins can be easily
> > avoided by setting "PermitRootLogin" to "no" in /etc/ssh/sshd_config.
> 
> Yes. This is a very simple thing to do.

Agreed, and if someone misses this change when installing a new system
it can be enabled at any time in the future.

> > I guess that remote root logins are allowed by default to simplify
> > management of small network appliances that do not have user accounts
> > on them.  But these appliances are only a small number of all OpenBSD
> > installations and, even if this number is not so small, a restricted
> > (non-root) account in the group wheel and probably in the group operator
> > too, on these devices is advisable to avoid damaging these appliances
> > by mistake.
> 
> These assumptions, I think, are the problem. I have no "small network
> appliances", yet I find SSH root login to be very useful in the initial
> stages of configuring a new computer installation.

I usually prefer doing these initial stages of configuration on the
console port.  There is a small risk of making the system not functional
in some cases.

> For a compromised password, there's no essential difference between root
> and someone with full sudo access. If you have 5 people in wheel/sudoers
> then an attacker can break *any* of those and get root.

Well, sudo should not allow full access to the system.  Users that
require full access should be in the wheel group and know the root
password (they *must be* trusted users).  sudo is excellent when
giving privileges for specific tasks to some users.

> No. It would be simple enough to disable everything, but that wouldn't
> be functional. OpenBSD has an excellent track record for security, yet
> many useful things are enabled by default. Do you *really* believe that
> nobody has thought about turning off root ssh in the default configs? Of
> course they have. Yet it remains enabled. Selecting a secure password
> for root is YOUR responsibility.

Agreed, I know that OpenBSD has an excellent track record for security
and reliability.  I know that good root passwords must be chosen too,
it is one of the main goals of a system manager: choosing good passwords
for system maintenance accounts and training users to choose good
passwords for their own accounts.

> > Someone that really wants to allow remote root logins should be able to
> > enable this feature just changing /etc/ssh/sshd_config.  But, in my
> > humble opinion, most users do not really want this dangerous feature
> > enabled by default.  And, even on small network appliances, an unprivileged
> > account in the wheel group (and even in the operator group) is a good
> > management practice.
> 
> Most users just don't care. More security conscious users *do* care, and
> often turn it off. They also block all icmp packets and a lot of other
> things that they read somewhere on the web, without understanding why,
> or assessing how much of a threat it poses to them, or how effective it
> is in countering the threat. *Really* security conscious people take the
> time to understand the issues, and to configure their systems.

Blocking ICMP packets has serious consequences on the network.  ECHO_REQUEST
and ECHO_REPLY messages are important for tracing network connections
when something goes wrong.  Timeouts sent by ICMP are useful to get
a fast response when a service is not working without awaiting for
the connection to being dropped.

Same happens with the time and daytime services enabled by default.
Most users choose closing these services.  I really like running
NTP on one server (and certainly OpenNTP is an excellent and lightweight
NTP implementation) and using rdate (and the time service enabled by
default) to synchronize the workstations without running NTP on them
and setting up a NTP server on the machine that gets the time from
the public NTP servers.  These services are simple and, as a consequence,
reliable... and very useful.

Certainly changing the behaviour of sshd is easy to do and, in this
case, I find this change useful (as a difference with blocking ICMP
-all my pf firewalls reply as they should to ICMP messages- or stopping
the useful time services.)

Best regards,
Igor.

Reply via email to