As networks are usually the primary point of entry point into IT systems, you can use network intrusion prevention and detection tools to help avert or uncover a security breach. You can then take steps such as disabling unused network services and configure a packet-filtering firewall and TCP wrappers.

There are several open-source tools for performing packet logging and analysis. For example, tcpdump and Snort capture TCP traffic and analyze it for suspicious usage patterns, such as those that typically occur with port scans or network DoS attacks. Sguil incorporates tcpdump, Snort, and the Wireshark protocol analyzer to provide a network intrusion and detection system that simplifies log analysis and reporting.

netstat -tulp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 localhost:9003          0.0.0.0:*               LISTEN      1776/osms-agent     
tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*               LISTEN      1042/rpcbind        
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      2051/sshd           
tcp6       0      0 [::]:sunrpc             [::]:*                  LISTEN      1042/rpcbind        
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      2051/sshd           
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                           1465/dhclient       
udp        0      0 0.0.0.0:sunrpc          0.0.0.0:*                           1042/rpcbind        
udp        0      0 localhost:323           0.0.0.0:*                           1062/chronyd        
udp        0      0 0.0.0.0:789             0.0.0.0:*                           1042/rpcbind        
udp6       0      0 [::]:sunrpc             [::]:*                              1042/rpcbind        
udp6       0      0 localhost:323           [::]:*                              1062/chronyd        
udp6       0      0 [::]:789                [::]:*                              1042/rpcbind

lsof -iTCP -sTCP:LISTEN

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind   1042  rpc    8u  IPv4  19998      0t0  TCP *:sunrpc (LISTEN)
rpcbind   1042  rpc   11u  IPv6  20001      0t0  TCP *:sunrpc (LISTEN)
osms-agen 1776 root   10u  IPv4  26707      0t0  TCP localhost:9003 (LISTEN)
sshd      2051 root    3u  IPv4  25784      0t0  TCP *:ssh (LISTEN)
sshd      2051 root    4u  IPv6  25786      0t0  TCP *:ssh (LISTEN)

nmap -sTU 10.0.2.15

Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-10 09:37 GMT
Nmap scan report for 10.0.2.15
Host is up (0.0017s latency).
Not shown: 1993 closed ports
PORT     STATE         SERVICE
22/tcp   open          ssh
111/tcp  open          rpcbind
68/udp   open|filtered dhcpc
111/udp  open          rpcbind
123/udp  open          ntp
631/udp  open|filtered ipp
5353/udp open|filtered zeroconf

Nmap done: 1 IP address (1 host up) scanned in 12.66 seconds

For more information, see the lsof(8), netstat(8), and nmap(1) manual pages.

The two sections in this chapter, Configuring Packet-filtering Firewalls and Configuring TCP Wrappers, are specific methods to restrict access to network services.

A packet filtering firewall filters incoming and outgoing network packets based on the packet header information. You can create packet filter rules that determine whether packets are accepted or rejected. For example, if you create a rule to block a port, any request that is made to that port that is blocked by the firewall, and the request is ignored. Any service that is listening on a blocked port is effectively disabled.

The Oracle Linux kernel uses the Netfilter feature to provide packet filtering functionality for IPv4 and IPv6 packets.

The firewalld-based firewall has the following advantages over an iptables-based firewall:

• Unlike the iptables and ip6tables commands, using firewalld-cmd does not restart the firewall and disrupt established TCP connections.

• firewalld supports dynamic zones, which allow you to implement different sets of firewall rules for systems such as laptops that can connect to networks with different levels of trust. You are unlikely to use this feature with server systems.

• firewalld supports D-Bus for better integration with services that depend on firewall configuration.

To implement a general-purpose firewall, you can use the Firewall Configuration GUI (firewall-config), provided by the firewall-config package.

Figure 4-1 shows the Firewall Configuration GUI.

Figure 4-1 Firewall Configuration

To create or modify a firewall configuration from the command line, use the firewall-cmd utility (or, if you prefer, the iptables, or ip6tables utilities) to configure the packet filtering rules.

The packet filtering rules are recorded in the /etc/firewalld hierarchy for firewalld and in the /etc/sysconfig/iptables and /etc/sysconfig/ip6tables files for iptables and ip6tables.

OpenSSH is suite of network connectivity tools that provides secure communications between systems. OpenSSH provides another layer of protection to your organization by ensuring that network traffic is safe from external threats. For more information, see Oracle^® Linux: Connecting to Remote Systems With OpenSSH.

sudo ldd /usr/sbin/sshd | grep libwrap

libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f877de07000)

When a remote client attempts to connect to a network service on the system, the wrapper consults the rules in the configuration files /etc/hosts.allow and /etc/hosts.deny files to determine if access is permitted.

The wrapper for a service first reads /etc/hosts.allow from top to bottom. If the daemon and client combination matches an entry in the file, access is allowed. If the wrapper does not find a match in /etc/hosts.allow, it reads /etc/hosts.deny from top to bottom. If the daemon and client combination matches an entry in the file, access is denied. If no rules for the daemon and client combination are found in either file, or if neither file exists, access to the service is allowed.

The wrapper first applies the rules specified in /etc/hosts.allow, so these rules take precedence over the rules specified in /etc/hosts.deny. If a rule defined in /etc/hosts.allow permits access to a service, any rule in /etc/hosts.deny that forbids access to the same service is ignored.

The rules take the following form:

daemon_list : client_list [: command] [: deny]

In the previous example, daemon_list and client_list are comma-separated lists of daemons and clients, and the optional command is run when a client tries to access a daemon. You can use the keyword ALL to represent all daemons or all clients. Subnets can be represented by using the * wildcard, for example 192.168.2.*. Domains can be represented by prefixing the domain name with a period (.), for example .example.com. The optional deny keyword causes a connection to be denied even for rules specified in the /etc/hosts.allow file.

The following are some sample rules.

Match all clients for scp, sftp, and ssh access (sshd).

sshd : ALL

Match all clients on the 192.168.2 subnet for FTP access (vsftpd).

vsftpd : 192.168.2.*

Match all of the clients in the example.com domain to gain access to all wrapped services.

ALL : .example.com

Match all clients for FTP access, and display the contents of the banner file /etc/banners/vsftpd. The banner file must have the same name as the daemon.

vsftpd : ALL : banners /etc/banners/

Match all of the clients on the 200.182.68 subnet for all wrapped services, and log all such events. The %c and %d tokens are expanded to the names of the client and the daemon.

ALL : 200.182.68.* : spawn /usr/bin/echo `date` “Attempt by %c to connect to %d" >> /var/log/tcpwr.log

sshd : ALL : severity emerg

sshd : .forbid.com : spawn /usr/bin/echo `date` "sshd access denied for %c" >>/var/log/sshd.log : deny

For more information, see the hosts_access(5) manual page.

A chroot operation changes the apparent root directory for a running process and its children. It allows you to run a program with a root directory other than /. The program cannot see or access files outside the designated directory tree. Such an artificial root directory is called a chroot jail, and its purpose is to limit the directory access of a potential attacker. The chroot jail locks down a given process and any user ID that it is using so that all they see is the directory in which the process is running. To the process, it appears that the directory in which it is running is the root directory.

For a chroot process to be able to start successfully, you must populate the chroot directory with all required program files, configuration files, device nodes, and shared libraries at their expected locations relative to the level of the chroot directory.

Oracle Linux provides the yum command that you can use to install or upgrade RPM packages. The main benefit of using yum is that it also installs or upgrades any package dependencies. The yum command downloads packages from repositories such as those that are available on the Oracle Linux yum server and the Unbreakable Linux Network (ULN), but you can also set up your own repositories on systems that do not have Internet access.

For more information about managing software with the yum utility, see Oracle^® Linux 7: Managing Software.

The Oracle Linux yum server is a convenient way to install Oracle Linux packages rather than installing them from installation media. You can also subscribe to the Oracle Linux errata mailing list, and obtain bug fixes, security fixes and enhancements. You can access the server at https://yum.oracle.com/.

If you have registered your system with ULN, you can use yum with the ULN channels to maintain the software on your system

for i in `rpm -qa` 
> do
> rpm -V $i > .tmp || echo -e "\nDiscepancies for package $i" && cat .tmp
> rm -f .tmp
> done

Discepancies for package gdm-2.30.4-33.0.1.el6_2.x86_64
.M....G..    /var/log/gdm
.M.......    /var/run/gdm
missing     /var/run/gdm/greeter

Discepancies for package libgcj-4.4.6-4.el6.x86_64
..5....T.  c /usr/lib64/security/classpath.security

Discepancies for package sudo-1.7.4p5-12.el6_3.x86_64
S.5....T.  c /etc/sudoers

Discepancies for package libcgroup-0.37-4.el6.x86_64
S.5....T.  c /etc/cgconfig.conf

Discepancies for package yum-3.2.29-30.0.1.el6.noarch
.......T.  c /etc/yum.conf

Discepancies for package kernel-2.6.32-279.el6.x86_64
.......T.    /etc/ld.so.conf.d/kernel-2.6.32-279.el6.x86_64.conf
...

A string of character codes indicates the discrepancies between an installed file and the metadata for that file. The following list describes the meanings of the character codes in the output of the rpm -V command.

• 5: MD5 sum

• D: Device major or minor number.

• G: Group ownership.

• L: Symbolic link path.

• M: Mode including permissions or file type.

• P: Capabilities.

• S: File size.

• T: Modification time.

• U: User ownership.

• .: None (test passed).

• ?: Unknown (test could not be performed).

If displayed, a single character code preceding the affected file denotes the file type, and can take the values that are shown in the following list.

• c: Configuration file.

• d: Documentation file.

• g: Ghost file, whose file contents are not included in the package payload.

• l: License file.

• r: Readme file

Most discrepancies are caused by editing the configuration files of subsystems. To see which files change over time, create a baseline file of discrepancies immediately after installation, and diff this file against the results found by rpm -V at a later date.

You can also use a file integrity checker to test whether a system has been compromised. There are several available open source and commercial file integrity checking tools, including AIDE (Advanced Intrusion Detection Environment) and Tripwire. AIDE and Tripwire are intrusion detection systems that scan file systems and record cryptographic hashes of each file in a database. After creating the database, you should then move it to a read-only medium to avoid tampering. On subsequent file system checks, the tool alerts you if the stored checksums do not match those for the current files. For more information, see the AIDE or Tripwire websites.

For more information, see the yum(8) manual page.

You can use data encryption to protect data that is stored or that is being transmitted. Data on storage devices and media can be at risk of theft or device loss. Data being transmitted over local area networks and the Internet can be intercepted or altered. In addition, data encryption to protect privacy and personal data is increasingly being made a mandatory requirement of corporate security policy and by governmental regulations (for example, HIPAA, GLBA, SOX, and PCI DSS).

Public Key Infrastructure (PKI) provides the tools and framework to encrypt and validate network connections. It also provides an authentication mechanism in the form of signed certificates. Managing your certificates and implementing strong public key infrastructure is an important part of maintaining good security within your organization. For more information, see Oracle^® Linux: Managing Certificates and Public Key Infrastructure

Authentication is a method of verifying the identity of users. The operating system authenticates user names and passwords by comparing this information to data stored on the system. If the login credentials match the data, then access to the system is granted. For more information, see Oracle^® Linux 7: Setting Up System Accounts and Authentication.

The Pluggable Authentication Modules (PAM) feature is an authentication mechanism for applications to verify user credentials. For more information, see Oracle^® Linux 7: Setting Up System Accounts and Authentication.

POSIX Access Control Lists (ACLs) provide a richer access control model than traditional UNIX Discretionary Access Control (DAC) that sets read, write, and execute permissions for the owner, group, and all other system users. You can configure ACLs that define access rights for more than just a single user or group, and specify rights for programs, processes, files, and directories. If you set a default ACL on a directory, its descendents inherit the same rights automatically. The kernel provides ACL support for ext3, ext4, and NFS-exported file systems.

The following are examples of setting and displaying ACLs for directories and files.

sudo setfacl -m u:user:r file

sudo getfacl file

sudo setfacl -m m::rx file

sudo setfacl -x g:group file

sudo getfacl f1 | setfacl --set-file=- f2

sudo getfacl --access dir | setfacl -d -M- dir

For more information about how to manage ACLs, see the setfacl(1) and getfacl(1) manual pages.

SELinux is a kernel module that enforces and implements access control policies on Oracle Linux systems to protect services and files from malicious or unauthorized access. Use the SELinux user space tools to manage policies and to resolve access issues. For more information, see Oracle^® Linux: Administering SELinux for more info

Auditing collects data at the kernel level that you can analyze to identify unauthorized activity. Auditing collects more data in greater detail than system logging, but most audited events are uninteresting and insignificant. The process of examining audit trails to locate events of interest can be a significant challenge that you will probably need to automate.

The audit configuration file, /etc/audit/auditd.conf, defines the data retention policy, the maximum size of the audit volume, the action to take if the capacity of the audit volume is exceeded, and the locations of local and remote audit trail volumes. The default audit trail volume is /var/log/audit/audit.log. For more information, see the auditd.conf(5) manual page.

By default, auditing captures specific events such as system logins, modifications to accounts, and sudo actions. You can also configure auditing to capture detailed system call activity or modifications to certain files. The kernel audit daemon (auditd) records the events that you configure, including the event type, a time stamp, the associated user ID, and success or failure of the system call.

The entries in the audit rules file, /etc/audit/audit.rules, determine which events are audited. Each rule is a command-line option that is passed to the auditctl command. You should typically configure this file to match your site's security policy.

The following are examples of rules that you might set in the /etc/audit/audit.rules file.

-a exit,always -S open -S truncate -F /etc -F success=0

-a exit,always -S open -F uid=10

-a exit,always -S open -F auid>=500 -F perm=wa

-w /etc/sudoers -p wa -k sudoers-change

-w /etc/ -p wa

-e 2

You can find more examples of audit rules in /usr/share/doc/audit-version/stig.rules, and in the auditctl(8) and audit.rules(7) manual pages.

Stringent auditing requirements can impose a significant performance overhead and generate large amounts of audit data. Some site security policies stipulate that a system must shut down if events cannot be recorded because the audit volumes have exceeded their capacity. As a general rule, you should direct audit data to separate file systems in rotation to prevent overspill and to facilitate backups.

You can use the -k option to tag audit records so that you can locate them more easily in an audit volume with the ausearch command. For example, to examine records tagged with the string sudoers-change, you would enter:

sudo ausearch -k sudoers-change

The aureport command generates summaries of audit data. You can set up cron jobs that run aureport periodically to generate reports of interest. For example, the following command generates a reports that shows every login event from 1 second after midnight on the previous day until the current time:

sudo aureport -l -i -ts yesterday -te now

For more information, see the ausearch(8) and aureport(8) manual pages.

The log files contain messages about the system, kernel, services, and applications. The journald logging daemon, which is part of systemd, records system messages in non-persistent journal files in memory and in the /run/log/journal directory. journald forwards messages to the system logging daemon, rsyslog. As files in /run are volatile, the log data is lost after a reboot unless you create the directory /var/log/journal. You can use the journalctl command to query the journal logs.

For more information, see the journalctl(1) and systemd-journald.service(8) manual pages.

The configuration file for rsyslogd is /etc/rsyslog.conf, which contains global directives, module directives, and rules. By default, rsyslog processes and archives only syslog messages. If required, you can configure rsyslog to archive any other messages that journald forwards, including kernel, boot, initrd, stdout, and stderr messages.

$MainMsgQueueSize 50000

The available configuration directives are described in the file /usr/share/doc/rsyslog-version-number/rsyslog_conf_global.html.

$ModLoad MODULE_name

Input modules receive messages, which pass them to one or more parser modules. A parser module creates a representation of a message in memory, possibly modifying the message, and passes the internal representation to output modules, which can also modify the content before outputting the message.

A description of the available modules can be found in RSyslog documentation at https://www.rsyslog.com/doc/.

An rsyslog rule consists of a filter part, which selects a subset of messages, and an action part, which specifies what to do with the selected messages. To define a rule in the /etc/rsyslog.conf configuration file, specify a filter and an action on a single line, separated by one or more tabs or spaces.

The following list identifies the available facility keywords for facility/priority-based filters:

• auth, authpriv: Security, authentication, or authorization messages.

• cron: crond messages.

• daemon: Messages from system daemons other than crond and rsyslogd.

• kern: Kernel messages.

• lpr: Line printer subsystem.

• mail: Mail system.

• news: Network news subsystem.

• syslog: Messages generated internally by rsyslogd.

• user: User-level messages.

• UUCP: UUCP subsystem.

• local0 - local7: Local use.

The following list identifies the available priority keywords for facility/priority-based filters, in ascending order of importance:

• debug: Debug-level messages.

• info: Informational messages.

• notice: Normal but significant condition.

• warning: Warning conditions.

• err: Error conditions.

• crit: Critical conditions.

• alert: Immediate action required.

• emerg: System is unstable.

All messages of the specified priority and higher are logged according to the specified action. An asterisk (*) wildcard specifies all facilities or priorities. Separate the names of multiple facilities and priorities on a line with commas (,). Separate multiple filters on one line with semicolons (;). Precede a priority with an exclamation mark (!) to select all messages except those with that priority.

The following are examples of facility/priority-based filters.

kern.*

mail.crit

daemon,kern.warning,err

cron.!info,!debug

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

*.*        @@logsvr:port

In the previous example, logsvr is the domain name or IP address of the log server and port is the port number (usually, 514).

$ModLoad imtcp
$InputTCPServerRun port

In the previous example, port corresponds to the port number that you set on the log clients.

To manage the rotation and archival of the correct logs, edit /etc/logrotate.d/syslog so that it references each of the log files that are defined in the RULES section of /etc/rsyslog.conf. You can configure how often the logs are rotated and how many past copies of the logs are archived by editing /etc/logrotate.conf.

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

For more information, see the logrotate(8), logwatch(8), rsyslogd(8) and rsyslog.conf(5) manual pages, the HTML documentation in the /usr/share/doc/rsyslog-5.8.10 directory, and the documentation at https://www.rsyslog.com/doc/.

The psacct package implements the process accounting service in addition to the following utilities that you can use to monitor process activities:

ac

Displays connection times in hours for a user as recorded in the wtmp file (by default, /var/log/wtmp).

accton

Turns on process accounting to the specified file. If you do not specify a file name argument, process accounting is stopped. The default system accounting file is /var/account/pacct.

lastcomm

Displays information about previously executed commands as recorded in the system accounting file.

sa

Summarizes information about previously executed commands as recorded in the system accounting file.

For more information, see the ac(1), accton(8), lastcomm(1), and sa(8) manual pages.

The Linux Containers (LXC) feature provides a way to isolate a group of processes from other processes that are running on an Oracle Linux system. LXC is a lightweight operating system virtualization technology that uses the control group (cgroup) feature to provide resource management and namespace isolation in a similar manner to chroot. Within a container, processes can have their own private view of the operating system with its own process ID space, file system structure, and network interfaces.

See the following documentation:

• See Oracle^® Linux 7: Working With LXC for more information about how to configure and use Linux Containers.

• Oracle Cloud Native Environment documentation at https://docs.oracle.com/en/operating-systems/olcne/.

The Linux kernel features some additional security mechanisms that you can use to enhance the security of a system. These mechanisms randomize the layout of a process's address space or prevent code from being executed in non-executable memory.