Revision date: May 29, 2023
TOC
Network Utilities
********************************************************************************
- Network Utilities -
********************************************************************************
This section describes some basic utilities available for use over a network.
To transfer files over the network:
$ ftp hostname
To perform an automatic file transfer
$ ftp -i -n hostname < scriptfile
where the file "scriptfile" contains
user user_name pass_word
[ftp commands such as cd, get, put, etc...]
quit
This will automate the transfer procedure.
Secure transfer can be accomplished via
$ sftp hostname
The host key used to verify the authenticity of a given host is stored in a
one of the files: ~/.ssh/known_hosts, /etc/ssh/ssh_known_hosts
A more efficient way to transfer files over the network (and even locally)
is rsync.
e.g.
$ rsync -av -e "ssh" programming mediauser@10.0.0.2:/home/mediauser
In this example rsync will copy the directory programming to /home/mediuser
on mediauser@10.0.0.2 using ssh (default).
the "a" option is for archive, which is needed if a directory is being
transferred.
For more about rsync see section rsync.
When using X-Windows it is possible for one machine to act as a graphical
terminal to another. In X-Windows the graphical terminal is called an xhost.
To become an xhost:
On the local (graphical) terminal type: xhost +
This gives the machine permission to be an xhost to any other machine
On the local terminal type: telnet <destination_machine>
Now you should be connected to the remote machine
Type: setenv DISPLAY <local_machine>:0.0
It is now possible to launch graphical programs that will run on the remote
machine, but will be rendered on the local machine.
A basic utility that has been around since the early days of UNIX used to
communicate with another person via the keyboard is "talk".
Usage:
$ talk user@host terminal
e.g.
$ talk jon@dilbert.eedsp.gatech.edu ttyp1
In order to identify the terminal name of the remote
person use the command
$ finger user@host
Terminal name is usually designated by "ttyXX" where XX is some letter-number
combination.
You can also look up your own terminal name by typing "tty".
The person on other side must respond to your talk request inorder for
a connection to be established. Messages should appear on the users
machine telling him/her what to do.
For example it will say:
"respond to XY by typing: talk jake@simpson.eedsp.gatech.edu"
Note 1: There are two incompatible version of talk, which will not connect
to each other.
Note 2: There is an option to enable and disable talk using the pine
program. simply go into setup and scroll down till reaching
the talk option.
Using ssh to run X-Windows based graphical programs from a remote host on a
local workstation.
Login to the remote host:
$ ssh -Y username@server_ip_address
Verify display is correct:
$ echo $DISPLAY
will print something like "localhost:10.0"
Run program from shell
$ xfig &
(should display application window on the local workstation)
To scan network
$ nmap -sn netid/netmask
e.g.
$ nmap -sn 192.168.0.0/24
The -sn option disables a port scan, and performs host discovery through ping.
nmap without arguments provides usage and options list
To scan for a specific port (e.g. port 445 used by the SMB protocol)
$ nmap -p 445 myexample.com
To suppress host discovery add -Pn option
$ nmap -Pn -p 445 myexample.com
For a full description of the command and its options refer to the manpage
$ man nmap
Modem tools
mgetty, sendfax
uucico
See Modems section in uniman for more about modems.
----------------------------
| Advanced Network Utilities |
----------------------------
* netstat - A tool for investigating network traffic and statistics.
* ss - A utility to investigate network traffic on sockets. Similiar to
netstat, but with more of a focus on connection oriented TCP traffic.
Remote Access
********************************************************************************
- Remote Access via ssh -
********************************************************************************
There are many utilities, both textual based or graphical, through which you can
gain access to another computer remotely.
Common examples of text based access are ftp (insecure), sftp (secure),
telent (insecure), ssh (secure).
ssh in combination with X-Windows can be used to gain access to graphical
applications.
The TCP/UDP ports that need to remain open are:
* ftp: port 21
* sftp: port 115
* telnet: port 23
* ssh: port 22
---------------
| An ssh Server |
---------------
In order to access a computer via one of the above utilities, a server
supporting the protocol (usually a daemon running in the background) must be
installed and running on the host.
Note: to use ssh, sftp or have a server run on a machine make sure to install
"openssh" package.
This will take care of both ssh and sftp
To start/stop the sshd (ssh-server) enter:
$ systemctl start sshd.service
$ systemctl stop sshd.service
To enable it (so it starts up at boot time) enter:
$ systemctl enable sshd.service
The configuration file for the sshd is /etc/ssh/sshd_config.
Normally sshd listens in on port 22, although you can add ports on which to
listen via the configuration file.
For example, to have sshd listen in on port 20020 add a line
Port 20020
If SELinux is active on your system, it will need to be configured to allow
that port to be used. This can be done using the semanage utility.
$ semanage port -a -t ssh_port_t -p tcp 20020
For more about ssh, port tunneling, tips and more, refer to the Archlinux Wiki:
Secure Shell
---------
| General |
---------
If a problem occurs whereby a host's public-key changes, then delete the hosts
reference in .ssh/known_hosts.
To use your computer as an X-Windows terminal enable X11 forwarding as such
$ ssh -X user@host
or
$ ssh -Y user@host
The -Y switch disables the security mechanism for X11 forwarding.
Use only if encountering problems with -X.
-----------
| Tunneling |
-----------
Tunneling is a mechanism by which you use a port designated for one
kind of service (e.g. web browsing) for use with another kind of
service (e.g. remote access).
This may come up for example when your company's policy is to allow network
traffic only through ports 80 (http) and 443 (https). In other words they
only allow you to communicate with the outside world through web type
interfaces.
Now, suppose you would like to access your computer at work from home.
This could be accomplished via tunneling.
The basic idea is to establish an ssh connection with your computer at home
on ports 80 or 443. Although normally reserved for web traffic, you can invoke
the ssh command with option to tunnel the remote connection session data
through one of these ports. This allows you to bypass your company's policy.
Of course this should only be done for legitimate purposes and with company
approval.
Tunneling is also the basis for VPN software (see here for more).
There are other uses for tunnelling as well.
For more refer to the Archlinux Wiki Secure Shell
----------------
| Authentication |
----------------
Usually, when attempting to access a remote account, you will be prompted to
enter a password. This is known as password authentication.
A different type of authentication offered by ssh is public key authentication.
The idea is to prove to the remote system that you own the private key
associated with the public key that is stored on that remote machine. Of course
this has to be done without divulging your private key, as private keys are not
meant to be known by anyone but yourself.
The first step in establishing public key authentication is to verify that the
remote system has public key authentication enabled.
On the remote system, edit the file /etc/ssh/sshd_config and search for
"PubkeyAuthentication".
The line entry should read
PubkeyAuthentication yes
If commented, uncomment by removing the # symbol.
Note, to disable public key authentication replace "yes" with "no".
Restart the ssh daemon
$ sudo systemctl restart sshd
The next step is to generate a public-private key pair.
This is to be done on the local system (or client).
SSH supports a few public key algorithms for authentication.
Probably the most prominent is RSA, which is based on the difficulty of
factoring large numbers. However, newer algorithms which are harder to crack
are available. I'll stick with RSA for this explanation.
Before proceeding, check to see if you already have a key pair.
The directory in which keys are stored by default is ~/.ssh
$ ls ~/.ssh
id_rsa
id_rsa.pub
The two files, id_rsa and id_rsa.pub, are likely a previously created private
key and public key, respectively. The "rsa" in the name correspond to the RSA
algorithm.
Open the file id_rsa, or display its first line.
$ head -n 1 id_rsa
If the first line reads "-----BEGIN OPENSSH PRIVATE KEY-----" then that's your
private key (don't share it).
Note, the .ssh directory should have its permissions set to "drwx------" (700).
That is, only the user (and root) should be able to see or access this
directory. Similarly, only the user (and root) should be able to see or access
the private key, and, therefore, its permissions should be "-rw-------" (600).
This directory and files should also be owned by the user.
$ ls -ld /home/jdoe/.ssh
drwx------. 2 jdoe jdoe 4096 Apr 26 .ssh
$ ls -l /home/jdoe/.ssh
-rw-------. 1 jdoe jdoe 1675 Apr 26 id_rsa
-rw-r--r--. 1 jdoe jdoe 402 Apr 26 id_rsa.pub
On the server side, ownership and permissions are important as well
$ ls -ld /home/yule/.ssh
drwx------. 2 yule yule 4096 Apr 26 /home/yule/.ssh/
$ -l /home/yule/.ssh
-rw-------. 1 yule yule 402 Apr 26 authorized_keys
I found that strict permissions and ownership need to apply to the home
directory on the server side as well.
$ ls -ld /home/yule
drwx------. 2 yule yule 4096 Mar 13 /home/yule/
To use this key pair to login to a remote account you'll have to provide the
remote account with your public key.
Public keys are stored in the file ~/.ssh/authorized_keys.
The process of providing the remote host with your public key can be facilitated
with the command ssh-copy-id. Simply issue
$ ssh-copy-id user@remotehost
For example
$ ssh-copy-id jdoe@10.0.50.225
If everything goes well, your public key will be added to the aforementioned
file on the remote system.
If you have more than one key, and/or you wish to copy over a specific key, use
the -i option. For example
$ ssh-copy-id -i mykeyname jdoe@10.0.50.225
For more about this command refer to the man page
$ man ssh-copy-id
If this command is not available to you, manually append your key entry into
the authorized_keys file on the remote system (you'll first have to login to
the remote account in the traditional way. i.e. with a password).
If you don't already have a key pair, or you wish to use a different key pair,
you'll need to generate one. This is done using the command ssh-keygen.
$ ssh-keygen
Without arguments the command will prompt for a location to store the keys.
Enter file in which to save the key (/home/jdoe/.ssh/id_rsa):
Press enter to use the suggested name, or provide some other name by entering
something like .ssh/mynewkey
The latter should generate two files in .ssh:
mynewkey
mynewkey.pub
The ssh-keygen command should have set the permissions correctly, so normally
no further action is required with respect to permissions.
To provide the remote account with your new public key, employ the procedure
described above.
To login to the remote account using your new key, issue
$ ssh -i ~/.ssh/mynewkey jdoe@10.0.50.225
(replace mynewkey with the name you gave your key, and jdoe@10.0.50.225 with
the appropriate destination).
If your key name is ~/.ssh/id_rsa then there is no need to specify the key name
via the -i option
$ ssh jdoe@10.0.50.225
If everything was done correctly, you will be logged in without having to enter
a password.
Sources:
* Key generation
* How to use ssh public key authentication
* Enabling and disabling public key authentication
Network Scripts
********************************************************************************
- Network Scripts -
********************************************************************************
This section describes some of the scripts and daemons that manage networking on
a Linux OS.
---------
| I. SYSV |
---------
In a Linux OS using System V (SYSV) style scripts, the network is configured
through a number of scripts that are launched at boot time.
Although systemd has mostly replaced SYSV runlevels and scripts, some SYSV
Linux holdouts such as debian, ubuntu and their derivates still employ network
scripts and run levels to configure networking and launch network daemons.
Some of the configuration scripts for a SYSV setup:
/etc/sysconfig/network - General network configuration file
Specifies whether the network will be used and the hostname.
This is used by system-config-network tool and should not be edited by hand.
/etc/sysconfig/network-scripts/ifcfg-lo - Configuration info for local loopback
USERCTL specifies whether an ordinary user may activate or deactivate network
/etc/sysconfig/network-scripts/ifcfg-eth0 - Configuration info for first
ethernet device.
Other interfaces will have their own files (e.g. ifcfg-eth1).
Can edit this file to set a persistent static IP address that will endure
across boots, and more.
Low level network scripts (SYSV)
/etc/sysconfig/network-scripts/ifdown eth0 - Brings up network device eth0
/etc/sysconfig/network-scripts/ifup eth0 - Brings down network device eth0
(Note: substitute eth0 for your device; You may specify only one device at
a time)
Higher level network scripts (SYSV)
/etc/init.d/network - General networking script that determines which devices
to activate and whether the core utilities necessary to do so are available.
This script employs the configuration information and scripts in
/etc/sysconfig to activate or deactivate the network.
It should not be used together with NetworkManager or some other network
manager software, as they may conflict. However, if by mistake this happens,
no permanent harm should come of it.
/etc/init.d/NetworkManager - Starts and stops the network manager daemon.
The daemon automatically switches identifies available network connections
and switches between them to attain the best network functionality. The
scripts merely configures and launches the daemon called "NetworkManager"
and terminates it on deactivation.
This service may be started via command line:
$ service NetworkManager start
-------------
| II. systemd |
-------------
In a Linux OS using systemd, networking functionality is initialized with
services that are launched by the system (mainly during the boot process).
Systemctl can be used to launch, terminate, restart and obtain status information
for various network functionality during runtime.
Some important systemd services:
netplugd - A network daemon that detects changes in network status, for instance
an ethernet cable that became unplugged, or a wireless network that appeared.
The service launches the daemon which acts upon the change that took place
in an appropriate manner.
NetworkManager - Launches the NetworkManager dameon (described above).
It should be run together with netplugd. It is a highly automated
networking service. It is easiest to control and tweak with window and
session managers such as gnome, kde, lxde, etc. using applets.
There are NetworkManager command line tools such as nm-tool, or gui like
tools such as nm-connection that may be may be invoked from the command line
of a terminal, and thus usable with non-applet window managers such as twm,
fvwm.
network - Launches the network service. This is a less automated networking
administration service than NetworkManager. It is, however, more suitable
with non-applet window managers such as twm, fvwm.
The main service is "systemd-networkd.service".
If having networking issues, first try:
$ systemctl restart systemd-networkd.service
Note: Do not configure the OS to start up both the NetworkManager service
and network service together.
Use "systemctl --type=service" to see what services are running.
Note: In the past, these services used to be executed at different run levels
(SYSV). Run levels are obsolete in newer versions of Linux distributions
employing systemd, although systemd will still recognize and handle SYSV
type scripts.
A useful directory is /etc/systemd.
It contains various files pertaining to services, some of them network
services.
-----------------
| Further reading |
-----------------
For a discussion about the differences between the various tools available for
network configuration, refer to:
What is the difference between Network Manager and 'ifconfig' 'ifup', etc?
For a tutorial in porting to command line network management utilities rather
than the more gui oriented network manager, refer to:
Switch from Network Manager
Basic Network Administration
********************************************************************************
- Basic Network Administration -
********************************************************************************
This section describes some basic network administration and tools and how to
use them.
----------
| ifconfig |
----------
ifconfig is used to set network interfaces or get status on currently enabled
network interfaces (e.g. IP address, MAC address of ethernet card, etc.)
When invoked without arguments it provides information about the network:
* lo entry describes local looback connection (present even whithout a
network connection)
* ethX entry displays info about ethernet card number X
* WiFi entries will be listed for wireless devices.
Note: ifconfig is mostly obsolete in many Linux systems and has been replaced
with the command ip (see below).
Note: In MS-Windows the command ipconfig has similar functionality to the
ifconfig command.
-----
| PPP |
-----
PPP (point-to-point protocol) is a data link protocol most commonly used for
establishing a connection between two computers over a serial cable or phone
line. When accessing the internet via a standard voice line modem, PPP is
used to establish the connection. One the connection is established, TCP/IP
protocols can be operated on top of it.
Note: DSL (ADSL, VDSL) modems use PPPoE (PPP over Ethernet.
For more about PPPoE see the Debian Wiki PPPoE
To activate PPP directly:
$ /usr/sbin/pppd /dev/modem
Note: For a user to run pppd, pppd must be set so that users that use it
have system privileges.
$ sudo chmod u+s /usr/sbin/pppd
Note that the proper configuration files in the ppp configuration directory
must be present - /etc/ppp/options.
Also, when using it for internet service, place the nameservers in
/etc/resolv.conf
Additionally user name should be listed in file /etc/kppp.allow
or /etc/pam.d/kppp to be allowed to use kppp.
A program with a user friendly interface to ppp is "kppp".
Manipulating the system ARP cache (IP to MAC # mapping)
arp -a [hostname] Displays cache for given hosts [or all hosts in cache]
Useful for getting an ethernet's card MAC #.
Xinetd (SYSV):
In Linux Redhat 7.1 the xinetd daemon controls most network processes
including telnet and ftp.
This is the network daemon that launches various network functions as
they are needed. For intance if a request for telnet comes in
xinetd will launch the telnet server process to accept the incoming
telnet session.
The network functions that are available can be enabled or disabled by
editing the appropriate config file in the /etc/xinetd.d directory.
The line containing "disable = yes" should be modified to "disable = no"
if one wishes to enable that process.
If changes are made, they can be put into effect by rebooting, or as follows:
/etc/rc.d/init.d/xinetd stop
/etc/rc.d/init.d/xinetd start
Alternatively, can use:
service xinetd restart
Note: xinetd has been superceded by network
(Note: As Fedora no longer uses SYSV style scripts, but rather systemd,
the following is obsolete)
Network on Fedora (SYSV):
In Fedora distributions the "network" script and programs it calls
manage networking. To stop or start or restart
$ /etc/rc.d/init.d/network stop|start|restart
In ubuntu the same is accomplished with network manager:
$ /etc/rc.d/init.d/network-manager stop|start|restart
Telnet and FTP Services:
Open the telnet and wu-ftpd files. Edit the line containing
"disable = yes" to "disable = no".
Either restart the computer or as do as mentioned above in Xinetd section.
TCP/IP
********************************************************************************
- TCP/IP -
********************************************************************************
The Internet protocol suite, often referred to as TCP/IP, comprises a set of
communication protocols together with a five layer conceptual model.
...
This section to be completed in future.
Ports
********************************************************************************
- Ports -
********************************************************************************
TCP (Transport Control Protocol) and UDP (User Datagram Protocol) of the TCP/IP
suite both use port numbers to ...
An IP packet containing a TCP ...
Commonly used ports:
ftp-21 (file transfer protocol, non-encrypted)
ssh-22 (secure shell, encrypted)
telnet-23 (like ssh, but not encrypted)
smtp-25 (simple mail transfer protocol, unencrypted)
http-80 (hypertext transfer protocol, unencrypted)
pop2-109 (post office protocl version 2)
pop3-110 (post office protocl version 3)
sftp-115 (secure file transfer protocol, encrypted)
imap-143 (internet messagae access protocol, nonencrypted)
impa3-220 (internet messagae access protocol 3, nonencrypted?)
https-443 (like http encrypted)
imaps-993 (internet messagae access protocol, encrypted)
smb-445 (smb, samba, cifs)
pop3s-995 (post office protocl version 3 over secure sockets - encrypted)
For more, refer to www.centos.org
To see which ports are open on your machine, use one the following commands
$ netstat
$ lsof
To test if a particular port is open on a remote machine, use the telnet
command. For example to test if port 25 is open on server mysrv.com
$ telnet mysrv.com 25
See also here.
ip command
********************************************************************************
- ip command -
********************************************************************************
The ip is used to show and manipulate network devices, interfaces,
routing, policy routing and tunnels.
ip is part the iproute2-bundle, and is used to configure hardware conforming
to the IEEE 802.3 (wired ethernet protocols) and IEEE 802.11 (wireless lan
protocols).
It is useful for setting up and manipulating network configurations.
However, for more dynamic capabilities (automatic identification and
network establishment), see sections on NetworkManager and netctl below.
The general invocation of ip is
$ ip [ OPTIONS ] OBJECT { COMMAND | help }
A second way to invoke ip is using a batch file
$ ip [ -force ] -batch filename
The first argument of ip is called the OBJECT, which basically states what you
want to do with ip.
$ ip link ...
$ ip address ...
$ ip addrlabel ...
$ ip route ...
$ ip neigh ...
$ ip ntable ...
$ ip tunnel ...
$ ip tuntap ...
$ ip maddress ...
$ ip mroute ...
$ ip mrule ...
$ ip monitor ...
$ ip xfrm ...
$ ip netns ...
$ ip l2tp ...
$ ip fou ...
$ ip macsec ...
$ ip tcp_metrics ...
$ ip token ...
$ ip netconf ...
$ ip ila ...
The man page for ip is object specific. For example:
To obtain general information about ip, issue
$ man ip
To obtain detailed information about ip link command
$ man ip link
In general
$ man ip object
Where object is one of the valid objects listed above
To get help for a given OBJECT
$ ip OBJECT help
Some useful invocations of ip --
$ ip address # display IP address of network interfaces # similar to ifconfig
$ ip address add 10.0.0.1/24 dev eth0 # add 10.0.0.1 address to eth0 interface
$ ip link show # shows configured links and running status
$ ip link address # shows configured links, running status, and ip addresses
$ ip link set net1 up # activates network associated with device interface "net1"
$ ip link delete enp0s # deletes device "enp0s" from available interfaces
To add an address to an interface
$ ip address add [save] 10.0.1.100 dev eth1 # gives eth1 interface address 10.0.1.100
(note, an interface can have more than one IP address)
To check routing tables
$ ip route show
To add a route
$ ip route add 10.0.0.0/24 via 192.168.50.138 dev eth0
To delete a route
$ ip route del 10.0.0.0/24
For information on the TCP protocol see man page on tcp.
netfilter Project and netfilter Hooks
********************************************************************************
- netfilter Project and netfilter Hooks -
********************************************************************************
The netfilter project provides packet filtering software for Linux kernel
version 2.4.X and later.
It is thus the foundation of much of the firewall software in Linux, such as
iptables, nftables, firewalld and ufw.
It provides
* various packet filtering capabilities,
* network address/port translation (NAT/NPT),
* packet logging,
* userspace packet queueing, and
* packet altering capabilities (mangling).
As packets traverse a Linux box, they are routed and modified by netfilter
software operating within the Linux kernel. The firewall administrator,
however, doesn't deal directly with netfilter, but rather configures
firewall rules through user-space firewall frontends (e.g. firewalld, ufw)
and/or backends (i.e. iptables, nftables).
In general, higher level firewall functionality is configured via a frontend
utility. For example allowing samba services in zone X, or disabling ICMP
traffic (e.g. ping requests) on interface eht0 are easily configured with the
firewall-config, firewall-cmd, or ufw command line utilities.
The frontend software implements this functionality by calling on backend
utilities, such as iptables or nftables. Often an administrator will implement
a firewall directly with iptables or nftables, but this requires extensive
knowledge of firewall rules and correct syntax (simple examples will be given
in subsequent sections).
As an IP packet enters and traverses a Linux box, it is examined and routed at
different points, and filtered and processed at different hooks.
A hook is netfilter's terminology for a specific stage of the packet as it's
processed by the kernel.
Decisions as how to route a packet through the netfilter structure are usually
made by reading the header. For example, an IP packet destined for an IP
address outside the box will be directed through the forward hook in the IP
layer.
As a packet encounters a hook, it may be allowed to travel on, be dropped,
rejected with an ICMP message, or mangled (altered).
Besides IP traffic, netfilter processes ARP packets as well.
ARP is the protocol responsible for resolving hardware addresses.
There are four families of hooks. They are listed here with their
corresponding hooks:
1. netdev (network device)
Hooks: Ingress, Egress
(introduced in later versions of the Linux kernel, and allow very early and
late processing of packets, respectively)
2. Inet, Ip, Ipv6 (IP layer hooks)
Hooks: Prerouting, Forward, Postrouting, Input, Output
3. bridge (Link layer network traffic)
Hooks: Prerouting Bridge, Forward Bridge, Postrouting Bridge, Input Bridge,
Output Bridge
4. arp
Hooks: Input, Output
The most common network traffic a firewall administrator will be concerned with
is IP traffic.
* As IP packets enter the IP layer they are processed at the Prerouting Hook.
* A routing decision is then made:
* If it's a packet destined locally (as discerned by the destination address)
it will routed to the Input Hook.
From the Input Hook it is routed to the Application Layer and processed by
the relevant application (e.g. sshd, SMB client, etc.)
The application may then route it back to the IP layer, in which case it
will encounter the Output Hook.
* If destined elsewhere it is routed to the Forward Hook and from there to
the Postrouting Hook.
At that point it may exit the box, or may be sent to the bridge layer.
The network layers through which network packets may be routed are:
ARP layer, Bridge layer, IP layer and Application layer.
For an illustrative diagram of the netfilter architecture, and flow schematic
refer to this webpage.
Rule construction in the firewall backend utilities is strongly tied to the
netfilter architecture. Where there is a netfilter hook (where selection and
filtering takes place) there is a corresponding "chain" in the backend
utilities. For example, the FORWARD chain in iptables corresponds to the
forward hook in netfilter.
Read on about iptables and netfilter to see how the netfilter framework is
configured by these backend utilities.
For detailed information on the netfilter project refer to the
netfilter project homepage.
iptables - User space utilities to manipulate Linux' netfilter framework
********************************************************************************
- iptables - User space utilities to manipulate Linux' netfilter framework -
********************************************************************************
iptables is a user space utility to configure the Linux kernel's network
filtering mechanism (netfilter).
Iptables can be used to set up firewall rules, configure the box as a router,
and handle any network traffic management task.
Iptables is actually one utility in a suite of user-space utilities usually
referred to as xtables that interface with netfilter:
* iptables
* ip6tables
* ebtables
* arptables
* ipset
For a good description and tutorial on iptables and NAT by Rusty Russel,
refer to Packet Filtering HOWTO and NAT HOWTO
Note, the iptables, ip6tables, arptables, ebtables and ipset utilities have
been superceded by nftables. See section on nftables for more about it.
--- Quote from Wikipedia article on netfilter ---
The kernel modules named ip_tables, ip6_tables, arp_tables (the underscore is
part of the name), and ebtables are some of the significant parts of the
Netfilter hook system. They provide a table-based system for defining firewall
rules that can filter or transform packets. The tables can be administered
through the user-space tools iptables, ip6tables, arptables, and ebtables.
Notice that although both the kernel modules and userspace utilities have
similar names, each of them is a different entity with different functionality.
Each table is actually its own hook, and each table was introduced to serve a
specific purpose. As far as Netfilter is concerned, it runs a particular table
in a specific order with respect to other tables. Any table can call itself and
it also can execute its own rules, which enables possibilities for additional
processing and iteration.
Rules are organized into chains, or in other words, "chains of rules". These
chains are named with predefined titles, including INPUT, OUTPUT and FORWARD.
These chain titles help describe the origin of the Netfilter stack. Packet
reception, for example, falls into PREROUTING, while the INPUT represents
locally delivered data, and forwarded traffic falls into the FORWARD chain.
Locally generated output passes through the OUTPUT chain, and packets to be
sent out are in the POSTROUTING chain. Netfilter modules not organized into
tables (see below) are capable of checking for the origin to select their mode
of operation.
--- End of quote from Wikipedia ---
Note: most commands in this section need to be run as root. Use sudo or login
as root to invoke the commands.
Note, iptables service daemon is now depricated. You may use iptables without
it. For legacy systems to use iptables you must first activate/enable the
iptables.service.
To check if active
$ systemctl status iptables.service
If not, then start the iptables service, as well as enable its loading on boot.
$ systemctl start iptables.service
$ systemctl enable iptables.service # To automatically start on boot
The file /etc/iptables/iptables.rules is a file containing all the rules
that are to be loaded when the service is launched.
To test a desired functionality (e.g. NAT configuration, firewall) it is
advised to start by manually inserting iptable rules using the command
"iptables".
When all is done and working, invoke
$ iptables-save
This will output into standard output the rules as they would
appear in iptables.rules
To save to the rules file, redirect the output as such
$ iptables-save > /etc/iptables/iptables.rules
Before playing around with iptables it is a good idea to backup the original
iptables.rules file.
You can also output rules for a specific table. For instance
$ iptables-save -t nat
Note: If a firewall service is active, then most likely the iptables.rules
file is being ignored, and the firewall is configuring its own rules.
To apply the rules you can invoke
$ iptables-restore < your_rules_file.rules
To flush the rules of a given table (for example nat)
$ iptables -t nat --flush
--------------------
| iptables structure |
--------------------
In order to set up rules it is necessary to be familiar with a few concepts
and terms.
There are five iptables "filter", "nat", "mangle", "raw" and "security".
What happens to a packet depends on what rules are present in each of the
tables. Which table is consulted depends on the packet traversing the system.
See here for a basic description of how packets are handled.
To invoke a rule for a specific table (default is "filter"), issue the command
$ iptables -t table ...
where table is one of the above, and fill in for the desired command.
A table contains a set of "chains". Chains are a essentially a sequence of
iptables rule commands that are invoked in the given order. As mentioned
before, which chain is invoked depends on the packet, where it came from and
where it's going. The Kernel decides to which chain to hand over the packet.
You, the user, get to specify (using iptables) what to do with the packet in
a given chain by populating it with rules.
The built-in chains are: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
(See man page and Wikipedia article on iptables)
* PREROUTING - for altering packets before they come in.
Packets will enter this chain before a routing decision is made
* INPUT - for altering packets destined to a local socket (this box)
Packet is going to be delivered locally.
It does not have anything to do with processes having an opened socket;
local delivery is controlled by the "local-delivery" routing table:
$ ip route show table local
* FORWARD - for packets being routed through the box.
All packets that have been routed and were not for local delivery will
traverse this chain of rules.
* OUTPUT - for locally generated packets
The rules in this chain will be applied to packets sent from the machine
itself.
* POSTROUTING - for altering packets as they are about to go out
Routing decision has been made. Packets enter this chain just before
handing them off to the hardware.
(e.g. translating destination address)
Note: a user can define new chains
Each chain consists of a set of rules.
To inspect the set of rules for a given chain, issue the command
$ iptables -L chain
For example, to inspect the INPUT chain
$ iptables -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
---
To print the rules for a given chain using the rule syntax
$ iptables -S chain
Two of the most used iptables are "filter" and "nat".
* filter - this table is consulted by default
It contains built-in chains INPUT, FORWARD, OUTPUT
* nat - consulted when a new connection is encountered
It contains built-in chains PREROUTING, INPUT, OUTPUT
To inspect nat chains statistics
$ iptables -t nat -L -v -n
Whereby
-L = list
-v = verbose, i.e. include counters and more
-n = use IP numbers instead of doing a DNS reverse lookup for IP addresses
included in the rules
---------------------
| Building an iptable |
---------------------
By default, none of the chains contain any rules. It is up to you to append
rules to the chains that you want to use. Chains do have a default policy,
which is generally set to ACCEPT, but can be reset to DROP, if you want to be
sure that nothing slips through your ruleset. The default policy always applies
at the end of a chain only. Hence, the packet has to pass through all existing
rules in the chain before the default policy is applied" (Archwiki).
Thus, to personalize a given table (filter, nat, etc.) your job is to append
rules to the chains for the specific table you wish to affect.
First thing to do is to turn off any firewall service running in background,
otherwise it will populate the iptables with its own rules.
$ systemctl stop firewalld.service
Since you will be making changes, you might want to save existing rules into a
file, so that if something goes wrong you can reinstate the original rules.
Saving the current configuration is simple:
$ sudo iptables-save > iptables-rules.orig
If something went wrong, you can subsequently restore from this file as such:
$ sudo iptables-restore iptables-rules.orig
Check to see if there are any rules in your tables
$ sudo iptables -t filter -L
$ sudo iptables -t nat -L
(mangle, raw and security tables are unlikely to have any rules in them)
Create a file of empty rules.
$ sudo vim /etc/empty.rules
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
Now apply these rules to your system (first stop firewalld.service if active)
$ sudo iptables-restore /etc/empty.rules
Check if the above rules have been applied:
$ sudo iptables-save
Note: This doesn't save anything. It only spits out to standard output the
rules currently in the system as they would appear in a rules file.
Try adding the following rule:
$ iptables -t nat -A PREROUTING
To see if the rule has been added, once again invoke
$ sudo iptables-save
and look for it in the output.
----------------
| Useful options |
----------------
A rule without options will be applied to any packet.
To fine tune which packets are affected you can apply various options.
-i (--in-interface) e.g. -i eth0
-o (--out-interface) e.g. -o eth1
-s (--source) e.g. -s 192.168.1.1; -s www.google.com; -s 10.0.0.0/24
(The last specifies the network 10.0.0.* i.e. network ID 10.0.0)
-d (--destination) e.g. -d 192.168.10.13
Further refinement of packet matching
-p (--protocol) e.g. -p TCP; -p UDP
--source-port (--sport) e.g. -p TCP --sport 80
--desintation-port (--dport)
Note, you can also use port names instead of numbers. See the file
/etc/services.
--------------------
| Filtering examples |
--------------------
Add rules to block all http and https packets destined to 10.0.2.1
through interface eth0.
$ iptables -A INPUT -s 10.0.2.1/32 -p tcp -m tcp --sport 80 -j DROP
$ iptables -A INPUT -s 10.0.2.1/32 -p tcp -m tcp --sport 443 -j DROP
If you subsequently wish to remove these rules invoke iptables with the -D
option. For example to remove the first rule above:
$ iptables -D INPUT -s 10.0.2.1/32 -p tcp -m tcp --sport 80 -j DROP
------------------
| Implementing NAT |
------------------
For background on NAT see Wikipedia article NAT
There are two kinds of NAT (see man page for iptables-extensions;
search for SNAT, DNAT, MASQUERADE for more details.)
Rusty Russel (in the NAT HOWTO)
divides NAT into two kinds. This is basically how he describes NAT:
* Source NAT = SNAT
Refers to altering the source address of the first outgoing packet, that is
making the packet appear as it came from a different address than it
actually did. This is always done post-routing.
Masquerading is a special case of SNAT (used with dynamically assigned IP
connections, as with dialup, and typically the case with home network
setups.)
This is what the gateway router attached to your private LAN does when
sending packets to the internet. The computers on your LAN have
non-internet legal addresses such as 10.0.0.3.
SNAT substitutes the address assigned to the router that interfaces with
the internet (which is a legal internet address assigned to it by the ISP).
If this isn't done, then the receiving party on the internet will not be
able to respond to the computer that sent it the packet(s).
The home router must keep track of addresses and TCP/UDP ports to which it
sends packets via NAT, in order that the address of returning packets are
correctly routed back to the nodes on the LAN.
Since all packets arriving back from the internet are addressed to the
gateway, TCP/UDP port numbers are altered to create an unambiguous mapping
between LAN and WAN connections.
* Destination NAT = DNAT
When altering the destination address of the first incoming packet, that
is, making the packet go to a different address than specified in the
original transmission of the packet.
This is what your gateway router that interfaces between your private LAN
and the internet does.
When a packet is being returned from say a computer hosting the web site
you are browsing, the destination address is your router's and not your
particular host on the private LAN. The router (which keeps track of
connections you made) will replace the destination address with your
hosts address (e.g. 10.0.0.3).
DNAT is done before routing (i.e. before the packet comes off the wire).
Examples of DNAT: Port forwarding, load sharing, transparent proxying.
For instance a proxy is a gateway through which all network traffic passes
before continuing on to the destination. The proxy may inspect the packets
before passing them on. For more on transparent proxies and the role of NAT
see: Transparent proxy and Implementation methods
Examples rules to implement SNAT
If your router has a fixed IP address, 1.2.3.4, on the WAN side,
apply the following rule
$ iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
eth0 is the interface that faces the WAN.
Suppose you have a few internet IP addresses that face the WAN
1.2.3.[4-6], then apply the rule
$ iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
To restrict SNAT to specific ports, say 1-1023
$ iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4:1-1023
If your router doesn't have a fixed IP address, but is rather assigned
one dynamically by your ISP, then you should be using "Masquerading".
It will substitute the assigned IP in place of the source address of
any outgoing packets.
$ iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Note, the interface specified is ppp0, which is a standard interface used
by ISP employing DSL/ADSL.
See NAT HOWTO (mentioned above) for more details and insights about NAT.
Files and Directories:
/proc/net - This directory contains runtime network related files.
As iptables modules are loaded, files will be automatically created here
containing useful information, such as connections, logs, etc.
For example, the conntrack module creates a file /proc/net/nf_conntrack
which contains info on all currently registered connections. To view it
$ cat /proc/net/nf_conntrack
/proc/sys/net - A directory containing files and directories of network
related settings. You can change a setting by editing a given file.
e.g. To turn on IP forwarding, issue:
$ echo 1 > /proc/sys/net/ipv4/ip_forward
/etc/services - File which itemizes protocols and corresponding port numbers
The netstat and ss tools are very useful and powerful system
tools used to monitor and analyze network usage. For example:
$ netstat -lntu
will list all open TCP and UDP ports which the system is listening to
-l is for listening sockets
-n is to show port number
-t is for tcp
-u is for udp
---------------------------------
| Port Forwarding and NAT Example |
---------------------------------
(See also related section NAT Port Forwarding).
Suppose your home network has a physical machine that runs a virtual machine,
and you would like to make that virtual machine into a server of some sort, and
to make that server accessible from other physical machines in the home network,
or even form outside the home network.
In this example I will demonstrate how to configure iptables to accomplish this.
The following network topology is considered
------------
|Home Router |
------------
/ \
---------------------------------- ------------
| PC1 | | PC2 |
| iface eth0 -------------------- | | iface eth0 |
| 10.0.0.50 | VM 192.168.100.150 | | | 10.0.0.60 |
| -------------------- | ------------
| virtual bridge
| iface virbr0 192.168.100.1 |
----------------------------------
In this exercise our initial objective is to allow PC2 to establish a secure
shell connection with VM (the virtual machine) on PC1.
We assume that the VM sits on isolated subnet 192.168.100.0/24 (that is, it is
invisible to other computers on the network with the exception of PC1).
Therefore, pinging VM from PC2 will yield no response
$ ping 192.168.100.150
I could of course specify a static route in PC2 that tells it how to
reach subnet 192.168.100.0/24
$ ip route add 192.168.100.0/24 via 10.0.0.50 dev eth0
However, if I wish other computers on the network to reach VM, I will have to
do this for each of them. And furthermore, if I wish to allow connections from
outside the home network, adding static routes is not a feasible solution.
The solution offered here involves turning PC1 into a router using packet
forwarding and network address translation (NAT).
Port 20001 will be used to connect the computers via ssh.
To reach VM from PC2, I will invoke ssh from PC2 as such
$ ssh -p 20001 jdoe@10.0.0.50 # note, port 20001 is being used
Notice, I am using PC1's address to reach the VM, rather than VM's address.
But keep in mind that after setting up iptables to route traffic onto port
20001 to VM, the above invocation of ssh will indeed result in a connection
with VM rather than PC1.
Before you begin, turn off your firewall and flush out any rules in iptables
that might be there (see here).
$ iptables -t filter --flush
$ iptables -t nat --flush
You will also need to check whether packet forwarding is enabled in the kernel.
$ sysctl net.ipv4.ip_forward
If you get net.ipv4.ip_forward = 0, then its disabled and you will need
to enable it.
Alternatively, you can check as follows
$ cat /proc/sys/net/ipv4/ip_forward
If you get 0 then its disabled; if 1 then its enabled.
If you found that port forwarding is disabled, then edit the file
/etc/sysctl.conf.
Find and set the setting
net.ipv4.ip_forward = 1
Apply settings
$ sudo sysctl -p
And now for the main part --
To turn PC1 in a router that bridges between other computers and VM, enter
the following commands, either individually or by placing them in a script.
The commands must be invoked as root.
Add rules to enable packet forwarding
# Packet forwarding - forward across box any packets coming in on port 20001
# public interface (visible to PC2) is eth0;
# private interface (one shared with VM) is virbr0
$ iptables -A FORWARD -i eth0 -o virbr0 -p tcp --syn --dport 20001 -m conntrack --ctstate NEW -j ACCEPT
$ iptables -A FORWARD -i eth0 -o virbr0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$ iptables -A FORWARD -i virbr0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Set the policy in the FORWARD chain to DROP.
$ iptables -P FORWARD DROP
This will ensure that packets that don't get matched by any of the rules are
terminated.
At this point forwarding is enabled, but packets sent from PC2 on port 20001
will not yet be redirected to VM. Two addditional rules in the nat table need
to be added.
The first is a rule for DNAT (destination network address translation).
$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 20001 -j DNAT --to-destination 192.168.100.150
This rule replaces the destination address 10.0.0.50 with VM's address
192.168.100.150. It is applied in the PREROUTING chain, thus, this happens
before the packet reaches any other chain in the nat table.
At this point invoking ssh -p 20001 jdoe@10.0.0.50 from PC2, results in packets
destined to 10.0.0.50 (on port 20001) arriving in VM.
You can observe this by invoking the tcpdump utility within VM
$ sudo tcpdump -n -i eth0 tcp port 20001 # inovke in VM
Where eth0 is the name of the network interface in the VM (note, it may be
named diffrently in the VM. Use ip addr to see which interface name
is associated with VM's address 192.168.100.150.)
An additional rule is required for packets being returned from VM to PC1 as a
result of the connection. The source address of these packets must be changed
from that of VM to that of PC1. The reason is, that PC2 thinks it's
communicating with PC1 rather than with VM. Although, PC1 is forwarding
packets from VM to PC2, if those packets bear the address of VM
(i.e. 192.168.100.150), PC2 will not associate them with the session it thinks
its having with PC1, and thus discard them.
To correct this, a rule for SNAT (source network address translation) is given
$ iptables -t nat -A POSTROUTING -o vibr0 -p tcp --dport 20001 -d 192.168.100.150 -j SNAT --to-source 192.168.100.1
With this rule in place, Any packets on port 20001 arriving from 192.168.100.150
(VM) will have their source address replaced with 192.168.100.1 (PC1's address
on its private interface).
Test to see if you are able to connect to VM from PC2.
In VM, start an ssh daemon process on port 20001
$ sudo /usr/sbin/sshd -d -p 20001 # In VM
In PC2, issue
$ ssh -p 20001 jdoe@10.0.0.50
If you are able to establish a connection, then your setup is correct.
If not, you will need to trace the source of the problem. Some suggestions:
* Check if your filewall is off
* Check for typos in interface names when specifying rules
* Verify addresses are correct
* Use tcpdump to observe network traffic
* Your VM may have more than one network interface, in which case network
traffic may be routed through the wrong interface (see next subsection)
* Your VM hypervisor may have inserted firewall rules using nftables which
are invisible to your iptables based firewall.
See subsection example with firewall about what to do.
--------------------------------------
| Previous example with two interfaces |
--------------------------------------
If your VM has more than one interface (say enp1s0 attached to virbr0,
and enp2s0 attached to virbr1), it is essential that network traffic bound for
the subnet in which PC2 resides (10.0.0.0/24) is directed to the the correct
interface.
Check the routing table on VM; within VM invoke
$ ip route show
You might get something like this
default via 192.168.100.1 dev enp1s0 proto static metric 101
default via 192.168.135.1 dev enp2s0 proto dhcp metric 100
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.150 metric 101
192.168.135.0/24 dev enp2s0 proto kernel scope link src 192.168.135.12 metric 100
In this case no routing information is available for PC2's subnet (10.0.0.0).
In such a case network traffic may be routed to enp2s0 instead of enp1s0.
This means virbr1 will receive the network traffic. If both interfaces are
aware of the 10.0.0.0/24 subnet, then this is not a problem.
However, if virbr1 is unaware of 10.0.0.0, then those packets originating from
your VM will never get to PC2.
To remedy this, add an appropriate static route; in VM invoke
$ ip route add 10.0.0.0/24 via 192.168.100.1 dev enp1s0
Note, the ip route add command is not persistent across reboots.
To make route persistent, if using NetworkManager add the route using nmcli
$ nmcli connection modify enp1s0 +ipv4.routes "192.168.100.0/24 10.0.0.1"
Alternatively, use the nmcli editor:
$ nmcli con edit enp1s0
At the prompt enter
nmcli set ipv4.routes 192.168.100.0/24 10.0.0.1
For other network managers refer to their documention as to adding static
routes.
--------------------------------
| Previous example with firewall |
--------------------------------
It is likely your Linux installation came with a pre-configured firewall, and
you may want to keep that firewall configuration.
Although, for the purpose of this exercise you were instructed to turn off the
firewall (so as to avoid potential conflicts), it is now time to turn it back
on.
$ systemctl start firewalld.service
Note, I describe here what to do with a Fedora (or related) installation.
Debian based distributions uses the ufw firewall, so the commands and
configuration specifics will differ, but the idea is the same.
Start the firewall configuration utility (install if you don't have)
$ firewall-config
In the View menu, select Direct Configuration, and a tab of that name will
appear towards the top.
Select that tab, and underneath select the Rules tab.
For each of the rules presented in this excercise press the Add button,
and in the dialog box:
* Select the relevant table for the rule at hand (fitler/nat)
* Enter the name of the chain for which the rule is part of (e.g. FORWARD)
* In the args field enter the portion of the rule that follows the name of the chain
(e.g. -i eth0 -o virbr0 -p tcp --syn --dport 20022 -m conntrack --ctstate NEW -j ACCEPT)
Test connectivity as above.
To make the change permanent, select under the Options menu Runtime to Permament.
Now, your hypervisor may insert its own set rules in the firewall, which may
interfere with your rules.
For example, in the FORWARD chain you may find the following rules
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A FORWARD -i eno1 -o virbr0 -p tcp -m tcp --dport 20022 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eno1 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i virbr0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
The latter three are yours, whereas the first three were inserted by the KVM
hypervisor. These rules actually invoke three user defined chains, LIBVIRT_FWX,
LIBVIRT_FWI and LIBVIRT_FWO. They specify what happens to forwarded packets
traversing the virtual network interfaces of your hypervisor.
If you list the rules in, say, LIBVIRT_FWI
$ iptables -t filter -S LIBVIRT_FWI
you may get something like
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
This means any forwarded packet destined towards your host will be rejected.
This means that none of the rules you inserted will be reached.
To correct this in KVM, you will need to enable forwarding in your virtual
network interface. To do so, edit the XML file
$ virsh net-edit mynet
and add the line
if [ "${1}" = "VMname" ]; then
# modification 1
rules=`nft list chain inet firewalld filter_FORWARD_ZONES`
extract=`echo $rules | sed -e "s/.*virbr1.*/virbr1/" -e "s/virbr1//"`
if [ ! -z "$extract" ]; then
touch /tmp/inserting-firewall-rule1
nft insert rule inet firewalld filter_FORWARD_ZONES iifname "virbr1" goto filter_FWD_libvirt
fi
# modification 2
rules=`nft list chain inet firewalld filter_FWD_FedoraWorkstation_allow`
extract=`echo $rules | sed -e "s/.*virbr1.*/virbr1/" -e "s/virbr1//"`
if [ ! -z "$extract" ]; then
touch /tmp/inserting-firewall-rule2
nft insert rule inet firewalld filter_FWD_FedoraWorkstation_allow oifname "virbr1" accept
fi
# modification 3
rules=`nft list chain inet firewalld filter_FORWARD`
extract=`echo $rules | sed -e "s/.*virbr1.*/virbr1/" -e "s/virbr1//"`
if [ ! -z "$extract" ]; then
touch /tmp/inserting-firewall-rule3
nft insert rule inet firewalld filter_FORWARD oifname "virbr1" accept
fi
fi
touch /tmp/finished-script
Substitute for "VMname" your virtual machine's name (as it is known to KVM).
The essence of the script are the three invocations of the nft command.
They insert the rules that tell the respective chains to accept forwarded
traffic coming into network interface virbr1 (check your own setup
for the relevant network interface name).
The script also checks that the rules are not already present in nftables, and
if so, they will not be duplicated.
The touch command time stamps some files in the /tmp directory to let
you know when the rules were inserted.
To have this script launched every time you start your virtual machine, place
the script in /etc/libvirt/hooks and make it executable.
This script will be executed for every virtual machine that is launched, and
will receive one argument: the name of the virtual machine (VNname).
Notice, by testing the value of this argument I limit the insertion of the
extra rules only to the VM of interest (see first if statement).
For more on KVM networks see here.
The nftables Framework for Packet Filtering
********************************************************************************
- The nftables Framework for Packet Filtering -
********************************************************************************
The nftables framework supercedes the xtables suite (iptables, etc.) for
manipulating Linux' netfilter framework. At the moment the xtables suite is
still widely used, but will eventually be replaced by nftables. As such, it is
worthwhile to learn nftables in preparation for the eventual switchover.
And besides, you will discover its many benefits, among them
* Syntactical elegance (similar in style to tcpdump)
* Unified handling of all the different protocols (ipv4, ipv6, arp, etc.)
with one tool for examining and writing filter rules.
* More sophisticated scripting capabilities, with the ability to define
variables.
* A script with errors will not take effect, thus, leaving the firewall intact
while you get your script in order.
* The inet family for simplified dual administration of IPv4 and IPv6
(in xtables, IPv4 and IPv6 are handled separately)
See here for other differences.
nft is the command line utility used to examine the filter/firewall rules,
and is the main nftables user-space program.
Another useful tool is iptables-translate, used to translate an iptables rule
to nftables.
To translate a rule set use the utility iptables-restore-translate.
See man page for more
$ man iptables-translate
I found the nftables.org quick reference exteremly valuable in getting started.
Some other useful online tutorials:
* nftables Howto - a comprehensive guide to nftables.
* Debian wiki on nftables
* Red Hat on nftables
-------------------------------
| General syntax of nft command |
-------------------------------
Common usage scenarios for the nft command include
* listing tables, rulesets
* adding tables and chains and rule sets
Firstly, identify what action you want to take. That will be the keyword you
enter following nft
$ nft action ...
You choice of actions are:
* list
* add
* delete
* flush
* insert
* replace
* export
* monitor
You can place all your rules in a script and execute the script as such
$ nft -f scriptname
Note, its best to experiment with a box or virtual machine environment where
you are not concerned about putting your guard down (in a networking sense).
If you have an existing firewall, set up by say, firewalld, then you will
probably want to flush all tables, chains and rules
$ nft flush ruleset
This may also be a good idea in the beginning of a script when you are writing
your own firewall and wish to discard any rules put out there by other software.
However, use with caution!
If implementing your own firewall you may probably want to disable other
firewall software (e.g. systemctl disable --now firewalld.service).
And now for examples...
---------------------------
| Examples of listing stuff |
---------------------------
Note, unlike with xptables, nftables comes without any predefined tables or
chains. Whatever you create is what you see. If you flushed your ruleset
as above, then the following listings will come out blank. Start your firewall
service if you want to see a list populated with tables, chains and rules.
Else, skip further down for examples on creating rules, and then list them
using the commands here.
* To list all nft tables:
$ nft list tables
* To list all rules in nftables (analogous to iptables-save)
$ nft list ruleset
* To list rules in all chains in table filter (ipv4) (analogous to iptables -L)
$ nft list table ip filter
* To list rules in INPUT chain in table filter (ipv4) (analogous to
iptables -L INPUT)
$ nft list chain ip filter INPUT
* To list rules in PREROUTING chain in table nat (ipv4)
$ nft list chain ip nat PREROUTING
* List inet (dual ipv4+ipv6) rules inserted by firewalld
$ nft list table inet firewalld
----------------------------------------------------------------
| Examples of creating tables and chains and other manipulations |
----------------------------------------------------------------
Create a table called myfirewall
$ nft add table myfirewall
Add chains called mychain and mysecondchain in this table
$ nft add chain myfirewall mychain
$ nft add chain myfirewall mysecondchain
The general syntax for adding a rule is:
$ nft add rule [<family>] <table> <chain> <matches> <statements>
matches is used to match a given property or value associated with a packet.
statement is what action to take if the packet has the given property.
For example add a rule to mychain to drop any packet with destined for tcp port
445.
$ nft add rule myfirewall mychain tcp dport 445 drop
Alternatively, drop with ICMP reject message
$ nft add rule myfirewall mychain tcp dport 445 reject with icmp type port-unreachable
Flush rules from mychain in myfirewall table
$ nft flush chain myfirewall mychain
Delete mysecondchain
$ nft delete mysecondchain
Router
********************************************************************************
- Home Router -
********************************************************************************
What is a router?
Routers may be simple household routers, or sophisticated high volume/traffic
enterprise routers (e.g. CISCO routers).
In the strict sense, any device or computer whose purpose is to route network
traffic to other routers or networks is called a router.
Most laymen use the term router to refer to a home router.
A home router faciliates construction of a local area network (LAN) which it
then may connect to a WAN (wide area network) via DSL or cable.
They are usually purcahsed as specialized hardware, but may also be
implemented with a standard home PC or virtual machine. Those who wish to
have a highly customized router and firewall will often implement the router
functionality on a PC rather than use specialized router hardware.
(See Custom Router sections further down for more about that).
A typical household router comes with a DSL or cable modem, a few ethernet
ports and WiFi.
The size of the LAN that the router supports is equal to the number
of ethernet ports plus any WiFi connections. Additional ethernet switches
may be attached to the ethernet ports (and cascaded) to increase network
size, although typical household routers are limited to subnets of 256 or
less.
A home router sometimes comes with one or two USB ports that may be used
to attach an external USB storage device or printer to the network, and
accessed via the SMB or NFS protocols.
The router is in essence a specialized computer that creates a LAN and
connects to the WAN, and directs all the network traffic within the LAN
as well as to and from the WAN.
A router will have a default IP address.
Using a web browser, router maintenance and configuration may be performed
by entering this IP address in the Web Browser URL field.
The subnet and router IP address may be reconfigured.
The network MASK will determine the maximum number of unique IP connections
that are available by the router.
For instance a mask of 255.255.255.0 indicates the availability of 255 IP
addresses, although the router may support even less.
Many home routers are coupled with a DSL Modem, although not necessarily.
They connect to one's Internet Service Provider (ISP) via DSL (ADSL or VDSL)
and interface with the router (internally) using PPPoE.
Cable and fiberoptic home routers are functionality the same, except they
connect to the ISP via coaxial cable or fiberoptic cables, respectively.
Most home routers come with a few ethernet ports. This basically means that
the router is a router combined with a network switch. In fact an old router
that has been replaced with a newer router, can still be used as a network
switch as well as a WiFi access point.
A home router which comes with only one ethernet port should normally be
connected to a switch (to enable connecting to more than one device), or a
to a WiFi access point. Alternatively it should be connected to a switch,
and the WiFi access point connected to the switch.
The main job of a home router is to implement Network Address Translation
(NAT) between the home LAN and the ISP.
A typical home router should have sufficient processing and memory capacity to
keep track of all the network traffic between a small LAN and the ISP.
For more demanding networks a custom router may be necessary.
A home router also typically functions as a DHCP server for its LAN.
This can usually be disabled in the configuration in case you wish to delegate
this service to a different computer on your LAN.
Enterprise routers and routers used by ISPs are able to handle a far greater
network capacity, as well as maintain large routing tables to determine which
is the best route for any given IP packet that passes its way.
A site using multiple LANs will require multiple routers to direct network
traffic between one LAN and another.
Configuring your PC as a Router
********************************************************************************
- Configuring your PC as a Router -
********************************************************************************
The following sections describe how to turn you computer into a gateway/router
for various Linux distributions.
It is based on Archlinux Wiki Router and other sources.
Custom Router using Fedora 29 Server
********************************************************************************
- Custom Router using Fedora 29 Server -
********************************************************************************
This tutorial addresses the following routing scenario.
________________________ ________________
----- | Custom | / ADSL/modem \ _____
| LAN | -- | intern0 Router extern0 | -- | Router 10.0.0.1 | -- | WAN |
----- |________________________| \________________/ -----
The gateway in this tutorial requires two physical ethernet connections.
(It is possible to create two virtual interfaces with a single ethernet
connection, but that is not the topic of this tutorial).
* One interface (ethernet interface/card) will connect to a router that serves
an existing LAN, or to the internet provider's modem. We shall refer to this
side of the network as the WAN (wide area network), whether is it large or
not. The WAN is shown on the right.
The ADSL/modem router is the one you currently use for your routing
functions.
Note: if the home network is exposed to the WAN via a DSL modem alone
(no router) than PPPoE will in use. The PPPoE software will communicate
with the modem and create an ethernet interface on the LAN side (see next
bullet).
In archlinux rp-pppoe package needs to be installed.
In this tutorial we shall name the external interface extern0.
* The Custom router is an additional custom router you will be constructing
either on a physical machine or on a virtual machine.
* A second interface (physical ethernet card) will connect to a single
computer or a switch (to which multiple computers on the LAN side can be
connected).
For our purposes LAN on the right represents all the devices hooked up
to the custom router.
The setup procedure for the "Custom Router" is what is being described
here.
On one side of the router is the ISP provider through a router/modem
combo. On the other side is the local area network (LAN).
The ISP modem/router combo is what is commonly available, so that is what
is going to be described here. Although if one has an ADSL modem without
router functionality, the procedure varies only slightly.
This setup requies two network cards, two ethernet dongle, or a combination.
To verify you have two network cards, issue the command
$ lspci -v | grep -A 8 Ethernet
If one or both of your network cards is a USB ethernet dongle, use the
following to verify it is connected
$ lsusb
To Obtain associated interface names, issue the command
$ ip link
All ethernet interfaces (and other network device interfaces)
should have a symbolic link to the interface name in /sys/class/net directory.
In my Fedora29 Server installation (installed as a qemu virtual machine)
they are named "ens3" and "ens4".
Interface names are assigned by udev.
Udev rules can be constructed to cause the names to differ from the above
default. Since I prefer the old fashioned names eth0 and eth1
I construct a rule which I will store in the file
/etc/udev/rules.d/10-local.rules
# Name ethernet interface with MAC address 52:54:00:7c:e7:73 eth0 (orinally ens3)
SUBSYSTEM=="net", ATTR{address}=="52:54:00:7c:c6:65", NAME="eth0"
# Name ethernet interface with MAC address 52:54:00:21:1b:d3 eth1 (orinally ens4)
SUBSYSTEM=="net", ATTR{address}=="52:54:00:21:1b:d3", NAME="eth1"
# If I am want to set up my USB Ethernet dongle as eth1 then provide
# a MAC address of "00:e0:4c:38:13:33"
Substitute MAC addresses for your own hardware.
Note, the udev rule can be constructed from other identifying attributes.
(MAC addresses are the most unique for ethernet devices)
Use udevadm info -a -p /sys/class/net/ens3 # or ens4
to obtain all the attributes of the associated device.
It will also show you the file name as the kernel had named and created it.
That is, /sys/class/net/ens3 is a symbolic link to
/sys/devices/pci0000:00/0000:00:03.0/net/ens3, which is the name and location
given to this file by the kernel.
(Note, udev rules are case sensitive. Also, in constructing a rule, do not mix
attributes from different parent devices as produced by "udevadm info ...")
You can use
$ udevadm test /class/net/ens3 # or ens4
to see what actions udev would take, without actually changing anything.
------------------------------
| NetworkManager configuration |
------------------------------
Fedora 29 Server uses NetworkManager to manage network devices
and functionality.
(Note, Archlinux uses netctl).
The command line utility used to interface with NetworkManager is "nmcli".
To show all defined interfaces, type
$ nmcli c show
(c is short for connection)
It is reccomended to change the interface names to more intuitive names.
$ nmcli c modify ens3 connection.id extern0
$ nmcli c modify ens3 connection.interface-name extern0
$ nmcli c modify ens3 connection.id intern0
$ nmcli c modify ens3 connection.interface-name intern0
* extern0 is the name given to the interface interfacing with the outside,
* intern0 is the name given to the interface interfacing with the LAN.
If you had used udev to change the names of the interfaces, and had connections
using the old names, you should delete them
$ nmcli c delete NAME
And then add new ones
$ nmcli c add save yes type ethernet ifname eth0 con-name extern0 # WAN side
$ nmcli c add save yes type ethernet ifname eth0 con-name intern0 # LAN side
("save yes" makes the naming persistent across boots, in otherwords saves
the connection).
Alternatively edit the pre-existing connections
$ nmcli c edit ...
Once in edit mode, type help for a list of commands
$ help
To get help on a command
$ help command
More commands within edit mode:
To set settings use set command. For example
$ set ipv4.addresses 10.0.0.138/24
To remove a setting use remove command. For example
$ remove ipv4.addresses
Note, only one address at a time will be removed.
To remove all addresses
$ set ipv4.addresses ""
To save modifications to connection
$ save
To active connection to use new settings
$ activate
To quit edit mode
$ quit
To see the profile you have created or modified
cat /etc/NetworkManager/system-connections/connection_name.nmconnection
To verify that your connection was setup correctly, issue
$ nmcli c show
NAME UUID TYPE DEVICE
extern0 .... ethernet eth0
intern0 .... ethernet eth1
To connect and disconnect interfaces, issue
$ nmcli device disconnect eth0 # or eth1
$ nmcli device connect eth0 # or eth1
Next, assign a fixed IP to intern0 interface
$ nmcli con mod intern0 ip4 10.0.2.138/24
Note, if you haven't yet created intern0 and bound it to eth1 and set its type,
then issue
$ nmcli con add con-name intern0 ifname eth1 type ethernet ip4 10.0.2.138/24
See man page for nmcli and nmcli-examples for more on creating, deleting and
modifying network connections using NetworkManager.
You may also use NetworkManager's GUI utility (usually available with Gnome
and KDE desktop environments) to make these modifications.
--------------
| DNS and DHCP |
--------------
Next you will probably need to set up the local DNS and DHCP services.
The DNS server will allow you to access devices on the LAN by name
(rather than by IP).
The DHCP server will dynamically assign IP addresses to connected devices
on the LAN.
It is possible to tell the DHCP server to associate certain IP addresses
with certain MAC addresses. That is, if a device with a given MAC address
is connected to the LAN, the DHCP will provide that device with an IP address
reserved specifically for that device.
Both the DNS and DHCP servers are implemented in "dnsmasq".
If not already installed, install it.
The configuration file for dnsmasq is
/etc/dnsmasq.conf
The contents of this file on the custom router look something like:
interface=intern0 # make dnsmasq listen for requests only on intern0 (our LAN)
expand-hosts # add a domain to simple hostnames in /etc/hosts
domain=foo.bar # allow fully qualified domain names for DHCP hosts (needed
# when "expand-hosts" is used)
dhcp-range=10.0.0.2,10.0.0.255,255.255.255.0,1h
# defines a DHCP-range for the LAN in the address range:
# 10.0.0.2 to 10.0.0.255, with a subnet mask of 255.255.255.0
# and a DHCP lease of 1 hour (modify to suit your preference)
Once configured the dnsmasq service will need to be activated and enabled
on future boots.
$ systemctl start dnsmasq.service # start it now
$ systemctl enable dnsmasq.service # enable start on boot
--------------------------------
| Private networks address range |
--------------------------------
Private networks can use the following IP address ranges:
24-bit block 10.0.0.0 - 10.255.255.255 (largest subnet mask 10.0.0.0/8)
20-bit block 172.16.0.0 - 172.31.255.255 (largest subnet mask 172.16.0.0/12)
16-bit block 192.168.0.0 - 192.168.255.255 (largest subnet mask 192.168.0.0/16)
-----------------------
| Port Forwarding - NAT |
-----------------------
This subsection to be completed in future.
Custom Router using Arch Linux
********************************************************************************
- Custom Router using Arch Linux -
********************************************************************************
In archlinux setting up a home Router is essentialy the same as described for
Fedora, except that you might want to employ "netctl" as the
network management software, as it comes natively with Archlinux.
Alternatively, you could install Network Manager, disable netctl.service,
and enable the NetworkManager.service.
When using netctl (see Archlinux Wiki - Router):
* Create file /etc/netctl/extern0-profile
Description='Public Interface.'
Interface=extern0 # name of interface on WAN side
Connection=ethernet
IP='dhcp' # have your WAN router assign an IP for the external interface
* Create file /etc/netctl/intern0-profile
Description='Private Interface'
Interface=intern0 # name of interface on LAN side
Connection=ethernet
IP='static' # Will not request DHCP to assign an address
Address=('10.0.2.1/24') # The router you create will have this address
# the /24 referes to the net mask. It says your LAN can assign addresses
# in range 10.0.2.1-10.0.2.255
You Can also edit /etc/sysconfig/network-scripts/ifcfg-eth1.
DEVICE="eth1"
BOOTPROTO=static
ONBOOT=yes
TYPE="Ethernet"
IPADDR=10.0.2.138 # or whatever static IP address you wish to assign
NAME="intern0" # Your connection name as was specified in the netctl profile
HWADDR=00:00:00:00:00:00 # Your interfaces' MAC address (substitute accordingly)
GATEWAY=10.0.2.1 # Your gateway address
IP Packet Sniffing
********************************************************************************
- IP Packet Sniffing -
********************************************************************************
Packet sniffing refers to inspecting network traffic, in particular IP packets.
Available tools are tcpdump, httpry and more
********** tcpdump **********
To capture packets for a given interface
$ tcpdump -i eth0
To capture packets for a given interface and host
$ tcpdump -i eth0 src 10.0.0.5
To capture packets whose source is 10.0.0.5
$ tcpdump -i eth0 dst 10.0.0.5
To capture packets whose source is 10.0.0.5 and are on port 22
$ tcpdump -n -i eno1 src 10.0.0.16 and tcp port 22
To capture packets whose source is 10.0.0.5 and are NOT on port 22
$ tcpdump -n -i eno1 src 10.0.0.16 and not tcp port 22
To write to a file rather than standard output
$ tcpdump -w tcpdumpfile
To read file and display in human readable format
$ tcpdump -r tcpdumpfile
(can also redirect to a file with > tcpdumpfile.txt)
To display ip numbers instead of addresses
$ tcpdump -n
To suppress time stamp of packet
$ tcpdump -t
tcpdump has many more options and sophisticated packet filtering capability.
Refer to man page for more.
********** httypry **********
To sniff packets for a given interface
$ httpry -i eht0
NetworkManager
********************************************************************************
- NetworkManager -
********************************************************************************
NetworkManager is package of programs/scripts manages the various network
services available. It does so dynamically, and is therefore able to handle
changing WiFi hotspots, laptops plugged into different networks, and so forth.
Its daemon (launched by systemd as service NetworkManager.service) configures
all networking automaticly.
The following tools come bundled with it.
* nm-tool - Displays assorted information about the current network connection
* nm-online - Determines if network is online (returns exit codes)
* nmcli - A powerful command line utility to obtain status, select,
as well as start and stop network connections
* nm-applet - A graphical interface to select, start and stop network
connections.
* nm-connection-editor - A graphical interface to manage, add, delete and
configure network connections
An important directory for NetworkManager is /etc/NetworkManager.
For example my DSL connection is specified in the file
"/etc/NetworkManager/system-connections/DSL connection 1"
Some examples of using nmcli to manage configured connections:
$ nmcli connection show --active # show all active connections
$ nmcli connection list # list all connections (whether active or not)
$ nmcli connection up id "DSL connection 1" # brings up connection "DSL ..."
$ nmcli general status -- display status of connection
An example of using nmcli to obtain info on available WiFi access points:
$ nmcli dev wifi
The list contains a column labeled SSID which is a textual identifier of
the access point or points.
The column labeled BSSID is a column separated numerical ID of a specific
access point.
Example of creating a configuration entry for a specific WiFi access point
$ nmcli dev wifi connect "B4:C7:99:59:EB:50"
where the quoted string is an SSID or BSSID of the desired access point
(it can be obtained with the "nmcli dev wifi").
Example of connecting to WiFi network "homenet" with a password
$ nmcli dev wifi con "homenet" password xxxmypassword
Example of creating an ethernet connection without auto-connect (autoconnect=no)
$ nmcli connection add type ethernet autoconnect no ifname eth0
Note, if unsetting autoconnect using nmcli connection editor, enter
set connection.autoconnect no
Example of renaming a connection
$ nmcli connection modify "Current name" connection.id "New name"
See man page for more extensive usage.
$ man NetworkManager
netctl, a network manager native to Archlinux
********************************************************************************
- netctl - a network manager native to Archlinux -
********************************************************************************
netctl is a network manager program that's native to Archlinux and uses
profiles to setup a network.
It includes WiFi configuration.
For extensive usage instructions and troubleshooting, refer to
Archlinux Wiki - Netctl
connman network manager
********************************************************************************
- connman network manager -
********************************************************************************
A command-line network manager.
It is modular and uses plugins to provide various network functionality such as
ethernet, WiFi, bluetooth, etc.
For more on connman refer to Archlinux Wiki - ConnMan
Wicd network manager
********************************************************************************
- Wicd network manager -
********************************************************************************
An alternative network manager to NetworkManager.
It can manage both wired and wireless interfaces.
For more on configuring and working with Wicd, refer to Archlinux Wiki - Wicd
DHCP
********************************************************************************
- DHCP -
********************************************************************************
DHCP stands for Dynamic Host Configuration Protocol.
The function of a DHCP server is to allocate IP addresses to machines/devices
on a network. When a desktop computer, laptop or mobile device connect to a
network they are assigned an IP address. If it weren't for the DHCP server,
each device would have to attempt to assign itself an IP address, and without
knowledge about other IP addresses already in use, IP duplication may occur,
resulting in address clashes.
To determine the IP address of a DHCP server
$ cat /var/lib/dhcp/dhclient.leases
On a home network with a router you can also identify the DHCP server's address
by issued the ip command
$ ip route
Look for a line containing "dhcp"
default via 192.168.154.1 dev enp1s0 proto dhcp metric 100
DNS
********************************************************************************
- DNS -
********************************************************************************
-------
| Intro |
-------
DNS is short for domain name server.
It is a server that is accessed by the computer for the purpose of converting a
textual name, called a Fully Qualified Domain Name (FQDN), to an IP address.
The IP address of one or more backup DNS servers should appear in the file
/etc/resolv.conf .
Although the IP addresses of DNS servers are usually obtained automatically from
the LAN's DHCP server (which usually sits on the gateway router, but not
necessarily), there may be times it isn't. In such a case it may be entered
manually into the above file.
You can specify your gateway (home router's) address as a DNS server, and your
gateway will forward DNS queries to whichever DNS server(s) were provided
to it by the ISP.
If the computer is not told about a DNS server it will not be able to
resolve names into IP addresses, and will therefore only be able to
access an address via its numerical IP form (the name will be meaningless).
An example resolv.conf file:
nameserver 10.0.0.100 # LAN gateway
nameserver 8.8.8.8 # Google name server
nameserver 8.8.4.4 # Another google name server
If you have a domain name, you should specify it in resolv.conf as such:
domain myco.com # substitute your own domain for myco.com
This is useful for resolving host names based on their short names.
e.g. mycomputer will be queried as mycomputer.myco.com
If you want to search short host names across one or multiple domains
specify the directive:
search mydom1.com mydom2.com ...
For more details refer to Setup DNS Resolution With resolv.conf
----------
| nslookup |
----------
The utility "nslookup" may be used to obtain an IP address given a FQDN.
For instance:
$ nslookup www.google.com
will give a few IP addresses associated with google.com
If your computer was not configured to point to a DNS server
you can specify a DNS server as a second argument on the command line.
$ nslookup www.archlinux.org 8.8.8.8
The IP address 8.8.8.8 is that of Google's primary DNS server.
If connected to a home router, it is often sufficient to specify the
router's LAN side IP address (e.g. 10.0.0.100).
It will then act as the DNS server.
In fact it merely forwards the resolution query to the DNS server specified
by the service provider, or to the DNS server you specified in your router
configuration.
A more detailed description of the DNS system follows.
The information here has been primarily derived from
* opensource.com - Introduction to the Domain Name System (DNS)
* wikipedia - Root Name Server
* opensource.com - Build your own name server on Linux
---------------------------------------
| A DNS search and types of DNS servers |
---------------------------------------
Suppose the name to be resolved is mach.foo.com.
The first method the OS uses to resolve the name is to look for mach.foo.com
in the file /etc/hosts.
Suppose there is an entry
10.0.0.7 mach.foo.com mach
In that case the OS will resolve mach.foo.com to 10.0.0.7
If there is no entry for mach.foo.com, then the OS will send a name resolution
query to the first DNS server listed in /etc/resolv.conf.
(Note, this file is what is used in Unix type OS's. In Windows the DNS
servers are specified when configuring the network through its GUI system,
which can be launched with Win-R ncpa.cpl)
Suppose the first entry in resolve.conf is:
nameserver 10.0.0.100 # router's LAN side address
The OS will send a name resolution query to 10.0.0.100, which in this example
is the router's IP address (Note, DNS server software must be running on the
router, if the OS is to receive a response.)
mach.foo.com is unlikely to be stored in the router's database of name
resolutions. Therefore, the router will forward the request further.
The router will look in its own /etc/resolv.conf file (or equivalent location
for other OS's) to determine to which remote DNS server to forward the request.
In the router, you normally specify the ISP's DNS server(s), and/or a public
name server such as Google's name servers:
nameserver 8.8.8.8
nameserver 8.8.4.4
All these servers are of the type "forwarder".
They will not actually attempt to resolve your address, but rather forward it
another kind of DNS server, called a (top level) root server (of which
originally there were 13 in the world).
The root server takes the last part of the name (com) and returns the IP
address of the .com authoratative DNS server.
Your OS now queries the .com server for mach.foo .
The com server doesn't know mach, but it knows foo, so it will send the IP
address of foo's authorative DNS server.
Your OS now queries foo's DNS server for mach, and foo will respond with the
correct IP address for mach in its domain.
Note, if mach is on a local network and doesn't have a legal internet address,
foo's DNS server will not have an address resolution entry for it to respond
to an outside query.
However, internal to the LAN foo's DNS server may respond to a query with a LAN
address (e.g. 10.0.5.49).
In practice your OS (as well as intermediate authoratative DNS servers) cache
name resolutions so as not to overburden the name servers with repeated requests.
For instance after your OS will have queried mach.foo.com, it will cache the
resulting IP address for a given amount of time.
Your web browser may also perform its own DNS caching.
(In firefox open a tab about:config and locate network.dnsCacheExpiration
parameter. If you set it to 0 firefox will use the DNS cache provided by the
OS.)
Source: DNS caching in Linux
------------------
| DNS record types |
------------------
A DNS server works with a database or table of entries which it parses to
respond to queries.
The following is a list of some of the more common DNS records:
* SOA - Start of Authority
First record in a forward or reverse zone file
* $ORIGIN
Its value is appended to any name in an A or PTR record that does not end in
a "." (Simplifies making entries, as only the short hostname need be
specified)
e.g. $ORIGIN mycom.com
"@" is also substituted by the content of this variable
* NS - Record specifying the authoritative name server for the zone
* A - host IPv4 address
This record specifies a host name to IP mapping
e.g. myhost.mycom.com. IN A 192.168.100.32
Could also omit .mycom.com. if $ORIGIN is defined as above
myhost IN A 192.168.100.32
* AAAA - host IPv6 address
Same as A, except for IPv6
* CNAME - Cannonical name
An alias to an A record for a host.
e.g.
myserver.mycom.com. IN A 192.168.100.1
www.mycom.com. IN CNAME myserver.mycom.com.
Could also omit .mycom.com. if $ORIGIN is defined as above
myserver IN A 192.168.100.1
www IN CNAME myserver
A query for myserver will result in the IP address of myserver.mycom.com
* PTR - Pointer
Used for reverse lookup
* MX - Mail eXchanger (mail server for the domain)
e.g.
mycom.com. IN MX 10 mail.mycom.com
The 10 field is a priority number.
The lower the number the higher priority the mail server will have.
This is relevant when there are more than one mail servers in the domain.
Setting all of them to have the same priority will cause the name server
to forward requests to the mail servers in round robin fashion.
--------------------------
| dig - DNS lookup utility |
--------------------------
This is best explained by quoting from the man page:
"dig is a flexible tool for interrogating DNS name servers. It performs DNS
lookups and displays the answers that are returned from the name server(s) that
were queried. Most DNS administrators use dig to troubleshoot DNS problems
because of its flexibility, ease of use and clarity of output. Other lookup
tools tend to have less functionality than dig".
For example, to query the public IP address through which your LAN connects
with the internet
$ dig +short myip.opendns.com @resolver1.opendns.com
or
$ dig TXT +short o-o.myaddr.l.google.com @ns1.google.com
In the examples above, the @ symbol is followed by the DNS server being queried
(e.g. resolver1.opends.com)
See this webpage for more examples.
----------------------------
| Troubleshooting DNS issues |
----------------------------
* VM's
When working with Virtual Machines, I sometimes find that the
virtual machine doesn't get an updated DNS server.
For instance:
* When there was a save state, and the machine was started on a different
network
* When the nameserver's IP as specified in resolv.conf is used before,
or is inaccessible or not relevant for the current network.
In such a case it might be necessary to restart the network manager, and if
that fails, manually add the DNS server's IP to resolv.conf
------------------------------------------------
| Getting you own public domain - DNS Registrars |
------------------------------------------------
The DNS system works hierarchially.
At the top of the hierarchy sit top level domain servers which handle the
.com, .org, .gov, etc. domains.
Country specific domains also sit at the top. e.g. .us, .il etc.
The top level domain servers are known as root nameservers.
The Internet Assigned Numbers Authority (IANA) manages the top of the DNS tree
which the root nameservers are responsible for.
Another important player in global DNS is ICANN (Internet Corporation for
Assigned Names and Numbers) which is an organization that is responsible for
making sure the DNS system functions properly. It is persuant to IANA policy,
and is invovled in the more technical aspects of top level DNS functionality.
A domain name registry is a database of all domain names and related
information in the top level domains of DNS.
When a user wishes to obtain a domain name he does not interface directly with
IANA or ICANN, but rather with a domain name registrar. This is a company
that is accredited by IANA to reserve domain names for one or more top level
domains.
Godaddy and Namecheap are examples of such registrar's (often the registrars
also provide WEB hosting services.)
To reserve a domain name one must first choose a registrar.
The registrar may offer various additional services besides registring the
domain, such as identity protection, domain protection and more.
When one registers a domain, various personal information relating to the
owner of the domain will be published in the whois catalog (maintained
by ICANN), such as the owner's name, email address, physical address and more.
To see a list of all information stored along with a given domain name refer to
the ICANN FAQ.
If identity protection is purchased, the registrar will substitute its own
information in the place of the owner's personal information.
The cost of a domain name can range between a few dollars to millions
of dollars.
To see if a particular domain is available perform a search on ICANN's
website Lookup.
A given registrar will also let you know if the desired name is available
as well as its cost. Note, however, that a given registrar only handles certain
top level domains (e.g. .com, .org, etc.).
Once you purchase a domain name you will want to add entries to the DNS tables
that reference your domain name.
In the simplest case, say you have a website sitting on a server with public IP
address yyy.148.28.123.
Use the registrar's tools to modify the "A" record to point to this address.
It you are using Godaddy, login to your account.
Goto "Your products".
Select your domain.
In the upper menu select "DNS" - "Manage zones".
Enter your domain name in the prompt box.
The browser will show a table of DNS entries associated with your domain.
Edit the A record to have value of your server's public IP.
Under "Name" place "@".
Under address place your server's IP address.
Save.
You can also add records. For instance add CNAME (alias) records, etc.
--------------------
| Setup a DNS server |
--------------------
Most home routers allow you to specify primary and secondary DNS servers, to
which the router forwards DNS queries.
If you wish to setup and manage your own DNS server to manage name translation
of hosts on your home network, you can setup a DNS server on one of the
computers on the network. The computer of choice should be one that is left on
continuously. On my network I have an a laptop that functions as both a file
server and as a DNS server.
Two software packages that provide DNS server functionality
are bind and dnsmasq.
The latter is actually provides both DHCP and DNS functionality together. Since
the two are related, it makes sense to combine the two into one program.
Since dnsmasq is discussed further down, I will only
discuss bind in this section.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
In Fedora, install bind
$ sudo dnf install bind
See here for more.
Firewall
********************************************************************************
- Firewall -
********************************************************************************
-----------------
| Fedora Firewall |
-----------------
Fedora comes with a systemd firewall service: firewalld.service
To activate/deactivate/enable or get status
$ sudo systemctl start|stop|enable|status firewalld.service
firewall-config is a gui application for configuring the firewall.
A Fedora installations comes with a default firewall configuration.
To see or modify the configuration, launch firewall-config.
On the right is a window frame titled "Active Bindings".
Usually under "Connections" will appear the name of the connection associated
with the physical interface (e.g. wired ethernet card).
If you have more than one ethernet card, or a WiFi interface, they too will
display, and likewise for virtual interfaces (created by VMWare, Virtualbox
or KVM).
Each connection has an associated default "zone".
A zone is basically a container of services, ports, protocols and more that
are permitted in that zone.
For instance, the FedoraWorkstation zone permits certain services by default,
which you can easily modify.
For example if you wish to make your workstation accessible by ssh, you will
need to do two things:
1. Start the ssh service
$ systemctl start sshd.service # use "enable" to make persistent across boots
This will start the ssh daemon, and the workstation will await requests to
initiate an ssh session.
2. Enable port 22 on the firewall to allow incoming ssh traffic.
To do this find the "Services" tab in the firewall-config window scroll and down
the pane and check the box labeled "ssh".
You can also configure which non-fixed ports of TCP and UDP are open
for the given zone using the "ports" tab (the default is to open ports
1025-65535 for both TCP and UDP).
The choice of zones will appear in the right window frame titled
"Configuration".
If your installation was from a Fedora Workstation image, the default zone
for you interfaces will be "FedoraWorkstation".
If your installation was from a Server image, the default zone for your
interfaces will be "FedoraServer".
Other zone types exist, and you can modify the default zone for your
interface(s) using firewall-config.
You can then customize services and ports, etc. that are available for the
zone.
To configure the firewall from the command line, use the command firewall-cmd.
Some examples:
To get and set default zone
$ firewall-cmd --get-default-zone
$ firewall-cmd --set-default-zone zone
To print information about specified zone
$ firewall-cmd --info-zone zone
To display zones used by your network interfaces:
$ firewall-cmd --get-active-zones
To display the current configuration
$ firewall-cmd --list-all
To add a service
$ firewall-cmd --add-service servicename # e.g. ssh, samba
To remove a service
$ firewall-cmd --remove-service servicename # e.g. ssh, samba
To add a rule that will cause the host to forward to address 192.168.122.76
all packets destined to port 20022
$ firewall-cmd --add-masquerade
$ firewall-cmd --add-forward-port=port=20022:proto=tcp:toaddr=192.168.122.76
$ firewall-cmd --add-forward # Enables intra zone forwarding
For more sophisticated firewall behavior, you may need to use iptables rules.
This can be done in conjunction with firewall, either with its graphical
interface or via the command line. For example to insert the rules of the
example elsewhere in this manual, enter the following commands:
$ firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i eth0 -o virbr0 -p tcp --syn --dport 20001 -m conntrack --ctstate NEW -j ACCEPT
$ firewall-cmd --direct --add-rule ipv4 filter FORWARD 1 -i eth0 -o virbr0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$ firewall-cmd --direct --add-rule ipv4 filter FORWARD 2 -i virbr0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$ firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 3 -o vibr0 -p tcp --dport 20001 -d 192.168.100.150 -j SNAT --to-source 192.168.100.1
$ firewall-cmd --direct --add-rule ipv4 nat PREROUTING 4 -i eth0 -p tcp --dport 20001 -j DNAT --to-destination 192.168.100.150
The numbers 0 through 4 indicate the priority of the rule. Rules with a lower
number receive higher priority.
To make runtime configuration permanent
$ firewall-cmd --runtime-to-permanent
-----------------
| Debian Firewall |
-----------------
Debian's (and related distributions) default firewall frontend configuration
tool is ufw (stands for "uncomplicated firewall"). It is a front-end
command line tool for managing iptables.
A few simple examples of using ufw:
* To enable the firewall:
$ ufw enable
* To disable:
$ ufw disable
* To get status and rules:
$ ufw status
* To get rules according to number:
$ ufw status numbered
* To disable http:
$ ufw deny proto tcp to any port 80
Sample configuration display using ufw:
[ 1] 80/tcp DENY OUT Anywhere (out)
[ 2] 443/tcp DENY OUT Anywhere (out)
[ 3] 22/tcp ALLOW IN Anywhere
[ 4] Samba ALLOW IN Anywhere
[ 5] 115/tcp ALLOW IN Anywhere
[ 6] 63.252.32.124 ALLOW IN Anywhere
[ 7] 213.151.33.115 ALLOW IN Anywhere
[ 8] Anywhere ALLOW IN 213.151.33.115
[ 9] 80/tcp DENY OUT Anywhere (v6) (out)
[10] 443/tcp DENY OUT Anywhere (v6) (out)
[11] 22/tcp ALLOW IN Anywhere (v6)
[12] Samba (v6) ALLOW IN Anywhere (v6)
[13] 115/tcp ALLOW IN Anywhere (v6)
Note: The order in which the above rules appear may be significant.
For instance if rule 1 denies outgoing traffic on port 80, and rule 2 permits
it, then rule 2 supercede rule 1, and traffic on port 80 will be permitted.
If they were specified in the reverse order, the result will be to block
outgoing traffic on port 80.
-----------------
| Debian Firewall |
-----------------
See Debian Firewall.
---------------------------
| Firewall issues in Fedora |
---------------------------
When activating the Fedora firewall, issues may arise with VM (virtual machine)
communications to the host and externally (NAT).
If you see there is no communication turn off the firewall and see if that
fixes the problem.
If so, then the following changes should be made in the firewall
(Note, start with runtime, and if that fixes the problem make permanent).
Select zone: FedoraWorkstation (default zone)
Under "Services tab" check "dns"
Under "Masquerading tab" check "Masquerade zone"
(this should permit communications between FedoraWorkstation
and the outside world via NAT)
In a VM the gateway (specified in /etc/resolv.conf) should be the IP address of
the virtual bridge created for communicating with the outside (NAT).
In the shell, execute command
$ ip address
This command will display information about all interfaces, including virtual
ones.
Identify the output which corresponds to the virtual bridge being used by your
VM (you may have created more than one virtual bridge).
For example
5: virbr0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:50:8f:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
Thus, the gateway address should be 192.168.100.1
Samba
********************************************************************************
- Samba -
********************************************************************************
-------
| Intro |
-------
Samba is a suite of programs for Linux and Unix systems intended primarily to
provide interoperability with Microsoft Windows OSs.
Windows uses the SMB (Server Message Block) protocol for sharing files,
printers and other resources between computers.
Over the years many versions of the SMB protocol (reffered to by Microsoft
as "dialects") have been developed.
Some of the major versions of the SMB protocol are listed here:
* CIFS was originally developed at IBM as a file sharing protocol for DOS.
* SMB1.0 is Microsoft's (modified) version of CIFS with various enhancements.
It was introduced with Windows 95.
* SMB2.0 is an improved and less "chatty" rework of the SMB protocol
Introduced with Windows Vista and Server 2008R
* SMB2.1
Introduced with Windows 7 and Server 2008R2
* SMB3.0 offers end-to-end encryption, RDMA, SMB Transparent failover and more
Introduced with Windows 8 and Server 2012
* SMB3.1.1 offers additional encryption and security enhancements.
Introduced with Windows 10 and Server 2016
SMB originally ran on top of NetBIOS using port 139.
NetBIOS has been depricated as a means of network communications in MS Windows,
and starting with Windows 2000, SMB runs on top of TCP using port 455.
If using a firewall, make sure this port is open, or specify that the samba
service should be available.
Samba consists of a server end and client end.
Sources:
1. What is SMB
A good (although not so recent) explanation of SMB
2. docs.microsoft.com - Microsoft SMB Protocol and CIFS Protocol Overview
3. Server Message Block
4. CIFS-vs-SMB
5. SMB port
See Fedora Magazine for a good introduction to using Samba.
--------------
| Installation |
--------------
To set up a Samba server, install the samba package:
$ dnf install samba # fedora
or
$ pacman -S samba # archlinux
Make sure there is an /etc/samba/smb.conf file present.
The Arch Linux installation comes with /etc/samba/smb.conf.default
Simply copy it to smb.conf
Fedora comes with a simple /etc/samba/smb.conf file.
In both cases you will need to edit this file when adding shares.
To install the client end in Fedora:
$ dnf install samba smbclient
To be able to mount Windows filesystems using SMB (either with mount command
or using /etc/fstab)
$ dnf install smbfs
Finally, enable and start the service.
$ systemctl enable smb.service # makes service persistent across reboots
$ systemctl start smb.service # start service now
---------------------------
| Samba users and passwords |
---------------------------
To add a user and set a samba password (see notes below):
$ smbpasswd -L -a user_name
Note: Pressing enter at the password prompt will set a blank password.
To enable a user:
$ smbpasswd -L -e user_name
Note: Normally Samba stores its password in the file: /etc/smbpasswd
However, if you find the following line in the smb.conf file
passdb backend = tdbsam
then the file containing the passwords is /etc/samba/passdb.tdb
(although in my installation it is /var/lib/samba/private/passdb.tdb).
In that case, a new samba user can only be created if a user by that name
already exists in the system. If not, create one, and then create the samba
user.
pdbedit is a tool for managing Samba users.
To list all Samba users and corresponding uid's, invoke
$ pdbedit -L
See man page for more.
--------------------
| Samba and Firewall |
--------------------
Firewalls often block samba requests.
If experiencing difficulty connecting to a samba server
(for instance getting error NT_STATUS_HOST_UNREACHABLE),
try disabling the firewall (both on server and client)
$ systemctl disable firewalld.service # in Fedora
If that resolves the problem, the firewall should be enabled again, and
configured to accept samba traffic.
firewall-config can be used to configure the firewall to accept both
smb-client traffic and smb-server traffic.
All modern implementations of SMB utilize TCP port 445.
Windows NT4 and earlier used a version of SMB that runs ontop of Window's
NETBIOS framework, using TCP port 139 (netbios-ssn) for most of the SMB
traffic, such as directory listings and file transfer.
Current versions of SMB uses port 445.
When Windows attempts to establish an SMB connection it will try port 445.
If successful it will continue to use this port.
If unsuccessful it will attempt to use TCP port 139 for SMB communications
over NETBIOS, as well as UDP port 137 for NETBIOS lookups.
UDP port 138 (NetBIOS Datagram Service) may also be used.
You can use tcpdump to observe this. Block TCP port 445 and run tcpdump
$ tcpdump -nn -v -i virbr0 dst host 10.0.10.5
virbr0 is the interface name for a virtual bridge between the
Windows virtual machine and the host machine.
You will see that at first packets destined for port 445 arrive. As these
are blocked by the firewall, the Windows machine will not receive a response
and will attempt to invoke SMB communications via NETBIOS, for which you will
observe packets for ports 139 and 137 arriving.
See this webpage for more about ports used by Samba.
See here for more about firewalling Samba.
Troubleshooting:
In Fedora, I found that when mapping a drive from a Windows virtual machine
to a Samba share on the host, the mapping fails when Fedora's firewall is
active. I had configured the samba service on the FedoraWorkstation zone as
active, so that wasn't the issue.
The virtual interface connecting the virtual machine to the host machine
(named virbr0) was set to the Default Zone which is the FedoraWorkstation
zone.
I solved the problem by changing the firewall Zone (left pane in Firewall
configuration tool) to FedoraWorkstation rather than Default zone.
That did the trick, although I am not sure why. After all the default zone is
FedoraWorkstation, so the two ways of setting the zone should have been
synonymous.
-------------------
| Samba and SELinux |
-------------------
The following is for Linux systems with SELinux enabled.
SELinux may block attempts to mount a share, returning the error:
NT_STATUS_BAD_NETWORK_NAME
If you suspect SELinux, then temporarily disable it:
$ setenforce 0 # to subsequently reenable, execute command setenforce 1
If that fixes the problem, then SELinux is at play, requiring configuration
on your part.
Two approaches are offered:
* SELinux has boolean variables which control its behavior.
Two boolean variables of interest pertaining to SAMBA are:
samba_export_all_ro, samba_export_all_rw
These tell SELinux to allow samba to share any file or directory
in either read-only mode or read-write mode.
To set the latter boolean:
$ setsebool -P samba_export_all_rw 1
To get the boolean's value:
$ getsebool boolean_name
To get them all:
$ getsebool -a
Setting these booleans is telling SELinux to allow samba to access any file or
directory.
* A more specific approach would be to change the "context type"
of all directories and files in the share as being a "samba share type".
$ chcon -R -t samba_share_t sharedir
The -R option tells the command to apply the change recursively.
Note: all parent directories of sharedir must also have context type
samba_share_t
Note: For samba to have access to say /srv/storage/mymedia, not only must the
"mymedia" directory be labeled samba_share_t, but also the "srv" and
"storage" directories. Although their subdirectories do not.
See Fedora documention on SELinux for more about SELinux in general, and the
section pertaining to Samba specifically.
Also see Red Hat documentation
for more on SELinux variables pertaining to Samba.
----------------------------
| Samba server configuration |
----------------------------
The samba server configuration file is /etc/samba/smb.conf .
Adding a share entails editing that file.
For instance, to add the share "myshare" add the following lines to the
end of smb.conf
[myshare]
path = /home/storage/mymedia
read only = no # Both reading and writing to this share will be possible
force user = jdoe # Any new files or directories created will appear
# on server as beloning to user jdoe
force group = jdeer # Same as above except for group
valid user = jdoe, jdeer # Allow only jdoe and jdeer users to access share
# Different ways of affecting file and directory permissions:
create mask = 0774
directory mask = ...
# The value of the following parameter is bitwise 'OR'ed onto the file mode
# after the mask set and the create mask parameters are applied:
force create mode = 0755
# Similarly, to effect directory permissions use:
force directory mode = 0755
The above will allow any permissions to be written for owner (7), but only
read permissions for group and others.
Place the following entry in /etc/fstab to mount this share:
//IP_ADDRESS/folder_name /home/localmntpoint cifs credentials=/home/jdoe/.smbcredentials,rw,uid=myself,gid=mygroup,noauto,user
Subsitute for myself your user name, and for mygroup your default group name
See below for more on mounting shares.
To change the default ports on which Samba listens, in smb.conf add line
smb ports = 20445 20139
Ports 20445 and 20139 will be used instead of 445 and 139.
This is useful if you are using port forwarding to make your home network
accessible to the internet, although, beware that doing so may compromise
your network's security.
For the changes to go into effect retart the samba daemon service.
$ sudo systemctl restart smb.service
If there was an error in the configuration file, the service will failed to
start. See the log file for clues /var/log/samba/log.smbd.
Many other options are available. See samba man page and internet references
for further details.
---------------
| Testing samba |
---------------
After configuring a samba share you can use an FTP type samba client interface
smbclient to test functionality.
Examples:
$ smbclient //localhost/myshare
will attempt to connect to the localhost computer and access "myshare".
If you get errors of any sort, first check out firewall and Samba as well
as SELinux and Samba sections above for preliminary diagnostic steps.
$ smbclient //10.0.0.2/testfolder
Will attempt to connect to 10.0.0.2 and access shared folder testfolder.
testfolder must be set for sharing across the network otherwise the
transaction will fail.
Similarly I can access an external usb drive connected to my router
whos IP address is 10.0.0.100
$ smbclient //10.0.0.100/usb_storage
Note: In both cases I can simply press return when prompted for a password
if no password has been set for these resources.
Alternatively the option -N can be used to suppress the password prompt.
By default smbclient will use only SMB version 1.0.
However, newer samba servers may require the client to communicate with SMB
protocol versions 2 (VISTA) or 2.1 (Windows-7) or 3 (Windows 8), but forbid
SMB1.0.
smbclient by default will use NT1 protocol, which is the highest SMB1
protocol.
smbclient can be told to use maximum protocol number 2 or 3 using the -m
option. For example, the following command will allow smbclient to
communicate with SMB2.0.
$ smbclient -m SMB2 //localhost/myshare
If communicating with Windows server 2012 with encrypted transport,
SMB3.0 will be necessary (since SMB3.0 supports end-to-end encryption).
$ smbclient -m SMB3 //localhost/myshare
------------------------------
| Mounting an SMB share folder |
------------------------------
Mounting a samba share using the command line:
$ mount -t cifs //IP_ADDRESS/folder_name mount_point
For example to mount a usb storage device connected to my router whose
IP address is 10.0.0.100 (the storage device share was named by the router
"usb_storage"):
$ sudo mount -t cifs //10.0.0.100/usb_storage /mnt
To mount as a specific user
$ sudo mount -t cifs -o user=jdoe //10.0.0.100/usb_storage /mnt
To place mounting information in fstab, add a line of the form:
//IP_ADDRESS/folder_name mount_point cifs credentials=credentials_file,rw,uid=user_name,noauto,user 2 1
Some options are specified following the file system type field "cifs".
The credentials option specifies a file containing the password
necessary to gain access to this share.
The rw option specifies that the mounted share can be read and
writen to.
The noauto option is telling the OS not to mount the share
automatically when it becomes available when it becomes available.
The user option is a general mount option that allows an ordinary
user to mount the share.
For more on mount options and specifically smb mount options refer to the
man page:
$ man mount
$ man mount.cifs
If you wish to automount a samba share on boot, enable using systemctl either
systemd-networkd-wait-online.service, or
NetworkManager-wait-online.service
depending which network manager you are using.
When in doubt as to which network manager is active use
$ systemctl list-unit-files | grep NetworkManager|networkd
and see which one is enabled.
For other network managers refer to their documentation as to which service
must be activated.
Alternatively, use systemctl status.
Can also add x-systemd.automount option to /etc/fstab line.
Note, the automount instructions also apply to NFS mounts.
For example:
//10.0.0.100/usb_storage /srv/mymediasrv cifs credentials=/home/jdoe/.smbcredentials,rw,uid=jdoe,gid=jdoe,noauto,user
The file .smbcredential should contain something like
username=jdoe
password=
domain=mediadom
(Leave the password line empty when no credentials are required.)
Alternatively, the added user information can be placed in the fstab line:
//10.0.0.100/usb_storage /srv/mymediasrv cifs username=jdoe,password=,domain=mediadom,rw,uid=jdoe,gid=jdoe,noauto,user
It is usually undesirable to have this information in a public file such as
/etc/fstab, and a credential file is obviously preferred.
If the server permits communication only with SMB versions 2 or 3, this can
be specified in the fstab line as an option (see corresponding option for
smbclient above).
For example:
//IP_ADDRESS/folder_name mount_point cifs vers=2.1,rw,uid=user_name,noauto,user
----------------------------------------------
| File And Directory Ownership And Permissions |
----------------------------------------------
When mounting a samba share, the ownership of directories and files within the
share will those of the mount process (normally root), or of the ownwer and
group specified by the uid/gid options.
For example,
$ mount -t cifs -o user=jdoe,uid=jdoe,gid=workgroup //mypc/myshare /mnt
will mount "myshare" using user "jdoe" (that user's credentials must be
entered for mount to succeed), and apply ownership and group membership
to all files and directories to jdoe and workgroup, respectively.
Note, if in the file system in which myshare sits on, ownership is not that
of jdoe, then you will not be able to read and/or write files to that share,
unless world read/write permissions have been granted.
Unlike with NFS, cifs will not pass along ownership information to the client,
as the following quote from the mount.cifs man page makes clear.
--- Quote from man page mount.cifs ---
The core CIFS protocol does not provide unix ownership information or mode for
files and directories. Because of this, files and directories will generally
appear to be owned by whatever values the uid= or gid= options are set, and
will have permissions set to the default file_mode and dir_mode for the mount.
Attempting to change these values via chmod/chown will return success but have
no effect.
--- End of quote from man page ---
However, this is not entirely true. If you revert back to SMB version 1.0,
it is possible to keep intact ownership information as follows.
In global section of smb.conf file enter:
client min protocol = NT1
min protocol = NT1
unix extensions = yes
Now mount your share as follows
$ mount -t cifs -o user=jdoe,rw,setuids,vers=1.0,posix //192.168.1.100/myshare /mnt
Listing the contents of /mnt
$ ls -l /mnt
You should see correct ownership of files.
Note, this works only between two Unix boxes, and not between a Unix box and a
Windows box.
To see if posix option was actually applied, run command
$ mount | grep myshare
If "nounix" option shows up, then the above didn't work.
To check system messages regarding your mount, check most recent output of dmesg
$ dmesg | tail
You can also use smbclient to browse through your share
$ smbclient -U yaron -m NT1 //space/tmpshare
(the -m NT1 forces SMB version 1.0)
Once in smbclient type
$ posix
This will put you in unix mode.
With that said, it is important to note that SMB version 1.0 is depricated
and deemed unsafe against eavesdroppers, as all traffic (including passwords)
gets passed along in plain text.
POSIX extensions should eventually be implemented in SMB 3.11, and the
Unix extensions should work on it as well.
Sources: bugs.launchpad.net
----------------------
| Samba Advanced Tools |
----------------------
$ smbd -b
Will give a whole list of samba parameters.
To extract the location where private Samba files are located
$ smbd -b | grep PRIVATE_DIR
/var/lib/samba/private
To extract the location where temporary Samba files are located
$ smbd -b | grep LOCKDIR
/var/lib/samba/private
For looking at database files with suffix tdb
$ tdbtool file.tdb
For example
$ tdbtool /var/lib/samba/private/passdb.tdb
At prompt enter the following to display first entry
$ first
At prompt enter the following to display next entry
$ next
To quit
$ quit
To see everything at once
$ tdbdump /var/lib/samba/private/passdb.tdb
See the Samba3-HOWTO for a more advanced description of Samba.
rsync
********************************************************************************
- rsync -
********************************************************************************
rsync is a popular fast and efficient feature rich copying and syncing utility.
It can be used as an enhanced "cp", syncing utility, or mirroring utility.
It can be used to sync files locally or remotely.
When syncing remotely it must be installed on both the source and destination
machines.
----------------
| Usage examples |
----------------
* Using rsync for simple copying:
$ rsync abc.txt ~/backup/
will copy the file abc.txt from the current directory to ~/backup.
If abc.txt is already contained in ~/backup, then rsync will check if the
version there is the same, and if not, it will replace it.
rsync is very efficient in determining if a file needs to be replaced or not.
It is therefore, a much better syncing tool than, say, the cp command, which
will simply overwrite identically names files, whether they are the same or
not.
* rsync can be used to copy files across a network as such
$ rsync abc.txt jdoe@192.168.125.31:docs/
The file abc.txt in the current directory will be synced to the docs directory
in user jdoe's home directory residing on machine whose IP address is
192.168.125.31.
Note, rsync uses ssh to sync files and directories across a network, so it is
deemed as secure as the underlying ssh session.
A common mistake in specifying a remote location is to forget the collon.
For example
$ rsync abc.txt jdoe@192.168.125.31
will copy abc.txt into a new file named "jdoe@192.168.125.31".
% Copying from a remote location to locally
$ rsync jdoe@192.168.125.31:abc.txt .
will copy the file abc.txt to the current directory.
* Copying and renaming
$ rsync abc.txt ~/backup/abc_bak.txt
will copy abc.txt onto ~/backup, renaming it to abc_bak.txt.
* Copy entire directory
$ rsync -R mydir ~/backup/
Copy directory mydir onto ~/backup. This copies not only the parent directory,
but also its contents.
The -R option makes the syncing recursive, that is, rsync will descend into
mydir and copy all of its contents as well. Without it, only the parent
directory, mydir, will be copied.
If you wish to preserve directory and file attributes, including that of
ownership, use the -a option.
$ rsync -a mydir ~/backup/
* To copy the contents of a directory
$ rsync -R mydir/ ~/backup/
This example is very similar to the one above, except that after completing,
~/backup will contain the contents of mydir, but not mydir itself. The
difference in syntax is the slash after mydir. This instructs rsync to only
sync the contents of the directory.
* To copy a file from one user's home directory to another's
$ sudo rsync ~richard/abc.txt ~brian/richards-stuff/
The sudo command is used since normally one user's home directory is not
inaccessible to another user.
* To use rsync on a network using a different port
$ rsync -e "ssh -p 2000" abc.txt 192.168.125.31:/home/jdoe/backup
This copies abc.txt to directory /home/jdoe/backup residing on machine whose IP
address is 192.168.125.31. However, instead of using a standard ssh session
to do the job, it will use ssh as specified by the -e option. That is, using
port 2000.
You must have an ssh daemon running on 192.168.125.31 port 2000 for this to
work. For example, on 192.168.125.31 issue the command
$ sudo /usr/sbin/sshd -D -p 2000
Furthermore, port 2000 must not be blocked by the firewall.
The option -e (in the rsync invocation) allows you to configure the ssh in the
manner you wish the remote communications to occur. This is useful not only
for working with a different port, but also for selecting a different
authentication method, etc.
See rsync man page for more examples
$ man rsync
----------------------
| Rsync in daemon mode |
----------------------
Rsync can also be run in daemon mode.
To create an rsync server you can
* manually run rsync in daemon mode (rsync --daemon ...), or
* install and enable rsyncd.service (in Fedora install rsync-daemon).
(if using xinet to start daemons see appropriate documentation outline
init file)
When running as a server you will need to configure the /etc/rsyncd.conf file.
The following example sets up an rsync module named "backupmod".
# Start of file
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
secrets file = /etc/rsyncd.secrets # file with user names and passwords
port = 873 # that is the default port # make sure it is open to firewall
use chroot = yes # necessary if you want to preserve attributes and time
# stamps (i.e. using rsync -a ...)
[backupmod]
path = /srv/backupsrv
comment = RSYNC MIRROR BACKUP
read only = false
timeout = 300
auth users = jdoe
uid = root
gid = root
# End of file
Explanation of file:
* pid of rsync daemon process will be stored in /var/run/rsyncd.pid
To kill daemon
$ kill `cat /var/run/rsyncd.pid`
* Log file is /var/log/rsync.log
* Password file for authorized users is /etc/rsyncd.secrets
It contains lines of the form
user:password
Make sure to make this file unreadable to "other". I.e.
$ sudo chmod 660 /etc/rsyncd.secrets
* [backupmod]
This starts a module section.
All settings associated with this module follow until the end of file or next
module (whichever comes first).
* path setting
In the example above the root of this module is /srv/backupsrv
A user using rsync with this module will not be able to access other
directories in /srv or /. Anything in /srv/backupsrv is potentially
accessible (if the permissions for the given user allow it).
* auth users setting is a list of users who are allowed to access this module.
Can also deny users. For example
auth users = baduser:deny @badgroup:deny
Will deny access to baduser and to anyone belonging to badgroup.
An accompanying password file (secrets file) must be created, and contain
entries for all authorized users.
Commenting out "auth users" will allow any user to access the module
(as anonymous).
* uid setting and gid setting
This sets the uid and gid of all files being transferred or retrieved
to the given values.
If you want to mirror a directory using the archive option (-a), then set
uid = root
gid = root
This will cause all files to retain their uid.
Without this, rsync will return errors saying it failed to change the owner or
group of the file(s) being transferred.
To see all modules for a given rsync server at IP 10.0.0.10:
$ rsync -t jdoe@10.0.0.10::
To list contents of backupmod
$ rsync -t jdoe@10.0.0.10::backupmod
The following is an example of mirroring the contents of the local directory
testdir to a server running an rsync daemon:
$ rsync -a --delete testdir/ jdoe@10.0.0.10::backupmod
The contents of testdir will be placed in /srv/backupsrv
Equivalently you can use
$ rsync -a --delete testdir/ rsync://jdoe@10.0.0.10/backupmod/
Note, the --delete option ensures that files which are not in testdir, but
which are presently in /srv/backupsrv will be deleted.
Important! remember to unblock the rsync port
Important! Verify that SELinux is not interfering with directory access (see
below for more)
-------------------
| rsync and SELinux |
-------------------
See Chap-managing confined services-rsync
Note, the following is not a comprehensive treatment of rsync with respect to
SELinux (refer to the above source for more details.)
Most basically, a directory/file that is to be accessed by an rsync daemon
in a system which has SELinux set to enforce mode should have an SELinux
context: rsync_data_t
To change the SELinux context for a directory and its contents:
$ chcon -R -t rsync_data_t tgtdir # -R is for recursive descent
Note, the parent directory of "tgtdir" should also be set to that
context. For example
$ chcon -t rsync_data_t /home
If the directory is to be shared with other services, such as samba, nfs, etc.,
then label the context "public_content_t". In such a case other actions might be
required. Such as setting rsync_anon_write boolean to true.
I was having "permission denied" problems. They went away when I set the
following boolean variable
$ sudo setsebool rsync_full_access=on
When preserving attributes with rsync, you must have in "rsyncd.conf" the line
use chroot = yes
This allows the rsync daemon to run as root, so it may modify file permissions
and time stamps on synced files, to match those in the source.
If this isn't done then SELinux will generate AVC denials with "dac_override"
messages in /var/log/audit/audit.log file.
To view the context of a given directory or file use:
$ ls -Z dir|fil
There are SELinux booleans associated with rsync. To list them use:
$ getsebool -a | grep rsync
To get a description of a given boolean use:
$ sepolicy booleans -b boolean_name
(In Fedora, you will need to install "policycoreutils-devel" package for this
command)
e.g.
$ sepolicy booleans -b rsync_anon_write
If using a nonstandard port with rsync (i.e. not 873), then you will need to
allow that port to be used in conjuction with rsync. For that purpose, issue
the command
$ semanage port -a -t rsync_port_t -p tcp port_number
Use netstat to display port status:
$ netstat -lnp | grep port_number
(If it says "LISTEN" that is good)
Diagnosing problems with rsync and SELinux may require scanning the logs.
You can use
$ sealert -a log_file and look for rsync entries to get detailed diagnostics
information. It is a good idea to copy only specific rsync entries in audit.log
into a temporary file and run sealert on that file.
See SELinux section in uniman for more.
See here for more on rsync and SELinux.
----------------------
| Mirroring with rsync |
----------------------
Mirroring can be useful for any number of reasons, amongst them:
* Having a readily available backup of your home directory.
* Maintaining identical repository servers in multiple locations around the
world.
* Keeping your home computer synced with your work computer.
As a simple example, consider mirroring your home directory onto a storage
device mounted onto /mnt:
$ rsync -rlpt -x --delete $HOME/ /mnt
The options utilized are:
* -r = Recursively descend into directories
* -l = Replicate symbolic links
* -p = Preserve file/directory permissions
* -t = Preserve file/directory time stamps
* -x = Don't cross file system boundaries. For example if you have another
file system mounted somewhere in your home directory, then do not descend
into the directory structure of that file system. This is obviously very
useful if you have a share mount mapped somewhere in your home directory,
which you do not want to replicate, because it is not yours.
* --delete = delete files and directories in destination (/mnt) which are not
in $HOME. For instance if foo.txt was in /mnt but not in $HOME, then
it will be deleted from /mnt.
Warning! Use the delete option very carefully, as it will irreversibly
erase files at the destination.
To exclude directories or files when mirroring with rsync you could use
the "--exclude" option.
For example to mirror your home directory excluding files with the iso
extention (which tend to be large) onto a backup partition mounted as /mnt:
$ rsync -rlpt -x --delete --exclude "*.iso" $HOME/ /mnt
The exclude option uses regular expressions and is very powerful. Refer
to the man page for more.
Windows
********************************************************************************
- Windows -
********************************************************************************
----------------------
| Administration tools |
----------------------
Windows has default networking and internet connection administration tools.
Before using their tools verify that the system doesn't come with its own
set of tools that override the Windows tools. For instance the lenovo
ThinkVantage comes with "Access Connections".
---------------------------
| Security related software |
---------------------------
Consider the effect of various security and Anti-Virus programs (e.g. Norton) as
well as firewalls running on the computer. This may disable the ability of your
Windows machine to network with other computers on the network.
So even though internet access is working fine, file sharing might not. If you
see problems, disable as much of such software as possible, and see if that
fixes the problem.
-------------------------
| Setting up file sharing |
-------------------------
In windows XP goto to control panel and run Network Setup Wizard.
Do this for each computer for which you wish to enable file sharing.
When choosing a workgroup make sure you choose the same one as on the
other computers on your network.
Individual folders may be made accessible to other users on the same
computer, as well as accessible to other users on the network.
This is accomplished by right clicking on the folder, bringing up the
properties dialogue box, and selecting the sharing tab.
To view the NetBIOS (Network Basic Input/Output System) name table of
the various computers and workgroups on the network type in a command
prompt (can be a command prompt shell, powershell or cygwin terminal):
$ nbtstat -n
-------------------------
| Mapping a network drive |
-------------------------
Right click on "My Computer" and select "map network drive".
In the dialog box that appears type the name of remote folder you wish to share
and press finish.
For example
\\10.0.0.10\testfolder
or
\\10.0.0.100\usb_storage
You can choose which drive letter will be associated with the network drive
(e.g. U).
To map a virtualbox share drive use: \\vboxsvr\sharename
Most routers offer a usb port (or two) to which an external usb drive may be
connected and shared. To configure such an arrangement, whereby all computers
connected to the router are able to use this drive, do as follows:
* Connect the drive.
* Configure the router to share the drive (if not already).
* Determine the share names given to the FAT32/NTFS partitions
on the connected drive.
* On each computer, map to a drive as described above.
Note, if a password is being requested it is probably not working.
Try reseting the router, switch it off and back on, etc.
NFS
********************************************************************************
- NFS -
********************************************************************************
NFS is an acronym for "Network File System".
NFS software comes with two main components:
* NFS server
Handled by systemd service: nfs-service.service
* NFS client
Handled by systemd service: nfs-client.service (or nfs.service)
If NFS file locking is desired then the services rpc.statd and rpc.lockd
must be run on both server and client.
See also nfs-lock.service
----------------------------
| NFS - Server configuration |
----------------------------
The following instructions are for configuring a basic NFS share.
For more details refer to NFS Server HOWTO.
Two things must be done to setup an NFS server installation:
* Set up NFS script files:
/etc/exports (for more info issue command "man 5 exports")
This file is used to tell the NFS server who can mount a given directory.
e.g. To allow machine 10.0.0.10 to mount rw /home/user/exportdir nfs share
include the following line in this file:
/home/user/exportdir 10.0.0.10(rw,sync,no_subtree_check)
e.g. To allow anyone on 10.0.0.0/24 subnet to mount rw /home/storage nfs
share, include line:
/home/storage 10.0.0.*(rw,sync,no_subtree_check)
After modifying /etc/exports, you'll need to refresh exports. To do so
issue the command
$ sudo exportfs -a
/etc/hosts.allow (for more info issue "man 5 hosts_options" and "man 5 hosts_access")
This file is used to tell the NFS server who can communicate with the NFS
server.
e.g. To allow all hosts on 10.0.0.0/24 subnet to communicate with NFS server,
include line:
ALL: 10.0.0.
/etc/hosts.deny
This file is used to tell the NFS server who to not communicate with
(i.e. blacklisting machines and/or networks).
* Run NFS daemons
In a systemd setup use "systemctl" to enable/start various NFS daemons.
$ systemctl enable nfs-server.service # enables nfs server
To show rpcinfo
$ rpcinfo -p server_IP
In the output look for nfs lines which indicate client can talk to NFS server.
To show possible mount shares
$ showmount -e server_IP
e.g.
$ showmount -e 10.0.0.1
To mount an nfs share onto /mnt
$ mount 10.0.0.1:/home/user/myshare/ /mnt
To mount nfs share with /etc/fstab entries
10.0.0.1:/home/user/myshare /mountpoint nfs rw,sync,no_subtree_check,nofail 0 0
-----------------
| NFS and Firwall |
-----------------
If firewall is active, then enable the following ports:
nfs (2049 tcp), nfs3 (2049 tcp/udp) and rpc-bind (111) ports
-----------------
| NFS and SELinux |
-----------------
If you suspect SELinux is interfering with correct NFS operation, then see if
disabling SELinux helps.
$ setenforce 0
If having problems reading or writing to NFS mounts and SELinux is active, try
$ setsebool -P nfs_export_all_rw 1
$ setsebool -P nfs_export_all_ro 1
To display the state of nfs related boolean values
$ getsebool -a | grep nfs
Perhaps can change file context in similar way as in Samba
$ chcon -R -t ??? nfs_share_dir
----------------------------
| NFS - Client configuration |
----------------------------
For more details refer to the NFS client HOWTO.
Start rpcbind.service, nfs-client.target and remote-fs.target
$ sudo systemctl start rpcbind.service
$ sudo systemctl start nfs-client.target
$ sudo systemctl start remote-fs.target
Enable them to make persistent across boots.
NFS mounts can be mounted manually. For example
$ sudo mount -t nfs server_IP:/home/jdoe/nfsshares/myshare /mnt
NFS mounts can be configured to mount at boot time using an fstab entry such as:
# device mountpoint fs-type options dump fsckorder
master.foo.com:/home /mnt nfs rw 0 0
It is also reccomended to add the hard and intr options.
hard - makes the nfs request hang till it is answered.
(soft makes nfs-client send an error if the file is inaccessible for some
reason. This can cause problems with some programs)
intr - allows the nfs request to be aborted by an interupt
If you wish to automount an NFS share on boot, enable with systectl either
systemd-networkd-wait-online.service or NetworkManager-wait-online.service,
depending which one you use.
If you are not sure which one, then issue the command
$ systemctl list-unit-files | grep NetworkManager|networkd
and see which one shows up.
Can also add x-systemd.automount option to /etc/fstab line.
(Note, automount instructions also apply to SAMBA mounts)
TLS/SSL Certificates
********************************************************************************
- TLS/SSL Certificates -
********************************************************************************
Certificates are the mechanism by which sites are verified as being secure
for https transactions and the like.
For a detailed HOWTO on certificates refer to the SSL Certificates HOWTO.
On a linux system trusted certificates are stored in /etc/ssl/certs.
Private keys are stored in /etc/ssl/private
Note, private keys should always be owned by root.root, and have permissions
0600.
There are three certificate formats
* DER
* PEM
* NET (obselete)
The PEM format is commonly used by browsers.
PEM Certificate files can take on a few suffixes:
.pem .crt .cer
The PEM format uses the header and footer lines:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Most browsers have a certificate management utility in preferences or settings.
--------------------------------------
| Importing and exporting Certificates |
--------------------------------------
Firefox uses .crt certificates.
You can use Firefox's certificate management utility to export it to
.pem or .cer format (which is what sits in /etc/ssl/certs).
Note: *.reg files are intended for Windows. They are registery entires
and are not useful for Linux.
If you have a certificate such as "myca.crt", you can import it into firefox
or Google Chrome or any browser with a certificate manager by navigating to:
In Firefox:
Preferences : advanced : certificates (tab) : view certificates
: import certificate
In Chrome:
Settings : HTTPS/SSL:Manage Certificates : Import
---------------------------
| Manipulating certificates |
---------------------------
openssl can be used to manipulate, convert and sign certificates.
For example, to translate from crt to pem using openssl:
$ openssl x509 -inform DES -in certname.crt -out certname.pem -text
To read more about openssl x509
$ man x509
For generating and signing certificates using openssl refer to the
SSL Certificates HOWTO
----------------------------------
| Bypassing certificate Validation |
----------------------------------
Warning! Bypassing certificate validation can expose your computer to
man-in-the-middle attacks, and other malicious activity. Use with care
and only when you trust the website involved.
Programs which use curl to download files from the web will run into
problems when accessing https websites if the certificate is untrusted.
If you trust the website you can use the -k (or --insecure) option
to bypass certificate validation.
If using makepkg which uses curl, go to "/etc/makepkg.conf"
Look for DLAGENTS=(... in beginning of config file.
This file contains the downloading agents to be used for different protocols.
For websites or ftp sites "/usr/bin/curl" is used.
Add -k option to 'https::/usr/bin/curl -fLC - ..."
That is: https::/usr/bin/curl -k -fLC - ...
dnf, pacman and aptget use ssl certificates to verify authenticity of
packages.
In order to disable ssl verification in dnf edit file /etc/dnf/dnf.conf
and add a line "sslverify=false"
(This may arise when using a proxy for which you don't have a trusted
certificate installed.)
Typical default path to ssl certificates is /etc/ssl/certs.
dnf allows customization of paths by setting options sslcacert, sslclientcert.
See dnf.conf man page for more.
----------------------
| Viewing certificates |
----------------------
To view certificates in a tablet or smartphone, you will need to navigate
through settings. Each phone or tablet may have slight variations
in navigating to the correct setting, so consider the following as a rough
guideline.
* For one phone I have I navigated as follows:
Settings : Security and location (Advanced) : Encryption and Credentials :
Trusted credentials
* Another example for a tablet or smartphone:
Settings : Security and location (Advanced) : Encryption and Credentials :
Install from SD Card
* Ipad/Ipod
Settings : General : About : Certificate Trust Settings
: Turn on "Enable full trust for root certificates"
"Name of certificate"
--------
| Chrome |
--------
Many Web browsers have a certificate manager.
Google Chrome in Linux didn't use have one, although now it does (note, could be
it had and I didn't know where to find it). It used to rely on the NSS Shared
DB (see below).
To access Chrome's certificate manager select "Settings" from the Chrome's menu.
Scroll all the way down till you see "Advanced" and press. More options will
appear. Keep scrolling until you encounter the "Manage certificates" entry.
---------------
| NSS shared DB |
---------------
Utilities that don't have their own certificate manager, such as command line
web access utilities (e.g. wget, curl) use the system's certificates.
To my knowledge Linux (unlike Windows) doesn't have its own centralized
certificate handling mechanism.
The NSS shared DB is a project that aims to become one.
If relying on the NSS shared DB, then to add SSL certificates to the database
utilize the command line utility: certutil
Note, in fedora it comes bundled with the nss-tools package.
An example of adding the certificate "Netspark.crt" to NSS
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "Netspark" -i Netspark.crt
The options utilized are:
-d specifies the directory in which to store the certificate
-t specifies trust attributes
-n specifies the certificate nickname
-i specifies the input file
The above command will store the Netspark certificate in the local
NSS database (for the given user).
To verify that it has been added use certutil and see if it is listed:
$ certutil -L -d sql:$HOME/.pki/nssdb
nss-gui is a graphical tool to manage certificates and more in the NSS database.
See man page for more info.
NAT and Port Forwarding
********************************************************************************
- NAT and Port Forwarding -
********************************************************************************
(See also related subsection Iptables Example).
I shall use an example to illustrate port forwarding.
In this example I would like computers on the WAN to connect to LAN address
10.0.0.9 on port 25565. To do this you must first obtain the router's gateway
address (this is the address that the world uses to interface to the router and
is usually dynamically allocated to your router by your ISP).
Login to your router's management interface with any web browser.
In this example I am using netgear router DGN2200v2.
***
For this router, the router's gateway address can be obtained by navigating
the web managment interface with either
Maintenance : Router Status
or
Setup : Basic settings : Internet IP Address
Router Gateway address:
Dynamically allocated (presently 95.86.114.60)
The router does give you an option to set a static IP address
(see Basic Settings : Internet IP Address) by checking appropriate button.
However, when I tried this, it didn't work, as I probably have to make an
arrangement with the ISP for a static IP.
***
Next you would like to identify the computer running the server on your LAN.
Using LAN Setup, set the computer to obtain a static LAN IP address.
In the case of this example the relevant information is:
Jon's PC:
* MAC address
00:1a:4d:2c:c0:4a
* IP address (LAN)
10.0.0.5
***
Next you might need to define a service.
The router's firewall rules comes with a number of predefined services like
HTTP:80 (web access on port 80)
HTTPS:443 (web access on port 443)
In general a service is something like TCP/port# or TCP/port#range.
I defined a service called gamesrv to be TCP/25565
This means that this service only allows port 25565 to be accessed using the
TCP protocol.
Note TCP, UDP and TCP/UDP are the available protocol choices.
***
Once you identified the service you need, or defined a custom service,
you will need to set up an inbound rule.
To understand what the inbound rule does, you have to understand how the router
manages internet traffic.
On one side of your router is your LAN.
On the other side is the ISP which is your gateway to the rest of the internet.
Your LAN is in principle hidden from the rest of the world.
Any IP address assigned by your router to connected devices on the LAN
are not directly accessible from the rest of the world.
For example your router might assign IP addresses in the range 10.0.0.1 to
10.0.0.32 to your different LAN devices.
As an aside, The IP protocol has defined three address ranges that are meant to
be only visible within a LAN. The 10.0.0.0/24 network address range is the
largest such address range. Therefore, any address 10.x.x.x is not a legal
internet address and is only legal within LANs.
Your ISP's routers, as well as global internet backbone routers will discard
traffic destined to addresses within this range.
Now in order for your LAN to communicate with the outside world, the router
must strip the outgoing network packets of the LAN address (e.g. 10.0.0.5), and
substitute the gateway address (e.g. 95.86.114.60) in its place.
This technique is called Network Address Translation (NAT).
Any computer or server that now receives packets originating from your LAN will
know to return packets back to the gateway (i.e. 95.86.114.60 which is your
router interface to the ISP), rather than to the ficticious address 10.0.0.5.
Of course, your router has to know that a returning packet must be forwarded
to address 10.0.0.5 rather than say 10.0.0.3.
For that, the router keeps a record of which packet was sent to where, and when
a return packet arrives, it uses its routing table to decide to which LAN IP it
must return the packet. Once decided it strips the return packet of the
gateway's address and substitutes the LAN address (i.e. 10.0.0.5).
With this background we can now explain an inbound rule.
When a computer on the internet accesses your server it uses your router's
gateway address as a destination address.
If you know that all requests for port 65565 are intended for your server,
gamesrv, then you define an inbound (firewall) rule telling the router
to forward all packets associated with this port to the LAN address where
gamesrv resides (i.e. 10.0.0.5). Note, if you have two servers running
on your LAN using the same port, this method will not work, as it is impossible
to know to which server to forward the incoming packets.
In such a case you will need to setup the servers to use two different ports.
*** Diagnostics of port forwarding
Your system may come with port forwarding disabled.
To check, issue the command
$ sudo sysctl net.ipv4.ip_forward
If port forward is enabled, you should get
net.ipv4.ip_forward = 1
If its disabled, you get
net.ipv4.ip_forward = 0
To enable port forwarding, edit the file /etc/sysctl.conf
Add the line
net.ipv4.ip_forward = 1
To have this take effect, issue
$ sudo sysctl -p
or
$ sysctl --system
To check if forwarding is working, issue the command
$ iptables -L -v -n
Look at the FORWARD section. If you get something like
Chain FORWARD (policy ACCEPT 537 packets, 13732 bytes)
then packets are being forwarded.
If you get something like
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
then no packets are being forwarded.
For more see here.
Network Diagnostic Tools
********************************************************************************
- Network Diagnostic Tools -
********************************************************************************
---------
| tcpdump |
---------
tcpdump is a tool to dump network traffic to standard output. It comes with
many options that affect its behavior. Its most important argument is an
expression that is used to specify packets of interest. General invocation is
$ tcpdump [ options ] [ expression ]
The syntax of expression is described in a separate manpage
$ man pcap-filter
Some basic examples will follow shortly.
tcpdump is not limited to IPv4 traffic. It will also display IPv6 traffic, ARP
messages, and others. See above man page for a complete listing.
tcpdump has many options.
Use option -n to display IP numbers rather than DNS names.
Use option -nn to display protocol and port numbers rather than names.
Various levels of verbosity are specified with -v, -vv and -vvv.
Some examples:
To list all available interfaces
$ tcpdump --list-interfaces
* To list all packets containing address of host 10.0.10.20
$ tcpdump host 10.0.10.20
* To do as in previous example, but listen only on interface eth0
$ tcpdump -i eth0 host 10.0.10.20
* To list all packets whose source address is 10.0.10.26, and do not convert
IP addresses to names
$ tcpdump -n src host 10.0.10.26
* To list all packets destined to address 10.0.10.5
$ tcpdump dst host 10.0.10.5
* To list all packets on port 80 (http) and 443 (https)
$ tcpdump port 80 or port 443
Alternatively
$ tcpdump port http or port https
* To list all packets on port 20022 orginating from address 8.8.8.8
$ tcpdump eno1 src host 8.8.8.8 and tcp port 20022
Note, the use of "or" in the above example. Other permitted boolean expression
are "not", "and"
Parenthesis can be used to group primitives. For example
(host 10.0.10.4 and port http) or (host 10.0.10.8 and port https)
Note, when entering the expression in a shell, the parenthesis must be escaped
as as to be interpreted correctly. i.e. \( and \). The above example would
be invoked in the shell as such
$ tcpdump \(host 10.0.10.4 and port http\) or \(host 10.0.10.8 and port https\)
For more examples see here.
---------
| netstat |
---------
netstat is a useful network diagnostic tool. The command name is short
for network statistics. According to the manpage it can be used to
print network connections, routing tables, interface statistics, masquerade
connections, and multicast memberships.
See this short tutorial for a good introduction to netstat.
Normally netstat lists connections specifying the host/domain names rather than
IP addresses. Use the -n option to specify connections in terms of IP address:
$ netstat -n
Note, this will also save on network traffic by eliminating DNS reverse lookups.
Invoking netstat without specifying the type of connection will likely flood
you with connection statistics you are not interested in. For example unix
sockets. It is thus recommended to limit the output to the type of connections
you interested in. For example
To limit statistics to only tcp connections, issue
$ netstat -t
To include also udp connections, issue
$ netstat -t -u
For the many other options and features refer to the manpage
$ man netstat
WiFi
********************************************************************************
- WiFi -
********************************************************************************
-------------------------------
| WiFi network management tools |
-------------------------------
* iw
iw is use to show and configure wireless devices.
It is a similar tool to ip for wireless.
See subsection iw for more.
* iwconfig
Similar to ifconfig, except for wireless.
* wpa_supplicant
This is technically not a network management tool, but rather an
authentication/encryption software package for wireless networks.
Refer to its man page for more
$ man wpa_supplicant
---------
| Drivers |
---------
Software drivers are much more of an issue with wireless devices than they are
with wired/ethernet devices. Wireless hardware often comes with proprietary
drivers, and has not always been made available by the manufacturer for Unix
like systems.
In some cases the drivers have been reverse engineered.
In other cases the manufacturer makes them available, but the user has to
download the software and firmware for his hardware and install it separately
from the OS. This installation step is not always straight forward.
Any wireless devices, whether an internal wireless module in a laptop,
a wireless dongle, or a wireless PCI device, is based on a particular
chipset. Vendors of wireless hardware may use different chipsets in
their line of products, so different products from the same company
may require different drivers.
Linux distributions usually come bundled with a set of standard wireless
drivers. These are loaded onto the kernel as modules. It is imperative
that the right modules be loaded for the correct operation of the wireless
hardware.
Often times a generic (e.g. reverse engineered driver) is loaded, which
clashes with a driver that is subsequently installed to operate with specific
hardware. In this case it may be necessary to blacklist the generic driver
so as not interfere with the correct driver.
The directory in which to find the modules conf files (e.g. for blacklisting):
/etc/modprobe.d/
For example a line in /etc/modprobe.d/blacklist.conf for blacklisting the wl driver
blacklist wl
How to go about determining the correct chipset for your wireless hardware,
and which module goes with it is beyond the scope of this guide.
A good reference on wireless devices and Linux is wireless.wiki.kernel.org.
The following should give a small illustration of using internet sources for
selecting the correct module for a Broadcom wireless chip.
For Broadcom wireless refer to:
Broadcom wireless
B43 hardware list
Drivers available:
* Kernel driver mainline version (recommended)
brcm80211 - split into two:
brcmsmac (PCIe) - is a mac80211-based SoftMAC driver
brcmfmac (SDIO/USB) - is a FullMAC driver
* Reversed engineered driver
b43 - for any new (supported) hardware
b43legacy - for BCM4301 and early BCM4306 versions
* Broadcom driver with restricted license
broadcom-wl
broadcom-wl-dkms (Kernel agnostic driver)
Besides drivers, you may need firmware as well.
Firmware resides in /lib/firmware or /lib64/firmware
* Example of determining a correct driver for an Asus Laptop
$ lspci -vnn -d 14e4:
01:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01)
Subsystem: AzureWave BCM4313 802.11bgn Wireless Network Adapter [1a3b:2047]
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fea00000 (64-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: bcma-pci-bridge
Kernel modules: bcma
From wireless.wiki.kernel.org - brcm80211
driver (PCIe), brcmfmac (SDIO/USB): brcmsmac
* Example of determining a correct driver for an HP Laptop
$ lspci -v
01:00.0 Network controller: Broadcom Limited BCM4312 802.11b/g LP-PHY (rev 01)
Subsystem: Hewlett-Packard Company Device 365e
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: wl
Kernel modules: ssb, wl
To see which WiFi modules are loaded:
$ lsmod | egrep "ssb|wl|bcma|b43"
(Add other modules names to the egrep string if you are aware of any)
----
| IW |
----
The following is a short illustration of using iw. For more detail on iw
refer to the Archlinux Wiki on Wireless.
First unblock all wireless devices:
$ rfkill unblock all
To list all wireless devices and their capabilities:
$ iw list
Check if your wireless is up or down:
$ ip link show dev interface
e.g.
$ ip link show dev wlan0
Look for up/down inside brackets "<...,UP>" (ignore DOWN/UP further down the
line.)
To discover access points:
$ iw dev interface scan
e.g.
$ iw dev wlan0 scan | less
To connect to an access point without encryption
$ iw dev interface connect "the_essid"
To connect to an access point with WEP encryption
$ iw dev interface connect "the_essid" key 0:your_key # Using a hexadecimal or
# ASCII key (the format is distinguished automatically, because a WEP key
# has a fixed length)
$ iw dev interface connect "the_essid" key d:2:your_key # Using a hexadecimal
# or ASCII key, specifying the third setup key as default (keys are
# counted from zero, four are possible)
To check conection:
$ iw dev interface link
e.g.
$ iw dev wlan0 link
Note, wireless interfaces are often named wlan0 or wlan1, but not necessarily.
Use "ip link" or "ifconfig" to list all interfaces.
------------
| Arch Linux |
------------
* broadcom-wl
To install broadcom-wl (with dkms - allows automatic upgrading of wl with
kernel upgrades)
$ pacman -S broadcom-wl-dkms
Will be prompted to reboot, or do the following without rebooting:
$ rmmod b43 b43legacy bcm43xx bcma brcm80211 brcmfmac brcmsmac ssb wl
$ modprobe wl
On my asus laptop eeepc with a "BCM4313 802.11bgn Wireless Network Adapter"
wl module doesn't appear to work. It had worked before and mysteriously
ceased to work.
* b43
Suport for cores revision 0x17 and 0x18 disabled by module param
allhwsupport=0.
Try b43.allhwsupport=1
$ modprobe b43 allhwsupport=1
or in /etc/modprobe.d/*.conf insert line:
options b43 allhwsupport=1
--------
| Debian |
--------
This is about a Debian installation for which the correct WiFi driver doesn't
come out of the box. You will need to do something like this:
$ apt-get update
$ dpkg --add-architecture i386
$ apt-get update
$ apt-get linux-headers-$(uname -r|sed 's,[^-]*[^-]*-,,')
# e.g. linux-headers-4.9.193-antix.1-486-smp
$ apt-get install libavcodec-extra
$ apt-get install firmware-linux-nonfree
$ sudo apt-get install wireless-tools
$ sudo apt-get install network-manager-gnome
For Broadcom:
$ apt-get install broadcom-sta-dkms
# reboot
For Realtek rtl8812au (or eu):
$ sudo apt-get install linux-headers-generic build-essential git
# (If Linux headers were already installed, get remove "linux-headers-generic"
# from above line)
$ git clone https://github.com/scrivy/rtl8812AU 8821AU linux.git
$ make
$ sudo make install
$ sudo modprobe rtl8812au
--------
| rfkill |
--------
To list WiFi/bluetooth soft/hard blocking status
$ rfkill
The following is a quote from Archlinux Wiki page Rfkill-caveat
Rfkill caveat
-------------
Many laptops have a hardware button (or switch) to turn off wireless card,
however, the card can also be blocked by kernel. This can be handled by rfkill.
To show the current status:
$ rfkill list
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: yes
If the card is hard-blocked, use the hardware button (switch) to unblock it.
If the card is not hard-blocked but soft-blocked, use the following command:
$ rfkill unblock wifi
Note: It is possible that the card will go from hard-blocked and soft-unblocked
state into hard-unblocked and soft-blocked state by pressing the hardware
button (i.e. the soft-blocked bit is just switched no matter what). This can
be adjusted by tuning some options of the rfkill kernel module.
Hardware buttons to toggle wireless cards are handled by a vendor specific
kernel module, frequently these are WMI modules. Particularly for very new
hardware models, it happens that the model is not fully supported in the latest
stable kernel yet. In this case it often helps to search the kernel bug
tracker for information and report the model to the maintainer of the
respective vendor kernel module, if it has not happened already.
WiFi Access Point
********************************************************************************
- WiFi Access Point -
********************************************************************************
Explained in this section is how to create a WiFi access point using a
computer/laptop with WiFi hardware.
Adpated from Archlinux Wiki - Software Access Point
Further reading can be found in:
* Archlinux and Ubuntu installations
Hostapd - the linux way to create virtual wifi access point
* Another example for a ubuntu installation
Create wireless access point hostapd
See also Archlinux WIKI for general background on networks and WiFi:
* A detailed description of configuring wireless interfaces
Archlinux Wiki - Wireless network configuration
* Using Netctl to manage networks using profiles
Archlinux Wiki - Netctl
* Configuring network interfaces
Archlinux Wiki - Network interfaces
The procedure for creating a WiFi access point can be divided in to two parts:
--------
| Part I | - Setting up the Wi-Fi link layer
--------
This will allow wireless clients to see your computer's software
access point and exchange packets with it. It will not, however,
give them internet functionality. That will be dealt with in Part II).
These are the steps involved:
1. Get some info about your wireless device.
* Hardware:
$ lspci -k
(look for Network Controller section in the output)
Check for WiFi chipset.
According to the Arch WIKI a special addon "hostapd-rtl871xdrv"
is required for hostapd for RTL8192CU chipset.
* Interface name:
$ ip link
(look for interface associated with wireless device)
e.g. wlp1s0b1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
mode DEFAULT group default qlen 1000
link/ether 2e:ba:ad:dc:f7:b0 brd ff:ff:ff:ff:ff:ff
"UP" in the <> triangle brackets means the interface is up and running (ignore the
"DOWN" later on).
Take note of interface name "wlp1s0b1"
If it is down:
$ ip link set wlp1s0b1 up
2. Install iw (manipulate wireless devices and their configuration)
(iwconfig is a similar software package)
iw list | grep "Supported interface modes" -A 8
(-A 8 option in grep will display a total of 8 lines for each search item
that's found)
3. Install hostapd software
4. Create a configuration file /etc/hostapd/hostapd.conf
(check /usr/share/doc/hostapd directory for example configuration files)
A simple example:
# use ip link to determine interface name for WiFi device
interface=wlp1s0b1
# Pick whatever you like for SSID
ssid=Example-WLAN
hw_mode=g
wpa=2
wpa_passphrase=PASS
wpa_key_mgmt=WPA-PSK WPA-EAP WPA-PSK-SHA256 WPA-EAP-SHA256
5. Test hostapd
$ hostapd /etc/hostapd/hostapd.conf
At first I got an error:
Configuration file: /etc/hostapd/hostapd.conf
nl80211: Could not configure driver mode
nl80211: deinit ifname=wlp1s0b1 disabled_11b_rates=0
nl80211 driver initialization failed.
wlp1s0b1: interface state UNINITIALIZED->DISABLED
wlp1s0b1: AP-DISABLED
hostapd_free_hapd_data: Interface wlp1s0b1 wasn't started
I followed advice in link
to turn off NetworkManager's handling of WiFi.
$ nmcli radio wifi off
$ rfkill unblock wlan
With hostapd running I was able to detect the WiFi service.
This can be made persistent across boots by masking the WiFi device
in the NetworkManager configuration files:
You can mask the device using its MAC:
edit /etc/NetworkManager/NetworkManager.conf
[keyfile]
unmanaged-devices=mac:
or mask the interface name:
[keyfile]
unmanaged-devices=interface-name:
Substitute accordingly.
---------
| Part II | - Network Configuration - Bridge method
---------
Modifying the network configuration on the host computer is essential
in order that the software access point properly relays IP packets
between the host computer and wireless clients.
6. Create a network interface configuration for the WLAN card
(to only run in an access point mode).
The following options are available to link the access point to
your computer's internet.
* Create bridge network
* Create NAT network
* Use create_ap package to automate creation of bridge or NAT
6-A. Bridge network
$ ip link add name mybridge type bridge # (creates a new bridge)
Let's say you want to incorporate interface enp2s0 into the bridge.
First make sure its up
$ ip link enp2s0 up
Add into bridge
$ ip link set enp2s0 master mybridge
Verify that enp2s0 is part of mybridge
$ bridge link
If you wish to remove the added interface from mybridge
$ ip link set enp2s0 nomaster
To delete a bridge
$ ip link delete mybridge type bridge
(This subsection and the next are incomplete)
6-B. NAT network
6-C. create_ap
This is by far the simplest.
It is a script that actives hostapd and sets up the network (either bridge
or NAT, as specified by options)
Simply type (in root mode)
$ create_ap --country IL wlp1s0b1 enp2s0 "Asus-WiFi" "mypassword"
No need to configure or run hostapd, or disable WiFi device from NetworkManager.
create_ap sets up everything.
There is also an option to generate a configuration file which will be
activated across boots.
# ***** TEMP
Example for seravo.fi (file needs to be in /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet static
hostapd /etc/hostapd/hostapd.conf
address 192.168.8.1
netmask 255.255.255.0
Archlinux uses netctl, so I adapt the above configuration accordingly.
Directory where user defined network interfaces can be added/modfied:
/etc/netctl/interfaces
# ***** end of TEMP
TP-link WiFi Access Point
********************************************************************************
- TP-link WiFi Access Point -
********************************************************************************
To setup the WiFi access point device, initially plug it to the router.
Check connected devices on the router and identify the WiFi access point device.
Use a web browser to connect to that address (e.g. http://10.0.0.17).
Look up the MAC address of the AP, and configure the file /etc/dhcp/dhcpd.conf
so as to associate this MAC address with a fixed IP.
For example
subnet 10.0.2.0 netmask 255.255.255.0 {
...
host tplink-hotspot {
hardware ethernet 00:00:00:00:00:00; # subsitute devices MAC address
fixed-address 10.0.2.137;
}
}
Change network name to whatever you want your home WiFi network to be
called. Fore example house-wifi (original TP-LINK_AP_EFF0)
Qemu and Networking
********************************************************************************
- Qemu and Networking -
********************************************************************************
------------------------------
| Guest-to-host communications |
------------------------------
If your guest machine uses a mactap backend for its networking,
it will generally not be able to see the host machine.
ping-ing or ssh-ing the host will not work.
(note this is not true the other way, as the virtual machine gets
assigned an IP address on the LAN)
In order to enable a guest to see the host, a virtual host-only network
must be established, and a second network interface device added to
the virtual machine.
The following procedure is taken from link
1. Install package for virsh (name?)
2. Create a file containing something like this:
<![CDATA[<network>
<name>isolated</name>
<ip address='192.168.254.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.254.2' end='192.168.254.254' />
</dhcp>
</ip>
</network>]]>
You can create and place this file in /tmp, /etc or some other location, as you
please. Once configured (as shown below), it need not be retained, although it
is a good idea to keep a copy.
Note, when viewing in editor ignore the "xmp" html directives at the beginning
and end of the segment. These are included so that the xml code displays
correctly on a web browser, and are not part of the file.
"isolated" is the name of the virtual network (subsitute a different name if
you like).
Private network's address range is 192.168.254.1 - 192.168.254.255
Host's (gateway's) address will be 192.168.254.1
You can also tell the DHCP server to reserve a particular IP address for a
given host. For example, to reserve address 192.168.254.30 to "myserver"
insert the following line after the XML element <range .../>
VNC
********************************************************************************
- VNC -
********************************************************************************
------------
| Background |
------------
There are a few methods to access graphical applications remotely. Here are
three that I am familiar with:
* VNC - Virtual Network Computing
This a popular open format for sharing a graphical desktop between two
computers. It is OS independent and can thus be used for sharing any type of
window manager or desktop environment (e.g. FVWM, gnome, LXDE, Windows 10,
Windows XP, etc.).
VNC server software needs to run on the host, and a VNC client application on
the client side.
For example, to access the desktop of a Linux host on a Windows client,
a VNC server is launched on the Linux side, and the Linux desktop remotely via
a VNC client app on the Windows side.
VNC software is also available for phones and tablets, allowing one to
establish a graphical connection with their desktop or laptop computer through
their phone/tablet.
* RDP - Remote Desktop Protocol
This is a propriety protocol created by Microsoft to handle remote desktop
communications. It is primarly used to share a Windows desktop enviornment
between a host and a client. Once connected the host's desktop appears on the
client's screen, and the client can launch applications and perform
administrative tasks as though he is physically present at the host. Remote
desktop is often used by system administrators to correct problems in the
user's computer without having to send a technician to the physical machine,
or to demonstrate remotely how to use a particular software product.
* X-Server
The X window system, follows a client server model architecture, and supports
graphics over a network, natively. See here for more about it.
* Citrix Server and Clients
This is a commercial product that has been around since at least the early
part of the century and has been used by businesses to provide a telecommuting
option to its employees, as well as a unified workspace experience with
centrally located applications and data.
I will focus here on VNC. To use VNC you will need to install a VNC server on
the host side, and a VNC viewer on the client side. There are a number of VNC
software packages available for free. I will discuss TigerVNC which is available
for Linux, Windows and MAC.
I will describe the installation and setup procedure specificaly for Linux
using TigerVNC.
-------------------------
| TigerVNC - Introduction |
-------------------------
On the server side, install the Tiger VNC server package. In Fedora
$ sudo dnf install tigervnc-server
On the client side, install the Tiger VNC viewer.
$ sudo dnf install tigervnc
Once installed I highly recommend reading the HOWTO document
$ less /usr/share/doc/tigervnc/HOWTO.md
It will describe for you in detail how to configure a VNC file.
That said, I provide a brief (and less detailed) description of the
configuration and startup procedure that's based on the above HOWTO, as well as
this entry in Fedora Docs.
The real work horse on the server side is Xvnc. However, for ordinary
purposes you are unlikely to have to deal with it directly.
Xvnc, essentially acts as an X-server, awaiting graphics rendering instructions
from the client. If run by itself no window manager or desktop session is
launched.
A different application, vncsession, handles launching Xvnc with the
appropriate options and starting a Window Manger for a given user session.
It too, however, is rarely launched directly. Rather, it is initiated by the
system service manager as will be described below.
However, before describing the procedure via the system service manager, I will
make brief mention of an easy method being phased out using a wrapper script
written in Perl called vncserver.
Note, if you don't have this utility, then it has probably been phased out
from your distribution.
-------------------------------------
| TigerVNC setup via vncserver script |
-------------------------------------
Invoke the script as follows
$ vncserver :displaynumber
Replace displaynumber with a number greater than or equal to 1.
For example, to start a VNC server on display 3
$ vncserver :3
If display 3 is already taken by a different session, the script will exit with
an error message. In that case try with a different number.
If you don't specify a display number, vncserver will pick the first available
display number.
To terminate the VNC session, shut down the server
$ vncserver -kill :displaynumber
For example
$ vncserver -kill :3
An important configuration file is xstartup. It is similar in function
to the .xinitrc file used to set up an X session on a machine running
an X-Server.
Refer to the vncserver man page for about this file, and the command in general.
$ man vncserver
----------------------------
| TigerVNC setup via Systemd |
----------------------------
The TigerVNC server can be setup via Systemd by launching a Systemd service.
Accompanying configuration files are used to configure how and what is setup.
(Read the tigervnc HOWTO mentioned above for a full description
/usr/share/doc/tigervnc/HOWTO.md)
Minimal configuration is required before starting. Edit the file:
/etc/tigervnc/vncserver.users
Add a mapping between users and display numbers. For example
:1=jdoe
:2=lisa
User jdoe will be associated with display number :1, whereas lisa will be
associated with display number :2.
A server can then be started and stopped using the systemctl command,
as such
$ sudo systemctl start vncserver@:x
For example, to start a VNC server on display :2 (i.e. user lisa)
$ sudo systemctl start vncserver@:2
In this example, the server will launch a session for user lisa. Bear in mind
that at this point no VNC viewer has been launched on the client side. This
step merely sets up a VNC server.
To view the session, a VNC viewer must be launched on the client side. A
password must also be created for user lisa. Both of these will be discussed
further down.
One point to add, since systemctrl is an administrative command, if you wish
to allow user lisa to launch the VNC server herself, you will need to provide
her with sudo permissions. Use visudoers to add the following
line to the sudoers file:
lisa ALL = /usr/bin/systemctl vncserver@:2
To waive the password requirement:
lisa ALL = NOPASSWD: /usr/bin/systemctl vncserver@:2
It is also possible to create a permanent service file as such (although I have
not tried this and have no more information about it)
$ vim /etc/systemd/system/vncserver@.service
$ systemctl daemon-reload
$ systemctl start vncserver@:1.service
In this way the client does not need to launch their own VNC session on the host
machine, as it will be automatically started by Systemd.
It is important to note that in using the Systemd method, a user cannot launch a
VNC session if they already have a desktop session running on the host. The
user must first log out.
To configure the VNC server, edit your user's config file
$ vim $HOME/.vnc/config
You can configure the screen geometry, security options, session type and more.
For example, to specify a Gnome session add the line
session=gnome
This assumes your system has Gnome installed.
Browse the /usr/share/xsessions directory for available session types.
For example my directory contains the following desktop entries:
gnome-classic.desktop gnome.desktop gnome-xorg.desktop
If you wish to use some other desktop environment (e.g. KDE), and there is no
corresponding entry, you will need to install the desktop environment on your
system.
---------------------------------------------
| Setting up a VCN Server manually using Xvnc |
---------------------------------------------
It is possible to setup a VNC session directly with Xvnc.
This is useful if you want to have direct control of your X session.
For example, if you wish to start the X ssesion with an xterm terminal and
the twm window manager, the Systemd method doesn't give you a convenient way
to do this (although the vncserver script described earlier did using the
xstartup file).
I'll give an example of manually launching a VNC server session on display :3
$ Xvnc :3 -rfbauth $HOME/.vnc/passwd
:3 is the display number (if :3 is already in use pick a different number.)
The -rfbauth option specifies the location of the password file (see below
on how to set up a VNC password).
The above is a minimal command line specification for launching a Vnc server
instance.
Once connected with a VNC viewer program, you will see a black screen with a
cursor, but nothing else.
You can launch programs from the host machine into the VNC window. For example
$ DISPLAY=:3 xterm # will open up an xterm
$ DISPLAY=:3 twm # will launch the twm window manager
You need not specify DISPLAY=:3 in front of each command.
Rather you can specify it once in the terminal from which you are launching
these commands.
$ export DISPLAY=:3
And then launch the commands as such
$ xterm &
$ xclock -geometry 50x50-0+0 &
$ twm &
Furthermore, you can write a script file that will include all of
the above invocations:
#!/bin/bash
Xvnc :3 -rfbauth $HOME/.vnc/passwd &
sleep 2
export DISPLAY=:3
xterm &
xclock -geometry 50x50-0+0 &
sleep 1
twm &
I added "sleep 2" to give Xvnc enough time to start, otherwise the commands that
follow will attempt to start (unsuccessfuly) before Xvnc is fully launched.
Save the file as start3.
Make the script executable
$ chmod 700 start3
To launch the session simply type
$ ./start3
To kill the Xvnc session you'll need to obtain the process number
$ ps -eaf | grep -i xvnc
jdoe 142181 2688 0 12:47 pts/2 00:00:00 Xvnc :3 -rfbauth /home/jdoe/.vnc/passwd
Then kill it
$ kill 142181
When I launched Xvnc via the vcnserver script (described above), I wanted to see
what kind of options were being passed to Xvnc, so I used the ps command to
do so
$ ps -eaf | grep -i vnc
The command invocation looked something like this
$ Xvnc :3 -auth $HOME/.Xauthority -desktop "Desktop Name" \
-fp catalogue:/etc/X11/fontpath.d -geometry 1024x768 -pn \
-rfbauth $HOME/.vnc/passwd -rfbport 5903 -rfbwait 30000
As you can see, the vncserver script invoked Xvnc with more options than I did
in the example above.
I'll comment briefly about the additional arguments:
* The -auth option is used to specify the authorization file
(see man page Xserver and search for -auth to read more about it)
* "Desktop Name" is simply the title you want on the VNC viewer's window (once
connected). Replace according to preference.
* -geometry specifies the initial window size
* The -rfbport option specifies on which port to listen for incoming
connection requests. The default is 5900 plus the display number.
In the above example specifying it is redundant since that port would have
been selected by default.
* -fp and -fn are Xserver options. See Xserver man page for more
$ man Xserver
In the Xvnc man page you can find out how to launch Xvnc on demand using inetd.
------------------------
| Setting a VNC password |
------------------------
Use the utility vncpassword to set a password for each user.
This is done on the server side.
The password is not stored as plaintext, but according to the man page is deemed
insecure, and as such, the file in which it is stored, ~/.vnc/passwd is created
without read or write permissions to anyone but the owner. Additionaly, it is
not a good idea to use the same password you log into your computer account (or
your bank account :-). See man page for more.
-----------------------
| Viewing a VNC session |
-----------------------
On the client side you can use a VNC viewer of your choice. If you had
installed TigerVNC launch the viewer as such
$ vncviewer host:displaynumber
For example
$ vncviewer 10.0.2.100:3
will attempt to connect to a VNC server running at IP address 10.0.2.100 on
display :3.
You will first be asked to authenticate.
If run without arguments vncviewer will provide a graphical dialogue prompting
for this information.
vncviewer comes with many options which are described in its manpage.
You can also install a VNC viewer on your smartphone and connect to the Xvnc
server running on your Linux computer.
Note, they should be on the same network, whether physically or by use of a VPN.
It is also possible to install a Linux environment app such as Termux on your
smartphone. Then install and launch vncserver in the app's terminal, and use a
VNC viewer to connect to that VNC server. In this case the phone is acting as
the server, and your computer as the client. You still will not be able to
launch your phone apps on your VNC server since those are sandboxed. You will,
however, be able to install applications on Termux and interact with them
using your computer's VNC viewer.
-----------------
| VNC and Wayland |
-----------------
Current versions of Gnome work with Wayland by default. An X11 compatibility
layer to Wayland is used to allow X applications to render on the Wayland
compositor. This works well when working directly on the host.
However, it presents a problem when working with a VNC server. Most Linux VNC
servers (including TigerVNC) rely on the X framework for rendering graphics.
This works well if you launch xterm or xclock. However, if you try launching
firefox, libreoffice or evince, instead of displaying on the VNC window, they
will instead display on the host machine's display.
Currently, the workaround is to set GNOME to work with X instead of Wayland.
This can be done on the host machine by pressing the users icon (as though you
are requesting to login). However, instead of entering a password to login,
press the settings button on the bottom of the screen, and select
"GNOME on Xorg" (note, you must be logged out to see the settings button).
-----------------
| Further reading |
-----------------
Relevant man pages:
$ man xvnc
$ man vncserver
$ man vncviewer
$ man vncconfig
Documentation:
* Howto documentation
/usr/share/doc/tigervnc/HOWTO.md
Web sites:
* Archwiki page on TigerVNC.
OpenVPN
********************************************************************************
- OpenVPN -
********************************************************************************
------------
| Background |
------------
Before the advent of VPNs (virtual private networks), and even predating the
internet, two distant facilities would connect their networks through a leased
dedicated phone line. Today most companies and individuals connect over the
internet using secure VPNs.
The idea behind a VPN is similar to that of a connection via a dedicated line.
In a VPN, rather than routing network traffic through a dedicated physical line,
it is routed through the internet on an encrypted channel, typically using
SSL/TLS encryption. Thus, two geographically disparate networks can be connected
securely in this virtual manner at little or no cost.
Some other common uses for VPNs today, are
* Connection to one's office computer from home or during travel
* Connection to one's home computer or network from work or during travel
* Bypassing restrictive firewall rules
* Private browsing, and privacy from snooping ISPs, Apps, etc.
* Creating a secure communication tunnel for the exchange of sensitive data
* Security on public networks (e.g. Wi-Fi)
Many companies offer free or paid VPN services. In this tutorial I will focus
on the OpenVPN software package, and how to setup your own VPN.
--------------
| Installation |
--------------
OpenVPN is available in a community edition and an Enterprise edition.
It is available for many platforms including Linux, Windows and Mac.
The community edition is open source and free, and downloads are available from
the official OpenVPN website.
If you have a Linux distribution, then check for availability in your
distribution's software repository. For example, to install on Fedora
$ dnf install openvpn
To install on Debian/Ubuntu
$ apt-get install openvpn
For MS Windows use the above downloads link to download the installer,
and follow the wizard's instructions.
Once installed, it is advisable to refer to the man page
$ man openvpn
Simple examples on getting started are available on a separate man page
$ man openvpn-examples
When installing on Linux, the folder /etc/openvpn is created.
This is where you will store both client and server configuration files.
Various documention and sample configuration files can be found in the
directory /usr/share/doc/openvpn.
Online documentation is available on the official website.
---------
| Example |
---------
Consider connecting two PCs using an OpenVPN tunnel.
PC1: 10.0.0.10
PC2: 10.0.0.50
On PC1 issue
$ sudo openvpn --remote 10.0.0.50 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1
On PC2 issue
$ sudo openvpn --remote 10.0.0.10 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
The --remote option should be given the IP address of the other computer.
The --dev option should be followed by the type of tunnel (tun, tap)
The --ifconfig option in this case contains the VPN's endpoints IP addresses.
Any private network addresses (e.g. in the range 192.168.0.0/16) can be
selected, which don't conflict with existing addresses in the network.
(Note, the arguments of --ifconfig depend on the type of tunnel selected)
Now you can communicate between PC1 and PC2 using ssh, and share files between
them using Samba or NFS. And all this using the VPN's IP addresses 10.4.0.1
and 10.4.0.2.
Note, this example was provided for illustration purposes only, as no security
measures were specified in the command line. This means all communication is
in plain text. See below for more on security.
Issues that might crop up:
* A firewall (on either side) may be blocking port 1194 (the official port used
by OpenVPN).
See next subsection for a discussion on OpenVPN and firewalls.
* If running OpenVPN from within a VM (virtual machine), the address specified
in --ifconfig may need to be changeable. Use --float option on the
VM side to accomplish this. If both end points are VMs within the same
network there is no need for it.
Other situations may also require the use of this switch (see man page).
-----------------------
| OpenVPN and Firewalls |
-----------------------
By default, OpenVPN communicates on port 1194.
Firewalls on either side of the connection may block communication on this
port, thus rendering OpenVPN inoperative.
Having access to the problematic firewall poses the most straight forward
solution, and that is opening up that port, at least for the IP addresses
involved.
When that is not an option, changing the port in use to one that is not being
blocked by the firewall is possible. This can be accomplished with the
--port option.
The OpenVPN installation comes with useful files and scripts in the /usr/share
directory. One such file pertaining to firewall configuration is:
/usr/share/doc/openvpn/sample/sample-config-files/firewall.sh
It is a script that inserts various iptable rules into the firewall, that put
in place various safeguards with respect to the use of a VPN.
--------------------------------------
| Configuring with configuration files |
--------------------------------------
OpenVPN is very versatile and includes a myriad of options and many scenarios it
can be used in. For more standard uses of OpenVPN, such as establishing an
OpenVPN server to which multiple clients can share their networks in a secure
environement, it will be more convenient (and sometimes even necessary) to work
with configuration files.
Both server and client configuration files are needed.
In general, the client configuration file mirrors that of the server, ensuring
consistency between settings and protocols selected for client and server.
In the example above the client and server configuration files would look
something like this:
PC1's configuration peer1.conf:
remote 10.0.0.50
dev tun1
ifconfig 10.4.0.1 10.4.0.2
PC2's configuration peer2.conf:
remote 10.0.0.10
dev tun1
ifconfig 10.4.0.2 10.4.0.1
To launch openvpn using the relevant configuration file:
* On PC1
$ openvpn --config peer1.conf
* On PC2
$ openvpn --config peer2.conf
Note, in this peer-to-peer scenario, there is no server or client, and as such,
I named the configuration files peer1 and peer2.
The configuration files on Unix like OSs have suffix conf, whereas
in MS Windows the suffix is .ovpn.
When running an OpenVPN client from Windows you will be asked to provide an
ovpn file.
When writing your own configuration file, it is always best to start with a
pre-existing configuration file and modify it to your needs. You can start
with the simple configuration files presented here. For a more sophisticated
server with multi-client setup refer to the directory
/usr/share/doc/openvpn/sample/sample-config-files containing the
configuration files client.conf and server.conf.
Refer to the OpenVPN Howto for detailed instructions on configuring OpenVPN.
------------------
| OpenVPN Security |
------------------
In the example above the VPN tunnel was established on an unsecure channel
(i.e. plain text communications). In general this is a very bad idea,
especially tunneling over the internet, as not only the content of
files are exposed to eavesedroppers as they traverse the channel, so are
passwords and the like.
In a simple scenario, say a point to point connection between two computers (as
in the above example) a shared private key between the client and server may
be sufficient for establishing a secure connection. To generate a key
$ openvpn --genkey --secret static.key
The key should be readable only by the owner of the account, and thus
created with permissions 600. It should be stored in a secure place.
The shared key will also need to be copied over to the other participating peer.
The utility scp can be used to transfer the key in a secure manner.
$ scp static.key jdoe@otherpeer.com:destination_dir
Look for static.key in destination_dir.
The configuration files will need to reference the key, and, optionally, specify
a cipher algorithm. Thus,
PC1's configuration peer1.conf will look something like
remote 10.0.0.50
dev tun1
ifconfig 10.4.0.1 10.4.0.2
cipher DES-EDE3-CBC
secret static.key
PC2's configuration peer2.conf
remote 10.0.0.10
dev tun1
ifconfig 10.4.0.2 10.4.0.1
cipher DES-EDE3-CBC
secret static.key
Note, different installations of ssh may support different pools of cipher
algorithms. Make sure that PC1 and PC2 both support the selected cipher.
You can get a list of supported ciphers by issuing
$ openvpn --show-ciphers
You can also select a cipher to be used on the command line
$ openvpn --cipher DES-EDE3-CBC ...
Note, on Fedora, for additional cipher possibilities install libssh2.
In more sophisticated scenarios full TLS based security will be necessary,
including a certificate/key pair (client.crt and server.crt) and a
certificate authority that has signed both certificates.
For more on this, I refer you to the OpenVPN examples man page
$ man openvpn-examples
as well as the OpenVPN Howto.
Apache Web Server
********************************************************************************
- Apache Web Server -
********************************************************************************
Apache is a popular open source web server software package that has been around
since the mid 1990s. For a basic description of the Apache web server on
Archlinux and its configuration see this ArchWiki article.
I will mainly describe Apache installation and configuration for Fedora 33,
although much of the procedure is applicable to other distributions.
Once, installed, the Apache server is started by issuing the command
$ systemctl start httpd.service
To make persistent across boots
$ systemctl enable httpd.service
Note, in some distributions the service may be named differently (e.g.
apache.service, apache2.service).
To verify Apache is running, open a browser and enter the link localhost.
An Apache test page should appear. To test out your own webpage, create the
file index.html in /var/www/html (this is usually the default location
in which Apache looks for web content), enter some HTML content, and browse to
URL localhost. The file index.html is the default file Apache looks for when
left unspecified in the URL field.
Apache is highly configurable, and in the next subsection, I discuss the main
configuration file.
--------------------------------
| Apache Main Configuration File |
--------------------------------
Much of the behavior of Apache is configurable through various configuration
files. Additionality, Apache is highly modular, and much of its functionality
and security features can be extended beyond its core capabilities through the
loading of modules. This too is implemented by way of the configuration files.
The first thing to do is to identify Apache's main configuration file,
and verify that it is configured correctly for your requirements. In my Fedora
installation the main configuration file is /etc/httpd/conf/httpd.conf.
The location and name may differ between one distribution and another
(e.g. /etc/apache2/apache2.conf). The file consists of XML style elements,
known as Directives. For a complete reference to Apache directives
refer to this webpage which is part of the official Apache documention website.
I will take an excerpt from the configuration file that came with my Fedora 33
installation, with the original comments stripped out. (Warning: do not rely
on this configuration file as is, as it is incomplete). The lines from the
configuration file are highlighted, followed by explanations.
ServerRoot "/etc/httpd"
This directive specifies the top directory under which the configuration, error
and log files are kept.
Listen 80
The Listen directive tells the Apache server on which port to listen to.
In the example above Apache will listen to any host on port 80 (the standard http
port). You can also specify an IP address (see below).
Include conf.modules.d/*.conf
The Include directive allows other configuration files to be loaded from
within the main configuration file. Multiple configuration files can be loaded
with a single Include directive via the wild card character (*).
In the above instance, the configuration files being loaded contain instructions
to load supplemental modules via the LoadModule directive.
User apache
Group apache
Normally the server is launched by root (although it is possible to be run as an
ordinary user). If you include the User directive, the server
will subsequently switch to running under the specified user. This means the
server will answer requests as that user.
Similarly the Group directive specifies the group under which the
server will answer requests.
In general it is a good idea to create a user/group specifically for the server
(e.g. apache).
Note, in a multi-user system, when users are to have their own websites
(discussed below), the directories containing their web content and the web
files themselves should be accessible to the server. If the server answers
as apache, and, say, user jdoe has index.html owned by jdoe.jdoe, then the
server will not be able to bring up that page, and a "Forbidden. You don't have
permission to access this resource" error will occur. In such a case you may
want to omit the User directive, or set group membership and permissions in
such a way so that the server will have access to the users' web content.
ServerAdmin root@localhost
This should specify the email to which to send a copy of error messages sent
to the client.
<Directory />
AllowOverride none
Require all denied
</Directory>
The Directory directive allows specifying a set of directives that will
apply to the given directory. In this case the directory to which the
directives are being applied to is /.
The basic gist of the directives inside the Directory block above is to deny
access to anywhere in the file system (i.e. /). Of course these will have to be
relaxed in subsequent Directory blocks to allow access to those places where
web content resides.
DocumentRoot "/var/www/html"
The above directive specifies the location of where the server will serve
files. It is the main document tree visible from the web and where web
content generally resides.
If set as above, your web files should reside in /var/www/html/.
To access files from outside this directory use symbolic links.
You are free to change the document root location, however, make sure
permissions are set correctly (more on permissions in this subsection).
The following Directory blocks permit access to /var/www and /var/www/html:
# Relax access to content within /var/www.
<Directory "/var/www">
AllowOverride None
# Allow open access:
Require all granted
</Directory>
# Further relax access to the default document root:
<Directory "/var/www/html">
</Directory>
<IfModule dir_module>
DirectoryIndex index.html
</IfModule>
The IfModule directive is used to implement a set of directives conditional
on the presence (or absence) of a given module. In this case if the dir_module
module is present then the directive DirectoryIndex will be implemented. This
directive specifies that when requesting a link that specifies a directory,
the server will look for the file index.html in that directory.
For example when requesting the link www.mydoc.org to be displayed in your
browser, the server will respond with the file /var/www/html/index.html.
If requesting the link www.mydoc.org/docs/, the server will respond with the
file /var/www/html/docs/index.html.
<Files ".ht*">
Require all denied
</Files>
The Files directive is similar to the Directory directive. But rather
than applying the enclosed directives to the contents of a directory, they are
applied to files matching the specified pattern. In this case any files
matching the pattern .ht* are affected. The files in mind are .htaccess and
.htpasswd, which are security related files.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
AddDefaultCharset UTF-8
This directive enables all content to be interpreted as UTF-8 by default.
IncludeOptional conf.d/*.conf
This directive instructs the server to load config files in the
/etc/httpd/conf.d directory, if any.
This directive is similar to the Include directive seen earlier, except it does
not return an error if a file does not exist or does not match the wild card.
-------------------------
| Setting up your website |
-------------------------
Here are a few tips about setting up your website.
If you are testing your website, and you wish to constrain the Apache server to
listen to a specific IP address, you can do so. For example, if you replace
the above line with
Listen 127.0.0.0:80
Apache will to listen to requests only from the local host (i.e. 127.0.0.1) on
port 80.
If you want to refer to your host by a web like name (e.g. mycompany.com)
then add a line in /etc/hosts
127.0.0.1 mycompany.com
Ultimately if you want your home machine to be a server to be seen by the
world, you have to arrange with your local internet provider to obtain a
static IP address, and obtain a domain name to attach to this IP address.
Although, it's more likely you'll sign up with a web hosting company, or rent
server space from companies such as AWS, Linode, Digital Ocean, and the like.
If you want to have a local portal to your LAN, you can run the Apache
server on a machine on that LAN, and it may then be accessed by other machines
on the same LAN (but not from outside.)
--------------------------------
| Apache Per-User Web Directories|
--------------------------------
A system with multiple users may grant all or selected users with their own
website. For example user jdoe's website on domain example.com may be accessed
as follows: example.com/~jdoe
Similarly, user lisa's website may be accessed via: example.com/~lisa
Depending on the distribution, Apache may or may not be configured to allow
per-user web directories. And even if the basic functionality of per-user web
directories is already configured out of the box, its likely that additional
steps, such as setting permissions, be taken to implement this feature.
The main configuration file should have a Directory Block that looks
something like this:
<Directory "/home/*/public_html">
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Require method GET POST OPTIONS
</Directory>
The wild card in the directory specification above expands to all users,
meaning this directory block will apply the enclosed directives to all user's
public_html directory.
The above was provided in my configuration file by default, and required no
modification.
Besides the main configuration file discussed earlier, an additional
file comes into play, the user configuration file:
/etc/httpd/conf.d/userdir.conf.
(Note, the name and location of this file may vary from one distribution to
another.)
User directories may or may not be enabled by default. To see if this feature
is enabled, open the userdir.conf configuration file, and look for a
block of code that looks something like this:
<IfModule mod_userdir.c>
#UserDir disabled
UserDir public_html
</IfModule>
The IfModule directive tells Apache to execute the enclosed directives
on condition that the mod_userdir (userdir module) is active.
To enable the per-user web directories feature, make sure the line
UserDir disabled is commented out (as above).
Secondly, uncomment or enter the line UserDir public_html.
This line tells the Apache server to look for user specific web content in the
directory ~user/public_html.
To change the directory in which to look for user web content, simply change
the name of the directory (e.g. UserDir www).
The second thing to do is to set correctly the permissions of the HTML content
directories and files. The permission must be such that all directories are
world executable and all files world readable. For example
$ chmod -R 755 /home/user
$ chmod -R 775 /home/user/public_html
Alternatively,
$ chmod o+x ~
$ chmod -R o+rx ~/public_html
Beware that doing this compromises parts of your home directory to snooping.
If you don't want outsiders seeing what's in your home directory, then make
sure all files and directories there (other than public_html and its contents)
do not have world read/write/execute permissions. For example
$ chmod o-rwx file/directory
Fore changes to take place, restart the Apache webserver daemon.
$ sudo systemctl restart httpd.service
If SELinux in enabled, see next section for additional configuration steps.
Sources:
* This page in the official Apache docs.
---------------------
| Apache with SELinux |
---------------------
Normally, Apache that is installed on an SELinux enabled distribution should run
out of the box once the service is started.
However, if you enabled user directories, then additional steps will be
required. Firstly, you will need to enable the homedirs SELinux variable.
$ setsebool -P httpd_enable_homedirs 1
Second, you will need to change the SELinux context of the www root directory
of each user whose webpage is to be accessed.
$ chcon -R -t httpd_sys_content_t ~username/public_html
There are other SELinux variables associated with Apache. Refer to this webpage
for more on Apache with SELinux.
------------------------------------------
| Apache Web Server on an AWS EC2 instance |
------------------------------------------
This subsection discusses how to set up a Web Server on an AWS EC2 instance.
If you don't have an EC2 instance running on AWS, see section on
AWS Cloud Computing.
The following is based on this AWS tutorial.
Login to your Amazon Linux AMI instance.
Note: Do not use Amazon Linux 2 AMI since it doesn't have the necessary
software packages. To display the release of your instance, issue the command
$ cat /etc/system-release
Update your installation (with latest bug fixes and security updates)
$ sudo yum update -y
Install Apache web server packages
$ sudo yum install -y httpd24 php56 php56-mysqlnd
Start Web Server:
$ sudo service httpd start
Verify your Web Server is running - In a browser, enter URL
http://yourIPaddress|yourDomainName
Configure server to start at system boot
$ sudo chkconfig httpd on
The following set of commands sets permissions so that ec2-user can manage
the web server. That is, that ec2-user will have read-write access to /var/www
directory and its contents.
$ sudo groupadd www # Add www group for managing web server
$ sudo usermod -a -G www ec2-user # Add ec2-user to that group
$ exit # Logging out refreshes your permissions
# Login to instance again
$ groups # Verify ec2-user is in www
$ sudo chgrp -R www /var/www
# Set /var/www and subdirectories for group write permissions
$ sudo chmod 2775 /var/www
# Set group write permissions of future subdirectories of /var/www
$ find /var/www -type d -exec sudo chmod 2775 {} +
# Set group write permissions of future files of /var/www
$ find /var/www -type f -exec sudo chmod 0664 {} +
AWS Cloud Computing
********************************************************************************
- AWS Cloud Computing -
********************************************************************************
AWS = Amazon Web Services
Amazon offers a plethora of web services, including web hosting, running a
VM server on the cloud, hybrid storage gateway (hybrid cloud storage).
To work with AWS you will need to set up an account.
A free Tier account is available for one year with access to a limited number
of services, with low processor and bandwidth performance.
Note, however, that even with free Tier you could end up paying something if you
wish to keep your VM running all the time, since the free tier limits you
to 750 hours per month.
(The following is based on this tutorial)
To manage and launch a VM select EC2 (EC2 is Amazon's cloud computing platform)
Press "Launch Instance".
Select from list of pre-built VM templates, which amazon calls
"Amazon Machine Image" (AMI).
The AMI defines the OS and other features.
Once an AMI is selected, an instance (1 or more) of that AMI can be launched.
Note, for free Tier check the "free Tier box" to filter out irrelevant VMs.
* Select a pre-configured AMI.
I experimented with "Amazon Linux AMI (HVM), SSD Volume Type".
- Press "Review and Launch" (bottom)
* In "Step 6" you can add firewall rules.
By default everything is closed up except port 22 for ssh communications.
You can add http (80), https (443), rsync (873) and more.
* In the "Step 7" screen that shows up
- Press Launch
* A popup window shows up whereby you need to select an existing key pair or
create a new key pair.
The public key is stored in AWS, and the private key is stored locally.
If you have an existing key pair then select it.
If not, then create one, store it locally in ~/.ssh
Warning: Without the key pair there is no way to access the account!
I created a keypair (using the popup window) and named it aws_keypair.pem
I then made the key readable only by user:
$ chmod 400 ~/.ssh/aws_keypair.pem
(See my entry on ssh authentication for more about public key authnetication).
- Press Launch Instances
* In Launch instance window press the "instance ID" link, and a window
showing your instances will be displayed.
You can always get to this window from the EC2 console by selecting
INSTANCES : Instances
on the left side panel.
Further down the line where the instance is listed, should be a Public DNS
address as well as a public IPv4 address.
* Use ssh to connect to the instance
$ ssh -i ~/.ssh/aws_keypair.pem ec2-user@{IP_Address}
* To work with X11 apps follow this procedure (see this Youtube video):
* Edit sshd configuration file:
$ vim /etc/ssh/sshd_config
Make sure X11 forwarding is enabled by adding this line (unless its already
there):
X11Forwarding yes
$ systemctl restart sshd
* Install minimal X software
$ yum install xorg-x11-xauth xterm
$ yum install xeyes # You can use this program to test the working of X11
* Add ordinary user (optional)
$ useradd newuser
$ password newuser
* Change root password (to allow login to root)
$ sudo su -
$ password
(enter new password)
* Allow the instance to use your host to display windows from programs
running on the remote EC2 instance.
On the host computer, issue the command
$ xhost +
* Logout of instance, and login again with X11 forwarding enabled
$ ssh -Y -i ~/.ssh/aws_keypair.pem ec2-user@{IP_Address}
* Run an X program from the instance terminal
$ xeyes
Wait a bit, it may take time.
* To terminate the instance:
Select instance in console, and select
: Actions : Instance State : Terminate
Free Tier only allows Stop, Reboot and Terminate (No Stop - Hibernate)
Important: Once terminated the instance is removed from memory, including all
data stored on the instance.
To use rsync with an AWS EC2 instance you will need to use rsync in a slightly
modified way since the authentication method used by AWS EC2 instances is not
with a password, but rather with a key pair. For example, to transfer a file
onto the home directory of the ec2-user, invoke the command:
$ rsync -e "ssh -i ~/.ssh/awskeypair.pem" fil2transfer ec2-user@IP:
The "-e" option tells rsync to connect using the command given as its
argument "ssh -i ~/.ssh/awskeypair.pem". The remaining syntax should be
familiar.
Acronyms & Terminology
********************************************************************************
- Acronyms & Terminology -
********************************************************************************
ADSL - Asymmetric DSL
ATM - Asynchronous Transfer Mode
AWS - Amazon Web Services
DMZ - Demilitarized zone - in networking, a reference to a computer or server
or subnet that is exposed to the "outside" world.
DNS - Domain Name System - A system by which names are matched to IP addresses.
The system is hierarchical and decentralized. DNS servers implement the
necessary functionality for the system to operate properly.
At the top of the hierarchy are the root name servers.
ISP's as well as LAN's will have their own name server.
DSL - Digital Subscriber Line
DHCP - Dynamic Host Configuration Protocol - A network management protocol
used in UDP/IP networks for the purpose of dynamically assigning IP addresses
to network devices on a given network.
A DHCP server running in the background implements such a service using
the DHCP protocol.
IP Suite (TCP/IP) - Internet Protocol Suite - "the conceptual model and set of
communications protocols used in the Internet and similar computer networks"
(Wikipedia)
IP - Internet protocol - "Principal communications protocol in the
Internet protocol suite for relaying datagrams across network boundaries.
Its routing function enables internetworking, and essentially establishes
the Internet" (Wikipedia).
ISP - Internet Service Provider - usually a phone or cable company that
provides a home network with a link to the internet.
MAC - Media Access Control
MAC Address - A unique 48 bit code used to uniquely identify a network
hardware device (usually ethernet or WiFi based)
MTU - Maximum Transmission Unit - This parameter specifies the maximum data
to contain within a packet. Typical values for Ethernet are 1500.
An frame requires an additional 18 bytes of overhead.
PPP - Point-to-Point Protocol
PPPoE - PPP over ethernet
UDP - User Data Protocol - Part of the IP suite. "UDP uses a simple
connectionless communication model with a minimum of protocol mechanism.
UDP provides checksums for data integrity, and port numbers for addressing
different functions at the source and destination of the datagram."
(Wikipedia)
TCP - Transmission Control Protocol - Part of the IP suite.
"TCP provides reliable, ordered, and error-checked delivery of a stream of
octets (bytes) between applications running on hosts communicating via an IP
network." TCP is used when reliable data transmission is required.
Its counterpart UDP is used when less reliable data transmission is required.
VM - Virtual Machine
Unsorted
********************************************************************************
- Unsorted -
********************************************************************************
systemd.link - Network device configuration
See man page of systemd.link which provides for a higher-level mechanism for
setting the network interface name.
Revision History
********************************************************************************
- Revision History -
********************************************************************************
2020-06-24: Comprehensive editing
2020-10-29: Another round of editing
2021-01-19: Minor additions to subsection rsync and SELinux
2021-02-05: Added to Samba section. In particular to subsection SAMBA and firewall.
Added section Network Diagnostic Tools about netstat and tcpdump.
2021-04-22: Added entry on Public Key Authentication.
2021-05-20: Expanded section on Tiger VNC.
2021-07-07: Expanded slightly section on iptables.
Added examples for nmap in section Network Utilities.
2021-07-28: Major revision to section Apache Server.
2022-11-22: Added subsections Port Forwarding and NAT Example and Previous example with firewall.
2022-11-23: Added section OpenVPN; made cosmetic changes on 2023-01-09
2023-01-12: Expanded subsection Previous example with firewall.
2023-01-19: Added subsection rsync examples.
2023-05-28: Added subsection iptables_example_with two_interfaces.
2023-05-29: Minor editing and additions to section on NFS.