Re: Securing development environment

[Gene Heskett]

On Saturday 19 May 2018 11:29:25 Andy Smith wrote:

> Hello,
>
> On Sat, May 19, 2018 at 12:03:37PM +0200, Hubert Hauser wrote:
> > On 19/05/18 07:29, Chris wrote:
> > > Make those services listen to localhost and do port forwarding in
> > > your SSH client.
> >
> > It might be a good idea but I am not sure whether fail2ban with
> > nginx basic_auth mechanism is a simplier solution. You have not
> > replied me is it. Should I worry about maximum length of passwords
> > (8 characters)?
>
> If the services are only available in localhost then you don't need
> fail2ban.
>
> Fail2ban is a massive hack (spotting wrongdoing by reading logs of
> it after the fact?) so if there is a way to avoid the issue in the
> first place then to me that is preferable.
>
> Cheers,
> Andy

I've had fail2ban running on my machinery here, for close to 20 years.  
Its never triggered. Portsentry, maybe twice in that same time frame.

I also have dd-wrt between my stuff and the internet. Nothing comes thru 
that unless I clear it. That's a comforting feeling...

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Securing development environment

[Andy Smith]

Hello,

On Sat, May 19, 2018 at 12:03:37PM +0200, Hubert Hauser wrote:
> On 19/05/18 07:29, Chris wrote:
> > Make those services listen to localhost and do port forwarding in your
> > SSH client.
> 
> It might be a good idea but I am not sure whether fail2ban with nginx
> basic_auth mechanism is a simplier solution. You have not replied me is
> it. Should I worry about maximum length of passwords (8 characters)?

If the services are only available in localhost then you don't need
fail2ban.

Fail2ban is a massive hack (spotting wrongdoing by reading logs of
it after the fact?) so if there is a way to avoid the issue in the
first place then to me that is preferable.

Cheers,
Andy

Re: Securing development environment

[Andy Smith]

Hello,

On Sat, May 19, 2018 at 07:29:28AM +0200, Chris wrote:
> Make those services listen to localhost and do port forwarding in your
> SSH client.

This would be my suggestions also. Have sshd as the only public
service, and require login by public key.

It's basically a VPN but a little bit less hassle. VPN is the best
solution for this but may be overkill for one developer and one
host. Once your setup becomes more complicated, a proper VPN is the
way to go.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Securing development environment

[Joe]

On Sat, 19 May 2018 12:03:37 +0200
Hubert Hauser  wrote:

> Hello!
> 
> On 19/05/18 07:29, Chris wrote:
> > Make those services listen to localhost and do port forwarding in
> > your SSH client.  
> 
> It might be a good idea but I am not sure whether fail2ban with nginx
> basic_auth mechanism is a simplier solution. You have not replied me
> is it. Should I worry about maximum length of passwords (8
> characters)?
> 

You might consider using a client-side authentication certificate. Here
are some hints:
https://fardog.io/blog/2017/12/30/client-side-certificate-authentication-with-nginx/

-- 
Joe

Re: Securing development environment

[Hubert Hauser]

Hello!

On 19/05/18 07:29, Chris wrote:
> Make those services listen to localhost and do port forwarding in your
> SSH client.

It might be a good idea but I am not sure whether fail2ban with nginx
basic_auth mechanism is a simplier solution. You have not replied me is
it. Should I worry about maximum length of passwords (8 characters)?

--
Best wishes,
Hubert Hauser.

Re: Securing development environment

[Chris]

On Fri, 18 May 2018 23:43:45 +0200
Hubert Hauser wrote:

> Which option is best solution? I am considering use VPN but I am not
> sure is too complicated and that problem can be solved simpler by
> nginx basic_auth mechanism and fail2ban. What are your
> recommendations?

Make those services listen to localhost and do port forwarding in your
SSH client.

Chris

-- 
Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der
Mann, der sich als Stellvertreter Christi ausgibt, von dem er
behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über
Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen
recht.

Securing development environment

[Hubert Hauser]

Hello everybody!

I have been renting a VPS with installed Debian Stretch. I want to host
a my personal website that includes basic functionality as blog, chat,
portfolio etc. Entire website will be written using Django framework and
Python 3.x, HTML5, CSS3, JS programming languages. These parts of that
project will be implemented as Django apps.

I do not want to expose development environment publicly. Experimental
version of this project contains DEBUG variable set to True and other
experimental features that should not be in production because I want to
be able easily detect any bugs. I have also running other sensitive
services e.g. SSH.

My question is how can I restrict access to the administrative services
like SSH, development environment, web console, ZNC admin etc. Of
course, I am using public key authentication on SSH without password.

My proposed solutions:

- use nginx mechanism called basic_auth to restrict access to
development environment, phpMyAdmin, phpPgAdmin etc. (vulnerable to
bruteforce attacks but it risk can be limited using fail2ban although
still weak 8 characters passwords),
- use OpenVPN protocol, configure listening ports of specific
applications and configure properly firewall (I think it would be most
secure choice),
- use proxy server like squid to access administrative services (in my
opinion worst option).

Which option is best solution? I am considering use VPN but I am not
sure is too complicated and that problem can be solved simpler by nginx
basic_auth mechanism and fail2ban. What are your recommendations?

--
Best wishes,
Hubert Hauser.



0x63D031274518F606.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature