Simplify and orchestrate VPN networking and configuration tasks.
Post Reply
d.mauri
Novice
Posts: 5
Liked: 1 time
Joined: Jul 14, 2014 10:09 am
Full Name: Davide Mauri
Contact:

[Veeam PN] Protecting the web interface from brute force attacks?

Post by d.mauri »

Hello everyone, I've not found any threads covering this, just a simple thread here about hardening, which unfortunately is not what I was looking for.

I've deployed Veeam PN manually, using the Ubuntu repositories and configuring many things by hand on the instance, such as proper split tunneling with custom instructions in the /etc/veeampn/EndpointOVPN.cfg file, installing fail2ban to lock malicious clients out, disabling password authentication via SSH, and so on.

I also opened the web interface to the internet so that I could get a real SSL certificate from Let'sEncrypt, but now I'd like to properly protect it from brute force attacks. Tailing /var/log/auth.log I mainly see two types of error:
  • Code: Select all

    Apr  7 19:22:11 hrmilvpn veeampnd: pam_unix(system-auth:auth): check pass; user unknown
    Apr  7 19:22:11 hrmilvpn veeampnd: pam_unix(system-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
    and
  • Code: Select all

    Apr  7 19:19:36 hrmilvpn veeampnd: pam_unix(system-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=***
I wanted to create a custom jail in fail2ban, but since the rhost field seems to be always empty, I think that locking out a malicious host trying to access the web interface from the internet is not possible.

Is there a way to achieve what I have in mind, or is someone trying to do the same thing?

Thanks and best regards.

Davide

anthonyspiteri79
Veeam Software
Posts: 718
Liked: 181 times
Joined: Jan 14, 2016 6:48 am
Full Name: Anthony Spiteri
Location: Perth, Australia
Contact:

Re: [Veeam PN] Protecting the web interface from brute force attacks

Post by anthonyspiteri79 »

Hey there Davide, first of all great work on taking VeeamPN and modding the underlying configuration to suit your needs. VeeamPN is provided as a free easy to deploy and configure tool to our customers and as such any custom configurations done outside of the scope of official support.

Be interesting to see if anyone has any further ideas on how to achieve your outcome.
Anthony Spiteri
Senior Global Technologist, Product Strategy
Email: anthony.spiteri@veeam.com | Mobile: +61488335699
Twitter: @anthonyspiteri

AVasilyev
Veeam Software
Posts: 70
Liked: 14 times
Joined: Jan 01, 2006 1:01 am
Contact:

Re: [Veeam PN] Protecting the web interface from brute force attacks?

Post by AVasilyev »

These days the usual recommendation would be to whitelist IP addresses to the management port (443) and to ban everybody else.
If you need to administer VeeamPN from different locations - please create an OpenVPN endpoint profile for your computer and connect to VeeamPN VPN network first - so you can access management UI by VeeamPN internal address https://10.210.0.1

Vanburen
Lurker
Posts: 2
Liked: 2 times
Joined: Mar 30, 2020 10:27 am
Contact:

Re: [Veeam PN] Protecting the web interface from brute force attacks?

Post by Vanburen »

If the only reason to have the web interface open to the internet is Letsencrypt, I would consider using the DNS-01 challenge [1] instead, then you should be able close off HTTP.

[1] https://letsencrypt.org/docs/challenge-types/

d.mauri
Novice
Posts: 5
Liked: 1 time
Joined: Jul 14, 2014 10:09 am
Full Name: Davide Mauri
Contact:

Re: [Veeam PN] Protecting the web interface from brute force attacks?

Post by d.mauri »

Hello everyone, and thanks for the feedback on this.

Unfortunately, as far as I know, the DNS provider does not support API invocations, so the DNS-01 challenge is out of the question. AVasilyev suggestion is interesting, though, since I'm spinning up Let'sEncrypt just for cert renewals.
So... I could leave HTTP open to the world, so that certs get renewed, and HTTPS opened only for specific IPs, so that when Apache is running, everything outside those IPs gets blocked out. Maybe it was not exactly what you were suggesting, but nice suggestion anyway :wink:

As for the OpenVPN profiles, we already have them in place, but if we're just accessing the service from inside the local network or through VPN, it kind of loses the "need" of being accessible from outside with a real SSL certificate.

Anyway, thanks again and best regards to all of you.

Davide

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest