Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've had a couple of very strange events in the past month. I'm looking for a secure/sandboxed distro that can reasonably be expected to stop most script-kiddies. I've tried Qubes and liked it, but it's too cumbersome. I've tried firejail in privacy mode but believe that I was hacked/tagged.
Is there a sandbox or distro that is easy and effective? Other things?? Sure would appreciate any ideas....
I think most distributions will be about the same as far as security is concerned with the possible exception of SELinux. You might take a look at that.
Security is less dependent on the distribution and more dependent on your setup. Look and evaluate your users and their memberships in groups. Look and evaluate the permissions for various directories. Perhaps some things should be encrypted - home folders, sensitive files, . . . . For this you might look at veracrypt. More importantly, evaluate the possible threats and set up your firewall appropriately. UFW is a good starting place for most distros, but if you are really concerned about security, learn to program iptables yourself to make sure the rules you need are there. The usual starting point is to deny all input except packets that are part of an existing or related connection and allow all output. Then you modify as necessary for YOUR situation.
Linux is not immune to attacks by any means, but it is less susceptible than other OSes.
Is there a sandbox or distro that is easy and effective? Other things?? Sure would appreciate any ideas....
Your choice is basically Qubes, Tails, or Whonix and don't keep any system info between sessions. The weak point in any arrangement is a graphical web browser. They are poor, almost M$ levels of poor, in regards to planned security. You can help that a little, but only a little, by blocking all scripts with NoScript or ScriptBlock and never allowing exceptions.
What evidence do you have that suggests your machines were cracked? You should try to tie up the loose ends there.
I think most distributions will be about the same as far as security is concerned with the possible exception of SELinux. You might take a look at that.
Security is less dependent on the distribution and more dependent on your setup. Look and evaluate your users and their memberships in groups. Look and evaluate the permissions for various directories. Perhaps some things should be encrypted - home folders, sensitive files, . . . . For this you might look at veracrypt. More importantly, evaluate the possible threats and set up your firewall appropriately. UFW is a good starting place for most distros, but if you are really concerned about security, learn to program iptables yourself to make sure the rules you need are there. The usual starting point is to deny all input except packets that are part of an existing or related connection and allow all output. Then you modify as necessary for YOUR situation.
Linux is not immune to attacks by any means, but it is less susceptible than other OSes.
The details of security and hardening are daunting. Is there a firewalls-for-dummies for beginners? Even better, has anyone built a hardening script for sale?
What evidence do you have that suggests your machines were cracked? You should try to tie up the loose ends there.
1) I had been running a new insall of Mint 18 for a week. It was on it's own disk in a multiple disk system. The other disk was wholly encrypted. During a session, a dialog box popped up and asked me for the password to the encrypted disk.
2) Last night, I was using the machine with a VPN. The VPN shutdown by itself. I was using firefox and firejail in privacy mode.
There are many of that kind, but that's the only kind there are. Once you've read up on firewalls, you realize how irrelevant and useless they are for most use cases. If you've got Linux Mint, then you might start with UFW which is a front-end for iptables. As for hardening, most distros do a good job of not installing anything listening by default. As mentioned above the graphical browser is the weak point these days. X11 itself is something people avoid talking about for the most part, too.
The advice above from Habitual about getting a tablet might be good, if there is a quick way to instantaneously restore it to factory defaults + updates. If you need a real keyboard, a Chromebook in guest mode is supposed to be quite robust insofar as intrusion is unlikely to survive across separate guest sessions.
Quote:
Originally Posted by ftalbot
1) I had been running a new insall of Mint 18 for a week. It was on it's own disk in a multiple disk system. The other disk was wholly encrypted. During a session, a dialog box popped up and asked me for the password to the encrypted disk.
2) Last night, I was using the machine with a VPN. The VPN shutdown by itself. I was using firefox and firejail in privacy mode.
What did the relevant logs say about either event? Just themselves, the two events don't indicate a break-in. Which kind of VPN? Not all are worth having nor provide 'security'
To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.
This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install.
Sounds like these people are wired right. Does BSD operate like ordinary Linux distros? How much of a learning curve is involved in using it?
What did the relevant logs say about either event? Just themselves, the two events don't indicate a break-in. Which kind of VPN? Not all are worth having nor provide 'security'
On the phantom dialog box appearing, what logs would be applicable?
The VPN that shutdown was AirVPN and the logs are erased at shutdown. Would any system logs mirror the internal VPN logs?
Does BSD operate like ordinary Linux distros? How much of a learning curve is involved in using it?
It's similar, but the key thing is that the built-in documentation is really good and you are expected to read it. In some ways it's much easier than GNU/Linux but nothing is done for you. You have to know what you want, including small components, and ensure that they are set to the way you want. There is a virtual machine coming to the next version which will allow you to partially isolate your web browser, but you can get at it in advance by following the snapshots. Once everything is installed and configured, the daily usage will be similar if not identical to GNU/Linux.
If you are interested in trying that route, I'd recommend ordering the final CD set (there won't be more) to get the latest digital signatures for their software and ports, as well as to send some small change their way and keep the server room(s) supplied with bandwidth and electricity.
If you can calmly find your way through their documentation, then it's a good fit. In some ways I prefer it. However, it is first and foremost a full operating system for the OpenBSD developers themselves. The rest of us can still benefit from it.
On the phantom dialog box appearing, what logs would be applicable?
The VPN that shutdown was AirVPN and the logs are erased at shutdown. Would any system logs mirror the internal VPN logs?
There is a program the name of which I've forgotten in Linux Mint and Ubuntu which allows you to click a dialog window and see its Process ID number. From there you can use ps to see it's parent process.
Can AirVPN be set to keep the logs after shutdown, as well as to increase log verbosity, at least temporarily? Does the involuntary shutdown happen often or in a repeatable manner?
Edit: xprop will give the PID of a dialog box, but if I recall correctly there is an easier, graphical program that gives similar information
Last edited by Turbocapitalist; 01-29-2017 at 06:22 AM.
There is a program the name of which I've forgotten in Linux Mint and Ubuntu which allows you to click a dialog window and see its Process ID number. From there you can use ps to see it's parent process.
Can AirVPN be set to keep the logs after shutdown, as well as to increase log verbosity, at least temporarily? Does the involuntary shutdown happen often or in a repeatable manner?
Edit: xprop will give the PID of a dialog box, but if I recall correctly there is an easier, graphical program that gives similar information
Excellent info on parent process ... I had no idea.
The airvpn client can be configured to write hardcopy logs. I'll set that prior to the next run. I've been using AirVPN on-and-off for a year or so. Never have encountered a shutdown before.
When I install a new Linux system, I always begin with a minimal installation: there are no services at all. Nothing is talking to nor listening to the outside world.
The first service to go on is OpenVPN, with tls-auth security enabled, on an undisclosed UDP-port. This, and possibly HTTP(S), is the only outward-facing port ... and you can't detect that it's there. (And it might face a totally different public-IP that appears to have nothing there.)
The next service to go on is apparmor, which uses SELinux-like security features but in a stronger way. When HTTP(S) goes on, it will have access to nothing that it isn't authorized to see, "and there's nothing that Apache can do about it."
Lurking behind this public-facing server are a series of supporting services ... NFS, MySQL ... none of which can be reached from the outside, and none of which can be ssh'd to from the web servers. All of the shares containing web material are read-only. And guess what: there are more OpenVPN tunnels with unrelated keys, also using tls-auth. (The key that gets you through door #2 is not the same as the one that unlocks the public-facing tunnel, and it is nowhere to be found on "machine #1." And so on. If you can't read the OpenVPN config files on #1, which you can't do unless you're root, then you don't even know where on the internal network the UDP port is located!)
All of the SSH connections accept keys ... and only keys ... and require that you have already passed through the necessary tunnel(s) to be permitted even to attempt them. It does you no good to know what "the password" is, because you'll never be offered the chance to give one.
This philosophy is called, "defense in depth." The defenses of the system, beyond the "smooth, featureless wall" that faces the outside, there are a series of "smooth, featureless" defenses beyond it. All of these defenses are based on unique, random, one-of-a-kind cryptographic keys that are thousands of bits long.
And yet, an authorized user, possessing the correct non-revoked credentials at all points, can pass smoothly and easily to wherever they need to go, virtually without (apparent) impediment, and personally-identifiable all the way.
Central authentication mechanisms based on encryption, such as Kerberbos, provide for secure central management of the whole thing, and greatly reduce the chance that a chink in the armor can be "slipped into" some configuration file somewhere.
- - -
Remember that most attackers are opportunists, "playing the numbers" in pursuit of mischief. (Or, they are recently-dismissed employees with a grudge.) The most important consideration is to give them no toe-hold: nothing to scan, nothing to probe, nothing even to find. The next most important thing is to give them a series of similar obstacles even if they do somehow break through the outer gate. A "kiddie" simply isn't going to go that far. He will "splat-witch" against the outermost defenses ... and, move on, quite possibly having never detected that there was anything there to attack. After all, there are millions of potentially-vulnerable IP-addresses out there ... why bother with yours?
Last edited by sundialsvcs; 01-29-2017 at 10:08 AM.
Meh, when I bank or do shady dealings online. A live run in read only mode loaded into ram suffices just fine. I keep a java .sfs and flash .sfs on hand to load up during the live run.
Script kiddies have no clue and I am running in root. Study up on read only file systems.
If wanting to understand where I am coming from. There is no need to run a installed system
for certain tasks in my world.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.