Safe surfing in Ubuntu. Safe surfing in Ubuntu Disable unnecessary services
Many users consider Ubuntu to be pop and Ubuntu Server not serious. Many people forget that Ubuntu Server has been supported for 5 years, and Debian 5.0 was on the market for 3 years - from 2009 to 2012.
At support prices - Ubuntu Server compared to Red Hat can and should be said - you got it for nothing, 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.04 LTS(Hardy Heron) | 10.04 LTS(Lucid Lynx) | 11.04 (Natty Narwhal) | 11.10 (Oneiric Ocelot) | 12.04 LTS(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 | |
| Protect /proc/$pid/maps | kernel & sysctl | kernel | kernel | kernel | kernel | kernel |
| Limitations of symbolic links | -- | -- | kernel | kernel | kernel | kernel |
| Limitations of Hard Links | -- | -- | kernel | kernel | kernel | kernel |
| ptrace scope | -- | -- | kernel | kernel | kernel | kernel |
| 0-address protection | kernel & sysctl | kernel | kernel | kernel | kernel | kernel |
| Protect /dev/mem | kernel (-mm patch) | kernel | kernel | kernel | kernel | kernel |
| /dev/kmem disabled | kernel (-mm patch) | kernel | kernel | kernel | kernel | kernel |
| Blocking module loading | 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 any open ports accessible from outside the network. The only exception to this rule is 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 newly installed system, if you do netstat -an --inet | grep LISTEN | grep -v 127.0.0.1 , then you can easily make sure 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. Once upon a time, a DES password hash was stored in /etc/passwd. But modern Linux has been storing hashes in /etc/shadow for a long time, and at first a hash based on MD5 with salt was used (salted MD5-based hashes crypt id 1). Since the same passwords had the same hashes without the use of a salt, the introduction of a salt made it possible to improve security and make it more difficult to crack the passwords of many users of the system.
Now MD5 is considered unreliable and with the increase in the computing capabilities of computers, with Ubuntu 8.10 the SHA-512 hash with salt is used (salted SHA-512 based password hashes crypt id 6). This makes brute force hacking by trying all the options incredibly difficult and time-consuming.
More details about man crypt.
Use test-glibc-security.py for tests.
SYN cookies
When a system becomes 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 permissions than the person running them can be reduced by using file system capabilities such as xattrs. Such features reduce the risk of abuse of potentially dangerous setuid applications.
The Linux kernel provides support and tooling libcap2-bin for using xattrs-type file capabilities to enhance the security of setuid applications.
Use test-kernel-security.py for tests.
Configurable firewall
ufw is a frontend for iptables, which is installed and used in Ubuntu, but the user must enable it independently. UFW is designed to provide an easy-to-use interface for people not familiar with the concepts of the iptables firewall, with its chains and tables.
At the same time, UFW simplifies complex iptables commands to help the administrator who knows what he's doing.
UFW is an assistant and the 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 inode - a file system index descriptor.
Installing the selinux package will make the necessary changes and adjustments while the PC boots.
Use test-kernel-security.py for tests.
SMACK
SMACK is a flexible mandatory access control system based on the concept of inode - a 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), which will encrypt all partitions, including the swap partition.
eCryptfs
Encrypted folders were first implemented in Ubuntu 8.10 as a secure place to store important 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 and the user could encrypt the entire home folder. Home folder encryption is supported in the Alternate installer and Desktop installer via the user-setup/encrypt-home=true parameter.
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 marker. This method makes stack overflows more difficult for various exploits.
A small number of programs work poorly if they are compiled with this parameter and for them -fstack-protector is disabled.
Use test-gcc-security.py for tests.
Heap protection
GNU C Library heap protection (automatically by ptmalloc and manually) provides corrupted-list/unlink/double-free/overflow protection in the glibc memory manager.
This prevents the possibility of executing arbitrary code through a heap memory overflow, thereby corrupting the structure of the heap region.
This defense has evolved over time, adding more and more defense options. In its current state, glibc 2.10 successfully resists even subtle attack conditions.
Obfuscated pointer
Some glibc pointers are obfuscated via PTR_MANGLE/PTR_UNMANGLE macros internally in glibc, preventing the pointers from being overwritten at runtime.
Use test-glibc-security.py tests.
Random placement in the address space. Address Space Layout Randomisation (ASLR)
ASLR is implemented in the kernel and the ELF loader places the most important structures in random addresses: stack, heap, shared libraries, etc.
This makes it difficult to predict addresses when an attacker tries to use exploits.
ASLR is changed globally via /proc/sys/kernel/randomize_va_space. Before 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 program execution are placed in different parts of the stack. It is difficult 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 memory locations. This makes it difficult to attack or jump to an address to perform a memory modification attack.
Protection is available from kernel 2.6.25 (Ubuntu 8.04 LTS).
brk ASLR
Like exec ASLR, brk ASLR regulates memory addresses between exec and brk for small memory allocation requests. Randomization brk exec memory offset was added in kernel 2.6.26 (Ubuntu 8.10).
VDSO ASLR
Each time the program is run, the results are placed 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 compiled with Position Independent Executables (PIE) with the "-fPIE -pie" option can take advantage of exec ASLR protection.
This protects against "return-to-text" attacks and makes 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 packets.
PIE for x86_64 has no performance issues and is used for all packages, but needs better testing.
| Plastic bag | 8.04 LTS | 9.04 | 9.10 | 10.04 LTS | 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 |
Build with Fortify Source
Programs built with "-D_FORTIFY_SOURCE=2" (and -O1 or higher) enable several compilation and runtime protections in glibc:
- calls "sprintf", "strcpy" with their undefined boundaries are replaced with related functions with limited N, when the buffer size is known in advance. This protects against memory overflows.
- stopping an attack via string format "%n" 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 indication of the mask when creating the file.
Assembly with RELRO
Tightening of ELF programs to combat bootloader memory overwriting. Reduces the likelihood of a GOT-overwrite-style attack.
Use tests test-gcc-security.py.
Building with BIND_NOW
Marks ELF programs to resolve dynamic characters at startup instead of on-demand, also known as "immediate binding".
This makes the GOT completely read-only, in combination with the RELRO parameter.
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 you to address 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 32-bit cores for processors that do not support NX hardware.
After downloading, you can see the level of NX protection support:
- 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, check your BIOS settings. As of 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 is 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.
Protect /proc/$pid/maps
When ASLR is running, the current memory maps of the processes become very valuable to the 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.
Limitations of symbolic links
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 with root privileges.
As of Ubuntu 10.10, symbolic links in directories like /tmp cannot be followed 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 mechanism /proc/sys/kernel/yama/protected_sticky_symlinks. Yama was developed by Canonical.
Use test-kernel-security.py tests.
Limitations of Hard Links
If the /etc/ and /home/ directories are located on the same partition, a normal user can create a hard link to the /etc/shadow file with password hashes in their home folder. Of course, if a certain file is not readable or writable by a user, the hard link to that file will have the same permissions and therefore will also not be accessible to that user. However, using hard links, an attacker can “slip” such a file to an application that has rights to access it.
Yama allows you to block this attack by preventing users who do not have permission to access the source files from creating hard links.
The behavior is controlled by /proc/sys/kernel/yama/protected_nonaccess_hardlinks Yama.
ptrace scope
Without 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, you can limit the scope of access to only the memory owned by the descendants of that process.
On Ubuntu 10.10 and older, users cannot debug processes using 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.
Strengthening kernel protection
Enabled kernel defense mechanisms 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, thereby preventing kernel address dereference - a "NULL dereference" attack.
Protection is available from kernel 2.6.22 via the sysctl parameter "mmap_min_addr". As of Ubuntu 9.04, mmap_min_addr is built into the kernel - address 64k for x86, 32k for ARM.
Use test-kernel-security.py tests.
Protect /dev/mem
Some applications, such as Xorg, require direct access to physical memory in user space. The special file /dev/mem provides such access.
In the past, it was possible to view and modify kernel memory through this file if the attacker gained root access.
The CONFIG_STRICT_DEVMEM option was introduced to block such attempts (the option was originally called CONFIG_NONPROMISC_DEVMEM).
Use test-kernel-security.py tests.
/dev/kmem disabled
For the modern user, /dev/kmem is not relevant, since 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 was not associated with anything in the kernel and is not used.
Use test-kernel-security.py tests.
Blocking module loading
In Ubuntu 8.04 LTS and earlier, it was possible to remove the CAP_SYS_MODULES feature and thereby prevent the loading of new kernel modules.
This was another level of protection to avoid downloading rootkits when a compromised system starts.
In kernel 2.6.25 (Ubuntu 8.10), this functionality disappeared. 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
Like protecting ELF programs in user space, the kernel can protect its internal stack through 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 prevent exploits. Enabled via the CONFIG_DEBUG_MODULE_RONX parameter.
Use test-kernel-security.py tests.
Kernel Address Display Restriction
When attackers try to develop a anywhere exploit using kernel vulnerabilities, they need to know the location of the internal kernel structures.
Kernel addresses, as important information, are not available 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 to be 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
Typically the kernel allows all network protocols to be automatically loaded on demand via the MODULE_ALIAS_NETPROTO(PF_...) macros.
Since many of these protocols are outdated, rare, and of little use for 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 limit potentially untrustworthy software.
Use test-kernel-security.py tests.
Bottom line
After reading, it is clear that in 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 connections-adventures to come its way. 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!
There is a common misconception that servers running Linux OS are the most secure and protected from external intrusions. Unfortunately, this is not the case; the security of any server depends on a number of factors and measures to ensure it and is practically independent of the operating system used.
We decided to start a series of articles devoted to network security with Ubuntu Server, since solutions on this platform are of great interest to our readers and since many believe that Linux solutions are safe in themselves.
At the same time, a router with a dedicated IP address is a “gate” to the local network, and it will depend only on the administrator whether this gate will be a reliable barrier or will turn out to be a country gate closed with a nail.
Another common misconception is reasoning in the style of: “who needs it, our server, we have nothing interesting.” Indeed, your local network may not be of any interest to attackers, but they can use a hacked server to send spam, attacks on other servers, an anonymous proxy, in short, as a starting point for their shady dealings.
And this is already unpleasant and can serve as a source of various problems: from the provider to law enforcement agencies. And you shouldn’t forget about the spread of viruses, theft and destruction of important information, as well as the fact that downtime of an enterprise leads to quite tangible losses.
Despite the fact that the article is dedicated to Ubuntu Server, first we will look at general security issues that apply equally to any platform and are the basics, without which there is no point in discussing the issue in more detail.
Where does safety begin?
No, security doesn't start with the firewall, it doesn't start with hardware at all, security starts with the user. After all, what’s the use of the coolest metal door installed by the best specialists if the owner leaves the key under the rug?
Therefore, the first thing you should do is conduct a security audit. Don’t be intimidated by this word, everything is not so complicated: draw a schematic network plan on which you mark a safe zone, a potential danger zone and a high danger zone, and also make a list of users who have (should have access) to these zones.
The safe zone should include internal network resources that are not accessible from the outside and for which a low level of security is acceptable. These could be workstations, file servers, etc. devices to which access is limited to the enterprise local network.
The potential danger zone includes servers and devices that do not have direct access to the external network, but whose individual services are accessible from the outside, for example, web and mail servers located behind a firewall, but still serving requests from the external network.
The dangerous zone should include devices directly accessible from the outside; ideally, this should be one router.
If possible, a potentially dangerous zone should be placed on a separate subnet - a demilitarized zone (DMZ), which is separated from the main network by an additional firewall.
LAN devices should only have access to those services in the DMZ that they need, such as SMTP, POP3, HTTP, and other connections should be blocked. This will allow you to reliably isolate an attacker or malware that took advantage of a vulnerability in a separate service in a demilitarized zone, denying them access to the main network.
Physically, a DMZ can be organized by installing a separate server / hardware firewall or by adding an additional network card to the router, but in the latter case you will have to pay close attention to the security of the router. But in any case, it is much easier to ensure the security of one server than a group of servers.
The next step should be to analyze the list of users, whether they all need access to the DMZ and to the router (with the exception of public services), special attention should be paid to users connecting from outside.
Typically, this requires the very unpopular step of enforcing a password policy. All passwords for users who have access to critical services and have the ability to connect from outside must contain at least 6 characters and contain, in addition to lowercase letters, characters from two categories out of three: uppercase letters, numbers, non-alphabetic characters.
In addition, the password should not include the user's login or part of it, should not contain dates or names that can be associated with the user, and, preferably, should not be a dictionary word.
It’s a good idea to get into the practice of changing passwords every 30-40 days. It is clear that such a policy can cause rejection on the part of users, but you should always remember that passwords like 123 or qwerty equivalent to leaving a key under the rug.
Server security - nothing extra.
Now, having an idea of what we want to protect and from what, let's move on to the server itself. Make a list of all the services and services, then think about whether they are all needed on this particular server, or whether they can be moved somewhere else.
The fewer services, the easier it is to ensure security, and the less chance of the server being compromised through a critical vulnerability in one of them.
Configure services that serve the local network (for example, squid) so that they accept requests exclusively from the local interface. The fewer services available externally, the better.
A vulnerability scanner will be a good assistant in ensuring security; it should scan the external interface of the server. We used a demo version of one of the most famous products - XSpider 7.7.
The scanner shows open ports, tries to determine the type of service running and, if successful, its vulnerabilities. As you can see, a correctly configured system is quite secure, but you shouldn’t leave the key under the rug; the presence of open ports 1723 (VPN) and 3389 (RDP, forwarded to the terminal server) on the router is a good reason to think about a password policy.
We should also talk about SSH security; this service is usually used by administrators for remote server management and is of great interest to attackers. SSH settings are stored in a file /etc/ssh/sshd_config, all changes described below are made to it. First of all, you should disable authorization under the root user; to do this, add the option:
PermitRootLogin no
Now the attacker will have to guess not only the password, but also the login, and he will still not know the superuser password (we hope it does not match your password). All administrative tasks when connecting from outside should be performed from under sudo logging in as an unprivileged user.
It is worth explicitly specifying the list of allowed users, and you can use entries like user@host, which allows the specified user to connect only from the specified host. For example, to allow the user ivanov to connect from home (IP 1.2.3.4), you should add the following entry:
AllowUser [email protected]
Also disable the use of the outdated and less secure SSH1 protocol, allowing only the second version of the protocol, to do this, change the following line to the form:
Protocol 2
Despite all the measures taken, there will still be attempts to connect to SSH and other public services; to prevent password guessing, use the utility fail2ban, which allows you to automatically ban a user after several unsuccessful login attempts. You can install it with the command:
Sudo apt-get install fail2ban
This utility is ready to work immediately after installation, however, we would advise you to immediately change some parameters; to do this, make changes to the file /etc/fail2ban/jail.conf. By default, only access to SSH is controlled and the ban time is 10 minutes (600 seconds), in our opinion it is worth increasing it by changing the following option:
Bantime = 6000
Then scroll through the file and enable sections for services running on your system by setting the parameter after the name of the corresponding section enabled in a state true, for example for a service proftpd it will look like this:
enabled = true
Another important parameter maxretry, which is responsible for the maximum number of connection attempts. After changing the settings, do not forget to restart the service:
Sudo /etc/init.d/fail2ban restart
You can see the utility log at /var/log/fail2ban.log.
At the annual LinuxCon conference in 2015, the creator of the GNU/Linux kernel, Linus Torvalds, shared his views on system security. He emphasized the need to mitigate the effect of certain bugs with competent protection, so that if one component malfunctions, the next layer covers the problem.
In this material we will try to cover 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 appeared with version 3.6 at the end of 2012. The vulnerability allows hackers to inject viruses into download files, web pages and open Tor connections, and hacking does not require much effort - the IP spoofing method will work.The maximum harm for encrypted HTTPS or SSH connections is interruption of the connection, but an attacker can insert new content, including malware, into unprotected traffic. A firewall is suitable to protect against such attacks.
Block access using Firewall
Firewall is one of the most important tools for blocking unwanted incoming traffic. We recommend allowing only really necessary traffic and completely blocking all others.
For packet filtering, most Linux distributions have an iptables controller. It is usually used by advanced users, and for simplified setup you can use the UFW utilities in Debian/Ubuntu or FirewallD in Fedora.
8. Disable unnecessary services
Experts from the University of Virginia recommend disabling all services that you do not use. Some background processes are set to autostart 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 background “daemon” programs; to disable loading the service, just put a “#” sign at the beginning of the line, turning it from executable to 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 disable = yes, 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 impossible to completely 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 seriously monitor security, limit access to servers, install security cameras and assign permanent security.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 system configuration and file data and further compares this data with new changes to determine whether they are harmful to the system.For example, the Tripwire and Aide tools collect a database of system files and protect them using a set of keys. Psad is used to monitor suspicious activity using firewall reports.
Bro is designed to monitor the network, track suspicious patterns of activity, collect statistics, execute system commands and generate alerts. RKHunter can be used to protect against viruses, most often rootkits. This utility checks your system against a database of known vulnerabilities and can identify 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 care, caution and constant self-education, all protective measures may not work.According to cvedetails.com, since 1999, 1,305 vulnerabilities have been found in the Linux kernel, of which 68 were found in 2015. Most of them do not pose any special problems, they are marked as Local and Low, and some can only be called when linked to certain applications or OS settings. In principle, the numbers are small, but the kernel is not the entire OS. Vulnerabilities are also found in GNU Coreutils, Binutils, glibs and, of course, in user applications. Let's look at the most interesting ones.
VULNERABILITIES IN THE LINUX KERNEL
OS: Linux
Level: Medium, Low
Vector: Remote
CVE: CVE-2015-3331, CVE-2015-4001, CVE-2015-4002, CVE-2015-4003
Exploit: concept, https://lkml.org/lkml/2015/5/13/740, https://lkml.org/lkml/2015/5/13/744
A vulnerability found in June in the Linux kernel before 3.19.3 in the __driver_rfc4106_decrypt function in arch/x86/crypto/aesni-intel_glue.c is due to the implementation of RFC4106 for x86 processors supporting the AES instruction set extension AES-NI (proposed Intel, Intel Advanced Encryption Standard Instructions) does not correctly calculate buffer addresses in some cases. If the IPsec tunnel is configured to use this mode (AES algorithm - CONFIG_CRYPTO_AES_NI_INTEL), the vulnerability can lead to memory corruption, crashes, and potentially remote CryptoAPI code execution. Moreover, the most interesting thing is that the problem can arise on its own, on completely legal traffic, without outside intervention. At the time of publication, the issue has been resolved.
Five vulnerabilities have been identified in the Linux 4.0.5 ozwpan driver, which has experimental status, four of which allow you to organize a DoS attack by crashing the kernel by sending specially designed packets. The problem is related to a buffer overflow due to incorrect handling of signed integers, in which the calculation in memcpy between required_size and offset returned a negative number, as a result, the data is copied to the heap.
Found in the oz_hcd_get_desc_cnf function in drivers/staging/ozwpan/ozhcd.c and in the oz_usb_rx and oz_usb_handle_ep_data functions of the drivers/staging/ozwpan/ozusbsvc1.c file. Other vulnerabilities involved possible division by 0, system looping, or the ability to read from areas outside the bounds of the allocated buffer.
The ozwpan driver, a new addition to Linux, can be paired with existing Ozmo Devices (Wi-Fi Direct) compatible wireless devices. Provides an implementation of a USB host controller, but the trick is that instead of a physical connection, the peripheral communicates via Wi-Fi. The driver accepts network packets with type (ethertype) 0x892e, then parses them and translates them into various USB functionality. For now it is used in rare cases, so it can be disabled by unloading the ozwpan.ko module.
LINUX UBUNTU
OS: Linux Ubuntu 12.04–15.04 (kernel until June 15, 2015)
Level: Critical
Vector: Local
CVE: CVE-2015-1328
Exploit: https://www.exploit-db.com/exploits/37292/
A critical vulnerability in the OverlayFS file system allows for root access on Ubuntu systems that allow mounting of OverlayFS partitions by an unprivileged user. The default settings required to exploit the vulnerability are used in all branches of Ubuntu 12.04–15.04. OverlayFS itself appeared in the Linux kernel relatively recently - starting with 3.18-rc2 (2014), it is a SUSE development to replace UnionFS and AUFS. OverlayFS allows you to create a virtual multi-layer file system that combines several parts of other file systems.
The file system is created from a lower and upper layer, each of which is attached to separate directories. The bottom layer is used for reading only in directories of any file systems supported in Linux, including network ones. The top layer is usually writable and will override the data in the bottom layer if the files are duplicated. It is in demand in Live distributions, container virtualization systems, and for organizing the operation of containers for some desktop applications. User namespaces allow you to create your own sets of user and group IDs in containers. The vulnerability is caused by incorrect check of access rights when creating new files in the directory of the underlying file system.
If the kernel is built with CONFIG_USER_NS=y (enable user namespace) and the FS_USERNS_MOUNT flag is specified when mounting, OverlayFS can be mounted by a normal user in another namespace, including those that allow root operations. In this case, operations with files with root rights performed in such namespaces receive the same privileges when performing actions with the underlying file system. Therefore, you can mount any FS partition and view or modify any file or directory.
At the time of publication, a kernel update with a fixed OverlayFS module from Ubuntu was already available. And if the system is updated, there should be no problems. In the same case, when the update is not possible, as a temporary measure, you should stop using OverlayFS by removing the overlayfs.ko module.
VULNERABILITIES IN KEY APPLICATIONS
OS: Linux
Level: Critical
Vector: local, remote
CVE: CVE-2015-0235
Exploit: https://www.qualys.com/research/security-advisories/exim_ghost_bof.rb
A dangerous vulnerability in the GNU glibc standard library, which is a core part of the Linux OS, and in some versions of Oracle Communications Applications and Oracle Pillar Axiom, discovered during a code audit by hackers from Qualys. Received the code name GHOST. This is a buffer overflow inside the __nss_hostname_digits_dots() function, which is used by glibc functions like gethostbyname() and gethostbyname2() to get the host name (hence the name GetHOST). To exploit the vulnerability, you must cause a buffer overflow using an invalid hostname argument to an application performing name resolution through DNS. That is, theoretically, this vulnerability can be applied to any application that uses the network to one degree or another. Can be called locally and remotely, allowing arbitrary code to be executed.
The most interesting thing is that the error was fixed back in May 2013, a patch was presented between the releases of glibc 2.17 and 2.18, but the problem was not classified as a security patch, so no attention was paid to it. As a result, many distributions turned out to be vulnerable. It was initially reported that the very first vulnerable version was 2.2 dated November 10, 2000, but there is a possibility that it will appear up to 2.0. Among others, the distributions RHEL/CentOS 5.x–7.x, Debian 7 and Ubuntu 12.04 LTS were affected. Hotfixes are currently available. The hackers themselves proposed a utility that explains the essence of the vulnerability and allows you to check your system. Everything is fine in Ubuntu 12.04.4 LTS:
$ wget https : //goo.gl/RuunlE $gcc gistfile1. c - o CVE - 2015 - 0235 $. / CVE - 2015 - 0235 not vulnerable |
Checking the system on GHOST
Almost immediately, a module was released to allow remote code execution on x86 and x86_64 Linux with a running Exim mail server (with the helo_try_verify_hosts or helo_verify_hosts parameter enabled). Later, other implementations appeared, for example, the Metasploit module for checking a blog on WordPress.
A little later, in 2015, three more vulnerabilities were discovered in GNU glibc that allowed a remote user to perform a DoS attack or overwrite memory cells outside the stack boundary: CVE-2015-1472, CVE-2015-1473, CVE-2015-1781.
OS: Linux (GNU Coreutils)
Level: Low
Vector: Local, Remote
CVE: CVE-2014-9471
Exploit: No
GNU Coreutils is one of the main *nix packages, including almost all the basic utilities (cat, ls, rm, date...). The problem was found in date. A flaw in the parse_datetime function could allow a remote attacker without an account on the system to cause a denial of service and possibly execute arbitrary code via a specially crafted date string using timezone. The vulnerability looks like this:
$ touch ‘-- date = TZ = ”123”345”@1’ Segmentation fault $ date - d ‘TZ = ”Europe / Moscow” “00 : 00 + 1 hour”’ Segmentation fault $ date ‘-- date = TZ = ”123”345”@1’ * * * Error in ` date ': free () : invalid pointer : 0xbfc11414 * * * |
Vulnerability in GNU Coreutils
If there is no vulnerability, we will receive a message about the incorrect date format. Almost all Linux distribution developers have reported the presence of the vulnerability. An update is currently available.
Normal output of patched GNU Coreutils OS: Linux (grep 2.19–2.21)
Level: Low
Vector: Local
CVE: CVE-2015-1345
Exploit: No
Vulnerabilities are rarely found in the grep utility, which is used to search for text using a pattern. But this utility is often called by other programs, including system ones, so the presence of vulnerabilities is much more problematic than it seems at first glance. A bug in the bmexec_trans function in kwset.c could result in reading uninitialized data from an area outside the allocated buffer or causing the application to crash. A hacker can take advantage of this by creating a special set of data supplied to the application input using grep -F. Updates are currently available. There are no exploits that use the vulnerability or a module for Metasploit.
VULNERABILITY IN FREEBSD
OS: FreeBSD
Level: Low
Vector: Local, Remote
CVE: CVE-2014-0998, CVE-2014-8612, CVE-2014-8613
Exploit: https://www.exploit-db.com/exploits/35938/
There are not many vulnerabilities in the CVE database for 2015, to be more precise - only six. Three vulnerabilities were found in FreeBSD 8.4–10.x at the end of January 2015 by researchers from the Core Exploit Writers Team. CVE-2014-0998 is related to the implementation of the VT console driver (Newcons), which provides multiple virtual terminals, enabled by the kern.vty=vt parameter in /boot/loader.conf.
CVE-2014-8612 occurs when using the SCTP protocol and is caused by an error in the SCTP stream ID verification code that implements SCTP sockets (local port 4444). The essence is an out-of-memory error in the sctp_setopt() function (sys/netinet/sctp_userreq.c). This gives a local unprivileged user the ability to write or read 16 bits of kernel memory data and escalate their privileges on the system, reveal sensitive data, or crash the system.
CVE-2014-8613 allows a NULL pointer dereference to be triggered when processing an externally received SCTP packet when the SCTP_SS_VALUE SCTP socket option is set. Unlike previous versions, CVE-2014-8613 can be used to remotely cause a kernel crash by sending specially crafted packets. In FreeBSD 10.1, you can protect yourself by setting the net.inet.sctp.reconfig_enable variable to 0, thereby disabling processing of RE_CONFIG blocks. Or simply prohibit applications (browsers, email clients, etc.) from using SCTP connections. Although at the time of publication the developers had already released an update.
FreeBSD Vulnerability Statistics VULNERABILITY IN OPENSSL
OS: OpenSSL
Level: Remote
Vector: Local
CVE: CVE-2015-1793
Exploit: No
In 2014, a critical Heartbleed vulnerability was discovered in OpenSSL, a widely used cryptographic package for working with SSL/TLS. The incident at one time caused massive criticism of the quality of the code, and, on the one hand, this led to the emergence of alternatives like LibreSSL, on the other hand, the developers themselves finally got down to business.
Top vendors by vulnerabilities The critical vulnerability was discovered by Adam Langley of Google and David Benjamin of BoringSSL. Changes made in OpenSSL versions 1.0.1n and 1.0.2b caused OpenSSL to attempt to find an alternative certificate verification chain if the first attempt to build a trust chain was unsuccessful. This allows you to bypass the certificate verification procedure and organize a confirmed connection using a fake certificate, in other words - to calmly lure a user to fake sites or an email server, or to carry out any MITM attack where a certificate is used.
After the vulnerability was discovered, the developers released releases 1.0.1p and 1.0.2d on July 9, which fixed this problem. Versions 0.9.8 or 1.0.0 do not have this vulnerability.
Linux.Encoder
The end of autumn was marked by the appearance of a number of encryption viruses, first Linux.Encoder.0, followed by modifications Linux.Encoder.1 and Linux.Encoder.2, which infected more than 2,500 sites. According to antivirus companies, Linux and FreeBSD servers with websites running using various CMSs - WordPress, Magento CMS, Joomla and others - are being attacked. Hackers are exploiting an unidentified vulnerability. Next, a shell script was placed (file error.php), with the help of which any further actions were performed (via the browser). In particular, the Linux encoder Trojan was launched.
Encoder, which determined the OS architecture and launched the ransomware. The encoder was launched with web server rights (Ubuntu - www-data), which is quite enough to encrypt files in the directory in which CMS files and components are stored. Encrypted files receive a new extension.encrypted.
The ransomware also tries to bypass other OS directories; if the rights are configured incorrectly, then it could easily go beyond the boundaries of the website. Next, the file README_FOR_DECRYPT.txt was saved in the directory, containing instructions for decrypting the files and the hacker’s requirements. At the moment, antivirus companies have introduced utilities that allow you to decrypt directories. For example, a set from Bitdefender. But you need to remember that all utilities designed to decrypt files do not remove the shellcode and everything can happen again.
Considering that many users involved in development or experimenting with website administration often install a web server on their home computer, you should worry about security: block access from outside, update software, conduct experiments on a VM. And the idea itself could be used in the future to attack home systems.
CONCLUSION
Complex software without errors physically does not exist, so you have to come to terms with the fact that vulnerabilities will be discovered constantly. But not all of them can be truly problematic. And you can protect yourself by taking simple steps: remove unused software, monitor new vulnerabilities and be sure to install security updates, configure a firewall, install an antivirus. And don’t forget about special technologies like SELinux, which are quite capable of compromising a daemon or user application.
Installing and configuring administration tools, network configuration
After we have installed the basic operating system ubuntu14.04 from a minimal distribution, the first thing we need to worry about is how to manage it comfortably. Basically, ssh/telnet is used to configure and manage *nix-based servers, but recently quite suitable tools based on web interfaces have also appeared 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 suited for some things, so it’s better to have both of them. I should note that on combat production servers such solutions are not installed based on security. Still, the more control systems there are, the greater the likelihood of finding a vulnerability in them. Therefore, if your security requirements are at the “paranoid” level, then simply accept the fact that you will have to work with the server only via ssh (via the console).
Setting up a network 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 detected 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 an unchanged network interface, then all other interfaces may 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 type of interface name depends on the type of network card, for example, if the network card operates via the WiFi protocol, then most likely its name will be wlan0.
To configure the network, let's 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 range of IPv4 (inet) addresses with a static ip (static);
address 192.168.0.184— indicates that the IP 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 must be enabled automatically when the system boots with the above parameters.
eth0— the name of the interface to be connected. The list of interfaces can be viewed by typing ifconfig
dns-nameservers— DNS servers are written separated by a space.
As you can see in my case, I decided to set a static ip 192.168.0.184
reboot 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; to do this, we’ll 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 make the setup surprisingly easier, as you will soon see for yourself:
ALL COMMANDS BELOW THIS LINE ARE ENTERED AS 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 wget https : //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 log into your browser at:
https://192.168.0.184:10000
By default, webmin looks minimalistic, the default interface is displayed in English, but everything is customizable!
We do it like this:
It turns out like this:
