Archive

Archives pour la catégorie ‘Réseau’

Iptables Allow MYSQL server incoming request on port 3306

24/03/2017 Comments off
Print Friendly

MySQL database is a popular for web applications and acts as the database component of the LAMP, MAMP, and WAMP platforms. Its popularity as a web application is closely tied to the popularity of PHP, which is often combined with MySQL. MySQL is open source database server and by default it listen on TCP port 3306. In this tutorial you will learn how to open TCP port # 3306 using iptables command line tool on Linux operating system.

Task: Open port 3306

In most cases following simple rule opens TCP port 3306:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT

The following iptable rules allows incoming client request (open port 3306) for server IP address 202.54.1.20. Add rules to your iptables shell script:

iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

However in real life you do not wish give access to everyone. For example in a web hosting company, you need to gives access to MySQL database server from web server only. Following example allows MySQL database server access (202.54.1.20) from Apache web server (202.54.1.50) only:

iptables -A INPUT -p tcp -s 202.54.1.50 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 202.54.1.50 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Please note if you follow above setup, then you need tell all your hosting customer to use 202.54.1.50 as MySQL host in PHP/Perl code. A better approach is to create following entry in /etc/hosts file or use fully qualified domain name (create dns entry) mysql.hostingservicecompany.com which points to 202.54.1.50 ip:
202.54.1.50 mysql

In shot MySQL database connection code from PHP hosted on our separate webserver would look like as follows:

// ** MySQL settings ** //
define('DB_NAME', 'YOUR-DATABASE-NAME');     // The name of the database
define('DB_USER', 'YOUR-USER-NAME');     // Your MySQL username
define('DB_PASSWORD', 'YOUR-PASSWORD''); // ...and password
define('DB_HOST', 'mysql');       // mysql i.e. 202.54.1.50
// ** rest of PHP code ** //

Lire la suite…

GeoIP pour iptables

18/03/2017 Comments off
Print Friendly

Source: how-to.ovh

Marre des pays exotiques qui essaient de s’introduire sur le serveur et pourrissent vos logs et font bosser fail2ban ?

Une solution pour bloquer les pays avec lesquels vous n’avez pas de relations. Pour Debian mais sûrement adaptable à d’autres distributions.

# Install GeoIP pour iptables

apt-get install dkms xtables-addons-dkms xtables-addons-common xtables-addons-dkms geoip-database libgeoip1 libtext-csv-xs-perl unzip

# On vérifie que c’est ok

dkms status xtables-addons

# on crée le repertoire

mkdir /usr/share/xt_geoip

# on se déplace dedans

cd /usr/share/xt_geoip/

# on télécharge le fichier

wget http://man.sethuper.com/wp-content/uploads/2013/06/geoip-dl-build.tar.gz

# on le décompresse

tar xvf geoip-dl-build.tar.gz

# on l’exécute

./xt_geoip_dl

# si cela donne un message d’erreur, on fait ceci

/usr/bin/perl -MCPAN -e'install Text::CSV_XS'

# on exécute l’autre fichier

./xt_geoip_build -D . *.csv

# on efface les fichiers inutiles

rm -rf geoip-dl-build.tar.gz

# on teste iptables en bloquant la Chine et la Russie

iptables -A INPUT -m geoip --src-cc CN,RU -j DROP

# on vérifie

iptables -L -v

# ce qui donnera cette ligne indiquant que les pays seront bloqués

DROP all -- anywhere anywhere -m geoip --source-country CN,RU

pour interdire le port 22 à ces pays

iptables -A INPUT -p tcp --dport 22 -m geoip --src-cc CN,RU -j DROP

Block entire countries on Ubuntu server with Xtables and GeoIP

18/03/2017 Comments off
Print Friendly

Source: jeshurun.ca

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.

Lire la suite…

How to save rules of the iptables?

18/03/2017 Comments off
Print Friendly
iptables-save

Saving iptables rules for reboot

On a server, iptables rules don’t reload automatically at reboot. You need to reload the rules using ax executable shell scripture a dedicated utility that will load them at the same time as the program itself, i.e. with the kernel.

Depending of the version of Linux you use, you can select different methods:

sudo su
iptables-save > /etc/iptables.rules

In /etc/network/if-pre-up.d/iptables, put:

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

After, in /etc/network/if-post-down.d/iptables, put:

#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.rules ];
       then iptables-restore < /etc/iptables.rules
fi
exit 0

After, give permission to the scripts:

sudo chmod +x /etc/network/if-post-down.d/iptables sudo chmod +x /etc/network/if-pre-up.d/iptables

Another scenario is to is to install iptables-persistent:

sudo apt-get install iptables-persistent

After it’s installed, you can save/reload iptables rules anytime:

    sudo /etc/init.d/iptables-persistent save 
    sudo /etc/init.d/iptables-persistent reload

Or if you use Ubuntu server 16.04, things are simpler:

The installation as described above works without a problem, but the two commands for saving and reloading above do not seem to work with a 16.04 server. The following commands work with that version:

    sudo netfilter-persistent save
    sudo netfilter-persistent reload

Easy Ubuntu 16.04 Server Firewall

23/02/2017 Comments off
Print Friendly

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

How to Enable IP Forwarding in Linux

19/11/2016 Comments off
Print Friendly

ip forwarding linuxBy 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:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

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:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1




cat /proc/sys/net/ipv4/ip_forward
1

If the result is 1 then the Linux system will start forwarding IP packets even if they are not destined to any of its own network interfaces.

How to monitor OpenFlow messages with packet sniffer

06/07/2016 Comments off
Print Friendly

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.

Lire la suite…

Techniques de scan de ports

06/07/2016 Comments off
Print Friendly

Généralités

techniques de scan de portsComme 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.

Lire la suite…

Disable NetBIOS and SMB to protect public Web servers

23/06/2016 Comments off
Print Friendly

As the connection between your internal network and the rest of the world, public Web servers always deserve an extra measure of protection. Find out one way to lock down these servers.

Windows10logoServing data to users outside of an internal network, public Web servers are typically the first point of contact for an external attack. In addition, internal networking ports are the most revealing and most often attacked ports on a server. That’s why you need to make sure you’ve disabled the services that are specifically for intranets.

The two biggest culprits that you need to worry about are the Server Message Block (SMB) protocol and NetBIOS over TCP/IP. Both services can reveal a wealth of security information and are reoccurring vectors for hacks and attacks. They’re unnecessary for the operation of a public Web server, and you should take steps to shut down both services on these servers.

Disable NetBIOS

NetBIOS was once a useful protocol developed for nonroutable LANs. In this case, it acts as a session-layer protocol transported over TCP/IP to provide name resolution to a computer and shared folders. NetBIOS uses these ports:

  • UDP 137: NetBIOS name service
  • UDP 138: NetBIOS datagram service
  • TCP 139: NetBIOS session service

Since external users — or hackers — don’t need access to shared internal folders, you should turn off this protocol. To disable NetBIOS over TCP/IP, follow these steps:

  1. Got to Start | Control Panel, and double-click the System applet.
  2. On the Hardware tab, click the Device Manager button.
  3. Select Show Hidden Devices from the View menu.
  4. Expand Non-Plug And Play Drivers.
  5. Right-click NetBios Over Tcpip, and select Disable.
  6. Close all dialog boxes and applets.

This disables the Nbt.sys driver, which stops NetBIOS from listening to or initiating sessions over TCP 139. While SMB normally uses this port for communication, it will now switch to TCP 445 — also known as the Common Internet File System (CIFS) port. That’s why you need to disable SMB next.

Uninstall SMB

SMB uses TCP 139 or TCP 445 — depending on which port is available. There’s one way to disable SMB on a non-domain controller. However, I recommend completely uninstalling this service to prevent some well-meaning individual (or program) from re-enabling the service.

To uninstall SMB, follow these steps:

  1. Go to Start | Control Panel, and double-click the Network Connections applet.
  2. Right-click Local Area Connection (i.e., the Internet-facing connection), and select Properties.
  3. Select Client For Microsoft Networks, and click the Uninstall button.
  4. After the uninstall finishes, select File And Printer Sharing For Microsoft Networks, and click the Uninstall button.
  5. Close all dialog boxes and applets. 

Understand the ramifications

You’ve now disabled both SMB and NetBIOS. If an attacker manages to compromise your Web server, he or she won’t be able to use NetBIOS or SMB to further explore and exploit your network.

Of course, security measures are often a balancing act of functionality and security. In this case, disabling these services takes away your ability to remotely manage Web servers through Active Directory’s Computer Management console. However, you can still connect to and manage these servers through the Remote Desktop Client.

Final thoughts

While it’s a common practice to block these ports at security boundaries, nothing beats disabling them on the machines themselves. Remember, as the connection between your internal network and the rest of the world, Web servers always deserve an extra measure of protection.

A Deep Dive into Iptables and Netfilter Architecture

09/06/2016 Comments off
Print Friendly

Introduction

Firewalls are an important tool that can be configured to protect your servers and infrastructure. In the Linux ecosystem, iptables is a widely used firewall tool that interfaces with the kernel’s netfilter packet filtering framework. For users and administrators who don’t understand the architecture of these systems, creating reliable firewall policies can be daunting, not only due to challenging syntax, but also because of number of interrelated parts present in the framework.

In this guide, we will dive into the iptables architecture with the aim of making it more comprehensible for users who need to build their own firewall policies. We will discuss how iptables interacts with netfilter and how the various components fit together to provide a comprehensive filtering and mangling system.

 

What Are IPTables and Netfilter?

The basic firewall software most commonly used in Linux is called iptables. The iptables firewall works by interacting with the packet filtering hooks in the Linux kernel’s networking stack. These kernel hooks are known as the netfilter framework.

Every packet that enters networking system (incoming or outgoing) will trigger these hooks as it progresses through the stack, allowing programs that register with these hooks to interact with the traffic at key points. The kernel modules associated with iptables register at these hooks in order to ensure that the traffic conforms to the conditions laid out by the firewall rules.

 

Netfilter Hooks

There are five netfilter hooks that programs can register with. As packets progress through the stack, they will trigger the kernel modules that have registered with these hooks. The hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet’s destination, and whether the packet was dropped or rejected at a previous point.

The following hooks represent various well-defined points in the networking stack:

  • NF_IP_PRE_ROUTING: This hook will be triggered by any incoming traffic very soon after entering the network stack. This hook is processed before any routing decisions have been made regarding where to send the packet.
  • NF_IP_LOCAL_IN: This hook is triggered after an incoming packet has been routed if the packet is destined for the local system.
  • NF_IP_FORWARD: This hook is triggered after an incoming packet has been routed if the packet is to be forwarded to another host.
  • NF_IP_LOCAL_OUT: This hook is triggered by any locally created outbound traffic as soon it hits the network stack.
  • NF_IP_POST_ROUTING: This hook is triggered by any outgoing or forwarded traffic after routing has taken place and just before being put out on the wire.

Kernel modules that wish to register at these hooks must provide a priority number to help determine the order in which they will be called when the hook is triggered. This provides the means for multiple modules (or multiple instances of the same module) to be connected to each of the hooks with deterministic ordering. Each module will be called in turn and will return a decision to the netfilter framework after processing that indicates what should be done with the packet.

 

IPTables Tables and Chains

The iptables firewall uses tables to organize its rules. These tables classify rules according to the type of decisions they are used to make. For instance, if a rule deals with network address translation, it will be put into the nat table. If the rule is used to decide whether to allow the packet to continue to its destination, it would probably be added to the filter table.

Within each iptables table, rules are further organized within separate « chains ». While tables are defined by the general aim of the rules they hold, the built-in chains represent the netfilter hooks which trigger them. Chains basically determine when rules will be evaluated.

As you can see, the names of the built-in chains mirror the names of the netfilter hooks they are associated with:

  • PREROUTING: Triggered by the NF_IP_PRE_ROUTING hook.
  • INPUT: Triggered by the NF_IP_LOCAL_IN hook.
  • FORWARD: Triggered by the NF_IP_FORWARD hook.
  • OUTPUT: Triggered by the NF_IP_LOCAL_OUT hook.
  • POSTROUTING: Triggered by the NF_IP_POST_ROUTING hook.

Chains allow the administrator to control where in a packet’s delivery path a rule will be evaluated. Since each table has multiple chains, a table’s influence can be exerted at multiple points in processing. Because certain types of decisions only make sense at certain points in the network stack, every table will not have a chain registered with each kernel hook.

There are only five netfilter kernel hooks, so chains from multiple tables are registered at each of the hooks. For instance, three tables have PREROUTING chains. When these chains register at the associated NF_IP_PRE_ROUTING hook, they specify a priority that dictates what order each table’s PREROUTING chain is called. Each of the rules inside the highest priority PREROUTING chain is evaluated sequentially before moving onto the next PREROUTING chain. We will take a look at the specific order of each chain in a moment.
Lire la suite…