Category Archives: Tutoriale Linux
Practical Networking for Linux Admins: TCP/IP | Linux.com
Linux grew up with a networking stack as part of its core, and networking is one of its strongest features. Let’s take a practical look at some of the TCP/IP fundamentals we use every day.
It’s IP Address
I have a peeve. OK, more than one. But for this article just one, and that is using “IP” as a shortcut for “IP address”. They are not the same. IP = Internet Protocol. You’re not managing Internet Protocols, you’re managing Internet Protocol addresses. If you’re creating, managing, and deleting Internet Protocols, then you are an uber guru doing something entirely different.
Yes, OSI Model is Relevant
TCP is short for Transmission Control Protocol. TCP/IP is shorthand for describing the Internet Protocol Suite, which contains multiple networking protocols. You’re familiar with the Open Systems Interconnection (OSI) model, which categorizes networking into seven layers:
- 7. Application layer
- 6. Presentation layer
- 5. Session layer
- 4. Transport layer
- 3. Network layer
- 2. Data link layer
- 1. Physical layer
The application layer includes the network protocols you use every day: SSH, TLS/SSL, HTTP, IMAP, SMTP, DNS, DHCP, streaming media protocols, and tons more.
TCP operates in the transport layer, along with its friend UDP, the User Datagram Protocol. TCP is more complex; it performs error-checking, and it tries very hard to deliver your packets. There is a lot of back-and-forth communication with TCP as it transmits and verifies transmission, and when packets get lost it resends them. UDP is simpler and has less overhead. It sends out datagrams once, and UDP neither knows nor cares if they reach their destination.
TCP is for ensuring that data is transferred completely and in order. If a file transfers with even one byte missing it’s no good. UDP is good for lightweight stateless transfers such NTP and DNS queries, and is efficient for streaming media. If your music or video has a blip or two it doesn’t render the whole stream unusable.
The physical layer refers to your networking hardware: Ethernet and wi-fi interfaces, cabling, switches, whatever gadgets it takes to move your bits and the electricity to operate them.
Ports and Sockets
Linux admins and users have to know about ports and sockets. A network socket is the combination of an IP address and port number. Remember back in the early days of Ubuntu, when the default installation did not include a firewall? No ports were open in the default installation, so there were no entry points for an attacker. “Opening a port” means starting a service, such as an HTTP, IMAP, or SSH server. Then the service opens a listening port to wait for incoming connections. “Opening a port” isn’t quite accurate because it’s really referring to a socket. You can see these with the netstat command. This example displays only listening sockets and the names of their services:
$ sudo netstat -plnt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1583/mysqld tcp 0 0 127.0.0.1:5901 0.0.0.0:* LISTEN 13951/qemu-system-x tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 2101/dnsmasq tcp 0 0 192.168.122.1:80 0.0.0.0:* LISTEN 2001/apache2 tcp 0 0 192.168.122.1:443 0.0.0.0:* LISTEN 2013/apache2 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1200/sshd tcp6 0 0 :::80 :::* LISTEN 2057/apache2 tcp6 0 0 :::22 :::* LISTEN 1200/sshd tcp6 0 0 :::443 :::* LISTEN 2057/apache2
This shows that MariaDB (whose executable is mysqld) is listening only on localhost at port 3306, so it does not accept outside connections. Dnsmasq is listening on 192.168.122.1 at port 53, so it is accepting external requests. SSH is wide open for connections on any network interface. As you can see, you have control over exactly what network interfaces, ports, and addresses your services accept connections on.
Apache is listening on two IPv4 and two IPv6 ports, 80 and 443. Port 80 is the standard unencrypted HTTP port, and 443 is for encrypted TLS/SSL sessions. The foreign IPv6 address of :::* is the same as 0.0.0.0:* for IPv4. Those are wildcards accepting all requests from all ports and IP addresses. If there are certain addresses or address ranges you do not want to accept connections from, you can block them with firewall rules.
A network socket is a TCP/IP endpoint, and a TCP/IP connection needs two endpoints. A socket represents a single endpoint, and as our netstat example shows a single service can manage multiple endpoints at one time. A single IP address or network interface can manage multiple connections.
The example also shows the difference between a service and a process. apache2 is the service name, and it is running four processes. sshd is one service with one process listening on two different sockets.
Unix Sockets
Networking is so deeply embedded in Linux that its Unix domain sockets (also called inter-process communications, or IPC) behave like TCP/IP networking. Unix domain sockets are endpoints between processes in your Linux operating system, and they operate only inside the Linux kernel. You can see these with netstat:
$ netstat -lx Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 988 /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 29730 /run/user/1000/systemd/private unix 2 [ ACC ] SEQPACKET LISTENING 357 /run/udev/control unix 2 [ ACC ] STREAM LISTENING 27233 /run/user/1000/keyring/control
It’s rather fascinating how they operate. The SOCK_STREAM socket type behaves like TCP with reliable delivery, and SOCK_DGRAM is similar to UDP, unordered and unreliable, but fast and low-overhead. You’ve heard how everything in Unix is a file? Instead of networking protocols and IP addresses and ports, Unix domain sockets use special files, which you can see in the above example. They have inodes, metadata, and permissions just like the regular files we use every day.
If you want to dig more deeply there are a lot of excellent books. Or, you might start with man tcp and man 2 socket. Next week, we’ll look at network configurations, and whatever happened to IPv6?
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
Linux Chgrp Command for Beginners (5 Examples) | Linux.com
Here at HowtoForge, we recently discussed the chown command which lets users change the owner as well as group of file (or a directory) in Linux. But did you know there exists a dedicated command line utility that you can use when it comes to changing group-related information? The tool in question is chgrp, and in this tutorial, we will be discussing this tool using easy to understand examples.
But before we do that, it’s worth mentioning that all examples and instructions mentioned in this tutorial have been tested on Ubuntu 16.04LTS.
Linux chgrp command
As you’d have already understood by now, if the requirement is to only change the group of a file or directory, then you can use chgrp instead of chown. The tool provides several command line options that you can use in different situations. Here’s the generic syntax of chgrp:
Read more at HowToForge
Install and monitor services using Monit on ubuntu 17.04 Server
Sponsored Link
Monit is a utility for managing and monitoring, processes, files, directories and devices on a UNIX system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations.
Monit Features
* Daemon mode — poll programs at a specified interval
* Monitoring modes — active, passive or manual
* Start, stop and restart of programs
* Group and manage groups of programs
* Process dependency definition
* Logging to syslog or own logfile
* Configuration — comprehensive controlfile
* Runtime and TCP/IP port checking (tcp and udp)
* SSL support for port checking
* Unix domain socket checking
* Process status and process timeout
* Process cpu usage
* Process memory usage
* Process zombie check
* Check the systems load average
* Check a file or directory timestamp
* Alert, stop or restart a process based on its characteristics
* MD5 checksum for programs started and stopped by monit
* Alert notification for program timeout, restart, checksum, stop resource and timestamp error
* Flexible and customizable email alert messages
* Protocol verification. HTTP, FTP, SMTP, POP, IMAP, NNTP, SSH, DWP,LDAPv2 and LDAPv3
* An http interface with optional SSL support to make monit accessible from a webbrowser
Install Monit on Ubuntu 17.04 server
sudo apt-get install monit
This will complete the installation.
Configuring Monit
Default configuration file located at /etc/monit/monitrc you need to edit this file to configure your options
sudo vi /etc/monit/monitrc
Sample Configuration file as follows and uncomment all the following options
## Start monit in background (run as daemon) and check the services at 2-minute
## intervals.
#
set daemon 120
## Set syslog logging with the ‘daemon’ facility. If the FACILITY option is
## omited, monit will use ‘user’ facility by default. You can specify the
## path to the file for monit native logging.
#
set logfile syslog facility log_daemon
## Set list of mailservers for alert delivery. Multiple servers may be
## specified using comma separator. By default monit uses port 25 — it is
## possible to override it with the PORT option.
#
set mailserver localhost # primary mailserver
## Monit by default uses the following alert mail format:
From: monit@$HOST # sender
Subject: monit alert — $EVENT $SERVICE # subject
$EVENT Service $SERVICE
Date: $DATE
Action: $ACTION
Host: $HOST # body
Description: $DESCRIPTION
Your faithful,
monit
## You can override the alert message format or its parts such as subject
## or sender using the MAIL-FORMAT statement. Macros such as $DATE, etc.
## are expanded on runtime. For example to override the sender:
#
set mail-format { from: monit@monitorserver.com }
## Monit has an embedded webserver, which can be used to view the
## configuration, actual services parameters or manage the services using the
## web interface.
#
set httpd port 2812 and
use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and
allow 172.29.5.0/255.255.255.0
allow admin:monit # require user ‘admin’ with password ‘monit’
===> Change 172.29.5.0/255.255.255.0 to your network ip range
# Monitoring the apache2 web services.
# It will check process apache2 with given pid file.
# If process name or pidfile path is wrong then monit will
# give the error of failed. tough apache2 is running.
check process apache2 with pidfile /var/run/apache2.pid
#Below is actions taken by monit when service got stuck.
start program = “/etc/init.d/apache2 start”
stop program = “/etc/init.d/apache2 stop”
# Admin will notify by mail if below of the condition satisfied.
if cpu is greater than 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 200.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop
if 3 restarts within 5 cycles then timeout
group server
#Monitoring Mysql Service
check process mysql with pidfile /var/run/mysqld/mysqld.pid
group database
start program = “/etc/init.d/mysql start”
stop program = “/etc/init.d/mysql stop”
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout
#Monitoring ssh Service
check process sshd with pidfile /var/run/sshd.pid
start program “/etc/init.d/ssh start”
stop program “/etc/init.d/ssh stop”
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout
You can also include other configuration files via include directives:
include /etc/monit/default.monitrc
include /etc/monit/mysql.monitrc
This is only sample configuration file. The configuration file is pretty self-explaining; if you are unsure about an option, take a look at the monit documentation
After configuring your monit file you can check the configuration file syntax using the following command
sudo monit -t
Once you don’t have any syntax errors you need to enable this service by changing the file /etc/default/monit
sudo vi /etc/default/monit
# You must set this variable to for monit to start
startup=0
to
# You must set this variable to for monit to start
startup=1
Now you need to start the service using the following command
sudo systemctl restart monit.service
Monit Web interface
Monit Web interface will run on the port number 2812.If you have any firewall in your network setup you need to enable this port.
Now point your browser to http://yourserverip:2812/ (make sure port 2812 isn’t blocked by your firewall), log in with admin and monit.If you want a secure login you can use https check here
Once you logged in you should see the following screen with all the services we are monitoring
Apache web server process details
Sponsored Link
Related posts
Understanding Linux Links | Linux.com
Linux is, without a doubt, one of the single most flexible operating system platforms on the planet. With the flagship open source ecosystem, there is almost nothing you cannot do. What makes Linux so flexible? The answer to that question will depend on your needs. Suffice it to say, the list of answers is significant and starts from the kernel and works it way out to the desktop environment. This flexibility was built into the operating system from the beginning, borrowing quite a lot of features from UNIX. One such feature is links.
What are links? I’m glad you asked.
Links are a very handy way to create a shortcut to an original directory. Links are used in many instances: Sometimes to create a convenient path to a directory buried deep within the file hierarchy; other uses for links include:
But aren’t these just “shortcuts”?
In a way, yes…but not exactly. Within the realm of Linux, there’s more to links than just creating a shortcut to another location. Consider this: A shortcut is simply a pseudo-file that points to the original location of the file. For instance, create a shortcut on the Windows desktop to a particular folder and, when you click that icon, it will automatically open your file manager in the original location. On Linux, when you create a link in Linux, you click on that link and it will open the link in the exact location in which it was created.
Let me explain. Say, for instance, you have an external drive, attached to your Windows machine. On that drive is a folder called Music. If you create a shortcut to the directory on your desktop, when you click to open the shortcut, your file manager will open to the Music directory on your external drive.
Now, say you have that drive attached to a Linux machine. That drive is mounted to, say, /data and on that drive is the folder Music. You create a link to that location in your home directory—so you how have a link from ~/Music that points to /data/Music. If you open the shortcut in your home directory, it opens the file manager in ~/Music, instead of /data/Music. Any changes you make in ~/Music will automatically be reflected in /data/Music. And that is the big difference.
Types of links
In Linux there are two different types of links:
-
Hard links
-
Symbolic links
The difference between the two are significant. With hard links, you can only link to files (and not directories); you cannot reference a file on a different disk or volume, and they reference the same inode as the original source. A hard link will continue to remain usable, even if the original file is removed.
Symbolic links, on the other hand, can link to directories, reference a file/folder on a different disk or volume, will exist as a broken (unusable) link if the original location is deleted, reference abstract filenames and directories (as opposed to physical locations), and are given their own, unique inode.
Now comes the fun part. How do you work with links? Let’s find out how to create both hard and symbolic links.
Working with hard links
We’re going to make this very simple. The basic command structure for creating a hard link is:
ln SOURCE LINK
Where SOURCE is the original file and LINK is the new file you will create that will point to the original source. So let’s say we want to create a link pointing to /data/file1 and we want to create the link in the ~/ directory. The command for this would be:
ln /data/file1 ~/file1
The above command will create the file ~/file1 as a hard link to /data/file1. If you open up both files, you will see they have the exact same contents. If you alter the contents in one, the changes will reflect in both. One of the benefits of using hard links is that if you were to delete /data/file1, ~/file1 would still remain. If you want to simply remove the link, you can use the rm command like so:
rm ~/file1
Working with symbolic links
The command structure for symbolic links works in the same manner as do hard links:
ln -s SOURCE LINK
The primary difference between hard and symbolic link creation, is that you use the -s option. Let’s create a symbolic link from ~/file2 to /data/file2 in similar fashion as we did above, only we’ll create a symbolic link, instead of a hard link. Here’s how that would be accomplished:
ln -s /data/file2 ~/file2
The above command will create a symbolic link from ~/file2 to the original location /data/file2. If you update the file in either location, it will update in both.
It is also important to note that you can use symbolic links for directories. Say, for instance, you have /data/directory1 and you want to create a symbolic link to that directory in ~/. This is done in the same way as creating a link to a file:
ln -s /data/directory1 ~/directory1
The above command will create the link ~/directory1 which points to /data/directory1. You can then add to that directory from either location and the change will reflect in both.
To see the difference between how each type of link looks from a terminal window, issue the command ls -li. You will see how each is represented with slight variation from one another (Figure 1).
One interesting thing of note is how inodes are treated by way of the different types of links. In Figure 1, you can see that the inode (string of characters in the first column) for the hard links are the same, whereas the inodes for the symbolic links are different. This can be further illustrated by removing the original location of the symbolic link. When you do that, the soft link goes away (although the broken referral link file remains behind). Why? The reference inode the symbolic link pointed to no longer exists.
Unlike with hard links, if you delete the original file or directory, the symbolic link will remain, however it will now be considered a broken link and will be unusable. Remember, with hard links, you can remove the original and the link will remain and still be usable.
Learn more
Of course, you’re going to want to know more about using links. If you issue the command man ln, you can read the manual page for the ln command and gain an even more in-depth understanding as to how links work.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
Containers Running Containers with LinuxKit | Linux.com
Some genuinely exciting news piqued my interest at this year’s DockerCon, that being the new operating system (OS) LinuxKit, which was announced and is immediately on offer from the undisputed heavyweight container company, Docker. The container giant has announced a flexible, extensible operating system where system services run inside containers for portability. You might be surprised to hear that even includes the Docker runtime daemon itself.
In this article, I’ll take a quick look at what’s promised in LinuxKit, how to try it out for yourself, and look also at ever-shrinking, optimized containers.
Less Is More
There’s no denying that users have been looking for a stripped-down version of Linux on which to run their microservices. With containerization, you’re trying your hardest to minimize each application so that it becomes a standalone process which sits inside a container of its own. However, constantly shifting containers around because you’re patching the host that the containers reside on causes issues. In fact, without an orchestrator like Kubernetes or Docker Swarm that container-shuffling is almost always going to cause downtime.
Needless to say that’s just one reason to keep your OS as miniscule as possible; one of many.
A favorite quote I’ve repeated on a number of occasions, comes from the talented Dutch programmer, Wietse Zweitze, who brought us the email stalwart Postfix and TCP Wrappers amongst other renowned software.
The Postfix website states that even if you’re as careful with your coding as Wietse that for “every 1000 lines [you] introduce one additional bug into Postfix.” From my professional DevSecOps perspective by the mention of “bug” I might be forgiven for loosely translating that definition into security issues, too.
From a security perspective, it’s precisely for this reason that less-is-more in the world of code. Simply put, there’s a number of benefits to using less lines of code; namely security, administration time and performance. For starters there’s less security bugs, less time updating packages and faster boot times.
Look deeper inside
Think about what runs your application from inside a container.
A good starting point is Alpine Linux which is a low-fat, boiled-down, reduced OS commonly preferred over the more bloated host favourites, such as Ubuntu or CentOS. Alpine also provides a miniroot filesystem (for use within containers) which comes in at a staggering 1.8MB at the last check. Indeed the ISO download for a fully working Linux operating system comes in at a remarkable 80MB in size.
If you decide to utilize a Docker base image from Alpine Linux, then you can find one on the Docker Hub where Alpine Linux describes itself as: “A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!”.
It’s been said, and I won’t attempt to verify this meme, that the ubiquitous Window Start button is around the same file size! I’ll refrain from commenting further.
In all seriousness, I hope that gives you an idea of the power of innovative Unix-type OSs like Alpine Linux.
Lock everything up
What’s more, it goes on to explain that Alpine Linux is (not surprisingly) based on Busy Box, the famous set of Linux commands neatly packaged which many people won’t be aware sits inside their broadband router, smart television and of course many IoT devices in their homes as they read this.
Comments on the the About page of Alpine Linux site state:
“Alpine Linux was designed with security in mind. The kernel is patched with an unofficial port of grsecurity/PaX, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.”
In other words the boiled-down binaries bundled inside the Alpine Linux builds which offers the system its functionality have already been sieved through clever industry-standard security tools in order to help mitigate buffer overflow attacks.
Odd socks
Why do the innards of containers matter when we’re dealing with Docker’s new OS you may ask?
Well, as you might have guessed, when it comes to containers, their construction is all about losing bloat. It’s about not including anything unless it’s absolutely necessary. It’s about having confidence so that you can reap the rewards of decluttering your cupboards, garden shed, garage, and sock drawer with total impunity.
Docker certainly deserve some credit for their foresight. Reportedly, early 2016 Docker hired a key driving force behind Alpine Linux, Nathaniel Copa, who helped switch the default, official image library away from Ubuntu to Alpine. The bandwidth that Docker Hub saved from the newly-streamlined image downloads alone must have been welcomed.
And, bringing us up to date, that work will stand arm-in-arm with the latest container-based OS work; Docker’s LinuxKit.
For clarity, LinuxKit is not ever-likely destined to replace Alpine but rather to sit underneath the containers and act as a stripped-down OS that you can happily spin up your runtime daemon on (in this case, the Docker daemon which spawns your containers).
Blondie’s Atomic
A finely-tuned host is by no means a new thing (I mentioned the household devices embedded with Linux previously) and the evil geniuses who have been optimizing Linux for the last couple of decades realized sometime ago that the underlying OS was key to churning out a server estate fulls of hosts brimming with containers.
For example the mighty Red Hat have long been touting Red Hat Atomic having contributed to Project Atomic. The latter goes on to explain:
“Based on proven technology either from Red Hat Enterprise Linux or the CentOS and Fedora projects, Atomic Host is a lightweight, immutable platform, designed with the sole purpose of running containerized applications.”
There’s good reason that the underlying, immutable Atomic OS is forwarded as the recommended choice with Red Hat’s OpenShift PaaS (Platform as a Service) product. It’s minimal, performant and sophisticated.
Features
The mantra that less-is-more was evident throughout Docker’s announcement regarding LinuxKit. The project to realise the vision of LinuxKit was apparently no small undertaking and with the guiding hand of expert Justin Cormack, a Docker veteran and master with unikernels, and in partnership with HPE, Intel, ARM, IBM and Microsoft LinuxKit can run on mainframes as well as IoT-based fridge freezers.
The configurable, pluggable and extensible nature of LinuxKit will appeal to many projects looking for a baseline upon which to build their services. By open-sourcing the project Docker are wisely inviting input from every man and their dog to contribute to its functionality which will mature like a good cheese undoubtedly over time.
Proof of the pudding
Having promised to point those eager to get going with this new OS, let us wait no longer. If you want to get your hands on LinuxKit you can do so from the GitHub page here: LinuxKit
On the GitHub page, there are instructions on how to get up and running along with some features.
Time permitting, I plan to get my hands much dirtier with LinuxKit. The somewhat-contentious Kubernetes versus Docker Swarm orchestration capabilities will be interesting to try out. I’d like to see memory footprints, boot times, and diskspace-usage benchmarking, too.
If the promises are true then pluggable system services which run as containers is a fascinating way to build an OS. Docker blogged the following on its tiny footprint: “Because LinuxKit is container-native, it has a very minimal size – 35MB with a very minimal boot time. All system services are containers, which means that everything can be removed or replaced.”
I don’t know about you, but that certainly whets my appetite.
Call the cops
Features aside with my DevSecOps hat on, I will be in seeing how the promise of security looks in reality.
Docker quotes from the National Institute of Standards and Technology (NIST) and claims that:
“Security is a top-level objective and aligns with NIST stating, in their draft Application Container Security Guide: “Use container-specific OSes instead of general-purpose ones to reduce attack surfaces. When using a container-specific OS, attack surfaces are typically much smaller than they would be with a general-purpose OS, so there are fewer opportunities to attack and compromise a container-specific OS.”
Possibly the most important container-to-host and host-to-container security innovation will be the fact that system containers (system services) are apparently heavily sandboxed into their own unprivileged space, given just the external access that they need.
Couple that functionality with the collaboration of the Kernel Self Protection Project (KSPP) and with a resounding thumbs-up from me, it looks like Docker have focused on something very worthwhile. For those unfamiliar, KSPP’s raison d’etre is as follows:
“This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws.”
The KSPP site goes on to state admirably that:
“Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to fail safely, instead of just running safely.”
And, initially, if Docker only take baby steps with LinuxKit, the benefit that it will bring over time through maturity will likely make great strides in the container space.
The end is far from nigh
As the powerhouse that is Docker continues to grow, there’s no doubt whatsoever that these giant-sized leaps in the direction of solid progress will benefit users and other software projects alike.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Advance your career in Linux System Administration! Check out the Essentials of System Administration course from The Linux Foundation.
This article originally appeared on DevSecOps.
