0

To prevent ssh brute-force attacks on our department servers I can firewall them from the greater internet and allow access from our campus subnet only. I can still get to them from the outside either via VPN or through a centrally-managed gateway host.

But we are running a gitlab server, and git uses the ssh port. Our gitlab users are off-campus, and some are not university staff and do not have access to the VPN or the gateway server. If I set up the firewall as above then I would block them off.

gitlab uses ssh via a single username: git, and all gitlab users' public keys are in the git user's .ssh/authorized_keys with a command= to run a service for the particular git request. Gitlab users do not get shell access. Only us admins can get shells.

Is the best approach to security on the gitlab server:

  • open the SSH port on the firewall
  • disable password logins on SSH
  • run fail2ban with an ssh jail

Is there any other way of blocking access from an IP range only for a section of ssh usernames? ie allow ssh for user git from anywhere, and allow ssh access for any other username only from our campus subnet? I guess firewalls cant do this without inspecting the packets, so maybe its something in the sshd config?

Spacedman
  • 101
  • 4

2 Answers2

0

sshd config has this attribute 

AllowUsers username

You can try.

Burak Talha Bolat
  • 123
  • 1
  • 6
0

Make it Internet facing

For user (and your) convenience, it is possible to run GitLab Internet facing. gitlab.com does so at scale.

Components to secure are sshd and a Ruby on Rails web app.

Disable ssh password auth with the usual openssh PasswordAuthentication directive. GitLab's git user is forced to use gitlab-shell via the authorized_keys it manages. You can restrict allowed key formats and lengths if you want.

Put whatever bans or jails in front of sshd you want. fail2ban, sshguard, denyhosts.

Integration with Rack::Attack allows throttling and blocking on the web app.

And enable multi factor authentication, always a good idea on apps.

With strong credentials and block lists, staying within the intranet does not gain you much security. You can revisit this if your logs show unreasonable threats from the Internet.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34