19.2 Planning for Security

This section discusses the following topics. For additional planning topics, see the OES online documentation.

19.2.1 Comparing the Linux and the OES Trustee File Security Models

The OES Trustee and Linux (POSIX) security models are quite different, as presented in Table 19-1.

Table 19-1 POSIX vs. NSS/NCP File Security Models

Feature

POSIX / Linux

Trustee Model on OES

Administrative principles

Permissions are individually controlled and managed for each file and subdirectory.

Because of the nature of the POSIX security model, users usually have read rights to most of the system.

To make directories and files private, permissions must be removed.

For more information on making existing directories private, see Section 16.4.2, Providing a Private Work Directory.

Trustee assignments are made to directories and files and flow down from directories to everything below unless specifically reassigned.

Default accessibility

Users have permissions to see most of the file system.

The contents of a few directories, such as the /root home directory, can only be viewed by the root user.

Some system configuration files can be read by everyone, but the most critical files, such as /etc/fstab, can only be read and modified by root.

Users can see only the directories and files for which they are trustees (or members of a group that is a trustee).

Home directories—an example of default accessibility

By default, all users can see the names of directories and files in home directories.

During LUM installation, you can specify that newly created home directories will be private.

For more information on making existing home directories private, see Section 16.4.2, Providing a Private Work Directory.

By default, only the system administrator and the home directory owner can see a home directory. Files in the directory are secure.

If users want to share files with others, they can grant trustee assignments to the individual files, or they can create a shared subdirectory and assign trustees to it.

Inheritance from parents

Nothing is inherited.

Granting permission to a directory or file affects only the directory or file.

Rights are inherited in all child subdirectories and files unless specifically reassigned.

A trustee assignment can potentially give a user rights to a large number of subdirectories and files.

Privacy

Because users have permissions to see most of the file system for reasons stated above, most directories and files are only private when you make them private.

Directories and files are private by default.

Subdirectory and file visibility

Permissions granted to a file or directory apply to only the file or directory. Users can't see parent directories along the path up to the root unless permissions are granted (by setting the UID, GID, and mode bits) for each parent.

After permissions are granted, users can see the entire contents (subdirectories and files) of each directory in the path.

When users are given a trustee assignment to a file or directory, they can automatically see each parent directory along the path up to the root. However, users can’t see the contents of those directories, just the path to where they have rights.

When an NCP volume is created on a Linux POSIX or NSS volume, some of the behavior described above is modified. For more information, see the OES 2023: NCP Server for Linux Administration Guide, particularly the NCP on Linux Security section.

19.2.2 User Restrictions: Some OES Limitations

Seasoned NetWare administrators are accustomed to being able to set the following access restrictions on users:

  • Account balance restrictions

  • Address restrictions

  • Intruder lockout

  • Login restrictions

  • Password restrictions

  • Time restrictions

Many of the management interfaces that set these restrictions (iManager, for example), might seem to imply that these restrictions apply to users who are accessing an OES server through any protocol.

This is generally true, with two important exceptions:

  • Maximum number of concurrent connections in login restrictions

  • Address restrictions

These two specific restrictions are enforced only for users who are accessing the server through NCP. Connections through other access protocols (for example, HTTP or CIFS) have no concurrent connection or address restrictions imposed.

For this reason, you probably want to consider not enabling services such as SSH and FTP for LUM when setting up Linux User Management. For more information on SSH and LUM, see Section 9.4, SSH Services on OES.

For more information on Linux User Management, see Linux User Management: Access to Linux for eDirectory Users. For more information on the services that can be PAM-enabled, see Table 13-2.

19.2.3 Ports Used by OES

The ports used by OES services are listed in Table 19-3.

Table 19-2 Open Enterprise Server Services and Ports

Service

Default Ports

Domain Services for Windows

  • 1636 (LDAPS)

  • 1389 (LDAP)

  • 88 (Kerberos TCP and UDP)

  • 135 (RPC Endpoint Manager TCP and UDP)

  • 1024 - 65535 (RPC Dynamic Assignments TCP)

  • 3268 (Global Catalog LDAP TCP)

  • 3269 (Global Catalog LDAP over SSL TCP)

  • 123 (Network Time Protocol UDP)

  • 137 (NetBIOS Name Service TCP and UDP)

  • 138 (NetBIOS Datagram Service TCP and UDP)

  • 139 (NetBIOS Session Service TCP and UDP)

  • 8025 (Domain Service Daemon TCP)

  • 445 (Microsoft-DS traffic TCP and UDP)

NetIQ eDirectory

  • 389 (LDAP)

  • 636 (secure LDAP)

    IMPORTANT:The scripts that manage the common proxy user require port 636 for secure LDAP communications.

  • 8028 (HTTP for iMonitor)

  • 8030 (secure HTTP for iMonitor)

  • 524 (NCP)

iManager

  • 80 (HTTP)

  • 443 (secure HTTP)

iPrint

  • 80 (HTTP)

  • 443 (secure HTTP)

  • 631 (IPP)

Novell Identity Translator

  • 3268

  • 389

OES CIFS

  • 139 (Netbios)

  • 445 (Microsoft-ds)

Cloud Integrated Storage (CIS)

Infrastructure services:

  • 2181 (ZooKeeper)

  • 2282 (secure ZooKeeper)

  • 9092 (Kafka)

  • 9094 (secure Kafka)

  • 9400 (Elasticsearch)

  • 2377, 7946 (Docker Swarm)

  • 2888, 3888 (Communication between ZooKeeper servers and leader election)

CIS core services:

  • 3306 (MariaDB)

  • 8000 (Agent)

  • 8105 (CIS configuration)

  • 8343 (secure Gateway)

  • 8344 (CIS management))

  • 8346 (secure Datascale Gateway)

  • 8347 (secure Datascale Data service)

  • 24224 (Fluentbit)

OES Cluster Service

  • 7023

OES DHCP

  • 67

OES DNS

  • 953 (secure HTTP)

  • 53 (TCP)

  • 53 (UDP)

OES FTP

  • 21

OES Information Portal

  • 80 (HTTP)

  • 443 (secure HTTP)

OES NetWare Core Protocol (NCP)

  • 524

OES Remote Manager

  • 8008 (HTTP)

  • 8009 (secure HTTP)

NURM

  • 80

  • 443

SFCB

  • 5988 (HTTP)

  • 5989 (secure HTTP)

Secure Shell

  • 22

Storage Management Services (Backup)

  • 40193 (smdr daemon)

Unified Management Console (UMC)

  • 5432 (database)

Time Synchronization

  • 323 (Network Time Protocol UDP)

19.2.4 Apache Security

As a best practice, if you are planning to have Apache based services such as iManager, NURM, iPrint, or UMC in OES, it is recommended to follow the Apache security tips.

For security consideration, Apache on OES 2023 enables only TLSv1.2 and TLSv1.3. The CBC mode ciphers supported with TLSv1.2 are considered vulnerable and therefore recommended to be disabled. Considering environments having OES2023 and any third-party devices and software, the following CBC mode ciphers are enabled by default.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Environments having only OES components such as iManager, NURM, and UMC can disable the CBC mode ciphers.Environments having iPrint are advised to enable or disable the ciphers based on their requirements.

TLSv1.3 does not support any of the CBC mode ciphers. Therefore, no action is required if only TLSv1.3 is enabled.

To disable CBC mode ciphers:

  1. On OES 2023, change the SSLCipherSuite setting in /etc/apache2/vhosts.d/vhosts-ssl.conf to include !SHA:!SHA256:!SHA284:!SHA384.

    For example, SSLCipherSuite HIGH:!MEDIUM:!LOW:!SHA:!SHA256:!SHA284:!SHA384:!aNULL@STRENGTH

    NOTE:If an administrator has removed the SSLCipherSuite setting in /etc/apache2/vhosts.d/vhosts-ssl.conf, then the change should be made in Apache global SSL configuration file /etc/apache2/global-ssl.conf.

  2. Restart Apache by using the command systemctl restart apache2.service.

19.2.5 Configuring and Administering Security

For a list of configuration and administration topics, see the OES online documentation.