philpep's blog - tag Packet Filter

Mon nouveau jouet

Wed, 05 May 2010 00:00:00 GMT

Pris un coup de folie et je me suis procuré le dernier joujou à la mode, un petit nokia n97. Les forfaits c'est vraiment du viol^Wvol, donc clairement je ne vous recommande pas ça, moi j'ai eu l'opportunité de ne pas le payer donc bon. Ce sera nettement plus convi quand il y aura un opérateur mobile valable avec du vrai internet.

En attendant tout ça j'ai quand même pu faire des choses sympa, faut dire que Nokia, contrairement à la pomme, laisse pas mal de liberté essentiellement parce qu'on peut installer tout ce qu'on veut sur la machine et ils fournissent tous les outils pour. J'ai le bestiau depuis seulement quelques jours donc j'ai pas encore trop réfléchi sur le coté dev, mais je pense qu'on peut sortir de la prison Internet by orange avec quelques tools réseau bien pensés.

Unes des premières appli que j'ai testé c'est putty mobile. En wifi sur le réseau local je passe par le port 22 tout marche normal. Seulement sur internet c'est pas sur le port 22 qu'il est mon serveur mais plutôt disons 1234, et avec Internet by orange forcément le port 1234 sortant ça pourrait bien être du contenu pédonazi et alors ça passe pas.

Du coup je browse sur un de mes sites, je chope l'IP 80.10.46.66 de la passerelle nazie dans mes logs, comme c'est bien pensé l'IP de la passerelle change souvent et faut plutôt utiliser 80.10.46.0/24 (voir plus si ça se trouve).

Un petit coup de pf.conf sur la box :

nazis = "80.10.46.0/24"
rdr pass proto tcp to port 1234 -> $serv port ssh # Pour les gens normaux
rdr pass proto tcp from $nazis to port ssh -> $serv

Et taaadaam :

Sûrement à bientôt pour de nouvelles aventures Internet By Orange.

Astuce pf du jour

Tue, 23 Feb 2010 14:09:07 GMT

J'ai la chance d'avoir une bibliothèque avec un rayon informatique bien rempli dans mon Université, dernièrement j'y ai emprunté ce bouquin. Là dedans j'y ai vu une syntaxe pour décrire le réseau local que j'avais raté quand j'ai lu la doc :

ext_if = "rl0"
# Au lieu de
localnet = "{ 192.168.0.0/24, 2a01:e35:2e58:9820::/64 }"
# On peut mettre
localnet = $ext_if:network
# Ou encore
localnet = rl0:network

Pf va lui même calculer le réseau local à l'aide de l'IP du netmask et du prefixe.

Attention tout de même si vous avez plusieurs IP (v4 et v6) sur l'interface, ça peut produire des règles redondantes, en cas de doute :

pfctl -sr

EDIT (27/02/10) : En fait quand il y a des alias sur l'IP il va les évaluer mais pour ne spécifier que l'adresses (sans les alias) on peut mettre $ext_if:network:0

pfstat

Sun, 06 Dec 2009 02:57:24 GMT

J'aime pas franchement les graphe les chiffres tout ça (j'entends déjà rire les gens qui me connaissent devant ce mensonge éhonté). Mais j'avoue que j'aime bien les stats donnée par pfstat (le site est souvent down en ce moment). Ce petit soft récolte des statistiques temporelles sur pf et peut les cracher sous forme de graphe.

Petit exemple tout de suite, ce graphe représente le traffic entrant/sortant (in/out) autorisé/bloqué (block in/block out) sur mon routeur pour les dernières 24h.

C'est assez interessant, il peut faire une multitude de graphes configurables, je vais pas poser ma conf ici parce que je l'ai honteusement pompée sur calomel. À noter que pfstat est aussi disponible en daemon (pfstatd), ça permet de générer les images des statistiques d'une autre machine. Il suffit de lancer pfstatd sur la machine ou l'on veut faire des statistiques, et lancer pfstat (dans cron par exemple) avec les options -r host:port.

Vous pouvez voir ici ce qui se passe sur mes deux modestes machines qui font exister philpep.org.

EDIT 10 janvier 2010 : pfstat ne semble plus maintenu :/ , en tout cas il a du mal avec les dernières versions de pf. Bref les graphes que vous voyez sont vieux

fail2ban sshd et pf

Wed, 18 Nov 2009 18:28:10 GMT

Mon /var/log/auth.log est blindé de choses du genre :

Nov 18 17:56:27 lenine sshd[49297]: Invalid user marcio from 24.17.93.35
Nov 18 17:56:27 lenine sshd[49297]: error: PAM: authentication error for illegal user marcio from 24.17.93.35
Nov 18 17:56:27 lenine sshd[49297]: Failed keyboard-interactive/pam for invalid user marcio from 24.17.93.35 port 63330 ssh2
Nov 18 17:58:05 lenine sshd[49312]: Address 92.126.194.108 maps to alfa.navsystem.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Nov 18 17:58:05 lenine sshd[49312]: Invalid user marcio from 92.126.194.108
Nov 18 17:58:05 lenine sshd[49312]: error: PAM: authentication error for illegal user marcio from 92.126.194.108
Nov 18 17:58:05 lenine sshd[49312]: Failed keyboard-interactive/pam for invalid user marcio from 92.126.194.108 port 38920 ssh2

C'est une attaque classique par dictionnaire mais distribuée. Ma seule défense pour l'instant c'est mon parre feu qui bloquait les bruteforces un peu trop rapides. Alors même si pf en filtre quand même pas mal, les petits malins tournent sur plusieurs IPs pour faire un bruteforce moins visible.

J'ai donc décidé de bloquer le reste avec fail2ban, la conf par défaut n'est pas adapté à ma config, j'ai des besoin précis sur le filtre sshd et il faut que ça marche avec pf.

L'install est toujours aussi simple :

# make -C /usr/ports/security/py-fail2ban install

La conf est dans /usr/local/etc/fail2ban

En premier lieu, créer l'action pour pf :

action.d/pf.conf

[Definition]
actionstart = 
actionstop = 
actioncheck = 
actionban = pfctl -t flood -T add <ip>
actionunban = pfctl -t flood -T del <ip>

Comme vous voyez on va largement utiliser les tables pf, il y a donc quelques modifs à faire dans votre /etc/pf.conf :

# La table
table <flood> persist
# On laisse passer tout sauf les IP de <flood>
pass in inet proto tcp from ! <flood> to $ext_if port ssh

Ensuite on modifie le filtre filter.d/sshd.conf :

[INCLUDES]

before = common.conf

[Definition]

_daemon = sshd

failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
               ^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT\s*$

ignoreregex =

Et on active le filtre dans jail.conf :

[ssh-pf]
enabled  = true
filter   = sshd
action   = pf
          sendmail-whois[name=SSH, dest=root@localhost, sender=noreply@localhost]
logpath  = /var/log/auth.log
maxretry = 1
bantime  = 86400

Ils sont bannis pour 1 jours (de quoi leur faire perdre beaucoup de temps). En prime pour chaque ban vous recevez le whois de l'IP concernée par mail.

Finalement on oublie pas de lancer fail2ban :

# echo fail2ban_enable=\"YES\" >> /etc/rc.conf
# /usr/local/etc/rc.d/fail2ban start

Ce qui pourrait être intéressant c'est de choper automatiquement les adresses mail Abuse du whois pour envoyer un mail au FAI du méchant pour lui dire tout ce qu'on pense de son client. Mais bon, on ne va pas non plus faire de délation à la HADOPI.

Limiter un utilisateur avec pf

Fri, 11 Sep 2009 17:10:28 GMT

OpenBSD Packet Filter permet de filtrer les paquets suivant l'UID de provenance (et peut être même de destination mais ça nous intéresse moins.

Vous avez un amis qui se connecte en ssh chez vous pour poser un irssi dans un GNU screen. C'est super sympa de votre part, seulement si on a pas une confiance totale en cet utilisateur il pourrait (lui ou un virus) se servir de son accès pour utiliser votre IP et balancer du spam, lancer une attaque de banque ou je ne sais quoi encore. Résultat : vous êtes responsable.

L'idée est simple, nous allons filtrer le trafic sortant de cet utilisateur (de login fictif machin) en lui autorisant uniquement le port IRC 6667 :

pass out on $ext_if proto tcp to port 6667 user machin tag TAG_MACHIN
block out quick on $ext_if proto tcp all user machin ! tagged TAG_MACHIN

La première règle autorise le port 6667 sortant pour machin et tagge le paquet avec TAG_MACHIN. La deuxième bloque tout ce qui vient de machin et qui n'est pas taggé avec TAG_MACHIN. Ce qui fait exactement ce que l'on veut.

Le mot clef quick permet a la règle d'être prise en compte immédiatement peu importe les règles suivantes (ce qui protège d'une éventuelle règle qui ferait tout passer ensuite).

Pour continuer dans l'exemple, il peut être utile d'autoriser les query DNS pour cet utilisateur (si vous n'avez pas de serveur DNS en interne), ça se passe en 53/udp :

pass out on $ext_if proto tcp to port 6667 user machin tag TAG_MACHIN
pass out on $ext_if proto udp to port domain user machin tag TAG_MACHIN
block out quick on $ext_if proto tcp all user machin ! tagged TAG_MACHIN

On peut même faire des listes sur les port et/ou utilisateurs :

users = { machin, truc }
pass out on $ext_if proto tcp to port { 6667, http } user $users tag TAG_USERS
pass out on $ext_if proto udp to port domain user $users tag TAG_USERS
block out quick on $ext_if proto tcp all user $users ! tagged TAG_USERS

Bloquer le trafic sortant de ses jails avec packet filter

Fri, 11 Sep 2009 17:04:18 GMT

Si comme moi vous utilisez une FreeBSD avec pleins de services/utilisateurs dans des jails, il vous est peut être arrivé de vouloir restreindre un peu plus le possibilité réseau dans vos jails. Par exemple empêcher qu'un de vos utilisateur (réel ou non) utilise votre IP pour faire des choses malsaine (un script qui envoie du spam par exemple).

Pour cela j'utilise Packet filter et ses tags. Le problème c'est qu'une fois que la NAT pour les jails est écrite, le paquet apparaît comme provenant de l'hôte et non de la jail. Comme toujours un bon fichier de conf vaut mieux qu'un long discourt :

ext_if = "fxp0"

# Network Description 
jails   = "10.0.0.0/24"    # Jails

set block-policy return
set skip on { lo0, lo1 }
set loginterface $ext_if
scrub in

# Nat for jails, we tag these packets to make filtering on out packets
nat on $ext_if from $jails  tag TAG_JAILS  -> $ext_if

# Block rules
block log all

# Pass out rules
pass out on $ext_if proto { tcp, udp } all ! tagged TAG_JAILS
pass out on $ext_if proto tcp to port { http ftp ircd  6697 domain 9418 } tagged TAG_JAILS
anchor "ftpsesame/*" on $ext_if

# Antispoofing
antispoof log for { $ext_if, lo0 } inet

Voilà, quand le paquet arrive sur la NAT, il est taggé avec TAG_JAIL et on effectue du filtrage ensuite sur ce tag, tout le trafic sortant passe pour les paquets qui ne proviennent pas des jails et le traffic qui provient des jails passe uniquement si le port de direction est autorisé. L'ancre "ftpsesame/*" est là pour autoriser le traffic sortant ftp, ce qui n'est pas aussi évident que l'on pense, voir ce billet.

Packet filter et ftp sortant

Fri, 11 Sep 2009 17:01:09 GMT

Comme j'ai expliqué dans ce billet, filtrer le traffic sortant est une bonne habitude à avoir, surtout pour un serveur qui utilise tout le temps les même ports sortant.

Le problème c'est le protocole FTP qui a été crée a un moment où la sécurité n'existait pas encore et on se connectait en telnet sans mot de passe. FTP n'est pas fait pour passer les parre feu. Si la connection est initié sur le port 21 le transfert des données se fait sur un autre port qui est négocié soit par le serveur soit par le client (Mode actif et mode passif). Du coup rend le filtrage beaucoup plus compliqué puisqu'on ne connait pas d'avance le port qui va être utilisé.

Après avoir lu la doc pour gerer le protocole FTP avec packet filter, j'ai essayé d'utiliser ftp-proxy et tous mes tests se sont soldés par un cuisant echec. Il semblerais que ftp-proxy ne soit pas adapté pour un client en ftp passif protégé par un parre feu local avec un filtrage strict des paquets sortants.

J'ai donc trouvé par miracle dans les ports FreeBSD un petit programme qui permet de regler le problème sans trop de difficultés.

(Remplacez rl0 par votre interface réseau)

make -C /usr/ports/ftp/ftpsesame install clean
echo "ftpsesame_enable=\"YES\"\nftpsesame_flags=\"-i rl0\"\n" >> /etc/rc.conf

Et la conf pf qui va avec :

# L'interface connecté au réseau local
ext_if = "rl0"

# Les ports sortant autorisés
out_tcp  = "{ ssh http ftp https 1213 6600 8000 8021 9418 xmpp-client 5223 }"
out_udp  = "{ domain }"

# Options
set loginterface $ext_if
set skip on lo0
scrub in

# Filtering, on bloque tout et on passe ce qui est autorisé
block log all
pass out on $ext_if proto icmp all
pass out on $ext_if proto udp to port $out_udp
pass out on $ext_if proto tcp to port $out_tcp
# On charge les rêgles de ftpsesame
anchor "ftpsesame/*" on $ext_if

# Antispoofing
antispoof log for { $ext_if, lo0 } inet

Et hop :

/usr/local/etc/rc.d/ftpsesame start
pfctl -f /etc/pf.conf

Franchement je sais pas comment ftpsesame se débrouille mais ça marche impécablement.

De l'importance de filtrer le traffic sortant

Fri, 11 Sep 2009 16:57:58 GMT

Bien souvent quand on lis des articles sur les milles et unes astuces pour sécuriser un peu plus sa machine on y retrouve très souvent l'idée de "fermer les ports" c'est à dire empecher un traffic entrant qui ne serait pas légitime.

C'est une bonne pratique, voici quelques rappels de bas étages sur les sockets (pour ceux qui entendent ce mot pour la première fois).

Pour que deux ordinateurs puissent communiquer il faut établir une connection, un tunel bidirectionnel dans lequel on peut lire et écrire des données. L'analogie humaine, une fois n'est pas coutume, est parfaitement adaptée ici. Quand vous discutez avec quelqu'un vous parlez (écrire) et vous écoutez (lire). En informatique un tel tunel s'appelle un socket. C'est un simple fichier que l'on doit créer sur les deux ordinateurs.

Mais on ne crée pas une communication aussi simplement, il faut "brancher" nos sockets ensemble, si les humains ont du mal à communiquer avec plusieurs personnes à la fois l'ordinateur peut lui discuter avec environ 65000 de ses homologues en même temps. Pour celà on a crée la notion de port, c'est un nombre entre 1 et 65000 (et des poussières). Pour connecter nos deux sockets, il faut que chaque ordinateur connaisse :

L'adresse de l'autre ordinateur, son IP
Le port sur lequel va s'effectuer la communication

Notez que les deux ports ne doivent pas forcement être les mêmes (d'ailleurs ce ne sont jamais les mêmes en pratique). Ensuite il y a la notion de client/serveur (qui est foireuse et c'est bien là dessus que je veux vous amener). C'est à dire que l'un des ordinateurs va jouer le role de serveur et l'autre de client, le serveur va mettre un socket sur écoute sur un certain port et le client va s'y connecter. Et là la communication est effective, nos deux amis peuvent écrire et lire des données qui seront envoyés a celui qui se trouve au bout du socket.

Du point de vue du serveur, c'est un traffic entrant et pour le client c'est un traffic sortant. Mais c'est vraiment la seule chose qui différentie le client du serveur, la nature des données qui transitent n'ont rien à voir avec tout ça.

Bloquer le traffic entrant permet de bloquer un éventuel intru du système qui mettrait un port sur écoute pour mieux controler votre machine à distance. Mais bloquer le traffic entrant n'est qu'une illusion de sécurité si on ne regarde pas ce qui se passe sur le traffic sortant. Comme je l'ai dit, la nature des données échangés n'a rien à voir et on pourrait très bien imaginer un programme ou le client executerait tout ce que lui dit le serveur.

D'ailleurs bon nombre de virus fonctionnent en se connectant sur un serveur IRC pour communiquer avec celui qui dirige à distance l'ordinateur de l'internaute imprudent. Et c'est du traffic sortant.

Si maintenant la paranoia vous guette, vous pouvez aller reconfigurer votre parre feu.

Regles pf pour bloquer le ssh bruteforcing et le deni de service

Thu, 10 Sep 2009 22:06:56 GMT

Packet filter, le parre feu d'OpenBSD (disponible et installé dans FreeBSD et NetBSD) nous offre des options de filtrage avancées.

Il est possible de contrer le ssh bruteforcing (tentative de trouver le mot de passe en testant une infinité de mots de passe) et le Déni de service (grand nombre de connexion à un serveur pour le faire exploser où empêcher les autres d'y accéder).

Pour celà il faut un peu jouer avec max-src-conn , max-src-conn-rate et les tables pf.

Voici un exemple commenté :

# Interface entrante
ext_if = "fxp0"

# On crée deux tables
table <ssh_abuse> persist
table <http_abuse> persist

# On bloque ceux qui sont dans la table sur les ports concernés
# Le 'quick' permet d'ignorer toute autre rêgle de filtrage 
# concernant ces paquets
block in quick on $ext_if proto tcp from <ssh_abuse> port ssh
block in quick on $ext_if proto tcp from <http_abuse> port http

# si on a plus de 2 connection toutes les 10 secondes sur
# le port ssh, on rajoute l'IP concernée dans la table ssh_abuse
pass in inet proto tcp to any port ssh flags S/SA keep state \
           (max-src-conn-rate 2/10, overload <ssh_abuse> flush global)
# Si on a plus de 100 connection avec cet IP ou plus de 20 connexion
# en 5 secondes, alors on met l'IP concernée dans la table http_abuse
pass in inet proto tcp to any port http flags S/SA keep state \
    (max-src-conn 100, max-src-conn-rate 20/5, overload <http_abuse> flush)