6 votes

Limiter ssh au réseau local, sauf pour l'utilisateur git

J'ai un serveur Ubuntu 12.04 configuré avec Gitlab et OpenVPN pour servir de serveur git et vpn pour nous.

Actuellement, j'ai ouvert le port 1194 dans le pare-feu pour OpenVPN et je laisse les utilisateurs s'authentifier avec un certificat rsa et une clé google auth.

Je n'ai pas encore ouvert le pare-feu pour le trafic SSH, car je ne veux pas que SSH soit totalement exposé au WAN. Cependant, nous devons être en mesure de pousser et de tirer sans être connectés à un réseau privé virtuel.

Comment ouvrir l'accès ssh au WAN uniquement pour l'utilisateur limité de git, tout en permettant aux administrateurs d'accéder au serveur depuis le LAN ?

Je pense que je devrais chercher quelque chose dans le sens de l'utilisation des groupes de correspondance dans le fichier sshd_config. Comme on le voit dans cette question : " Comment puis-je configurer les méthodes d'authentification par utilisateur d'OpenSSH ? "Quelqu'un a-t-il une expérience dans ce domaine ?


Editar:

J'ai d'abord accepté la réponse consistant à utiliser access.conf pour limiter l'accès à la connexion. Mais les réponses ultérieures indiquent que la même chose peut être réalisée dans sshd.conf soit par une directive match, soit en utilisant la syntaxe username@hostaddress.

À première vue, je trouve plus intuitif de mettre cela dans sshd, et ce sera probablement plus facile à maintenir et à comprendre pour les autres administrateurs. Y a-t-il des avantages importants à utiliser access.conf plutôt que sshd.conf ?

Si je devais classer les options mentionnées ici selon leur caractère intuitif, je dirais : 1. sshd.conf 2. access.conf 3. IpTables

Êtes-vous d'accord ?

5voto

jowi Points 111

Vous êtes à la recherche de pam_access Avec elle, vous pouvez configurer sshd pour accepter l'authentification de tous les utilisateurs du réseau local et de l'utilisateur git depuis n'importe où.

Quelque chose comme :

+ : ALL : 10. crond :0 tty1 tty2 tty3 tty4 tty5 tty6
+ : git : ALL
- : ALL : ALL

dans votre access.conf devrait faire l'affaire

5voto

Kasper Holdum Points 4173

Vous pouvez contrôler l'endroit d'où les utilisateurs sont autorisés à se connecter à l'aide de l'outil de contrôle de l'accès. AllowGroups , AllowUsers , DenyGroups y DenyUsers dans les directives de sshd_config . Ils sont traités dans l'ordre suivant DenyUsers , AllowUsers , DenyGroups , AllowGroups . AllowUsers peut inclure l'hôte ainsi que le nom d'utilisateur ; je pense que les autres n'autorisent que les noms.

Disons que votre

  • LAN est 192.168.1.0/24
  • L'utilisateur git est nommé git
  • les utilisateurs admins s'appellent alice et bob

Dans sshd_config, vous devriez dire

AllowUsers alice@192.168.1.0/24 bob@192.168.1.0/24 git

Alternativement, vous pourriez faire cela avec la Match directive. La directive match vous permet de modifier le comportement de sshd en fonction de certaines conditions, comme l'adresse à partir de laquelle un utilisateur se connecte.

Dans la partie globale de l sshd_config vous auriez

AllowUsers git

à la fin du fichier, vous devez remplacer ceci pour votre réseau local par

Match Address 192.168.1.0/24
    AllowUsers alice bob git

3voto

cjpembo Points 171

Vous pouvez utiliser le fichier sshd_config pour contrôler l'accès par utilisateur/hôte et par réseau ; en outre, vous pouvez utiliser iptables ainsi que tcpwrappers. Je vous recommande d'utiliser tcpwrappers pour contrôler l'accès dans ce cas en plus d'iptables. Utiliser iptables :

Utilisez l'option -s de iptables. Elle accepte une IP de la forme nnn.nnn.nnn.nnn ou avec un masque (nnn.nnn.nnn.nnn/nn.nnn.nnn.nnn ou nnn.nnn.nnn.nnn/nn). Ainsi, pour autoriser par exemple les connexions en provenance de nnn.nnn.nnn.*, vous pouvez écrire

iptables -A INPUT -s nnn.nnn.nnn.0/255.255.255.0 -i em1 -p tcp --dport XXXXX -m state --state NEW,ESTABLISHED -j ACCEPT

o

iptables -A INPUT -s nnn.nnn.nnn.0/24 -i em1 -p tcp --dport XXXXX -m state --state

Si vous ne pouvez pas créer un masque de réseau, je crains que vous ne deviez dupliquer la règle pour chacune des adresses IP que vous souhaitez autoriser à se connecter à votre serveur.

En utilisant des wrappers tcp, ouvrez /etc/hosts.allow pour autoriser l'accès :

sshd: 192.168.0.0/255.255.255.0 1.2.3.4

Au-dessus, il autorisera votre LAN et une seule IP WAN qui est 1.2.3.4 dans ce cas. et ensuite vous pouvez simplement refuser l'accès à tous les autres hôtes.

Pour refuser l'accès :

Ouvrez le fichier /etc/hosts.deny dans un éditeur de texte. Ce fichier contient la liste des hôtes/IP qui ne sont pas autorisés à accéder au système. Pour refuser ssh pour tous :

sshd: ALL

Veuillez consulter les documents suivants Référence de TCP Wrapper sur le site web de RedHat pour plus de détails.

Je vous recommande d'utiliser plusieurs couches de sécurité afin de rendre votre serveur plus sûr et, bien sûr, d'utiliser l'authentification par clé et mot de passe pour ssh.

1voto

Shâu Shắc Points 336

Pam_access pourrait être une option, mais je ne l'utilise que si j'ai besoin de restreindre les accès ssh et console.

Pour ssh, la ligne de configuration suivante devrait fonctionner pour vous :

AllowUsers git *@localhost

0voto

nandoP Points 1961

Il est assez simple de verrouiller la boîte avec iptables..... si tout ce que vous voulez est de supprimer le trafic, sauf pour une seule ip pour la gestion ssh, et le réseau local peut frapper tcp/80 (pour http)

iptables -F
iptables -A INPUT -P tcp -p 22 -s [votre-adresse-ip]/32 -j ACCEPT
iptables -A INPUT -P tcp -p 80 -s [your-local-network-addr]/[your-local-netmask] -j ACCEPT
iptables -A INPUT -j DROP

Je ne sais pas exactement quelle est votre adresse réseau interne / masque de réseau interne, mais si le réseau interne est un /16 et que l'adresse réseau est 192.168.0.0, cela peut permettre à des adresses IP privées non-rfc d'accéder au port 80 (en supposant que cette configuration se trouve sur un périphérique du périmètre avec un trafic IP entrant direct).

vous pouvez et devez avoir des règles iptables plus élaborées / spécifiques, mais au minimum, ceci devrait fonctionner

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X