Hi All
I've a service running on port 8983 of an ubuntu Digital Ocean droplet. In front of that I've got Apache web server forwarding from port 80.
It seams that Digital Ocean droplets don't have any security, which obviously isn't great for production. I'd like to secure my server ready for production, but I'm not really sure where to start.
I'm assuming I at least need to block access to all ports except 80 and the SSH port, but I don't know how. What else do I need to do?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 17/04, Paul Grenyer wrote:
It seams that Digital Ocean droplets don't have any security, which obviously isn't great for production. I'd like to secure my server ready for production, but I'm not really sure where to start.
I'm hosted with linode and they have a fairly useful guide that covers a few things: https://www.linode.com/docs/security/securing-your-server/
I'm sure most of that would apply to Digital Ocean.
Also, here's a good guide to iptables: https://wiki.archlinux.org/index.php/Iptables
In general, if you've got all ports shut down except those you need and ssh is restricted to key-only login (and definitely disallow root login!) then you'll be in a good place.
Obviously, you can take security to the nth degree but the main attack points will be through the software you're intentionally exposing (web applications) and for that... good luck :)
btw, I'm not a security expert ;) Others on the list might be. I take my cue from the IRC channel: "advice given here generally isn't".
Steve
It's probably worth mentioning Ubuntu server uses ufw for firewall related things & 'app armor' replaces SELinux.
I too have a Ubuntu VPS running on a digital ocean droplet (it's running Wordpress, so security is... a concern!). So long as you only permit certain services through firewall & harden SSH you have at least the basics nailed.
If you want to go further, Tripwire can keep track of file changes & fail2ban can block IP addresses that fail to login too often. You could also set up a script that emails you whenever someone logs in so if you're the only one administrating the server you know if there's an unauthorised login.
However, if security is the paramount issue I'd go with CentOS or FreeBSD. I'm using the former for two digital ocean VPSs - one runs self-hosted mail (using iRed Mail), the other runs OwnCloud.
Regards,
Bob
On 22 Apr 2015, at 10:27, Steve Engledow steve@offend.me.uk wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 17/04, Paul Grenyer wrote: It seams that Digital Ocean droplets don't have any security, which obviously isn't great for production. I'd like to secure my server ready for production, but I'm not really sure where to start.
I'm hosted with linode and they have a fairly useful guide that covers a few things: https://www.linode.com/docs/security/securing-your-server/
I'm sure most of that would apply to Digital Ocean.
Also, here's a good guide to iptables: https://wiki.archlinux.org/index.php/Iptables
In general, if you've got all ports shut down except those you need and ssh is restricted to key-only login (and definitely disallow root login!) then you'll be in a good place.
Obviously, you can take security to the nth degree but the main attack points will be through the software you're intentionally exposing (web applications) and for that... good luck :)
btw, I'm not a security expert ;) Others on the list might be. I take my cue from the IRC channel: "advice given here generally isn't".
Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVN2ltAAoJEL/3HArzwYbRwNUP/iMTrBLk5fZFO5iMNsGmBV26 vnvXnsQE3EdqwrByo8X+kADQrsAmrmo/Wk3fQJvqogemSb8pNbV7szcBED7f0Jt1 nUfC6ZsnJeTdxiRxwcw/GpxDhR8+bXrmq76+t7KKxy3isHeWipFaN/jO+Ib8BBIc 7uhIjP506WcUVzgNkisYaKYeclFa6793haI00lLN4RUfYN+blzYWhlOFiJ8mx9Nb YcVJDyb/PPXTwMniKikD9CjjDUn5DEMG7B5JzQOEfCfBVSW+JyOyCXDNKwzliBeg yXbQT7YwvPMw9rXk8rVt8k3a/fkh1VkUQx9FfaBFYfDlL35U5WaSjX+qWh11EnJP ZRZKAwKNVy6SnDKpxRr6EJvh8BrkM31e6NRwlrzsxiTziluxaGJF3xKmYESuN3VC G2L3+jVYMI+mVbFhVLHkNDMLc9ux1SXMUtedQE4+bnZcQT8fkCiPZgOL0oZwiv+t Se70nlvdGY3ub4yPURDz+MpGI3IfcxLoGdaafMwGWMzt8XpXGXCFmBGr3Iblj7vV qKkLgYmRsHOCfZGUYuA9ySekrb55HF5A9Cubz0bFSaI2mpM00tcg2A4PKfI2D+jk K2KdZWLXNqPFYJuQWx7wxp1RKj/RrwwkfQJZdBXd8eKV0xMCP39eE09mpITo1C4R jTebccJqQrorCGaTCsEU =ZGRb -----END PGP SIGNATURE-----
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Fri, 17 Apr 2015 18:45:27 +0100 Paul Grenyer paul@nakedelement.co.uk allegedly wrote:
Hi All
I've a service running on port 8983 of an ubuntu Digital Ocean droplet. In front of that I've got Apache web server forwarding from port 80.
It seams that Digital Ocean droplets don't have any security, which obviously isn't great for production. I'd like to secure my server ready for production, but I'm not really sure where to start.
I'm assuming I at least need to block access to all ports except 80 and the SSH port, but I don't know how. What else do I need to do?
Paul
I have three VPS at DO. You are correct - they are wide open by default. I wrote a blog post[1] back in 2012 which may help. Happy to discuss if you like.
Mick
[1] https://baldric.net/2012/09/09/iptables-firewall-for-servers/
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
Hi Steve
Thanks for the response!
I'm sure most of that would apply to Digital Ocean.
It basically a very basic Ubunto with everything open.
Also, here's a good guide to iptables: https://wiki.archlinux.org/index.php/Iptables
Yep, someone on another list pointed me to ufw which I've not used to configure IPTables.
In general, if you've got all ports shut down except those you need
Yep, this is where I am now.
and ssh is restricted to key-only login (and definitely disallow root login!) then you'll be in a good place.
Need to sort this.
Obviously, you can take security to the nth degree but the main attack points will be through the software you're intentionally exposing (web applications) and for that... good luck :)
Absolutely! This is the first server we're putting into production, so we keen to get it locked down.
btw, I'm not a security expert ;) Others on the list might be. I take my cue from the IRC channel: "advice given here generally isn't".
As always! :-) Many thanks!
I've actually got another issue now with Apache which I'll post about shortly.
Hi Bobby
Thanks for your reply.
However, if security is the paramount issue I'd go with CentOS or FreeBSD.
What is it these offer that is better in terms of security?
On 22 Apr 14:09, Paul Grenyer wrote:
Hi Bobby
Thanks for your reply.
However, if security is the paramount issue I'd go with CentOS or FreeBSD.
That sounds wrong to me, CentOS is community supported rebuilds of RHEL. FreeBSDs security record isn't that great, and if you were going to a BSD for "security" raisens, then OpenBSD would be the generally accepted flavour...
Also, Paul, can you please ensure that you send mail to the list as text/plain only, as the HTML attachment gets the mail stuck in the moderation queue, which generally doesn't get glared at overly often.
Cheers,
Hopefully I can answer both of you here :)
On 22 Apr 2015, at 14:45, Brett Parker iDunno@sommitrealweird.co.uk wrote:
On 22 Apr 14:09, Paul Grenyer wrote: Hi Bobby
Thanks for your reply.
However, if security is the paramount issue I'd go with CentOS or FreeBSD.
That sounds wrong to me, CentOS is community supported rebuilds of RHEL. FreeBSDs security record isn't that great, and if you were going to a BSD for "security" raisens, then OpenBSD would be the generally accepted flavour...
I didn't know security raisins existed. I'll be sure to include them in any end-to-end encrypted slices of fruit cake I find myself producing. Yum! :D
Back on topic, CentOS (to all intents and purposes) is RHEL. The focus is on security and stability over fancy new features, and the tools you use on top to harden it are military-grade. Security patches are rolled out quickly & new improvements only arrive after they've been tested to death. (You could even secure it further with something like Oracle Linux, which is essentially RHEL with a hardened kernel). They've also made a lot of sensible decisions when it comes to default settings etc and it's very easy to scale.
So long as your copy of CentOS comes from a reputable source the only difference should be that you're not paying Red Hat for a support contract. I count DO's pre-built CentOS images as being quite reputable. If you don't, we can agree to disagree on that.
Ubuntu seems to me like a desktop distribution that's trying to behave like a server OS. While you can use it for small web servers (I use it for my own WordPress blog) I question how scalable it is. You may have counter examples to refute this.
IMHO if you want to use a Debian-based server OS I've found Debian is probably a better choice, as it seems to strike a good balance between new features/security patches and keeping things stable.
In the case of BSD: in general you have security systems that go right the way down to kernel level, as (particularly in the case of FreeBSD) their focus is on being "secure by design". There's also an element of security through obscurity you gain by using it too. We could also talk about how amazing BSD server uptime is.
Ultimately it's up to you which BSD you want to use. FreeBSD & OpenBSD would both work in a server setup. I'd question the use of PC-BSD though as that's aimed more as a desktop OS.
I realise with all those areas I've been fairly vague. Hopefully I've avoided starting a flame war! :)
Regards,
Bob
Also, Paul, can you please ensure that you send mail to the list as text/plain only, as the HTML attachment gets the mail stuck in the moderation queue, which generally doesn't get glared at overly often.
Cheers,
Brett Parker
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On 22 Apr 15:17, Bobby Moss wrote: <snip />
Back on topic, CentOS (to all intents and purposes) is RHEL. The focus is on security and stability over fancy new features, and the tools you use on top to harden it are military-grade. Security patches are rolled out quickly & new improvements only arrive after they've been tested to death. (You could even secure it further with something like Oracle Linux, which is essentially RHEL with a hardened kernel). They've also made a lot of sensible decisions when it comes to default settings etc and it's very easy to scale.
See, now I've watched many a times a security update hit Debian well before RHEL or CentOS, so I generally consider Debian Stable as the right way forwards... that and it's not full of rpm hell where actually half the stuff you're running is either self compiled or coming from non-official sources... ;)
So long as your copy of CentOS comes from a reputable source the only difference should be that you're not paying Red Hat for a support contract. I count DO's pre-built CentOS images as being quite reputable. If you don't, we can agree to disagree on that.
Mmmhmm.
Ubuntu seems to me like a desktop distribution that's trying to behave like a server OS. While you can use it for small web servers (I use it for my own WordPress blog) I question how scalable it is. You may have counter examples to refute this.
I don't, and wouldn't, run Umbongo on anything other than a toy machine with out direct interwebnets access.
IMHO if you want to use a Debian-based server OS I've found Debian is probably a better choice, as it seems to strike a good balance between new features/security patches and keeping things stable.
New features don't happen in stable, at all, ever. They might happen in backports, and then you generally want to know that the backport maintainer is sane and timely.
In the case of BSD: in general you have security systems that go right the way down to kernel level, as (particularly in the case of FreeBSD) their focus is on being "secure by design". There's also an element of security through obscurity you gain by using it too. We could also talk about how amazing BSD server uptime is.
Ultimately it's up to you which BSD you want to use. FreeBSD & OpenBSD would both work in a server setup. I'd question the use of PC-BSD though as that's aimed more as a desktop OS.
Both are a PITA to keep up to date, though, Debian all the way! (OK, so there is Debian GNU/kFreeBSD for those that *really* *really* want a FreeBSD kernel :))
Cheers,
On 22 Apr 2015, at 16:07, Brett Parker iDunno@sommitrealweird.co.uk wrote:
On 22 Apr 15:17, Bobby Moss wrote:
<snip />
Back on topic, CentOS (to all intents and purposes) is RHEL. The focus is on security and stability over fancy new features, and the tools you use on top to harden it are military-grade. Security patches are rolled out quickly & new improvements only arrive after they've been tested to death. (You could even secure it further with something like Oracle Linux, which is essentially RHEL with a hardened kernel). They've also made a lot of sensible decisions when it comes to default settings etc and it's very easy to scale.
See, now I've watched many a times a security update hit Debian well before RHEL or CentOS, so I generally consider Debian Stable as the right way forwards... that and it's not full of rpm hell where actually half the stuff you're running is either self compiled or coming from non-official sources... ;)
To each his own! :) You have to have the discipline to stick to known good packages and not add extra repositories (like EPEL). I find this is often down to organisations sticking with ancient versions of RHEL (I know some that still insist on RHEL5) rather than moving up to new versions or hobbyists who like to tinker. I've been guilty of doing it on occasion myself.
That said, RHEL/CentOS 7 now comes with Docker, which removes that temptation as you can do what you like with the container without messing with the host system. Makes app deployment much easier & keeps host secure. It'll be good when this (eventually) becomes the norm.
So long as your copy of CentOS comes from a reputable source the only difference should be that you're not paying Red Hat for a support contract. I count DO's pre-built CentOS images as being quite reputable. If you don't, we can agree to disagree on that.
Mmmhmm.
Ubuntu seems to me like a desktop distribution that's trying to behave like a server OS. While you can use it for small web servers (I use it for my own WordPress blog) I question how scalable it is. You may have counter examples to refute this.
I don't, and wouldn't, run Umbongo on anything other than a toy machine with out direct interwebnets access.
I went with Ubuntu out of laziness, as DO offered a pre-built Wordpress VPS ...built on Ubuntu. Wouldn't have done this myself if starting from scratch :)
That said, as a kind of intro to noobie Linux users trying to create their servers for the first time it's a good learning tool.
IMHO if you want to use a Debian-based server OS I've found Debian is probably a better choice, as it seems to strike a good balance between new features/security patches and keeping things stable.
New features don't happen in stable, at all, ever. They might happen in backports, and then you generally want to know that the backport maintainer is sane and timely.
Exactly. When I said new features, I meant between versions.
In the case of BSD: in general you have security systems that go right the way down to kernel level, as (particularly in the case of FreeBSD) their focus is on being "secure by design". There's also an element of security through obscurity you gain by using it too. We could also talk about how amazing BSD server uptime is.
Ultimately it's up to you which BSD you want to use. FreeBSD & OpenBSD would both work in a server setup. I'd question the use of PC-BSD though as that's aimed more as a desktop OS.
Both are a PITA to keep up to date, though, Debian all the way! (OK, so there is Debian GNU/kFreeBSD for those that *really* *really* want a FreeBSD kernel :))
They could make life easier with pkg. It's very much the advanced/power user option, and I've yet to use it on my own VPSs as it tends to be overkill for my needs.
Cheers,
Brett Parker
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Wed, Apr 22, 2015 at 04:29:12PM +0100, Bobby Moss wrote:
That said, RHEL/CentOS 7 now comes with Docker, which removes that temptation as you can do what you like with the container without messing with the host system. Makes app deployment much easier & keeps host secure. It'll be good when this (eventually) becomes the norm.
Good luck with that approach. Having seen the utter shite that people are creating it scares the crap out of me with regard to security.
Example:
http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-...
Anyone advocating any OS or distro over another because of "security" is quite frankly wrong, they are all insecure and securing them is part of the process of proper deployment.
Adam
On 22 Apr 2015, at 20:53, Adam Bower adam@thebowery.co.uk wrote:
On Wed, Apr 22, 2015 at 04:29:12PM +0100, Bobby Moss wrote:
That said, RHEL/CentOS 7 now comes with Docker, which removes that temptation as you can do what you like with the container without messing with the host system. Makes app deployment much easier & keeps host secure. It'll be good when this (eventually) becomes the norm.
Good luck with that approach. Having seen the utter shite that people are creating it scares the crap out of me with regard to security.
It's not an insurmountable challenge. For enterprises there's systems like Puppet or Ansible that can handle deployment of docker containers, app configurations and maintenance of system components. Theory is you keep all instances following consistent security policies and up to date, and any new instances are just as secure as what other in production systems.
Admittedly I'm coming at this as a software engineer rather than a sysadmin. It's only through experience I've learned I can't always have the "new shinies" I want to use! lol
Example:
http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-...
Anyone advocating any OS or distro over another because of "security" is quite frankly wrong, they are all insecure and securing them is part of the process of proper deployment.
Of course. But some systems have fewer holes & better commitment to patching vulnerabilities than others. While in theory you could secure any system, I don't think it's invalid to advocate systems that require less work to harden. :)
Adam
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On 22 Apr 2015, at 21:51, Bobby Moss bobbyjmoss@me.com wrote:
On 22 Apr 2015, at 20:53, Adam Bower adam@thebowery.co.uk wrote:
On Wed, Apr 22, 2015 at 04:29:12PM +0100, Bobby Moss wrote:
That said, RHEL/CentOS 7 now comes with Docker, which removes that temptation as you can do what you like with the container without messing with the host system. Makes app deployment much easier & keeps host secure. It'll be good when this (eventually) becomes the norm.
Good luck with that approach. Having seen the utter shite that people are creating it scares the crap out of me with regard to security.
It's not an insurmountable challenge. For enterprises there's systems like Puppet or Ansible that can handle deployment of docker containers, app configurations and maintenance of system components. Theory is you keep all instances following consistent security policies and up to date, and any new instances are just as secure as what other in production systems
I probably should have mentioned here that some work needs to go into packaging, maintaining & testing components in this way internally. Your link talks of downloading containers & binaries from unknown sources. That's certainly not a good idea!
Admittedly I'm coming at this as a software engineer rather than a sysadmin. It's only through experience I've learned I can't always have the "new shinies" I want to use! lol
Example:
http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-...
Anyone advocating any OS or distro over another because of "security" is quite frankly wrong, they are all insecure and securing them is part of the process of proper deployment.
Of course. But some systems have fewer holes & better commitment to patching vulnerabilities than others. While in theory you could secure any system, I don't think it's invalid to advocate systems that require less work to harden. :)
Adam
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Wed, Apr 22, 2015 at 09:51:55PM +0100, Bobby Moss wrote:
It's not an insurmountable challenge. For enterprises there's systems like Puppet or Ansible that can handle deployment of docker containers, app configurations and maintenance of system components. Theory is you keep all instances following consistent security policies and up to date, and any new instances are just as secure as what other in production systems.
I work in a reasonably sized enterprise using technologies such as this, I'd say that there is a good middle ground but just pointing at new technology like this and using as is will just result in disasters.
The theory around lots of this stuff is utter nonsense, it still requires people who know how all the components hook together to make it work.
Adam
On Wed, Apr 22, 2015 at 09:58:19PM +0100, Bobby Moss wrote:
I probably should have mentioned here that some work needs to go into packaging, maintaining & testing components in this way internally. Your link talks of downloading containers & binaries from unknown sources. That's certainly not a good idea!
Unfortunately most software engineers don't understand the full system end to end and what security means. When the build scripts for the software you might want to use do that then you're already screwed. This is really a good example of why you shouldn't let engineering lead on deployment.
There's a middle ground but blindly following what people say is a very very bad idea (as is suggesting different operating systems based on how secure they are, they're all insecure until you build some security into your system).
Adam
On 22 Apr 2015, at 22:18, Adam Bower adam@thebowery.co.uk wrote:
On Wed, Apr 22, 2015 at 09:58:19PM +0100, Bobby Moss wrote:
I probably should have mentioned here that some work needs to go into packaging, maintaining & testing components in this way internally. Your link talks of downloading containers & binaries from unknown sources. That's certainly not a good idea!
Unfortunately most software engineers don't understand the full system end to end and what security means. When the build scripts for the software you might want to use do that then you're already screwed. This is really a good example of why you shouldn't let engineering lead on deployment.
Hear hear on your other response btw. In response to the above as a software engineer the information we have to go on is what the designer or client has told us. If neither have spoken to the Ops teams/sysadmin(s) about what's supportable and secure then it can lead to the problems you mentioned. The moral of the story is everyone from end to end has to work together to build good systems.
There's a middle ground but blindly following what people say is a very very bad idea (as is suggesting different operating systems based on how secure they are, they're all insecure until you build some security into your system).
Fair enough.
Adam
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 22/04, Adam Bower wrote:
Anyone advocating any OS or distro over another because of "security" is quite frankly wrong, they are all insecure and securing them is part of the process of proper deployment.
Seconded. I don't get the distro-hopping thing at all. All the tools are generally available for all the distros. Learning how to use them is the main thing.
Steve
-
Adam Bower -
Bobby Moss -
Brett Parker -
mick -
Paul Grenyer -
Paul Grenyer -
Steve Engledow