Security

Do you manage a server and think you can’t be attacked? Here are the things you need to know

Do you manage a server and think you can't be attacked?  Here are the things you need to know

We are well into the second decade of the 2000s and yet the widespread and fallacious belief according to which attackers always focus on specific websites is still prevalent. In reality, attackers not only target a wide range of websites but also focus on servers connected to the Internet that provide all kinds of services. The provision of Web pages through the use of HTTP/HTTPS protocols is in fact only the tip of the iceberg: the services that a server machine can expose on thePublic IP there can be many (even those not having to do with the Web).

Most attacks start from bot, or by automated systems in turn connected to the Internet, which know nothing about the systems being scanned, the activities they carry out, or the websites that the servers possibly host. In short, bots do not take the targets of their activities into even the slightest consideration: if a machine, of any type, is reachable via IP public is always a potential target.

Bots attack any server on a daily basis – it’s a fact

According to the experts of Imperva, half of all website visitors are bots. Of these, around 29% are there to attack the site. Indeed, little-used servers, those that host domains with few daily visits, are often favorite targets: the lack of security measures or the adoption of insufficient protective measures can result in the inclusion of the attacked machine in a botnet.

Honeynet, a non-profit organization that deals with information security, some time ago created a sort of “trap” to track security attacks on a web server connected to the network. The machine was using an instance created on Amazon AWS and it didn’t even tie a domain name to itself: analyzing traffic with the well-known and appreciated packet sniffer Wireshark for 24 hours and then using p0f (Passive OS fingerprinting), software for identifying Fingerprints in TCP/IP traffic, it was possible to ascertain that the server – practically unknown – suffered a total of something like 250,000 attack attempts.

In mid-August 2023, two French researchers published the results of a three-year work focused on the use and implementation of the RDP protocol which, as is known, allows you to establish sessions desktop remoto. Also in this case creating a honeypotwere able to record and study in depth the actions of bots and real attackers, once the vulnerable target was discovered.

In other words, regardless of the website or service you are administering (and which is publicly accessible on the Internet) someone, every day, will knock on your door. Usually these are bots: whether using particular scripts or attack mode “basic” leads to the desired result (by the attackers), the IP address of the vulnerable system is noted down and then passed to malicious users who will try to violate it for various purposes.

Why attackers attack a server

Attackers can attack a web server for a variety of reasons, which depend on their goals and motivations. They range from the collection of personal information and confidential data to identity theft, from extortion attempts to the desire to cause reputational damage, from the use of the attacked server for the distribution of malware to the installation of ransomware (with a demand for a cash ransom).

Some attacks are intended to use the server resourcessuch as computing power or bandwidth, to perform illegal actions such as initiating DDoS attacks (Distributed Denial of Service), sending spam campaigns, the mining of cryptocurrencies without the knowledge of the legitimate owners of the machines.

The actions of attackers, however, are not only directed towards web servers. Even in the case of other servers, which are not running web servers, attackers can try to raid confidential information, financial, personal details and business secrets. Not to mention the abuse of computing resources, extortion phenomena, the distribution of malicious components, the addition of systems to botnet and so on.

Among many, there is also a publicly accessible search engine, called Shodan, which contains a constantly updated list of IP addresses which specific services access: some of them clearly suffer from specific vulnerability. The search mechanism that Shodan integrates, even allows, using specific ones filtersto select the machines that – globally or in a specific country – expose one or more ports reachable from any remote device.

Use firewall to avoid exposing unnecessary services on public IP

The golden rule To avoid running risks, it consists in displaying only and exclusively the strictly necessary services on the public IP. Nothing more. If, for example, a machine is to act as a Web server, typically only the porte 80 (HTTP) e 443 (HTTPS): everything else must be absolutely blocked at the level of firewall.

Of course, that same machine will have to be administered remotely, but it makes no sense to show the ports on which the server module is listening and awaiting requests for remote connection and administration. For example RDP (Remote Desktop Protocol) uses ports TCP/UDP 3389 and is a favorite target for remote attackers. Both because the attacks brute-force attempts to guess login credentials are on the rise, both because system administrators often don’t install them security updates that directly affect Remote Desktop servers.

Protection of access via SSH, RDBMS and other server applications

The same thing goes for via access SSH (Secure Shell), whose default port is TCP 22, extremely common on GNU/Linux platforms. It is essential to avoid publicly exposing SSH remote administration, even if properly protected with username and password on the public interface.

Similar considerations apply, for example, to the main servers RDBMS or in any case of the server modules used for data management. The ports on which the servers listen MySQL/MariaDB, PostgreSQL, MongoDB and so on cannot and must not overlook the public IP address. And this even if the use of the account had been deactivated root outside of local IP addresses and if the permissions had been carefully assigned (grant) to individual accounts.

Let’s not even talk about the resources shared via SMB/NFS: these should never, ever appear on the public IP.

The list of services that should be kept unreachable on the public IP is almost endless.

Firewall configuration

The firewall should be configured to allow unrestricted access only to specific users static IP addresses used by system administrators who connect remotely. Alternatively, you should set a server VPN for access to the remote infrastructure to be administered, taking care to regularly update the VPN server itself in order to promptly correct any security vulnerabilities.

In case of difficulty, you should always have one available console Web (generally provided, for example, by cloud providers) that allows you to act on the machines, even if access via VPN is not working.

You should opt for one firewall hardware; it is however possible to integrate software products such as pfSense, OPNsense, Endian, IPFire or similar into a cloud infrastructure.

Security vulnerabilities in server components and applications

The “bete noire” of any system administrator is the presence of vulnerability in applications that integrate server functionality, especially those that are exposed on the public IP.

Let’s mention the most banal (but also very common) case of the classic Web server: if a serious security gap were discovered, exploitable remotely, in components such as Apache HTTP Server (httpd), Nginx, IIS (Internet Information Services) and others, you should study the problem immediately and take action as soon as possible. Especially if a “malformed” request, appropriately crafted by the attacker, were to allow the overcoming of restrictions, the acquisition of confidential information or, even, remote code execution.

You can usually resolve the issue by installing the security patches official or by applying, at least temporarily, workaround corrective.

Leave a Reply

Your email address will not be published. Required fields are marked *