Christopher Negus - Linux Bible - Ninth Edition

firewall-config

This is the graphical configuration tool for firewalld.

On the left there is the overview of the active bindings. These are the zones, that have a connection, interface or source
bound or added to it. Here it is possible to easily change the zone of these bindings. But it is not possible to add new
bindings here. Use the Interface and Source tab in the Zones
notebook on the right side for this.

The firewall-config tool has a drop-down selection menu
labeled Configuration. This enables selecting between
Runtime and Permanent mode. Notice that if you select
Permanent, an additional row of icons will appear in the left
hand corner. These icons only appear in permanent
configuration mode because a service’s parameters cannot
be changed in runtime mode.

Changes in the permanent configuration mode are not
effective immediately. If you want to have changes also in
the runtime environment, then either add the changes there
also or reload firewalld.

firewall-applet

firewall-applet is a tray applet for firewalld. It provides information about the firewalld configuration like the default zone
and also the zone bindings like connections, interfaces and sources.

There is a left and also right mouse button menu and also a tooltip with the active settings when moving the mouse over
the icon.

The applet has been ported over to Qt4 as the StatusIcon support in Gtk3 has been deprecated.

Limitations with Gnome3

Not all options are available in Gnome3. This desktop environment changes the behaviour of the applet externally:

● With enabled notifications, the icon is made invisible after it was sending out a notification. The applet is not
able to detect or change that it is hidden.

● The tooltip is not visible.
● The menus are not always usable or visible.

Zone

A firewall zone defines the trust level for a connection, interface or source
address binding. This is a one to many relation, which means that a
connection, interface or source can only be part of one zone, but a zone can
be used for many network connections, interfaces and sources.

Predefined Zones

These are the zones provided by firewalld sorted according to the default trust level of the zones from untrusted to trusted:

drop
Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

block
Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated within this system are possible.

public
For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected
incoming connections are accepted.

external
For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on
networks to not harm your computer. Only selected incoming connections are accepted.

Predefined Zones

dmz
For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only
selected incoming connections are accepted.

work
For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected
incoming connections are accepted.

home
For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected
incoming connections are accepted.

internal
For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only
selected incoming connections are accepted.

trusted
All network connections are accepted.

Service

A firewalld service can be a list of local ports and destinations and additionally
also a list of firewall helper modules automatically loaded if a service is
enabled. The use of predefined services makes it easier for the user to enable
and disable access to a service.

Example - FTP

<?xml version="1.0" encoding="utf-8"?>
<service>

<short>FTP</short>
<description>FTP is a protocol used for remote file transfer. If you plan to make your FTP server
publicly available, enable this option. You need the vsftpd package installed for this option to be
useful.</description>
<port protocol="tcp" port="21"/>
<module name="nf_conntrack_ftp"/>
</service>

IPSet

An ipset can be used to group several IP or MAC addresses together. An ipset for IP addresses is
either usable for IPv4 or IPv6. This is defined by the family setting of the ipset. It can be either inet
(the default) or inet6.

With the use of ipsets, the number of rules for black or white listing for example is reduced to only a
few rules for a long list of addresses in the ipset. The number of needed rules depends on the use
case.

Example - White list

<?xml version="1.0" encoding="utf-8"?>
<ipset type="hash:net">
<short>white-list</short>
<entry>1.2.3.4</entry>
<entry>1.2.3.5</entry>
<entry>1.2.3.6</entry>

</ipset>

Helper

A firewalld helper defines the configuration that are needed to be able to use a netfilter connection tracking helper if
automatic helper assignment is turned off, which is then the secure use of connection tracking helpers.

This can be achieved wither with the kernel default setting for nf_conntrack_helper, a sysctl setting of
net.netfilter.nf_conntrack_helper or with the AutomaticHelpers setting in the firewalld.conf file.

A firewalld helper can be a list of local ports, a kernel module and a family definition.

Example - FTP

<?xml version="1.0" encoding="utf-8"?>
<helper module="nf_conntrack_ftp">

<port protocol="tcp" port="21"/>
</helper>

ICMP Type

The Internet Control Message Protocol (ICMP) is used to exchange information
and also error messages in the Internet Protocol (IP). ICMP types can be used
in firewalld to limit the exchange of these messages.

Example - echo-request

<?xml version="1.0" encoding="utf-8"?>
<icmptype>

<short>Echo Request (ping)</short>
<description>This message is used to test if a host is reachable mostly with the ping
utility.</description>
</icmptype>

Direct Interface

The direct interface is mainly used by services or applications to add specific firewall rules. It requires basic
knowledge of ip(6)tables concepts (tables, chains, commands, parameters, targets).

It can also be used to add rules to the firewall, that are not supported by firewalld directly, yet. But it advised
to use it carefully and only by advanced users.

Example - Blacklisting of the networks 192.168.1.0/24 and 192.168.5.0/24 with logging and dropping early in
the raw table

<?xml version="1.0" encoding="utf-8"?>
<direct>

<chain ipv="ipv4" table="raw" chain="blacklist"/>
<rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0">-s 192.168.1.0/24 -j blacklist</rule>
<rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1">-s 192.168.5.0/24 -j blacklist</rule>
<rule ipv="ipv4" table="raw" chain="blacklist" priority="0">-m limit --limit 1/min -j LOG
--log-prefix "blacklisted: "</rule>
<rule ipv="ipv4" table="raw" chain="blacklist" priority="1">-j DROP</rule>
</direct>

Two Configuration Directories

Default and Fallback Configuration

The directory /usr/lib/firewalld contains the default and fallback configuration provided by firewalld for icmptypes, services
and zones. The files provided with the firewalld package should not get changed and the changes are gone with an update
of the firewalld package. Additional icmptypes, services and zones can be provided with packages or by creating files.

System Specific Configuration

The system or user configuration stored in /etc/firewalld is either created by the system administrator or by customization
with the configuration interface of firewalld or by hand. The files will overload the default configuration files.

To manually change settings of pre-defined icmptypes, zones or services, copy the file from the default configuration
directory to the corresponding directory in the system configuration directory and change it accordingly.

If there is no /etc/firewalld directory of if it there is no configuration in there, firewalld will start using the default
configuration and default settings for firewalld.conf.

Configuration: Runtime versus Permanent

The configuration is separated into the runtime and the permanent configuration.

Runtime Configuration

The runtime configuration is the actual effective configuration and applied to the firewall in the kernel. At firewalld service
start the permanent configuration becomes the runtime configuration. Changes in the runtime configuration are not
automatically saved to the permanent configuration.

The runtime configuration will be lost with a firewalld service stop. A firewalld reload will replace the runtime configuration
by the permanent configuration. Changed zone bindings will be restored after the reload.

Permanent Configuration

The permanent configuration is stored in configuration files and will be loaded and become new runtime configuration with
every machine boot or service reload/restart.

Runtime to Permanent

The runtime environment can also be used to create a firewall setup that fits the
needs. When it is complete and working it can be migrated with the runtime to
permanent migration. It is available in firewall-config and firewall-cmd.
The firewall-cmd is:
firewall-cmd --runtime-to-permanent

If the firewall setup is not working, a simple firewalld reload/restart will reapply the
working permanent configuration.

firewalld.conf

The firewalld.conf file in /etc/firewalld provides the base configuration for
firewalld. If it is absent or if /etc/firewalld is missing, the firewalld internal
defaults will be used.

The following settings are the default values.

Default Settings

Default Zone - The default zone used if an empty zone string is used. Everything that is not explicitly bound to another

zone will be handled by the default zone.

DefaultZone=public

Minimal Mark - Marks up to this minimum are free for use for example in the direct interface. If more free marks are

needed, increase the minimum.

MinimalMark=100

Clean Up On Exit - If set to no or false the firewall configuration will not get cleaned up on exit or stop of firewalld.

CleanupOnExit=yes

Default Settings

Lockdown - If set to enabled, firewall changes with the D-Bus interface will be limited to applications that are

listed in the lockdown whitelist. The lockdown whitelist file is lockdown-whitelist.xml.

Lockdown=no

IPv6_rpfilter - Performs a reverse path filter test on a packet for IPv6. If a reply to the packet would be sent via

the same interface that the packet arrived on, the packet will match and be accepted, otherwise dropped. The rp_filter
for IPv4 is controlled using sysctl.

IPv6_rpfilter=yes

Individual Calls - Do not use combined -restore calls, but individual calls. This increases the time that is needed

to apply changes and to start the daemon, but is good for debugging.

IndividualCalls=no

Log Denied - Add logging rules right before reject and drop rules in the INPUT, FORWARD and OUTPUT chains for

the default rules and also final reject and drop rules in zones. Possible values are: all, unicast, broadcast, multicast and
off.

LogDenied=off

Enable and Disable firewalld

firewalld provides an init script for systems using classic SysVinit and also a
systemd service file. The following documentation is about the systemd
service used in Ubuntu, Fedora, RHEL and CentOS distributions.

It is not recommended to use iptables directly while firewalld is running as
this could lead into some unexpected issues. If a user for example is removing
base rules or chains of the chain structure, than a firewalld reload might be
needed to create them again.

Get firewalld State - with systemctl and with firewalld-cmd

$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon

Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
pr

Active: active (running) since Wed 2016-06-29 14:28:51 CEST; 1 weeks 6 days
a

Docs: man:firewalld(1)
Main PID: 24540 (firewalld)

Tasks: 2 (limit: 512)
CGroup: /system.slice/firewalld.service

└─24540 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

$ firewall-cmd --state
running

Reload firewalld

With firewall-cmd

To reload firewalld, you can use the command line client firewall-cmd:

firewall-cmd --reload

Reload firewall rules and keep state information. Current permanent configuration will become new runtime configuration,
i.e. all runtime only changes done until reload are lost with reload if they have not been also in permanent configuration.

firewall-cmd --complete-reload

Reload firewall completely, even netfilter kernel modules. This will most likely terminate active connections, because state
information is lost. This option should only be used in case of severe firewall problems. For example if there are state
information problems that no connection can be established with correct firewall rules.

Using a signal

As root you can send the HUP signal to the firewall daemon to initiate reload:

# killall -HUP firewalld

Open a Port or Service

There are different ways to open up a port (range) or service. These ways depend on the use case
and the number of changes that are needed to make it work.

A simple port number or port range can be used in the cases where no additional changes are
needed. For example with opening port 80/tcp to allow access to a local http service on the standard
port. For most of the more important services there is already a service defined in firewalld. Then
there is no need to know about the default port number(s). The service can then simply be enabled
in the used zone.

If there is a need to open different ports or to do additional changes, then using a service might be
simpler. If you need to add a new or custom service, then please have a look at the howto “Add a
Service”. It is also possible to adapt a built-in service according to the needs, for example to change
one of the used ports. But it is recommended to generate a new service in this case to make it more
obvious that the service has been customized.

How to open port 80/tcp with firewall-cmd

firewall-cmd --zone=public --add-port=80/tcp
This will open the port 80 with protocol tcp in the public zone of the runtime environment. The runtime
environment is only effective until the machine has been rebooted or the firewalld service has been
restarted. The zone option can be omitted here if the port should be added to the default zone.

firewall-cmd --permanent --zone=public --add-port=80/tcp
If you want to make this a permanent change also, then open the port also in the permanent environment.
This means the port will be open also after a system reboot or firewalld service reload.

How to open a service with firewall-cmd

firewall-cmd --zone=public --add-service=http
This opens the service in the public zone of the runtime environment.

firewall-cmd --permanent --zone=public --add-service=http
This also opens the service in public zone of the permanent environment.

Lab: configure a Linux box to act as a NAT device

Using IPTABLES and using Firewalld

In a Linux system with two NIC’s (one connected to a LAN, the other connected
to internet) enable the LAN machines to connect to internet through the Linux
box.

We should then enable and configure:

● Input rules
● Forward rules
● Masquerading

Local Security Principles - Learning Objectives

● Have a good grasp of best practices and tools for making Linux systems
as secure as possible.

● Understand the powers and dangers of using the root (superuser)
account.

● Use the sudo command to perform privileged operations while restricting
enhanced powers as much as feasible.

● Explain the importance of process isolation and hardware access.
● Work with passwords, including how to set and change them.
● Describe how to secure the boot process and hardware resources.

User Accounts

The Linux kernel allows properly
authenticated users to access files and
applications. While each user is identified
by a unique integer (the user id or UID), a
separate database associates a username
with each UID. Upon account creation, new
user information is added to the user
database and the user's home directory
must be created and populated with some
essential files. Command line programs
such as useradd and userdel as well as GUI
tools are used for creating and removing
accounts.

User Accounts

For each user, the following seven fields are maintained in the /etc/passwd file:

Types of Accounts

By default, Linux distinguishes between several account types in order to isolate processes and workloads. Linux has three types of
accounts:

● root
● System
● Normal

For a safe working environment, it is advised to grant the minimum privileges possible and necessary to accounts, and remove inactive
accounts. The last utility, which shows the last time each user logged into the system, can be used to help identify potentially inactive
accounts which are candidates for system removal.
Keep in mind that practices you use on multi-user business systems are more strict than practices you can use on personal desktop
systems that only affect the casual user. This is especially true with security. We hope to show you practices applicable to enterprise
servers that you can use on all systems, but understand that you may choose to relax these rules on your own personal system.

Understanding the root Account

root is the most privileged account on a Linux/UNIX system. This
account has the ability to carry out all facets of system
administration, including adding accounts, changing user
passwords, examining log files, installing software, etc. Utmost
care must be taken when using this account. It has no security
restrictions imposed upon it.

When you are signed in as, or acting as root, the shell prompt
displays '#' (if you are using bash and you haven’t customized
the prompt as we discuss elsewhere in this course). This
convention is intended to serve as a warning to you of the
absolute power of this account.

Operations Requiring root Privileges

root privileges are required to perform operations such as:

● Creating, removing and managing user accounts.
● Managing software packages.
● Removing or modifying system files.
● Restarting system services.

Regular account users of Linux distributions may be allowed to install
software packages, update some settings, and apply various kinds of
changes to the system. However, root privilege is required for performing
administration tasks such as restarting services, manually installing
packages and managing parts of the filesystem that are outside the normal
user’s directories.

Operations Not Requiring root Privileges

A regular account user can perform some operations requiring special permissions; however, the system configuration must allow
such abilities to be exercised.

SUID (Set owner User ID upon execution—similar to the Windows "run as" feature) is a special kind of file permission given to a file.
SUID provides temporary permissions to a user to run a program with the permissions of the file owner (which may be root) instead
of the permissions held by the user.

The table provides examples of operations which do not require root privileges:

Comparing sudo and su

In Linux you can use either su or sudo to temporarily grant root access to a normal user; these methods are actually quite different.
Listed below are the differences between the two commands.

sudo Features

sudo has the ability to keep track of unsuccessful attempts at gaining root access. Users' authorization for using sudo is based on
configuration information stored in the /etc/sudoers file and in the /etc/sudoers.d directory.

A message such as the following would appear in a system log file (usually /var/log/secure) when trying to execute sudo bash
without successfully authenticating the user:

authentication failure; logname=op uid=0 euid=0 tty=/dev/pts/6 ruser=op rhost= user=op
conversation failed
auth could not identify password for [op]
op : 1 incorrect password attempt ;
TTY=pts/6 ; PWD=/var/log ; USER=root ; COMMAND=/bin/bash

The sudoers File

Whenever sudo is invoked, a trigger will look at /etc/sudoers and the
files in /etc/sudoers.d to determine if the user has the right to use
sudo and what the scope of their privilege is. Unknown user requests
and requests to do operations not allowed to the user even with sudo
are reported. You can edit the sudoers file by using visudo, which
ensures that only one person is editing the file at a time, has the proper
permissions, and refuses to write out the file and exit if there is an error
in the changes made.
The basic structure of an entry is:
who where = (as_whom) what
The file has a lot of documentation in it about how to customize. Most
Linux distributions now prefer you add a file in the directory
/etc/sudoers.d with a name the same as the user. This file contains
the individual user's sudo configuration, and one should leave the
master configuration file untouched except for changes that affect all
users.

Command Logging

By default, sudo commands and any failures are logged
in /var/log/auth.log under the Debian distribution
family, and in /var/log/messages and/or
/var/log/secure on other systems. This is an
important safeguard to allow for tracking and
accountability of sudo use. A typical entry of the message
contains:

● Calling username
● Terminal info
● Working directory
● User account invoked
● Command with arguments.

Running a command such as sudo whoami results in a log file entry such as:
Dec 8 14:20:47 server1 sudo: op : TTY=pts/6 PWD=/var/log USER=root COMMAND=/usr/bin/whoami

Process Isolation

Linux is considered to be more secure than many other operating systems because processes are naturally isolated from each other.
One process normally cannot access the resources of another process, even when that process is running with the same user
privileges. Linux thus makes it difficult (though certainly not impossible) for viruses and security exploits to access and attack random
resources on a system.

Additional security mechanisms that have been recently introduced in order to make risks even smaller are:

● Control Groups (cgroups): Allows system administrators to group processes and associate finite resources to each
cgroup.

● Linux Containers (LXC): Makes it possible to run multiple isolated Linux systems (containers) on a single system by
relying on cgroups.

● Virtualization: Hardware is emulated in such a way that not only processes can be isolated, but entire systems are run
simultaneously as isolated and insulated guests (virtual machines) on one physical host.

Hardware Device Access

Linux limits user access to non-networking hardware devices in a manner that is extremely similar to regular file access. Applications
interact by engaging the filesystem layer (which is independent of the actual device or hardware the file resides on). This layer will then
open a device special file (often called a device node) under the /dev directory that corresponds to the device being accessed. Each
device special file has standard owner, group and world permission fields. Security is naturally enforced just as it is when standard
files are accessed.

Hard disks, for example, are represented as /dev/sd*. While a root user can read and write to the disk in a raw fashion, for example,
by doing something like:

$ echo hello world > /dev/sda1

the standard permissions as shown in the figure make it impossible for regular users to do so. Writing to a device in this fashion can
easily obliterate the filesystem stored on it in a way that cannot be repaired without great effort, if at all. The normal reading and
writing of files on the hard disk by applications is done at a higher level through the filesystem, and never through direct access to the
device node.

Keeping Current

When security problems in either the Linux kernel or applications and libraries are discovered, Linux distributions have a good record
of reacting quickly and pushing out fixes to all systems by updating their software repositories and sending notifications to update
immediately. The same thing is true with bug fixes and performance improvements that are not security related.

However, it is well known that many systems do not get updated frequently enough and problems which have already been cured are
allowed to remain on computers for a long time; this is particularly true with proprietary operating systems where users are either
uninformed or distrustful of the vendor's patching policy as sometimes updates can cause new problems and break existing
operations. Many of the most successful attack vectors come from exploiting security holes for which fixes are already known but not
universally deployed.

So the best practice is to take advantage of your Linux distribution mechanism for automatic updates and never postpone them. It is
extremely rare that such an update will cause new problems.

How Passwords are Stored

The system verifies authenticity and identity using user credentials. Originally,
encrypted passwords were stored in the /etc/passwd file, which was
readable by everyone. This made it rather easy for passwords to be cracked.
On modern systems, passwords are actually stored in an encrypted format in
a secondary file named /etc/shadow. Only those with root access can
modify/read this file.

Password Algorithm

Protecting passwords has become a crucial element of security. Most Linux distributions rely on a modern password encryption
algorithm called SHA-512 (Secure Hashing Algorithm 512 bits), developed by the U.S. National Security Agency (NSA) to encrypt
passwords.

The SHA-512 algorithm is widely used for security applications and protocols. These security applications and protocols include TLS,
SSL, PHP, SSH, S/MIME and IPSec. SHA-512 is one of the most tested hashing algorithms.

For example, if you wish to experiment with SHA-512 encoding, the word “test” can be encoded using the program sha512sum to
produce the SHA-512 form (see graphic):

Good Password Practices

IT professionals follow several good practices for securing the data and the password of every user.

1. Password aging is a method to ensure that users get prompts that remind them to create a new password after a specific
period. This can ensure that passwords, if cracked, will only be usable for a limited amount of time. This feature is
implemented using chage, which configures the password expiry information for a user.

2. Another method is to force users to set strong passwords using Pluggable Authentication Modules (PAM). PAM can be
configured to automatically verify that a password created or modified using the passwd utility is sufficiently strong. PAM
configuration is implemented using a library called pam_cracklib.so, which can also be replaced by pam_passwdqc.so for
more options.

3. One can also install password cracking programs, such as John The Ripper, to secure the password file and detect weak
password entries. It is recommended that written authorization be obtained before installing such tools on any system
that you do not own.

Lab: Password Aging

Modify the expiration date for an user in your system, setting it to be something that has passed,
and check to see what has changed.
When you are finished and wish to delete the newly created account, use userdel, as in:
$ sudo userdel newuser

Requiring Boot Loader Passwords

You can secure the boot process with a secure password to prevent someone from bypassing the user authentication step. For
systems using the older GRUB boot loader, version 1, you can invoke grub-md5-crypt which will prompt you for a password and then
encrypt.

You then must edit /boot/grub/grub.conf by adding the following line below the timeout entry:

password --md5 $1$74r8m1$NmkE69eAjXre.oF1k0cyk/

You can also force passwords for only certain boot choices rather than all.

However, for the GRUB version 2 (which has taken over almost completely now) things are more complicated. While you have more
flexibility, you can take advantage of more advanced features, such as user-specific passwords (which can be their normal login
password.) Also, you never edit the configuration file, /boot/grub/grub.cfg, directly, rather you edit system configuration files in
/etc/grub.d and then run update-grub, or the equivalent utility on your Linux distribution. One explanation of this can be found at
https://help.ubuntu.com/community/Grub2/Passwords.

Hardware Vulnerability

When hardware is physically accessible, security can be compromised by:
● Key logging: Recording the real time activity of a computer user including the keys they press. The captured data can

either be stored locally or transmitted to remote machines.

● Network sniffing: Capturing and viewing the network packet level data on your network.

● Booting with a live or rescue disk

● Remounting and modifying disk content.

Your IT security policy should start with requirements on how to properly secure physical access to servers and workstations. Physical
access to a system makes it possible for attackers to easily leverage several attack vectors, in a way that makes all operating system
level recommendations irrelevant.
The guidelines of security are:

● Lock down workstations and servers.

● Protect your network links such that it cannot be accessed by people you do not trust.

● Protect your keyboards where passwords are entered to ensure the keyboards cannot be tampered with.

● Ensure a password protects the BIOS in such a way that the system cannot be booted with a live or rescue DVD or USB

key.

For single user computers and those in a home environment some of the above features (like preventing booting from removable
media) can be excessive, and you can avoid implementing them. However, if sensitive information is on your system that requires
careful protection, either it shouldn't be there or it should be better protected by following the above guidelines.

Software Vulnerability

Like all software, hackers occasionally find weaknesses in the Linux
ecosystem. The strength of the Linux (and open source community in general)
is the speed with which such vulnerabilities are exposed and remediated.

Summary

● The root account has authority over the entire system.
● root privileges may be required for tasks, such as restarting services, manually installing packages and managing parts of the

filesystem that are outside your home directory.
● In order to perform any privileged operations such as system-wide changes, you need to use either su or sudo.
● Calls to sudo trigger a lookup in the /etc/sudoers file, or in the /etc/sudoers.d directory, which first validates that the

calling user is allowed to use sudo and that it is being used within permitted scope.
● One of the most powerful features of sudo is its ability to log unsuccessful attempts at gaining root access. By default, sudo

commands and failures are logged in /var/log/auth.log under the Debian family and /var/log/messages in other
distribution families.
● One process cannot access another process’ resources, even when that process is running with the same user privileges.
● Using the user credentials, the system verifies the authenticity and identity.
● The SHA-512 algorithm is typically used to encode passwords. They can be encrypted, but not decrypted.
● Pluggable Authentication Modules (PAM) can be configured to automatically verify that passwords created or modified using
the passwd utility are strong enough (what is considered strong enough can also be configured).
● Your IT security policy should start with requirements on how to properly secure physical access to servers and workstations.
● Keeping your systems updated is an important step in avoiding security attacks.

SSH Tricks

Here's something really powerful.

If you want to setup aliases for servers you access often, you can create an ~/.ssh/config file and specify
each server you log into, along with the authentication method to use:

Host somealias ● HostName - The server host (domain or ipaddress)
HostName example.com ● Port - The port to use when connecting
Port 2222 ● User - The username to log in with
User someuser ● IdentityFile - The SSH key identity to use to log in
IdentityFile ~/.ssh/id_example
IdentitiesOnly yes with, if using SSH key access
● IdentitiesOnly - "Yes" to specify only attempting to
Host anotheralias
HostName 192.168.33.10 log-in via SSH key
User anotheruser ● PubkeyAuthentication - "No" to specify you wish to
PubkeyAuthentication no
bypass attempting SSH key authentication

SSH Tricks

SSH can be used for tunneling, which is essentially port forwarding. There's a
few ways we can do this - Local (Outbound), Remote (Inbound), and some
others (Dynamic and Agent Forwarding).

Local Port Forwarding

Local port forwarding is what you use when you need to tunnel through a server's firewall or other limitation.

A common example is attempting to connect to a remote database which is either behind a firewall or is only
listening to local connection. For example, MySQL only listens to localhost connections by default. You can't
remotely connect to it without editing the my.cnf file and have it listen on all networks. There's also a firewall
preventing you connecting to MySQL's port 3306 anyway.

Assuming we have SSH access to the remote server, we can get around this by creating a tunnel into the

server. What might that look like?

ssh -L 3306:localhost:3306 username@hostname ● -L - Setup local port forwarding
● 3306 - The local port to forward
● localhost:3306 - Within the remote server, what address

and port to forward traffic to. Since the MySQL server is on
the remote server, we're tunneling to the remote server's

"localhost" on port 3306, which MySQL is listening to.
● username@localhost - The SSH username and host to

connect to

Remote Port Forwarding

To access port 8001 on our system from a remote server:

ssh -R 9000:localhost:8001 username@hostname

Let's go over this command:

● -R - Using remote port forwarding
● 9000 - The remote server's port to use (not our local server this time!)
● localhost:8001 - The local address to forward to. Since our web server is on localhost port 8001,

that's what we specify here. (Yep, the order of those arguments changed for -R over -L!)
● username@hostname - SSH access to the remote server

One-Off Commands

You can run commands remotely using SSH. You're actually running the command on the remote server but
any resulting output will be displayed in your terminal.

The following will run pwd command. Then we'll run the ls command to see the directory's output:

# Run `pwd` command
$ ssh -p 2222 username@hostname pwd
/home/username

# Run `ls -la` command

$ ssh -p 2222 username@hostname ls -la

drwxr-xr-x 8 username username 4096 Jun 30 17:49 .

drwxr-xr-x 4 root root 4096 Apr 28 2013 ..

-rw------- 1 username username 18589 Jun 30 17:49 .bash_history

-rw-r--r-- 1 username username 220 Apr 28 2013 .bash_logout

-rw-r--r-- 1 username username 3486 Apr 28 2013 .bashrc

-rw-r--r-- 1 username username 675 Apr 28 2013 .profile

drwxrwxr-x 2 username username 4096 Mar 15 14:21 .ssh