Si pour des raisons de sécurité ou autres… Vous souhaitez changer le port de l’interface web de Pfsense, voici la procédure :
C’est très simple, il faut déjà avoir l’accès à l’interface.
Ensuite « System » -> « Advanded » et de mettre le numéro de port choisi dans la case « TCP Port« .
Enfin on sauvegarde avec « save » et quelques secondes plus tard vous pouvez vous relogguer (en oubliant pas de changer le port sans le navigateur).
Par défaut, l’interface web de pfsense n’est accessible que depuis le LAN.
Attention ce qui va suivre désactive quelques principes de sécurité. On pourra pour compenser filtrer sur une adresse ip par exemple.
La méthode est assez simple ! car il suffit simplement de créer une nouvelle règle dans le firewall.
Nous allons aller dans « Firewall » > « Rules » et se placer dans l’onglet « WAN » et cliquez sur le « + »
Nous allons créer la nouvelle règle :
Action : "Pass" Interface : "WAN" Source : Soit vous mettez toutes les ips soit une seule pour plus de sécurité. Destination : "WAN Address" Destination port range : "HTTP" Log : Oui ou non cela dépend si vous voulez des logs Description : Votre choix
Enfin on clique sur « Save » puis « Apply changes »
Vous pouvez alors accéder à l’interface depuis http://WAN/
Voici une liste des codes HTTP… En français :
* 100 : OK pour continuer
* 101 : le serveur a changé de protocoles
* 200 : requête effectuée avec succès
* 201 : document créé (raison : nouvelle URI)
* 202 : requête achevée de manière asynchrone (TBS)
* 203 : requête achevée de manière incomplète
* 204 : aucune information à renvoyer
* 205 : requête terminée mais formulaire vide
* 206 : requête GET incomplète
* 300 : le serveur ne peut pas déterminer le code de retour
* 301 : document déplacé de façon permanente
* 302 : document déplacé de façon temporaire
* 303 : redirection avec nouvelle méthode d’accès
* 304 : le champ ‘if-modified-since’ n’était pas modifié
* 305 : redirection vers un proxy spécifié par l’entête
* 307 : HTTP/1.1
* 400 : erreur de syntaxe dans l’adresse du document
* 401 : pas d’autorisation d’accès au document
* 402 : accès au document soumis au paiement
* 403 : pas d’autorisation d’accès au serveur
* 404 : la page demandée n’existe pas
* 405 : méthode de requête du formulaire non autorisée
* 406 : requête non acceptée par le serveur
* 407 : autorisation du proxy nécessaire
* 408 : temps d’accès à la page demandée expiré
* 409 : l’utilisateur doit soumettre à nouveau avec plus d’infos
* 410 : cette ressource n’est plus disponible
* 411 : le server a refusé la requête car elle n’a pas de longueur
* 412 : la précondition donnée dans la requête a échoué
* 413 : l’entité de la requête était trop grande
* 414 : l’URI de la requête était trop longue
* 415 : type de média non géré
* 500 : erreur interne du serveur
* 501 : requête faite au serveur non supprimée
* 502 : mauvaise passerelle d’accès
* 503 : service non disponible
* 504 : temps d’accès à la passerelle expiré
* 505 : version HTTP non gérée
La même liste en anglais :
* 200 : request completed
* 201 : object created, reason = new URI
* 202 : async completion (TBS)
* 203 : partial completion
* 204 : no info to return
* 205 : request completed, but clear form
* 206 : partial GET furfilled
* 300 : server couldn’t decide what to return
* 301 : object permanently moved
* 302 : object temporarily moved
* 303 : redirection w/ new access method
* 304 : if-modified-since was not modified
* 305 : redirection to proxy, location header specifies proxy to use
* 307 : HTTP/1.1: keep same verb
* 400 : invalid syntax
* 401 : access denied
* 402 : payment required
* 403 : request forbidden
* 404 : object not found
* 405 : method is not allowed
* 406 : no response acceptable to client found
* 407 : proxy authentication required
* 408 : server timed out waiting for request
* 409 : user should resubmit with more info
* 410 : the resource is no longer available
* 411 : the server refused to accept request w/o a length
* 412 : precondition given in request failed
* 413 : request entity was too large
* 414 : request URI too long
* 415 : unsupported media type
* 500 : internal server error
* 501 : required not supported
* 502 : error response received from gateway
* 503 : temporarily overloaded
* 504 : timed out waiting for gateway
* 505 : HTTP version not supported
Si vous avez une adresse IP statique, chez vous ou au bureau, ou peut-être votre propre VPN, vous avez la chance de pouvoir augmenter votre sécurité. La technique consiste à restreindre les accès à l’admin de wordpress par une ou plusieurs ip.
Nous allons voir comment le mettre en place sur Nginx.
Nous allons créer un bloc map pour y inclure la liste des adresses ip autorisées.
map $remote_addr $allowed_ip {
1.2.3.4 1;
1:: 1;
5.6.7.8 1;
default 0;
}
On assigne la valeur 1 aux adresses ip que l’on veut autoriser et 0 pour le reste.
Nous allons modifier notre « bloc server » pour y inclure nos conditions. Nginx ne supporte pas les opérateurs logiques dans les bloc if , nous allons donc devoir contourner le problème en mettant plusieurs if.
server {
...
set $check ''; #initialisation de la variable
if ( $allowed_ip = 0 ) {
set $check "A";
}
if ( $request_uri ~ ^/wp-(login\.php|admin/) ) {
set $check "${check}B";
}
if ( $check = "AB" ) {
return 403;
}
...
}
Donc si l’adresse n’est pas dans la liste du bloc map « check = A » et si l’uri correspond à /wp-login.php ou wp-admin/ « check = AB ». Si nous avons $check = AB nous retournons une 403 ( forbidden ).
Il est très intéressant de pouvoir écrire dans un fichier de log les erreurs de HAProxy. Cela peut aussi servir dans le cas d’un debug.
Les logs de HAProxy peuvent être activés en ajoutant cette ligne dans le fichier de configuration haproxy.cfg.
log 127.0.0.1 local0
Il suffit ensuite de créer ce fichier /etc/rsyslog.d/10-haproxy.conf avec le contenu suivant :
$ModLoad imudp $UDPServerRun 514 $template Haproxy,"%msg%\n" local0.=info -/var/log/haproxy.log;Haproxy local0.notice -/var/log/haproxy.notice;Haproxy local0.* ~
On relance Rsyslog :
/etc/init.d/rsyslog restart
Avec ceci, tous les logs de type info vont être écrit dans le fichier /var/log/haproxy.log.
Les types notice iront dans le fichier /var/log/haproxy.notice.
Pour finir, les fichiers de logs peuvent être tournés via rotatelog, il faut ajouter cette configuration dans /etc/logrotate.d/haproxy :
/var/log/haproxy.log {
missingok
notifempty
sharedscripts
rotate 14
daily
compress
postrotate
reload rsyslog >/dev/null 2>&1 || true
endscript
}
Comment redémarrer le service réseau sur un système OpenBSD ?
Supposons que l’on vient de modifier notre interface em0 via le fichier /etc/hostname.em0. Comment prendre en compte nos modifications ?
sh /etc/netstart em
La deuxième astuce consiste à désactiver l’interface puis de la réactiver
ifconfig em0 down ifconfig em0 up
Comme pour Nginx, il peut aussi être intéressant de vouloir cacher la version de php dans les headers http de notre site web.
Par défaut la version est renvoyé dans les headers http. Ce qui peut donner ceci :
$ curl -I https://www.cloud-devops.fr/ HTTP/1.1 200 OK Server: nginx Date: Fri, 05 Feb 2016 21:04:09 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Powered-By: PHP/5.6.3
Pour ne plus afficher le X-Powered-By: PHP il suffit d’ouvrir le fichier /etc/php.ini
et de passer la variable expose_php à off
expose_php = Off
Si vous utilisez ph-fpm il faut relancer le service.
service php-fpm restart
On test que cela fonctionne :
$ curl -I https://www.cloud-devops.fr/ HTTP/1.1 200 OK Server: nginx Date: Fri, 05 Feb 2016 21:04:09 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding
Il n’y a plus rien qui s’affiche cela fonctionne correctement !
Les services FTP ont toujours été difficile à filter.
Tout ceci à cause des modes ftp (actif / passif) qui change la donne.
Voici quelques explications :
Mode actif :
C’est le mode par défaut des clients FTP. Le client établi dans un premier temps une session TCP sur le port 21 (FTP) du serveur (« control channel »).
Une fois la session établie et l’authentification FTP acceptée, c’est le serveur qui établi une session TCP (avec le port source 20, FTP-DATA) vers un port dynamique du client (« data channel »).
Mode passif :
Le mode passif est conseillé à partir du moment où l’on est derrière un pare-feu.
Comme pour le FTP actif, le client établi une première session TCP sur le port 21 (FTP) du serveur (« control channel »). Une fois la session établie et l’authentification FTP acceptée,
On demande au serveur de se mettre en attente de session TCP grâce à la commande PASV. Alors le client peut établir une seconde session TCP sur un port dynamique vers le serveur (« data channel »).
il faut d’abord charger le module ip_conntrack_ftp ( pour suivre les connexions ftp).
modprobe ip_conntrack_ftp
Ensuite la commande suivantes pour que la connexion puisse s’établir :
iptables -A INPUT -i eth0 -p tcp \--sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp \--sport 21 -m state --state ESTABLISHED -j ACCEPT
Ensuite, c’est la que l’on a besoin de ip_conntrack_ftp, pour que le serveur puisse établir la connexion pour les données ( en mode actif).
iptables -A INPUT -i eth0 -p tcp \--sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp \--sport 20 -m state --state ESTABLISHED -j ACCEPT
Pour que le serveur puisse établir la connexion pour les données (en mode passif) ici le mode ip_conntrack_ftp est nécessaire.
iptables -A INPUT -i eth0 -p tcp \--sport 1024:65535 --dport 1024:65535 -m state ESTABLISHED -j ACCEPT iptables -A OUTOUT -o eth0 -p tcp \--sport 1024:65535 --dport 1024:65535 -m state ESTABLISHED,RELATED -j ACCEPT
Voilà !
Il existe un utilitaire en ligne de commande qui permet d’agir sur fail2ban.
Il s’agit de fail2ban-client. Il s’utilise de cette façon :
fail2ban-client set JAILNAME unbanip IPADDRESS
Pour connaitre le vrai « JAILNAME », on peut utiliser cette commande :
# iptables -L -n target prot opt source destination fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22
Chez moi, « JAILNAME » correspond à fail2ban-ssh
Ce qui donne la commande suivante :
# fail2ban-client set ssh unbanip 1.2.3.4
Depuis sa version 1.9.5, nginx apporte le support du protocole http version 2. Si vous utilisiez déjà le module SPDY, il est remplacé par le module HTTP/2.
Pour savoir si vous supportez ce protocole :
# nginx -V
Vous devez avoir une version supérieur à 1.9.5 et avoir dans les options de compilations –with-http_v2_module. Si vous n’avez pas cette option, il faudra mettre à jour votre version de nginx.
Il faut savoir que l’implémentation de HTTP/2 requière du HTTPS.
Pour ajouter la prise en charge de HTTP/2 dans la configuration de nginx, il suffit de remplacer dans le bloc server { }
listen 443 ssl;
par :
listen 443 ssl http2;
On recharge ensuite la config :
# service nginx restart
Pour vérifier que cela fonctionne correctement je vous invite à faire le test sur :