New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
God help you...
I shed a tear too.
It's important to have some form of scanner, whilst these wont be active on execution by default you can make it scan once a week / day and send you an e-mail or something with results.
In addition to file-based scanners, you'll need infrastructure / network protection too. The most common attack being bruteforce of your SSH/FTP and other authentication services. Install and configure something like fail2ban to ratelimit and ban after several failed attempts.
Anything exposed externally is a threat and needs to be secured. If you're going to be storing files from untrusted sources (users, colleagues) then you should ensure you have some form of file-based av protection.
Always go for least privs, you shouldn't install your webserver as root for example, this means if the webserver or an underlying application is pwned they then have a much easier time...
Security should be like an onion, multiple layers, even if they penetrate one, there's another to deal with. Unless they're committed they will probably stop after they realize there's a bunch of layers to go through.
Correct setting of access levels for users + Ipseс + iptables + periodic monitoring of logs, and better automation with notification of certain events - that's the security pledge, in my opinion
Besides the fact that only clamav is an AV most AV products have been found to (sometimes) actually create attack surfaces and vulnerabilities themselves.
My view is that a HID (like aide) make much more sense on unix. One reason for not taking AV serious on unix is that clamav is a rather poor AV solution - which I don't say to smear clamav but for the reason behind it: Evidently it's not worth the effort to create a good AV solution for linux; if it were woth the effort the effort would be made.
Another tool in the box is in the fact that it's very easy to just reinstall a Unix system. /home is on its own partition anyway if a system is reasonably set up and nearly all of the personal configuration is in /etc (plus /usr/local/etc on BSD) so reinstalling is a painless process.
Just install updates regularly/automatically, configure newly installed services correctly, use non trivial passwords, and make backups regularly. That's literally all you need to do.
Yeah someone could buy a $1 million exploit and use it on your $15/year VPS and then it would help to be able to detect it and to block all unnecessary connections with a firewall, but realistically that's never going to happen.
What you said applies to desktop as well, or just a server?
The discussion was not about a VPS.
Almost not (to desktop). Just make sure that you don't needlessly run any server software on your desktop.
@scorcher9 Some people seem to be of the mind that if its not open source it should rot in hell. i use linux mint for its choice and flexibility. Windows assumes everything and gives you really 1 option, made by Microsoft, even if its shit.
I dont read most source code for my software because it generally comes from trusted sources or huge "brands". There also the fact that its not PRACTICAL to be a security consultant on every line of code I download nor do I have the time or money to get an audit on everything. So there is a fair bit of trust involved.
I could read the source as I am a web developer, system admin, engineer, etc. I have multiple "hats" in my experience, but I have work to do. That doesn't involve auditing code over paranoia.
I also dont bother too much with my firewall, fail2ban, clamscan etc. Im behind a router which I have root (openwrt) and have a residential IP space. The only realistic way I get "hacked" is by some flash or java drive by on linux, and since I dont work as root, and even if wine ran a virus, its in a virtual folder I can purge and start over and limited permissions.
So overall its not very practical to exploit a consumer linux PC without physical access unless the browser has an exploit or your running an insecure LAMP type setup.
You have to secure a server as its in commercial/data center IP space that is very publicly known with Chinese and Russian bots mass port scanning all the time. The IP's are static so its much easier with a higher rate of success.
So if you want to feel better, use gufw and schedule clamscan. But linux is a minority for hackers as a consumer still. Windows is their pot of gold which is why even a vanilla install has to be fort Knox and even then with it having as many holes as swiss cheese its usually easier to re-image or reformat then clean up.
These are my opinions, hope they help you in your Linux journey
.
@pcfreak30 Thank you so much for your opinion and those are some really great points for me.
I do run a LEMP stack but I run it only when needed and I have it listen to localhost only. So I suppose I am good there.
If there's a file that's suspect, you can use ClamAV to check it. Really only good for checking individual files though.
Linux also has good firewalls, but they need configuration - both options are built in and free - iptables and systemd ... they're highly configurable based on your needs.
For general security, use key pairs instead of passwords. Just a really good general security principle for Linux.
And systemd provides which security service?
No. Reason: That's just a mindless security mantra.
Using key pairs is NOT somehow more secure per se. Plus you pay a price in that your private key is on your disk ready to be picked up e.g. by FBI or burglars or ...
Do I hear "Yes, but one should of course have keys with a password!"? If so I'd like to know how a password is a poor solution for ssh authentication but somehow magically turns into a great solution when securing ones private key. And btw not all PK algorithms (and implementations!) are of equal and good quality.
The correct statement is "Do not use poor passwords particularly not with a server that has a poor password config like storing SHA-1 hashes".
If anyone prefers to use passwords that's perfectly fine as long as the password aren't poor and the server has a proper password config (like SHA-512).
Mainly due to it becoming 2-factor(ish) due to that (something you have (keyfile) + something you know (password))
I get your point but "something I have" quickly becomes "something they have" if the "what I know" is poor. And btw the official and real - and sensible - reason is simply to protect ones private key. So obviously a GOOD password DOES offer protection.
Think of it like this: A reasonable program (like one would hope an openssh client) does not use the password like you enter it but runs it at least through a hash like SHA-256 and the result is then used as key. So, you end up with 128, 256 or even more bits security (comparable to RSA or ECC). The problem is just that the entropy of the hash input is often low in diverse ways. That opens some doors like for example rainbow tables.
TL;DR Use good (long and complex and uncommon) passwords! If you do you are rewarded with security that is in the range of public key crypto.