Anyone who has administered even a moderately high traffic server will have noticed that certain unwelcome traffic such as port scans and probes tend to come from IP addresses belonging to a certain group of countries. If your application or service does not cater to users in these countries, it might be a safe bet to block these countries off entirely.
This is especially true for email servers. The average email server, based on anecdotal evidence of servers for around 20 domains, rejects about 30% of incoming email every day as spam. Some servers on some days reject up to as much as 97% of incoming email as spam. Most of these originate in a certain subset of countries. That is a lot of wasted CPU cycles being expended on scanning these undesired emails for spam and viruses. Although tools such as amavisd and spamassasin do a good job of keeping the vast majority of spam out of users’ inboxes, when the rare well crafted and targeted phishing email does get through, it wrecks havoc in the enterprise.
If you read our previous article Easy Ubuntu Server Firewall, then you may have noted that on Ubuntu 16.04 the described method no longer works. This is due to systemd. In the article below we will walk through creating a persistent IPTables based firewall on Ubuntu 16.04 LTS. First we need to install some required software packages. As seen in the command below, install iptables-persistent. Next we will make netfilter-persistent run at boot. This is the most important step as it will ensure your rules are reloaded at boot time.
# Install IPTables Persistent Package
apt-get install-y iptables-persistent
# Add netfilter-persistent Startup
invoke-rc.d netfilter-persistent save
# Stop netfilter-persistent Service
service netfilter-persistent stop
Once the packages above are installed and the service is stopped, you will have a new directory at /etc/iptables/. This directory holds the IPTables filter rules that will be reloaded at boot time. These files are named rules.v4 and rules.v6 respectively. IPV4 rules are loaded into rules.v4 and IPV6 rules are loaded into rules.v6. For the purpose of this article we will focus on IPV4 rules. Next we will want to copy the rules below into our rules.v4 file. Of course the rules will need to be modified to fit your environment.
# Generated by iptables-save v1.3.3 on Wed Apr 9 10:51:08 2008
# Flush out any rules that are already in there
*filter
:INPUT ACCEPT [146:11332]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [104:9831]
# Allow internal loopback connections
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
# Allow pinging
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Allow any outbound data, and any inbound data related to a connection that is already in use
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# =========BEGIN SERVER SPECIFIC PORT OPEN RULES=========
# Allow SCP/SSH Access from Green & Blue Subnet
-A INPUT -s 172.16.12.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 10.10.12.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT
# Allow HTTP Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
# Allow HTTPS Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
# Allow MySQL Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 3306 -j ACCEPT
# Allow FTP Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 58000:58010 -j ACCEPT
# =========END SERVER SPECIFIC PORT OPEN RULES=========
# Drop everything that hasn't been picked up by one of the rules above
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j DROP
COMMIT
# Completed on Wed Apr 9 10:51:08 2008
Lastly, in order for our new rules to take affect, we simply need to start the netfilter-persistent service as seen below. That’s it, you now have a fully functional IPTables based firewall.
# Start netfilter-persistent Service
service netfilter-persistent start
# Check if IPTables were applied
iptables -L
By default any modern Linux distributions will have IP Forwarding disabled. This is normally a good idea, as most peoples will not need IP Forwarding, but if we are setting up a Linux router/gateway or maybe a VPN server (pptp or ipsec) or just a plain dial-in server then we will need to enable forwarding. This can be done in several ways that I will present bellow.
Check if IP Forwarding is enabled
We have to query the sysctl kernel value net.ipv4.ip_forward to see if forwarding is enabled or not: Using sysctl:
or just checking out the value in the /proc system:
cat /proc/sys/net/ipv4/ip_forward
0
As we can see in both the above examples this was disabled (as show by the value 0).
Enable IP Forwarding on the fly
As with any sysctl kernel parameters we can change the value of net.ipv4.ip_forward on the fly (without rebooting the system):
sysctl -w net.ipv4.ip_forward=1
or
echo 1 > /proc/sys/net/ipv4/ip_forward
the setting is changed instantly; the result will not be preserved after rebooting the system.
Permanent setting using /etc/sysctl.conf
If we want to make this configuration permanent the best way to do it is using the file /etc/sysctl.conf where we can add a line containing net.ipv4.ip_forward = 1
/etc/sysctl.conf:
net.ipv4.ip_forward = 1
if you already have an entry net.ipv4.ip_forward with the value 0 you can change that 1.
To enable the changes made in sysctl.conf you will need to run the command:
sysctl -p /etc/sysctl.conf
On RedHat based systems this is also enabled when restarting the network service:
service network restart
and on Debian/Ubuntu systems this can be also done restarting the procps service:
/etc/init.d/procps.sh restart
Using distribution specific init scripts
Although the methods presented above should work just fine and you would not need any other method of doing this, I just wanted to note that there are also other methods to enable IP Forwarding specific to some Linux distributions. For example Debian based distributions might use the setting:
/etc/network/options:
ip_forward=no
set it to yes and restart the network service. Also RedHat distributions might set this using:
/etc/sysconfig/network:
FORWARD_IPV4=true
and again restart the network service.
Regardless the method you have used once you have completed this you can check it out using the same method shown above:
As a key enabler for software-defined networking (SDN), OpenFlow was initially introduced in the academia as a way to enable innovation on production networks which had traditionally been built with closed and proprietary networking hardware. OpenFlow offloads the high-level routing/forwarding decisions (control plane) from networking devices such as switches, and moves the control plane on to a separate controller. The networking devices then simply forward traffic, as programmed by the external OpenFlow controller. It is the OpenFlow protocol that is used by the OpenFlow controller to program the networking devices.
Suppose you have an OpenFlow testbed running, which consists of an OpenFlow controller and a set of OpenFlow-capable switches. For troubleshooting purposes, you want to capture and examine OpenFlow messages exchanged between the controller and the switches. For this you could monitor exchanged OpenFlow messages either at the controller or the switch side, but what if it is not convenient to do so? Another way is to « sniff » network packets on the OpenFlow control channel and interpret the packets.
In this tutorial, I am going to show how to sniff live OpenFlow control packets and decode OpenFlow messages contained in the packets.
Note that for such packet sniffing to work, SSL must be disabled in any existing OpenFlow control channels between the controller and switches. Let’s assume we are not talking about any production environment here, so the SSL is off for now.
Method One: Sniff OpenFlow Messages via Wireshark GUI
If you want to monitor OpenFlow messages using packet sniffing, the most user-friendly way is via Wireshark, a GUI-based packet sniffer. A nice thing about Wireshark is its extensive list of built-in and custom dissectors. Each dissector decodes some part of packet data based on a specific network protocol. For pretty much any existing network protocol, there is a corresponding Wireshark dissector (either built-in or contributed by a third-party). The OpenFlow protocol is not an exception.
While there is an official OpenFlow dissector, I am going to use a third-party OpenFlow dissector developed by Big Switch Networks, since the former seems to have patchy/incomplete support for different OpenFlow versions.
Here is how to install the OpenFlow dissector for Wireshark.
$ mkdir -p ~/.wireshark/plugins
$ cd ~/.wireshark/plugins
$ wget http://www.projectfloodlight.org/openflow.lua
Now go ahead and start Wireshark.
To verify that the OpenFlow dissector is successfully installed, go to « Help » -> »About Wireshark ».
Under the « Plugin » tab, if you see openflow.lua listed, it means the Openflow dissector is successfully loaded on Wireshark.
Comme un débutant tâchant d’effectuer une réparation automobile, je peux me battre pendant des heures en essayant d’utiliser convenablement mes rudimentaires outils (marteau, clefs, etc.) pour la tâche à laquelle je me suis attablé. Une fois que j’ai lamentablement échoué et que j’ai fait remorquer ma guimbarde par un vrai mécanicien, à chaque fois il farfouille dans sa grosse caisse à outils pour y trouver le parfait bidule qui, d’un coup de cuillère à pot, répare le truc. L’art du scan de port, c’est la même chose. Les experts connaissent des douzaines de techniques de scan et choisissent la bonne (ou une combinaison) pour une tâche donnée. D’un autre côté, les utilisateurs inexpérimentés et les script kiddies essaient de tout résoudre avec le scan SYN par défaut. Comme Nmap est gratuit, la seule barrière à franchir pour atteindre la maîtrise du scan est la connaissance. C’est bien mieux que l’automobile, où il faut une grande expérience pour déterminer que vous avez besoin d’une plieuse à tablier hydraulique, mais où quand bien même il faut encore payer des centaines d’euros pour en disposer.
Types de scans
La plupart des types de scans ne sont disponibles que pour les utilisateurs privilégiés. Ceci est dû au fait qu’ils émettent et reçoivent des paquets bruts (raw), qui nécessitent les droits root sur les systèmes UNIX. L’utilisation d’un compte administrateur est conseillé sous Windows, bien que Nmap puisse fonctionner avec des utilisateurs non-privilégiés si WinPcap est déjà chargé avec l’OS. Ce besoin des droits root était une sérieuse restriction quand Nmap a été diffusé en 1997, car beaucoup d’utilisateurs avaient seulement accès à des comptes Internet partagés. Maintenant, le monde est différent. Les ordinateurs sont moins chers, bien plus de gens disposent d’un accès 24/24 direct à Internet et les systèmes UNIX de bureau (comme Linux et Mac OS X) sont répandus. Une version Windows de Nmap est désormais disponible, permettant ainsi de le lancer sur encore plus de machines. Pour toutes ces raisons, les utilisateurs ont bien moins besoin de lancer Nmap depuis des comptes Internet limités. Ceci est heureux, car les options privilégiés rendent Nmap bien plus puissant et flexible.
Résultats
Si Nmap essaie de produire des résultats précis, il faut garder à l’esprit que toute sa perspicacité est basée sur les paquets renvoyés par les machines cibles (ou les pare-feux qui les protègent). De tels hôtes ne sont pas toujours dignes de confiance et peuvent répondre dans le but de d’induire Nmap en erreur. Les hôtes qui ne respectent pas les RFCs et ne répondent pas comme ils devraient sont encore plus courants. Les scans FIN, Null et Xmas sont les plus sensibles à ce problème. Ces points sont spécifiques à certains types de scan et sont donc abordés dans leur section propre de la documentation.
Cette section documente la douzaine de techniques de scan de ports gérées par Nmap. Les méthodes ne peuvent pas être utilisés simultanément, excepté le scan UDP (-sU) qui peut être combiné avec chacun des types de scan TCP. A titre d’aide mémoire, les options de type de scan sont de la forme -s<C>, où <C>est un caractère prépondérant dans le nom du scan, souvent le premier. La seule exception est le désuet scan par rebond FTP (-b). Par défaut, Nmap effectue un scan SYN, bien qu’il y substitue un scan connect() si l’utilisateur ne dispose pas des droits suffisants pour envoyer des paquets bruts (qui requièrent les droits root sous UNIX) ou si des cibles IPv6 sont spécifiées. Des scans listés dans cette section, les utilisateurs non-privilégiés peuvent seulement exécuter les scans connect() et le scan par rebond FTP.
Commandes et options
-sS
(Scan TCP SYN)
Le scan SYN est celui par défaut et le plus populaire pour de bonnes raisons. Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un réseau rapide lorsqu’il n’est pas entravé par des pare-feux. Le scan SYN est relativement discret et furtif, vu qu’il ne termine jamais les connexions TCP. Il marche également contre toute pile respectant TCP, au lieu de dépendre des particularités environnementales spécifiques comme les scans Fin/Null/Xmas, Maimon ou Idle le sont. Il permet de plus une différentiation fiable entre les états ouvert, fermé et filtré.
Cette technique est souvent appelée le scan demi-ouvert (half-open scanning), car il n’établi pas pleinement la connexion TCP. Il envoie un paquet SYN et attend sa réponse, comme s’il voulait vraiment ouvrir une connexion. Une réponse SYN/ACK indique que le port est en écoute (ouvert), tandis qu’une RST (reset) indique le contraire. Si aucune réponse n’est reçue après plusieurs essais, le port est considéré comme étant filtré. Le port l’est également si un message d’erreur « unreachable ICMP (type 3, code 1,2, 3, 9, 10 ou 13) » est reçu.
-sT
(Scan TCP connect())
Le scan TCP connect() est le type de scan par défaut quand le SYN n’est pas utilisable. Tel est le cas lorsque l’utilisateur n’a pas les privilèges pour les paquets bruts (raw packets) ou lors d’un scan de réseaux IPv6. Plutôt que d’écrire des paquets bruts comme le font la plupart des autres types de scan, Nmap demande au système d’exploitation qui l’exécute d’établir une connexion au port de la machine cible grâce à l’appel système connect(). C’est le même appel système haut-niveau qui est appelé par les navigateurs Web, les clients P2P et la plupart des applications réseaux qui veulent établir une connexion. Cet appel fait partie de l’interface d’application connue sous le nom de « Berkeley Sockets API ». Au lieu de lire les réponses brutes sur le support physique, Nmap utilise cette application API pour obtenir l’état de chaque tentative de connexion.
Si le scan SYN est disponible, il vaut mieux l’utiliser. Nmap a bien moins de contrôles sur l’appel système haut niveau connect() que sur les paquets bruts, ce qui le rend moins efficace. L’appel système complète les connexions ouvertes sur les ports cibles au lieu de les annuler lorsque la connexion est à demie ouverte, comme le fait le scan SYN. Non seulement c’est plus long et demande plus de paquets pour obtenir la même information, mais de plus la probabilité que les cibles activent la connexion est plus grande. Un IDS décent le fera, mais la plupart des machines ne disposent pas de ce système d’alarme. De nombreux services sur les systèmes UNIX standards noteront cette connexion dans le journal, accompagné d’un message d’erreur sibyllin si Nmap ouvre puis referme la connexion sans n’envoyer aucune donnée. Les services réseaux les plus piteux risquent même de tomber en panne, mais c’est assez rare. Un administrateur qui verrait un tas de tentatives de connexions dans ses journaux en provenance d’une seule machine devrait se rendre compte qu’il a été scanné.
-sU
(Scan UDP)
Même si les services les plus connus d’Internet son basés sur le protocole TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53, 161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les ignorent. C’est une erreur, car les services UDP exploitables sont courants et les attaquants eux ne les ignoreront pas. Par chance, Nmap peut aider à répertorier les ports UDP.
Le scan UDP est activé avec l’option-sU. Il peut être combiné avec un scan TCP, comme le scan SYN ( -sS), pour vérifier les deux protocoles lors de la même exécution de Nmap.
Le scan UDP envoie un en-tête UDP (sans données) à chaque port visé. Si un message ICMP « port unreachable (type 3, code 3) » est renvoyé, le port est alors fermé. Les autres messages d’erreur « unreachable ICMP (type 3, codes 1, 2, 9, 10, or 13) » rendront le port filtré. À l’occasion, il arrive qu’un service répond par un paquet UDP, prouvant que le port est dans l’état ouvert. Si aucune réponse n’est renvoyée après plusieurs essais, le port est considéré comme étant ouvert|filtré. Cela signifie que le port peut être soit ouvert, soit qu’un dispositif de filtrage bloque les communications. Le scan de versions ( -sV) peut être utilisé pour différencier les ports ouverts de ceux filtrés.
Une des grandes difficultés avec le scan UDP est de l’exécuter rapidement. Les ports ouverts et filtrés ne renvoient que rarement des réponses, laissant Nmap expirer son délai de retransmission au cas où les paquets se soient perdus. Les ports fermés posent encore un plus grand problème: ils renvoient normalement une erreur ICMP « port unreachable ». Mais à la différence des paquets RST renvoyés par les ports TCP fermés en réponse à un scan SYN ou à un connect(), de nombreux hôtes limitent par défaut la cadence d’émission de ces messages. Linux et Solaris étant particulièrement stricts à ce sujet. Par exemple, le kernel 2.4.20 limite cette cadence des destinations inaccessibles (« destination unreachable ») à un par seconde (cf.net/ipv4/icmp.c).
Nmap détecte cette limitation de fréquence et s’y ralenti conformément afin d’éviter de saturer le réseau avec des paquets inutiles que la machine cible rejettera. Malheureusement, une limitation à la Linux d’un paquet par seconde fera qu’un scan des 65 536 ports prendra plus de 18 heures. Les idées pour accélérer les scans UDP incluent le scan des cibles en parallèle, ne scanner que les ports les plus courants en premier, scanner derrière le pare-feu et utiliser l’option --host-timeoutpour éviter les hôtes les plus lents.
