Archives pour la catégorie ‘Réseau’

Linux Security Basics

16/01/2019 Aucun commentaire

One of the most daunting prospects of administering your own server on a public network is dealing with your server’s security. While security threats in a networked world are real and it is always important to be mindful of security issues, protecting against possible attacks is often a matter of exercising basic common sense and adhering to some general best practices.

This guide takes a broad overview of common security concerns and provides a number of possible solutions to common security problems. You are encouraged to consider deploying some of these measures to “harden” your server against possible attacks.

It’s important to remember that all of the solutions we present in this document are targeted at specific kinds of attacks, which themselves may be relevant only in specific configurations. Security solutions need to be tailored to the kind of services that you’re providing and the software you’re running, and the decision whether or not to deploy a specific security solution is often a matter of personal discretion and cost-benefit analysis.

Perhaps most importantly, it should be understood that security is a process, not a product (credit to Bruce Schneier.) There is no “magic bullet” set of guidelines that can be followed to ensure the security of any system. Threats are constantly evolving, so vigilance is required on the part of network administrators to prevent unauthorized access to systems.

Keep Systems and Software Up To Date

One of the most significant sources of security vulnerabilities are systems running out of date software with known security holes. Make a point of using your system’s package management tools to keep your software up to date; this will greatly assist in avoiding easily preventable security intrusions.

Running system updates with the package management tool, using apt-get update && apt-get upgrade (for Debian and Ubuntu Systems) or yum update (for CentOS and Fedora systems) is simple and straightforward. This practice ensures that if your distribution maintains active security updates, your system will be guarded against many security holes in commonly used software packages.

System update tools will, however, not keep software up to date that you’ve installed outside of package management. This includes software that you’ve compiled and installed “by hand” (e.g. with ./configure && make && make install) and web-based applications that you’ve installed from a software developer’s site, as is often the case with applications like WordPress and Drupal. Also excluded from protection will be libraries and packages you’ve installed with supplementary package management tools like Ruby’s Gems, Perl’s CPAN tool, Python easy_install, and Haskell Cabal. You will have to manage the process of keeping these files up to date yourself.

The method you use to make sure that your entire system is kept up to date is a matter of personal preference, and depends on the nature of your workflow. We would recommend trying very hard to use the versions of software provided by your operating system or other programming platform-specific package management tools. If you must install from “source,” we would recommend that you save the tarballs and source files for all such software in /src/ or ~/src/ so that you can keep track of what software you’ve installed in this manner. Often, you can remove a manually compiled application by issuing make uninstall in the source repository (directory). Additionally, it may be helpful to maintain a list of manually installed software, with version numbers and download locations. You may also want to investigate packaging your own software so that you can install it with apt, yum or pacman.

Because of the complexity of maintaining software outside of the system’s package management tools we strongly recommend avoiding manually installing software unless absolutely necessary. Your choice in a Linux distribution should be heavily biased by the availability of software in that distro’s repositories for the systems you need to run on your server.

Lire la suite…

Tarpit & iptables : les armes fatales anti-DDOS !

16/01/2019 Aucun commentaire

Tarpit + iptables : le Graal?

Un ennemi à part !

Le problème est, ma foi, assez simple :

En sécurité informatique, on sait de nos jours parer à la grande majorité des menaces. Si on se concentre sur la partie serveur et sur Linux, Grsex / Pax, un coup de hardening, un kernel statique et optimisé, du chroot et ma foi on est déjà pas mal…

Les démons comme apaches et Mysql, ainsi que les interprêteurs comme PHP ou Perl, sont protégés contre leurs ennemis intimes : les overflows. Les droits séparés, les arborescences protégées, les connexions filtrées, que peut on faire de plus ? Par exemple séparer le back office sur un autre vhost pour ajouter un htaccess afin de le protéger, auditer le site contre les vulnérabilités classiques, XSS, SQL injection etc…

Well… Que reste t’il, un ou deux mécanismes à protéger mais… Le D.D.O.S, c’est fatal.

Know your ennemy !

La D.D.O.S – Distributed Denial Of Services – c’est la grande frayeur de n’importe quel E-commerçant, de n’importe quel site gagnant de l’argent en ligne et surtout, de votre infogérant…

Un déni de service distribué consiste à envoyer des milliers, des dizaines de milliers, des centaines de milliers de requêtes simultanément. Si l’on limite la réflexion aux sites Web, il suffit, en général, de faire 10 à 50 000 connexions simultanées pour mettre à genou un serveur et/ou la connexion Internet des serveurs.

Ces innombrables connexions arrivent, en général, depuis des machines compromises, de partout dans le monde. Ces machines sont compromises par des vers, par exemple Confliker ou d’autres plus discrets, qui sommeillent dans des PC depuis des mois, à l’écoute des ordres. Ces machines, appelées Zombies, font partie de réseaux nommés Botnets.

Ensuite, c’est malheureusement d’une simplicité diabolique. Un script kiddy (ou même un vrai hacker) paye quelques poignées de dollars et loue tout simplement la puissance d’un botnet. Combien de machines, combien de temps, quelles commandes doit être lancée. Simple, terriblement efficace, imparable…

Les machines reçoivent les ordres et en quelques minutes, des centaines milliers de connexions pleuvent sur le site ciblé.

Comment éviter une D.D.O.S ?

Une D.D.O.S se base, pas essence, sur des machines compromises, la plupart du temps des bêtes PC de particuliers.

Evidemment, nous ne pouvons avoir une action sur ces machines directement. Les désinfecter à distance n’est pas possible, pas plus que cela ne serait autorisé du reste.

Ensuite, bloquer ces machines une par une dans un firewall est aussi inutile qu’impossible. Impossible à cause du volume, inutile car bloquer ces connexions n’empêchera pas le pirate d’en envoyer d’autres, d’en envoyer plus et de toute façon, si ce ne sont pas les serveurs qui craquent, ca sera la connexion Internet des serveurs.

Lire la suite…

iptables: Linux firewall rules for a basic Web Server

15/01/2019 Aucun commentaire

What is iptables?

linux firewall web serveriptables is a package and kernel module for Linux that uses the netfilter hooks within the Linux kernel to provide filtering, network address translation, and packet mangling. iptables is a powerful tool for turning a regular Linux system into a simple or advanced firewall.

Firewall & iptables basics

Rules are first come first serve

In iptables much like other (but not all) firewall filtering packages the rules are presented in a list. When a packet is being processed, iptables will read through its rule-set list and the first rule that matches this packet completely gets applied.

For example if our rule-set looks like below, all HTTP connections will be denied:

  • Allow all SSH Connections
  • Deny all connections
  • Allow all HTTP Connections

If the packet was for SSH it would be allowed because it matches rule #1, HTTP traffic on the other hand would be denied because it matches both rule #2 and rule #3. Because rule #2 says Deny all connections the HTTP traffic would be denied.

This is an example of why order matters with iptables, keep this in mind as we will see this later in this article.

Lire la suite…

Use ipset and iptables to block traffic

14/01/2019 Aucun commentaire

Source: – 445352

Here’s how you can block traffic coming from an IP, list of IPs, full networks or even entire countries. This is done under a Debian 7 x86 server so adapt the commands to your distro of choice…

1 – Install ipset, for commands reference check

apt-get install ipset

2 – Setup your sets, sets are basically lists in which you’ll add all the IP or IP networks to it, in this case I’m creating a list to support IP Networks (x.x.x.x/yy form). If you need to create a set to support individual IPs use the hash:ip option.

#Create 3 lists, 2 to support networks and 1 to support single IP addresses
#hash:net = Networks
#hash:ip = single IPs
# Command is ipset -N setname [set options], but I'm using default
# options here
ipset -N china hash:net
ipset -N some-country  hash:net
ipset -N badguys hash:ip
# Now we list the just created sets with:
ipset -L

Lire la suite…

Basic iptables Rulesets for IPv4 and IPv6

13/01/2019 Aucun commentaire

iptables ipv4Appropriate firewall rules heavily depend on the services being run. Below are iptables rulesets to secure your Linode if you’re running a web server. These are given as an example! A real production web server may want or require more or less configuration and these rules would not be appropriate for a file or database server, Minecraft or VPN server, etc.

iptables rules can always be modified or reset later, but these basic rulesets serve only as a beginning demonstration.



# Allow all loopback (lo0) traffic and reject traffic
# to localhost that does not originate from lo0.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s -j REJECT

# Allow ping and traceroute.
-A INPUT -p icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp --icmp-type 11 -j ACCEPT

# Allow SSH connections.
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere
# (the normal ports for web servers).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Accept inbound traffic from established connections.

# Log what was incoming but denied (optional but useful).
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7

# Reject all other inbound.

# Log any traffic which was sent to you
# for forwarding (optional but useful).
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7

# Reject all traffic forwarding.


Optional: If you plan to use Linode Longview, add this additional rule below the section for allowing HTTP and HTTPS connections:
# Allow incoming Longview connections 
-A INPUT -s -m state --state NEW -j ACCEPT


Lire la suite…