Linux Security Guide. Dangerous Linux Vulnerabilities Encrypt the file system in Linux for more complete Linux security

At the annual LinuxCon conference in 2015, the creator of the GNU / Linux kernel Linus Torvalds shared his opinion about the security of the system. He emphasized the need to mitigate the effect of the presence of certain bugs with competent protection, so that if one component fails, the next layer covers the problem.

In this article we will try to reveal this topic from a practical point of view:

7. Install firewalls

Recently there was a new vulnerability that allows DDoS attacks on servers running Linux. A bug in the system core has appeared since version 3.6 at the end of 2012. The vulnerability allows hackers to inject viruses into download files, web pages and expose Tor connections, and it does not take much effort to hack - the IP spoofing method will work.

The maximum harm for encrypted HTTPS or SSH connections is connection interruption, but an attacker can put new content, including malware, into unprotected traffic. To protect against such attacks, a firewall is suitable.

Block access with Firewall

Firewall is one of the most important tools for blocking unwanted incoming traffic. We recommend that you allow only the traffic you really need to pass through and completely block all other traffic.

For packet filtering, most Linux distributions have an iptables controller. It is usually used by advanced users, and for simplified configuration, you can use the UFW utilities on Debian/Ubuntu or FirewallD on Fedora.

8. Disable unnecessary services

Specialists from the University of Virginia recommend turning off all services that you do not use. Some background processes are set to autoload and run until the system shuts down. To configure these programs, you need to check the initialization scripts. Services can be started via inetd or xinetd.

If your system is configured via inetd, then in the /etc/inetd.conf file you can edit the list of “daemons” background programs, to disable the loading of the service, just put a “#” sign at the beginning of the line, turning it from an executable into a comment.

If the system uses xinetd, then its configuration will be in the /etc/xinetd.d directory. Each directory file defines a service that can be disabled by specifying the disable = yes clause, as in this example:

Service finger ( socket_type = stream wait = no user = nobody server = /usr/sbin/in.fingerd disable = yes )
It's also worth checking for persistent processes that are not managed by inetd or xinetd. You can configure startup scripts in the /etc/init.d or /etc/inittab directories. After the changes have been made, run the command under the root account.

/etc/rc.d/init.d/inet restart

9. Protect the server physically

It is not possible to fully protect against attacks by an attacker with physical access to the server. Therefore, it is necessary to secure the room where your system is located. Data centers take security seriously, limiting access to servers, installing security cameras, and appointing constant guards.

To enter the data center, all visitors must go through certain authentication steps. It is also strongly recommended to use motion sensors in all areas of the center.

10. Protect the server from unauthorized access

An unauthorized access system, or IDS, collects data about system configuration and files and then compares this data with new changes to determine if they are harmful to the system.

For example, the Tripwire and Aide tools collect a database of system files and protect them with a set of keys. Psad is used to track suspicious activity through firewall reporting.

Bro is designed to monitor the network, track suspicious activity patterns, collect statistics, execute system commands and generate alerts. RKHunter can be used to protect against viruses, most often rootkits. This utility scans your system against a database of known vulnerabilities and can detect unsafe settings in applications.

Conclusion

The tools and settings listed above will help you partially protect the system, but security depends on your behavior and understanding of the situation. Without attention, caution and constant self-learning, all protective measures may not work.

It can certainly be said that linux more safe(protected) than Windows. Safety V linux built-in, and not screwed somewhere on the side, as is implemented in Windows. Safety systems linux covers the area from the kernel to the desktop, but there are chances for hackers to damage your home directory (/home).

Your bytes of photos, home videos, documents, and credit card or wallet data are the most valuable piece of information on a computer. Of course, Linux is not susceptible to all sorts of Internet worms and viruses for Windows. But attackers can find a way to access your data in your home directory.

Having prepared your old computer or hard drive before selling, formatting, do you think it will be enough? There are a lot of modern tools for data recovery. The hacker will easily recover your data from your hard drive, regardless of the operating system in which you worked.

On this topic, I recall the experience of one company repurchasing used computers and disks. In the course of their activities, they issued a verdict that 90% of the previous owners of their computer did not take proper care of cleaning their storage media before selling. And they were extracting very sensitive bytes of data. It’s even scary to imagine that somewhere in the bins of your hard drive there is information to enter your online bank or online wallet.

Start with Linux security basics

Let's step into the basics (), which will fit almost any
Linux distributions.

Encrypting the file system in Linux for more complete Linux security

Custom passwords won't solve the problem if you really want no one to be able to read your home directory (/home) or a certain byte size. You can do it so that even a user with the highest privileges of root cannot poke his nose.

Delete sensitive files so that no one else can recover them

If you decide to sell or donate your computer or storage media, don't assume that simple formatting will permanently delete your files. You can install the secure-delete tool on your Linux, which includes the srm utility to securely delete files.

Also, do not forget about the firewall available in the Linux kernel. All Linux distributions include lptables, which is part of the kernel. Lptables allows you to filter network packets. Of course, you can configure this utility in the terminal. But this method is beyond the power of many, including me. So I install and configure as easily as if I were playing a game.

Like all operating systems, Linux is prone to the accumulation of junk when running various applications. And this is not Linux's fault, since various applications, such as browsers, text editors and even video players, work outside the kernel level and accumulate temporary files. You can install the BleachBit universal garbage disposal utility.

Anonymous surfing, hiding your IP - very important for the security of your identity under Linux OS


In conclusion, I want to tell you about anonymous web surfing. Sometimes it happens that it is necessary, as I do, when, secretly from my wife, I visit sites with erotic content. Of course I was joking.

It will be difficult for attackers to get to you if they cannot determine your location. We cover the tracks with a simple setup of two utilities working together called privoxy and tor.

In my opinion, following and setting up all these rules will secure you and your computer by 90%.

P.S. I'm using a cloud called dropbox. I keep my old and new, not yet published articles in it. It is convenient to have access to your files from anywhere in the world and on any computer. When writing articles for the site in a text editor, I save my text documents with a password and only then upload them to the dropbox server. You should never neglect extra security, which will only play into your hands.

We all know that the Linux operating system is much safer than Windows due to its architecture and a special system for distributing access between users. But programmers are people too, as much as we hate it, they make mistakes too. And because of these errors, holes appear in the system through which attackers can bypass security systems.

These errors are called vulnerabilities, they can occur in various programs and even in the very core of the system, undermining its security. In recent years, the popularity of Linux has begun to grow and security researchers are paying more attention to this system. More and more vulnerabilities are being discovered, and thanks to the open source code, it turns out to fix them very quickly. In this article, we will look at the most dangerous Linux vulnerabilities that have been discovered over the past few years.

Before moving on to the list of vulnerabilities itself, it is important to understand what they are and what they are. As I said, a vulnerability is a bug in a program that allows a user to use the program in a way that was not intended by its developer.

This may be the lack of validation of the received data, verification of the data source and, most interestingly, the size of the data. The most dangerous vulnerabilities are those that allow the execution of arbitrary code. In RAM, all data has a certain size, and the program is designed to write to memory data from a user of a certain size. If the user submits more data, then it should throw an error.

But if the programmer made a mistake, then the data will overwrite the program code and the processor will try to execute them, thus buffer overflow vulnerabilities arise.

Also, all vulnerabilities can be divided into local ones, which work only if the hacker has access to the local computer, and remote ones, when access via the Internet is sufficient. And now let's move on to the list of vulnerabilities.

1. Dirty COW

The first on our list will be a fresh vulnerability that was discovered this fall. The name Dirty COW stands for Copy on Write. An error occurs in the file system during copy-on-write. This is a local vulnerability that allows any unprivileged user to gain full access to the system.

In short, two files are needed to exploit the vulnerability, one is writable only on behalf of the superuser, the second is for us. We start writing data to our file and reading from the superuser file a lot of times, after a certain time there will come a moment when the buffers of both files are mixed and the user will be able to write data to a file whose write is not available to him, so you can give yourself root rights in the system.

The vulnerability was in the kernel for about 10 years, but after the discovery it was quickly eliminated, although there are still millions of Andoid devices in which the kernel has not been updated and does not think and where this vulnerability can be exploited. The vulnerability was coded CVE-2016-5195.

2. Glibc Vulnerability

The vulnerability received the code CVE-2015-7547. This has been one of the most discussed vulnerabilities among open source projects. In February 2016, it turned out that the Glibc library has a very serious vulnerability that allows an attacker to execute his code on a remote system.

It is important to note that Glibc is an implementation of the C and C++ standard library, which is used in most Linux programs, including services and programming languages ​​such as PHP, Python, Perl.

An error was made in the code for parsing the DNS server response. Thus, the vulnerability could be used by hackers whose DNS was accessed by vulnerable machines, as well as performing a MITM attack. But the vulnerability gave full control over the system

The vulnerability has been in the library since 2008, but after the discovery, patches were released fairly quickly.

3. Heartbleed

In 2014, one of the most serious vulnerabilities in terms of scale and consequences was discovered. It was caused by a bug in the heartdead module of OpenSSL, hence the name Heartbleed. The vulnerability allowed attackers to gain direct access to 64 kilobytes of server RAM, the attack could be repeated until all memory was read.

Despite the fact that the fix was released very quickly, a lot of sites and applications were affected. In fact, all sites using HTTPS to secure traffic were vulnerable. Attackers could get user passwords, their personal data, and everything that was in memory at the time of the attack. The vulnerability received the code CVE-2014-0160.

4.Stagefright

If a vulnerability has received a code name, it definitely means that it deserves attention. The Stagerfight vulnerability is no exception. True, this is not really a Linux problem. Stagefright is a library for handling multimedia formats in Android.

It is implemented in C++, which means it bypasses all the Java security mechanisms. In 2015, a whole group of vulnerabilities were discovered that allowed arbitrary code to be remotely executed on the system. These are CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 and CVE-2015-3829.

It was enough for an attacker to send an MMS to a vulnerable smartphone with a specially modified media file, and he got full control over the device with the ability to write and read data from the memory card. The vulnerability was fixed by Android developers, but millions of devices still remain vulnerable.

5. Kernel Zero Day Vulnerability

This is a local vulnerability that allows you to elevate the current user to root due to an error in the system for working with kernel cryptographic data that is stored in memory. It was discovered in February 2016 and covered all kernels starting from 3.8, which means that the vulnerability existed for 4 years.

The error could have been used by hackers or malware to increase their authority in the system, but was quickly fixed.

6. Vulnerability in MySQL

The vulnerability was coded CVE-2016-6662 and affected all available MySQL database server versions (5.7.15, 5.6.33, and 5.5.52), Oracle databases, and clones of MariaDB and PerconaDB.

Attackers could gain full access to the system through an SQL request, a code was transmitted that allowed them to replace my.conf with their own version and restart the server. It was also possible to execute malicious code with superuser rights.

MariaDB and PerconaDB solutions released patches quite quickly, Oracle reacted, but much later.

7 Shellshock

This vulnerability was discovered in 2014 before it lasted 22 years. She was assigned the code CVE-2014-6271 and the code name Shellshock. This vulnerability is comparable in danger to the already known Heartbleed. It is caused by a bug in the Bash command interpreter, which is the default on most Linux distributions.

Bash allows you to declare environment variables without user authentication, and together you can execute any command in them. This is especially dangerous in CGI scripts, which are supported by most sites. Vulnerable are not only servers, but also personal computers of users, routers and other devices. In fact, an attacker can remotely execute any command, this is a full-fledged remote control without authentication.

Vulnerabilities were affected by all versions of Bash, including 4.3, however, after the discovery of the problem, the developers very quickly released a fix.

8.Quadrooter

This is a whole series of vulnerabilities in Android, which was discovered in August 2016. They received the codes CVE-2016-5340, CVE-2016-2059, CVE-2016-2504, CVE-2016-2503. More than 900 million Android devices are affected by the error. All vulnerabilities were found in Qualcomm's ARM processor driver, and all of them can be used to gain root access to the device.

Like DirtyCOW, no permissions are needed here, just install a malicious application and it will be able to get all your data and transfer it to an attacker.

9. Vulnerability in OpenJDK

This is a very serious linux 2016 vulnerability in the OpenJDK Java Machine with CVE-2016-0636 code that affects all users running Oracle Java SE 7 Update 97 and 8 Update 73 and 74 on Windows, Solaris, Linux and Mac OS X. This vulnerability allows an attacker to execute arbitrary code outside of a Java machine if you open a special page in a browser with a vulnerable version of Java.

This allowed an attacker to gain access to your passwords, personal data, and also run programs on your computer. In all versions of Java, the bug was fixed very quickly, it has existed since 2013.

10. HTTP/2 Vulnerability

This is a series of vulnerabilities that were discovered in 2016 in the HTTP/2 protocol. They received the codes CVE-2015-8659, CVE-2016-0150, CVE-2016-1546, CVE-2016-2525, CVE-2016-1544. All implementations of this protocol in Apache, Nginx Microsoft, Jetty and nghttp2 were subject to vulnerabilities.

All of them allow an attacker to slow down the web server very much and perform a denial of service attack. For example, one of the errors resulted in the possibility of sending a small message, which was unpacked into gigabytes on the server. The bug was fixed very quickly and therefore did not cause much noise in the community.

Are you safe?

In this article, we reviewed the most dangerous Linux vulnerabilities of 2016, 2015 and 2014. Most of them could cause serious damage to systems if not corrected in time. Thanks to the open source code, such Linux vulnerabilities are effectively detected and quickly fixed. Just don't forget to update your system. The problem remains only with Android. Some devices are no longer receiving updates and there is no solution to this problem yet.


Many users consider Ubuntu pop and Ubuntu Server not serious. Many people forget that Ubuntu Server is supported for 5 years, and the father of Debian 5.0 was on the market for 3 years - from 2009 to 2012.

In terms of support prices - compared to Red Hat, Ubuntu Server can and should be said - you got it for free, even if you order round-the-clock support 24x7x365.

See what security solutions are implemented in all versions of Ubuntu and make it safe and reliable.

Possibilities

Security capability matrix

Opportunity 8.04LTS(Hardy Heron) 10.04LTS(Lucid Lynx) 11.04 (Natty Narwhal) 11.10 (Oneiric Ocelot) 12.04LTS(Precise Pangolin) 12.10 (Quantal Quetzal)
No open ports policy policy policy policy policy policy
Password hash md5 sha512 sha512 sha512 sha512 sha512
SYN cookies -- kernel & sysctl kernel & sysctl kernel & sysctl kernel & sysctl kernel & sysctl
File system capabilities -- kernel kernel kernel kernel kernel
Configurable firewall ufw ufw ufw ufw ufw ufw
PR_SET_SECCOMP kernel kernel kernel kernel kernel kernel
AppArmor 2.1 2.5 2.6.1 2.7.0~beta1 2.7.0 2.7.0
SELinux universe universe universe universe universe universe
SMACK -- kernel kernel kernel kernel kernel
Encrypted LVM alt installer alt installer alt installer alt installer alt installer alt installer
eCryptfs -- ~/Private or ~, filenames ~/Private or ~, filenames ~/Private or ~, filenames ~/Private or ~, filenames ~/Private or ~, filenames
Stack protection gcc patch gcc patch gcc patch gcc patch gcc patch gcc patch
Heap protection glibc glibc glibc glibc glibc glibc
obfuscated pointer glibc glibc glibc glibc glibc glibc
ASLR stack kernel kernel kernel kernel kernel kernel
libs/mmap ASLR kernel kernel kernel kernel kernel kernel
Exec ASLR kernel (-mm patch) kernel kernel kernel kernel kernel
brk ASLR kernel (exec ASLR) kernel kernel kernel kernel kernel
VDSO ASLR kernel kernel kernel kernel kernel kernel
Building with PIE -- package list package list package list package list package list
-- gcc patch gcc patch gcc patch gcc patch gcc patch
Assembly with RELRO -- gcc patch gcc patch gcc patch gcc patch gcc patch
Building with BIND_NOW -- package list package list package list package list package list
Non-Executable Memory PAE-only PAE, ia32 partial-NX-emulation PAE, ia32 partial-NX-emulation PAE, ia32 partial-NX-emulation PAE, ia32 partial-NX-emulation
Protecting /proc/$pid/maps kernel & sysctl kernel kernel kernel kernel kernel
Symbolic link limits -- -- kernel kernel kernel kernel
Hard link restrictions -- -- kernel kernel kernel kernel
ptrace scope -- -- kernel kernel kernel kernel
0-address protection kernel & sysctl kernel kernel kernel kernel kernel
Protecting /dev/mem kernel (-mm patch) kernel kernel kernel kernel kernel
Disabled /dev/kmem kernel (-mm patch) kernel kernel kernel kernel kernel
Module loading blocking drop CAP_SYS_MODULES sysctl sysctl sysctl sysctl sysctl
kernel kernel kernel kernel kernel kernel
Kernel stack protection -- kernel kernel kernel kernel kernel
RO/NX module -- -- kernel kernel kernel kernel
-- -- kernel kernel kernel kernel
-- -- kernel kernel kernel kernel
System call filtering -- -- -- kernel kernel kernel

No open ports

The default Ubuntu installation does not have open ports available from outside the network. The exception to this rule is only for network infrastructure services such as DHCP client and mDNS (Avahi/ZeroConf).

When Ubuntu Server is installed, the administrator can install additional network services such as the Apache web server. But by default, on a freshly installed system, if you do netstat -an --inet | grep LISTEN | grep -v 127.0.0.1 , then you can easily verify that Ubuntu does not unnecessarily open ports for access from networks to the system.

Password hash

The system password used to log into Ubuntu is stored in /etc/shadow. Long ago, the DES password hash was stored in /etc/passwd. But modern Linuxes have been storing hashes in /etc/shadow for a long time and at first a salted MD5-based hashes crypt id 1 was used. Since the same passwords had the same hashes without the use of a salt, the introduction of a salt improved security and made it more difficult to crack the passwords of many users of the system.

Now MD5 is considered unreliable and with the growth of computing capabilities of computers, with Ubuntu 8.10, a SHA-512 hash with a salt (salted SHA-512 based password hashes crypt id 6) is used. This makes brute-force brute-force hacking incredibly difficult and time consuming.

See mancrypt for details.

Use test-glibc-security.py for tests.

SYN cookies

When the system is flooded with new network connections, the SYN cookie mechanism helps reduce the damage from SYN flood attacks.

File system capabilities

The need for setuid applications that run with higher privileges than the one who launched them can be reduced by using filesystem features such as xattrs. Such capabilities reduce the risk of abuse of potentially dangerous setuid applications.

The Linux kernel maintains support and there is a libcap2-bin toolkit for using file capabilities like xattrs to enhance the security of setuid applications.

Use test-kernel-security.py for tests.

Configurable firewall

ufw is an iptables front-end that is installed and used in Ubuntu, but must be enabled by the user. UFW aims to provide an easy to use interface for people not familiar with iptables firewall concepts, chains and tables.

At the same time, UFW simplifies complex iptables commands to help the administrator who knows what he is doing.

UFW is an assistant and a basis for graphical frontends.

Use ufw tests for tests.

PR_SET_SECCOMP

AppArmor

SELinux

SELinux is a mandatory access control system based on the concept of an inode - a file system inode.

Installing the selinux package will make the necessary changes and adjustments during PC boot.

Use test-kernel-security.py for tests.

SMACK

SMACK is a flexible mandatory access control system based on the concept of inode - file system index descriptor.

Use test-kernel-security.py for tests.

File system encryption

LVM Encryption

Users using the Alternate installer can install Ubuntu on an encrypted LVM (Logical Volume Manage - Logical Volume Manager), which will encrypt all partitions, including the swap partition.

eCryptfs

Encrypted folders were first implemented in Ubuntu 8.10 as a safe place to store sensitive user information.

The Alternate and Server Disk Installer allows you to set up encrypted folders for the first user.

In Ubuntu 9.04, support for folder encryption was expanded to allow the user to encrypt the entire home folder. Home folder encryption is supported in the Alternate installer and the Desktop installer via the user-setup/encrypt-home=true option.

Strengthening User Space Security

Many security features are implemented through compilation flags when building software packages and the kernel.

Stack protection

The gcc -fstack-protector flag provides stack overflow protection by placing a small random number as a token. This technique makes stack overflows more difficult for various exploits.

A small number of programs do not work well if they are built with this option and have -fstack-protector disabled for them.

Use test-gcc-security.py for tests.

Heap protection

The GNU C Library heap protection (automatically ptmalloc and manually) provides corrupted-list/unlink/double-free/overflow protection in the glibc memory manager.

This prevents arbitrary code from executing through heap memory overflow, thereby corrupting the structure of the heap area.

This protection has evolved over time, adding more and more protection options. In its current state, glibc 2.10 successfully resists even subtle attack conditions.

obfuscated pointer

Some glibc pointers are obfuscated via the PTR_MANGLE/PTR_UNMANGLE macros internally in glibc, preventing pointers from being overwritten at runtime.

Use the test-glibc-security.py tests.

Random placement in the address space. Address Space Layout Randomization (ASLR)

ASLR is implemented in the kernel and the ELF loader places the most important structures at random addresses: stack, heap, shared libraries, and more.

This makes it harder to predict addresses when an attacker tries to use exploits.

ASLR is changed globally via /proc/sys/kernel/randomize_va_space. Prior to Ubuntu 8.10, the value was "1" (enabled). In later releases that include brk ASLR, the value is set to "2" (enabled with brk ASLR).

ASLR stack

The results of each execution of the program are placed in different places on the stack. It is hard to find in memory and attack the program by adding malicious payload.

libs/mmap ASLR

Libraries are loaded dynamically into different memory locations, making it difficult for an attacker to find a return point.

Protection is available from kernel 2.6.15 (Ubuntu 6.06).

Exec ASLR

Programs built with the "-fPIE -pie" option are loaded into different locations in memory. This makes it harder to attack or jump to an address to carry out a memory modification attack.

Protection is available from kernel 2.6.25 (Ubuntu 8.04 LTS).

brk ASLR

Like exec ASLR, brk ASLR adjusts memory addresses between exec and brk for small memory allocation requests. Randomization of brk exec memory offset was added in kernel 2.6.26 (Ubuntu 8.10).

VDSO ASLR

Each time the program is run, it places the results in a different vdso. First appeared in kernel 2.6.18 (x86, PPC) and 2.6.22 (x86_64), but was not included in Ubuntu 6.10 due to COMPAT_VDSO, which was removed in Ubuntu 8.04 LTS.

Protects against jump-into-syscall attacks.

Only x86 was supported by glibc 2.6. glibc 2.7 (Ubuntu 8.04 LTS) already supported x86_64 ASLR vdso.

Those who need the ancient static pre-libc6 vdso can use "vdso=2" as a kernel parameter and get COMPAT_VDSO again.

Building with PIE

All programs that are built with the Position Independent Executables (PIE) option "-fPIE -pie" can take advantage of the exec ASLR protection.

This protects against "return-to-text" attacks and renders conventional memory modification attacks useless.

Due to PIE, there is a large performance drop (5-10%) on architectures with a small number of general purpose registers (such as x86).

Therefore, PIE is used for a small number of security-critical packages.

PIE for x86_64 doesn't have performance degradation issues, so it's used for all packages, but needs better testing.

Plastic bag 8.04LTS 9.04 9.10 10.04LTS 10.10 11.04 11.10
openssh Yes Yes Yes Yes Yes Yes Yes
apache2 -- Yes Yes Yes Yes Yes Yes
bind9 -- Yes Yes Yes Yes Yes Yes
openldap -- Yes Yes Yes Yes Yes Yes
postfix -- Yes Yes Yes Yes Yes Yes
cups -- Yes Yes Yes Yes Yes Yes
postgresql-8.3 -- Yes Yes Yes Yes Yes Yes
samba -- Yes Yes Yes Yes Yes Yes
dovecot -- Yes Yes Yes Yes Yes Yes
dhcp3 -- Yes Yes Yes Yes Yes Yes
ntp -- -- Yes Yes Yes Yes Yes
amavisd-new -- -- Yes Yes Yes Yes Yes
squid -- -- Yes Yes Yes Yes Yes
cyrus-sasl2 -- -- Yes Yes Yes Yes Yes
exim4 -- -- Yes Yes Yes Yes Yes
nagios3 -- -- Yes Yes Yes Yes Yes
nagios-plugins -- -- Yes Yes Yes Yes Yes
xinetd -- -- Yes Yes Yes Yes Yes
ipsec-tools -- -- Yes Yes Yes Yes Yes
mysql-dfsg-5.1 -- -- Yes Yes Yes Yes Yes
evince -- -- -- Yes Yes Yes Yes
firefox -- -- -- Yes Yes Yes Yes
gnome-control-center -- -- -- -- -- Yes Yes
tiff -- -- -- -- -- Yes Yes
totem -- -- -- -- -- Yes Yes
qemu-kvm -- -- -- -- -- -- Yes
pidgin -- -- -- -- -- -- Yes

Building with Fortify Source

Programs built with "-D_FORTIFY_SOURCE=2" (and -O1 or higher) include several compile-time and run-time protections in glibc:

  • calls "sprintf", "strcpy" with their undefined bounds are replaced with related functions with bounded N, when the buffer size is known in advance. This protects against memory overflows.
  • stopping an attack via the "%n" string format when the string is in a memory segment with write access.
  • require checking the return codes of the most important functions and arguments (for example, for system, write, open).
  • require an explicit mask when creating the file.

Assembly with RELRO

Tightening for ELF programs to combat bootloader memory overwriting. Reduces the chance of a GOT-overwrite-style attack.

Use test-gcc-security.py tests.

Building with BIND_NOW

Marks ELF programs to allow dynamic characters at startup, instead of on-demand, also known as "immediate binding".

This makes the GOT fully read-only, in combination with the RELRO option.

Use test-built-binaries.py tests.

Non-Executable Memory

Modern processors protect data memory areas (heap, stack) from code execution.

This technology is known as Non-eXecute (NX) or eXecute-Disable (XD). Protection reduces the ability of an attacker to place arbitrary code.

Protection requires "PAE", which also allows addressing above 3 GB of RAM. 64bit and 32bit -server and -generic-pae kernels are already built with PAE.

Starting with Ubuntu 9.10, protection is partially emulated on 32bit kernels for processors that do not support NX hardware.

After loading, you can see the degree of support for NX protection:

  • Hardware: [ 0.000000] NX (Execute Disable) protection: active
  • Emulation:
    [ 0.000000] Using x86 segment limits to approximate NX protection

If you don't see any mention of NX then check your BIOS settings. Since Ubuntu 11.04, BIOS settings for NX are ignored by the kernel.

Ubuntu 9.04 and earlier
CPU supports NX CPU does not support NX
NX enabled in BIOS NX disabled in BIOS
i386 -386, -generic kernel (non-PAE) nx is not supported nx is not supported nx is not supported
-server kernel (PAE) real nx nx is not supported nx is not supported
amd64 any core (PAE) real nx nx is not supported nx is not supported

Use test-kernel-security.py tests.

Protecting /proc/$pid/maps

When ASLR is running, current process memory maps become very valuable to an attacker. The map file is readable only by the process itself and the process owner.

Available since kernel 2.6.22.

Use test-kernel-security.py tests.

Symbolic link limits

The most common way to exploit this defect is to force root to use a symbolic link created by an attacker in order to perform a malicious action as root.

As of Ubuntu 10.10, symlinks in directories like /tmp cannot be traversed unless the "follower" and the owner of the directory are the same as the owner of the symlink.

This mechanism is controlled by the Yama /proc/sys/kernel/yama/protected_sticky_symlinks mechanism. Yama is developed by Canonical.

Use test-kernel-security.py tests.

Hard link restrictions

If the /etc/ and /home/ directories are on the same partition, a normal user can create a hard link to the password hash file /etc/shadow in their home folder. Of course, if a certain file is not readable or writable by any user, the hard link to that file will have the same permissions and therefore will not be available to that user either. However, using hard links, an attacker can "slip" such a file to an application that has the rights to access it.

Yama allows you to block this attack by preventing the creation of hard links by users who do not have access rights to the source files.

The behavior is controlled by /proc/sys/kernel/yama/protected_nonaccess_hardlinks Yama.

ptrace scope

Without the use of the appropriate Yama protection, any process with the CAP_SYS_PTRACE privilege can access the memory of all processes with the same UID. When using Yama, it is possible to limit the scope of access to only memory owned by the descendants of such a process.

In Ubuntu 10.10 and later, users cannot debug processes with ptrace unless they are descendants of it.

The behavior is controlled by /proc/sys/kernel/yama/ptrace_scope Yama.

Use test-kernel-security.py tests.

Hardening the kernel

Enabled kernel defenses to make attacks more difficult.

0-address protection

Since the kernel and user space share virtual memory addresses, "NULL" memory must be protected and "user" memory cannot start at address 0, thus preventing kernel address dereferences - a "NULL dereference" attack.

The protection is available since kernel 2.6.22 via the "mmap_min_addr" sysctl parameter. As of Ubuntu 9.04 mmap_min_addr is built into the kernel - address 64k on x86, 32k on ARM.

Use test-kernel-security.py tests.

Protecting /dev/mem

Some applications, such as Xorg, require direct access to physical memory in user space. The special /dev/mem file provides this access.

In the past, it was possible to view and modify kernel memory through this file if an attacker gained root access.

The CONFIG_STRICT_DEVMEM option was introduced to block such attempts (originally the option was called CONFIG_NONPROMISC_DEVMEM).

Use test-kernel-security.py tests.

Disabled /dev/kmem

For a modern user, /dev/kmem is not relevant, as it was mostly used by attackers to download rootkits.

CONFIG_DEVKMEM is now set to "n".

The /dev/kmem file exists in releases from Ubuntu 8.04 LTS to Ubuntu 9.04, but has not been associated with anything in the kernel and is not used.

Use test-kernel-security.py tests.

Module loading blocking

In Ubuntu 8.04 LTS and earlier, it was possible to remove the CAP_SYS_MODULES feature and thus prevent new kernel modules from being loaded.

This was another layer of protection, so as not to download rootkits at the start of a compromised system.

In kernel 2.6.25 (Ubuntu 8.10) this functionality is gone. As of Ubuntu 9.10 it is now possible to disable modules again by setting /proc/sys/kernel/modules_disabled to "1".

Use test-kernel-security.py tests.

Read-only data section

Marking the kernel data section as read-only ensures that changes are blocked. This helps protect against some rootkits. Enabled via the CONFIG_DEBUG_RODATA option.

Use test-kernel-security.py tests.

Kernel stack protection

As well as protecting ELF programs in user space, the kernel can protect its internal stack via the CONFIG_CC_STACKPROTECTOR option.

Use test-kernel-security.py tests.

RO/NX module

This feature extends CONFIG_DEBUG_RODATA to include restrictions on loaded kernel modules. This helps to resist exploits. Enabled via the CONFIG_DEBUG_MODULE_RONX parameter.

Use test-kernel-security.py tests.

Kernel Address Display Restriction

When attackers try to develop an exploit that works everywhere using kernel vulnerabilities, they need to know the location of internal kernel structures.

Kernel addresses, as important information, are inaccessible to ordinary users.

Starting with Ubuntu 11.04, /proc/sys/kernel/kptr_restrict is set to "1" and blocks leaks of kernel address information.

Also, various files and directories are made read-only by root.
/boot/vmlinuz*, /boot/System.map*, /sys/kernel/debug/, /proc/slabinfo

Use test-kernel-security.py tests.

Black list of rare protocols

Normally the kernel allows all network protocols to be automatically loaded on demand via MODULE_ALIAS_NETPROTO(PF_...) macros.

Since many of these protocols are outdated, rare, and of little use to the average Ubuntu user, and may contain unknown vulnerabilities, they have been blacklisted since Ubuntu 11.04.

Blacklisted: ax25, netrom, x25, rose, decnet, econet, rds and af_802154.

If any of these protocols are needed, they can be loaded via modprobe or by editing /etc/modprobe.d/blacklist-rare-network.conf.

Use test-kernel-security.py tests.

System call filtering

Programs can filter kernel calls using seccomp_filter.

This is done in containers or sandboxes to further restrict potentially untrusted software.

Use test-kernel-security.py tests.

Outcome

After reading, it is clear that Canonical takes Ubuntu security seriously. Two projects, AppArmor and Yama, have long been associated with Ubuntu and help improve security. Ubuntu, by default, does not open unnecessary ports-doors on the network and does not wait for adventure connections on its head. AppArmor profiles have been created for key programs that work with the network, which keep programs in check.

Your computer will be safe with Ubuntu!

Installation and configuration of administration tools, network configuration

After we have installed the base operating system ubuntu14.04 from the minimal distribution, the first thing to consider is how to manage it comfortably. Basically, ssh/telnet is used to configure and manage *nix-based servers, but recently web-based tools have also appeared quite suitable for this. I use free solutions webmin And Ajenti. Both of these panels deserve attention, and despite the fact that they can do everything individually, each of them is better for something, so it is better to have both of them. I should note that on combat production servers, such solutions are not installed on the basis of security. Still, the more control systems, the more likely it is to find a vulnerability in them. Therefore, if your security requirements are at the "paranoia" level, then just accept the fact that you will have to work with the server only through ssh (via the console).

network setup in ubuntu 14.04

To communicate with our server over the network, you first need to configure it. By default, during installation, the network was configured automatically, and if the installer found a DHCP server on the network, then most likely it has already configured everything as needed. If there is no DHCP server on the network, then the installer still configured everything based on polling the router to which the network card is connected. In order to see how the network is currently configured, just type in the terminal:

What do we see here:

We have two network interfaces eth0 and lo where lo is the “loopback interface” and eth0 is the name of our network card, and if lo is the unchanged network interface, then all other interfaces can differ in name. If two network cards are installed in the system unit, then their interfaces will most likely look like eth0 and eth1, and so on. The appearance of the interface name depends on the type of network card, for example, if the network card works using the WiFi protocol, then most likely it will have a name wlan0.

To configure the network, edit the following file:

sudo nano /etc/network/interfaces

Let's bring it to this form:

iface eth0 inet static
address 192.168.0.184
netmask 255.255.255.0
gateway 192.168.0.1
auto eth0
dns-nameservers 8.8.8.8 8.8.4.4

Where: iface eth0 inet static- indicates that the interface (iface eth0) is in the IPv4 (inet) address range with a static ip (static);
address 192.168.0.184- indicates that the IP address (address) of our network card is 192.168.0.184;
netmask 255.255.255.0- indicates that our subnet mask (netmask) is 255.255.255.0;
gateway 192.168.0.1- default gateway address 192.168.0.254;
auto eth0- indicates to the system that the eth0 interface should be enabled automatically when the system boots with the above parameters.
eth0— name of the connected interface. The list of interfaces can be viewed by typing ifconfig
dns-nameservers- DNS servers are written with a space.

As you can see in my case, I decided to set a static ip 192.168.0.184

restart the server with the command

We ping our server from the network and make sure that it is visible. Now it's time to establish a connection with it via SSH, for this we will actually install the ssh server:

sudo apt-get install ssh

Now you can connect to our server via ssh through the putty program, for example, now you can enter commands not manually, but by copying and pasting the lines we need into the ssh client, because in the future this will surprisingly facilitate configuration, as you will soon see for yourself:

ALL COMMANDS BELOW THIS LINE ARE ENTERED ON BEHALF OF THE SUPERUSER, and in order to enter superuser mode, you need to type:

Installing webmin

echo "deb https://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list echo "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib" >> /etc/apt/sources.list wget https://www.webmin.com/jcameron-key.asc apt-key add jcameron-key.asc apt-get update apt-get install -y webmin

echo "deb https://download.webmin.com/download/repository sarge contrib">>

echo "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib">> /etc/apt/sources. list

wgethttps : //www.webmin.com/jcameron-key.asc

apt - key add jcameron - key . asc

apt-get update

apt - get install - y webmin

All! 6 sequentially entered commands and webmin is installed and configured. Now you can go through the browser at the address:

https://192.168.0.184:10000

By default, webmin looks minimalistic, the interface is displayed in English by default, but everything is customizable!

We do it like this:

It turns out like this:

mob_info