Quote:
Originally Posted by ness2616
My friends and I have been using ownCloud for a few weeks (..)
|
First of all you want to start assessing system security
as you build the system, that is, before you put it to production use.
Quote:
Originally Posted by ness2616
Would anyone (..) please help us to evaluate the security of our OC server?
|
Your notes revolve mostly around
one single service, so that would be second: assess the security posture of
the whole server.
Quote:
Originally Posted by ness2616
(..) desktop computer running Linux Mint, to act as the server (we like GUI).
|
Ask yourself why you would need that? One of the reasons the majority of servers runs headless is that once configured they don't need adjustments that can't be made from the command line. Secondly the less software is
installed and used the smaller the exposed attack surface becomes. (Don't think of only open ports but also users that have shell access.) Third the less software a server needs to run the more resources can be spent on what actually matters like performance. Xorg plus a Desktop Environment basically is a resource hog. Finally the (unnecessary) use of Desktop Environments or web-based management panels or any such crutches (with all due respect) often points to a lack of practical admin knowledge. That can (and should!) be remedied as any machine you admin and connect to the 'net is your responsibility.
Quote:
Originally Posted by ness2616
(..) OC server-side encryption; (..) I think that this is strong enough security to protect our personal files and data from the mean streets of the internet
|
If you mean disk encryption then, together with SSL usage, you've covered two thirds: data in transit and data at rest. However what happens if I gain access to the Live server? Could I find and open any document? Would I be able to find (personally identifiable?) information which would allow me to gain access to other (financial) services?
Quote:
Originally Posted by ness2616
Is there anything else we could do to harden the server and make it less likely to be hacked or accessed by others? (..) Any recommendations for free server auditing software?
|
Before I list things please remember that your fellow LQ members will help out where they can but ultimately you are responsible for making this work. (This also includes determining if what information you get from documentation, web log or forum posts is current, if it is a best practice or not, etc, etc. If unsure: ask!) Also realize that the most important cause for breaches of security is (IMNSHO:
criminally) negligence on the part of server admins: not knowing what they run, no server hardening and auditing, bad access restrictions or configuration decisions, no software updates, allowing others to run outdated or questionable software, etc, etc.
- Read the Linux Mint (security?) documentation and since Mint is based on Ubuntu which in turn is based on Debian the
Securing Debian Manual,
- install only what you need right now, that is, remove (or at least disable) any ('net-facing) services you don't need,
- install a file system integrity scanner like Samhain, AIDE or even tripwire,
- before you go harden the server (further) run GNU/Tiger and act on its reporting,
- ensure logging is enabled for all services and
act on daily Logwatch reporting,
- ensure user access restrictions apply to all levels,
- make regular (off-site!) backups,
- run a copy of the OC machine on another machine (virtualization) to test software updates and configuration changes before putting them into production,
- run OpenVAS
from a remote machine or use SecuritySpace online free basic audit or equivalent,
- most importantly remember that security is not a one off but a continuous process of auditing and adjusting.
*Bonus points if you know what the SANS Reading Room, OWASP and the CIsecurity Linux profiles contain.
Quote:
Originally Posted by Habitual
Code:
deny from all
allow from ip0
allow from ip1
...
|
Agreed. White listing is an effective way to regulate access (and combined with say port knocking also easier to manage). But why not start with an ipset of allowed IP addresses or ranges in the mangle table? That would be better IMHO as it would prevent malicious traffic from even reaching the application level (which is better performance-wise too).
Quote:
Originally Posted by ericson007
Also if you can get selinux running if not already, that will further protect the server if hacked not to be able make use of other services as an attack vector.
|
Agreed. The SELinux default targeted policy is especially aimed at 'net-facing services
Quote:
Originally Posted by ericson007
The most important is of course to monitor your logs,
|
Agreed. You don't know what you don't log!
Quote:
Originally Posted by ness2616
I definitely agree about monitoring logs and will have to learn to configure e-mail notifications for intrusion detection. I think that's an option in Fail2Ban. Fail2Ban has honestly been very tricky for us to set up and configure properly. Still haven't got it working, which is too bad, because I think it will offer a huge increase in protection just by limiting login attempts, its other features notwithstanding. It's just not intuitive to me yet.
|
Actually having fail2ban or equivalent tools send emails is about the most useless function on offer for the simple reason that if you receive emails
you're supposed to act on them immediately. Given that you may not like to admin the machine 24/7, plus more importantly, fail2ban is about
active response (meaning by the time you read that email fail2ban already did its job) I disable it everywhere and just use syslog reporting via Logwatch. Secondly if you limit the amount of exposed services and go for white listing you reduce what fail2ban has to watch. Also because of the templates it comes with I contest it's hard to set up: do give an example of what you tried to configure to illustrate your problems?
Quote:
Originally Posted by ness2616
Sometimes I feel like the server is secure, but then I read more security articles, and I feel like I'm way out of my element and that server security is unattainable!
|
One of the things that makes computing fun and easy is that it's basically binary: conditions can be tested to be true or false, meaning something is secure or it is not, so there's no need for fuzzy human interpretations like "think", "feel" or "worry". That said if you're new to admin work or if you don't harden servers often then getting a clear view of the steps to take and in which order may seem like a daunting task. With the information posted in this thread you should have everything to start your journey the right way. If anything is unclear: just ask.
Have fun!