gratifiant > linux.debian.user.french

Daniel Caillibaud (24/09/2019, 18h40)
Le 24/09/19 =C3=A0 17:27, Daniel Huhardeaux <no-spam> a =C3=A9cr=
it :
> Modifier le port de connexion de services connus comme ssh +=20
> identification par cl=C3=A9 suffit pour ne pas avoir =C3=A0 rajouter une = couche.


En quoi changer le port am=C3=A9liorerait la s=C3=A9curit=C3=A9 ?

> Personnellement, en dehors des ports r=C3=A9put=C3=A9s fig=C3=A9s, aucun = service ne=20
> tourne sur les ports traditionnels.


C'est peut-=C3=AAtre du "sentiment de s=C3=A9curit=C3=A9" mais =C3=A7a ne s=
=C3=A9curise rien du tout (et =C3=A0 priori
plut=C3=B4t l'inverse, un faux sentiment de s=C3=A9curit=C3=A9 est pas tr=
=C3=A8s bon, =C3=A7a peut conduire =C3=A0 qq
n=C3=A9gligences).
Le scan de ports c'est tout le temps et =C3=A7a se voit pas dans les logs, =
un port d=C3=A9plac=C3=A9 ne
prot=C3=A8ge de rien du tout (ok, pour le ssh =C3=A7a peut limiter les mess=
ages dans le auth.log, mais
y'a d'autres moyens pour =C3=A7a ;-)).

Et pour moi le port 22 du ssh est un port "fig=C3=A9", comme le 80/443 pour=
le web, le 53 pour le
dns, 25/487 pour le mail=E2=80=A6 et c'est valable pour tous les ports ouve=
rts sur mes ip publiques.

Je comprends qu'on mette un service "priv=C3=A9" sur une ip publique par co=
mmodit=C3=A9, mais dans ce cas
faut assumer et g=C3=A9rer sa s=C3=A9curit=C3=A9, le mettre sur un port exo=
tique ne l'am=C3=A9liorera pas.

--=20
Daniel

- Aujourd'hui, c'est la chasse =C3=A0 l'ours.
O=C3=B9 cours-tu le lapin? Tu ne risques rien!
- Eh, t'es con! J'ai pas mes papiers!
Coluche
Daniel Huhardeaux (24/09/2019, 19h20)
Le 24/09/2019 à 18:36, Daniel Caillibaud a écrit :
> Le 24/09/19 à 17:27, Daniel Huhardeaux <no-spam> a écrit :
>> Modifier le port de connexion de services connus comme ssh +
>> identification par clé suffit pour ne pas avoir à rajouter une couche.

> En quoi changer le port améliorerait la sécurité ?


Modifie le port ssh et tu verras la diminution drastique des tentatives
(iptables log les connexions vers mes ports exotiques).

>> Personnellement, en dehors des ports réputés figés, aucun service ne
>> tourne sur les ports traditionnels.

> C'est peut-être du "sentiment de sécurité" mais ça ne sécurise rien du tout (et à priori
> plutôt l'inverse, un faux sentiment de sécurité est pas très bon, ça peut conduire à qq
> négligences).


Une connexion avec clé me parait sécurisé. Ne serait ce qu'un sentiment ? ;)

> Le scan de ports c'est tout le temps et ça se voit pas dans les logs, un port déplacé ne
> protège de rien du tout (ok, pour le ssh ça peut limiter les messages dans le auth.log, mais
> y'a d'autres moyens pour ça ;-)).

Les "méchants" ne s'embêtent pas ou peu à scanner: ils ont assez de
boulot avec les ports traditionnels. J'utilise au bureau une UTM qui
hebdomadairement remonte les statistiques. Ex pour la semaine passée:

Les 10 principaux services abandonnés
Nombre total de paquets abandonnés : 102 578
Principal Nom du service Protocole Service Paquets %
1 TELNET TCP 23 5 869 5.72 %
2 T9C0 ICMP t9c0 3 689 3.60 %
3 MICROSOFT-DS TCP 445 2 320 2.26 %
4 SSH TCP 22 1 402 1.37 %
5 T11C1 ICMP t11c1 1 096 1.07 %
6 HTTP TCP 80 1 023 1.00 %
7 PERSONAL-AGENT TCP 5555 998 0.97 %
8 SIP UDP 5060 887 0.86 %
9 HTTP-ALT TCP 8080 882 0.86 %
10 DOMAIN UDP 53 815 0.79 %

> Et pour moi le port 22 du ssh est un port "figé", comme le 80/443 pour le web, le 53 pour le
> dns, 25/487 pour le mail? et c'est valable pour tous les ports ouverts sur mes ip publiques.
> Je ne vois rien de cela dans mes logs


Que le 80,443,53,25,487 (liste non exhaustive) soient ouverts me parait
normal. C'est ce que j'ai appelé les ports figés.

> Je comprends qu'on mette un service "privé" sur une ip publique par commodité, mais dans ce cas
> faut assumer et gérer sa sécurité, le mettre sur un port exotique ne l'améliorera pas.


Je ne parlai pas de service "privé", je parle de service "publique" que
l'on peut déplacer. Et j'assume.

Ce débat a déjà eu lieu et revient périodiquement. À chacun selon son
niveau/besoin/"sentiment"/... de traiter
Pascal Hambourg (12/10/2019, 10h00)
Le 10/10/2019 à 19:58, G2PC a écrit :
> Voilà, cette partie a été traitée.
> J'ai également remplacé :
> -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
> par
> -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,NEW -j ACCEPT


Donc tu as supprimé RELATED de la liste des états autorisés.

> J'espère que c'est cohérent.


C'est cohérent si tu n'utilises pas le suivi de connexion FTP pour ces
connexions de données passives. Si tu l'utilises, le premier paquet de
ces connexions sera classé dans l'état RELATED et ne pourra être accepté
par cette règle. Il faudra donc une autre règle spécifique pour accepter
ce premier paquet, sinon la connexion échouera.

Discussions similaires