Pushing security to the practical limits (Discussion)

Chat about Linux in general
Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Locked
Aug33

Pushing security to the practical limits (Discussion)

Post by Aug33 »

Hello guys,

Reason for this thread
Writing this topic for those interested (Both for the knowledgeable about Linux security, the non-knowledgeable, and I (somewhat non-knowable about the topic as well)) in hope to start a discussion about the general theme of Linux vulnerabilities and security (of any kind, hack, malware, user stupidity, code error vulnerabilities). You don't have to read it all in this message, just jump in if you got something you would like to add.

If you know similar threads feel free to add links, also again I'm not asking these questions purely for me, but also perhaps others might find answers here useful as well. In general a discussions between those who know, and those who don't.

I put this thread here given that it is not necessarily about Linux Mint, but in general Linux. However it would be sweet to discuss Linux Mint in addition as well.

Cutting to the chase
I'm curious about which extinct you can pull security (when you're not a Linux "guru" or security expert). This means reaching into the realms of the paranoid.
The reason I think it's a good idea to push for maximum security is that attacks and even malware becomes increasingly sophisticated, and as such to stay ahead of the game between the victim and the attacker (In other words, being passive makes you an easy target).
About the malware, as I understand it, it is mostly only possible to appear in Linux if the user themselves install it (I'm aware there are currently very few Linux malware, and none that is not patched, still though, for the sake of the small possibility of malware), or if a hacker plants it after breaking in).

To that end, if I understand it right, Linux is strong against malware on its own (and to some extinct hackers too).
But a user of Linux might sc*ews up and manages to install a Linux malware, or if changing settings in Linux which might make it easier for a hacker to break into the system.

I'm not a believer of the "The most used OS has the most malware" religion without scientific base (an assumption), while to some exthinct it is probably true, but Linux has a large portion of the server market, so it would be weird to say that Linux isn't big enough to get more malware. Inherently as I understand it, it is because how the kernel and system is protected by what one might call a wall analogy (password), seperating the user and user data from the kernel and the system (Hopefully I got that right).
And also given that Linux (at least Linux Mint) out of the box has a different approach to listening to the internet, which only seems to be causing problems if you start installing servers etc., forcing you to install firewalls which is not otherwise needed with Linux Mint ouf of the box. But firewalls do not always protect you, and sometimes hackers can sneak in through the holes in the server firewall meant for otherwise normal traffic. (or malware in windows). (I know very little of this area, I'm quite curious, if anyone feels like elaborating it would be awesome of you).
Another possible here could be a unaware Linux user who installs something that starts listening to the internet without being aware of it (Is that a security problem to begin with?)

Another inherent weakness as far as I understand it, is if the user installs applications with weak code with administrator access (Sudo) (errors, lacking sufficient skills with C++ causing mistakes, memory overflow, etc.), since this creates an opening to the system levels which normally otherwise perfectly seperates the user area and the system area, correct? or is it still secured despite non-malware but weakly written applications?

Other weaknesses that prey on code weaknesses, user unawareness or stupidity, "shortcomings of software design vs. impossibilities to defend against", and so forth?
And finally, how can users not experts in security or Linux security guard themselves better?

I hope someone wants to participate, both the knowable and non-knowable regarding Linux security, as the more discussion on this much needed topic the better.
At least for myself, I feel that good security is a technical monster that I (and I'm sure others too) would like to tame a little more, that only experts can fully handle, and even then it's not always enough (no system is 100% secure, right?).

Thanks for reading, feel free to correct me if I said any nonsense :mrgreen:
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
User avatar
xenopeek
Level 25
Level 25
Posts: 29590
Joined: Wed Jul 06, 2011 3:58 am

Re: Pushing security to the practical limits (Discussion)

Post by xenopeek »

If you want to push security to the practical limits, you readily arrive at security by isolation. Security by "perfect code" that has no bugs that can be exploited is an unrealistic goal. Despite advances in compilers, programming practices, and tools to analyse code or binaries for bugs, most if not all non-trivial programs contain bugs and those bugs can expose vulnerabilities that can be exploited to weaken security.

A step in the right direction are things like SELinux, AppArmor, and similar tools to implement mandatory access control (which means, unless there is a specific rule that "program X is allowed to do Y" program X won't be permitted to do Y). A simpler tool than SELinux and AppArmor is firejail (see http://forums.linuxmint.com/viewtopic.php?f=42&t=202735; firejail allows you to easily sandbox common applications that are Internet connected—and thus the ones most at risk on a home computer). SELinux comes readily installed on Red Hat, CentOS, and Fedora. It's less commonly used on Ubuntu based distros like Linux Mint. Development on SELinux was started by the NSA to secure US Government computers. AppArmor has good support on Ubuntu and Ubuntu's next package management tool (snappy) will integrate AppArmor profiles with each package (or will have a default profile apply). You can also use this on Linux Mint though personally I find firejail easier to use.

Probably the best implementation of security by isolation right now is Qubes OS. Read the intro on their website to get a feeling for what it does. This is the one to try if you are paranoid.
Image
Aug33

Re: Pushing security to the practical limits (Discussion)

Post by Aug33 »

xenopeek wrote:If you want to push security to the practical limits, you readily arrive at security by isolation. Security by "perfect code" that has no bugs that can be exploited is an unrealistic goal. Despite advances in compilers, programming practices, and tools to analyse code or binaries for bugs, most if not all non-trivial programs contain bugs and those bugs can expose vulnerabilities that can be exploited to weaken security.

A step in the right direction are things like SELinux, AppArmor, and similar tools to implement mandatory access control (which means, unless there is a specific rule that "program X is allowed to do Y" program X won't be permitted to do Y). A simpler tool than SELinux and AppArmor is firejail (see http://forums.linuxmint.com/viewtopic.php?f=42&t=202735; firejail allows you to easily sandbox common applications that are Internet connected—and thus the ones most at risk on a home computer). SELinux comes readily installed on Red Hat, CentOS, and Fedora. It's less commonly used on Ubuntu based distros like Linux Mint. Development on SELinux was started by the NSA to secure US Government computers. AppArmor has good support on Ubuntu and Ubuntu's next package management tool (snappy) will integrate AppArmor profiles with each package (or will have a default profile apply). You can also use this on Linux Mint though personally I find firejail easier to use.

Probably the best implementation of security by isolation right now is Qubes OS. Read the intro on their website to get a feeling for what it does. This is the one to try if you are paranoid.
Interesting, so it really is impossible to write perfect code, that is a bummer. Had hoped it would be possible with software that was feature perfected and opensource over a decade or more, can't be helped I guess. It's still puzzling why it is impossible though, but that is just a minor curiosity considering how much else there is to learn for now, I'll read up on it at a later date as I can imagine it probably is difficult to explain in a single forum post.

What about firmware though, would it perhaps be possible to write a system to firmware level to prevent damage to it? For example if we imagine 20-30 years out, perhaps the development of kernels will slow down, would it then be feasible to write it into firmware? Would it add enough to profit security on it, if any security from this approach?
Like the how this company https://phonebloks.com/ who is trying to make module technology such as smartphones and computers. Perhaps feasible if having an entire OS on a firmware module, getting a new kernel module every time it is updated?

I definitely have to check out SELinux, AppArmor and Qubes OS, sounds neat, thanks for the recommendations. I'm not really that paranoid, just skeptical on computer security if you may :mrgreen: I'll check out Qubes OS live boot later tonight, it sounds promising. Although the live boot looks to be in alpha stage, might have to just install it in full first I guess.

Do you know if they can protect you against memory theft, for example if you have resources such as KeePass running open or recently closed it? Perhaps it is possible to prevent this specific issue from happening in Linux Mint as well? KeePass security is my absolute biggest concern.

That is a really handsome collection you made there, thanks man! Just bookmarked them all, so will definitely read it all.
While we are on bookmarks though, my three biggest concerns about security is theft of bookmarks, KeePass from memory, and documents such as pdf, odt/docx and so on. The most trivial is the bookmarks, the other two could hurt much more if stolen.

Do you guys have recommendations on how to make these more secure? I imagine Qubes OS might be a step in that direction, but is it possible to add extra security to these if using for example Linux Mint? Asking now before I finish reading all this, as those three issues are concerns that would make me sleep better at night if it was more secure yet still somewhat practical for daily use.

I was thinking keeping pdf, odt/docx files on a USB-Pen might be an approach, since malware are significantly rare on Linux, and a hacker would have to hack the same time the pen is stuck in the computer, right? (not that it would happen, but who knows, it might just, at least I sleep better) But what about the memory after use? Like with KeePass, memory space seems like to be a major issue against theft?
Ark987

Re: Pushing security to the practical limits (Discussion)

Post by Ark987 »

Before sharing my thoughts I want to share this article first, is about privacy (a bit off-topic) but at some point privacy and security converges.

http://distrowatch.com/weekly.php?polln ... wvote=1#qa
Balancing privacy with ease of use

Trying-to-keep-things-private asks: I've read a lot about Linux distros being more secure than operating systems like Windows since you can review the source code yourself and that makes a lot of sense. There are Linux distros available that focus on security such as Tails and Ubuntu Privacy Remix. Unfortunately they all seem to have cons.

So my question to you: Can you recommend some distros that are above average for security and privacy, but are user friendly and can be used as an everyday OS? I would love for you to recommend some Linux distros that are above average and some that are way above average.

DistroWatch answers: First, I would like to point out that distributions such as Tails, which are highly focused on privacy and on-line security, generally are not designed with regular day-to-day computer use in mind. A distribution like Tails is useful for people who wish to communicate information privately or operate in a hostile environment. Tails is useful for journalists who need to send reports or communicate privately with sources. Such a distribution might also be useful for a political protester. Tails is meant to make communication as private and anonymous as possible without the requirement of installing the operating system on the local computer. This makes Tails a distribution that is far above average when it comes to privacy, but not particularly practical for use at home or the office.

Most of the mainstream Linux distributions have a pretty good security record and try to protect the privacy of their users. Part of that is the nature of open source (it's harder to hide spyware when people can see exactly what the program is doing). Part of what makes Linux better at privacy though is the culture. People who work on Linux (and free software) are usually more interested in personal rights, privacy and keeping their computers secure. Many Linux distributions are not made by corporate software companies and so lack much of the financial incentive to monitor their users.

This does mean that, on the whole, most Linux distributions will be better about not monitoring your behaviour and phoning home with information about you. (Many see Ubuntu's transmission of dash searches to be an exception, but even this invasive feature can be easily disabled in the distribution's settings panel.) Most of the mainstream distributions are also proactive when it comes to fixing security holes which might lead to the operating system being compromised.

I think what you are looking for may depend on just how secure you need to be. If you are a journalist trying to protect a source, then Tails is probably the best tool for the job. On the other hand, most people doing common tasks at home like sending e-mail, browsing the web and making on-line purchases should be fine with something like Linux Mint. For people who want to have a useful day-to-day operating system, but want to be able to lock it down further, then I suggest looking at Fedora. On Fedora SELinux is enabled by default. Plus, Fedora is one of the few distributions to ship with SELinux tools by default. Running SELinux means the operating system can be locked down quite a bit and SELinux, when used properly, can mitigate many security breaches.
Security starts and ends with YOU, I also consider that security is a very subjective and situational matter, it's like asking which is the best Desktop Environment or Linux Distribution.

When you start thinking about security, you start thinking about risks, e.g.:
Aug33 wrote: I was thinking keeping pdf, odt/docx files on a USB-Pen might be an approach, since malware are significantly rare on Linux, and a hacker would have to hack the same time the pen is stuck in the computer, right? (not that it would happen, but who knows, it might just, at least I sleep better) But what about the memory after use? Like with KeePass, memory space seems like to be a major issue against theft?
My first recommendation is to start making various lists about your personal situation:
  • Which type of data are you handling and storing in your devices?
  • Can you identify the risk that may harm your security?
  • Which risks may affect you (be realistic here)
  • Which risks do want to deal with?
Typically you can have this kind of data stored in your devices:
  • Financial data
    Personal health data
    Private individual data
    Military and government data
    Confidential/sensitive business data
You also need to have a clear understanding of these concepts:
  • Data at rest is data that is commonly located on desktops and laptops, in databases and on file servers. In addition, subsets of data can often be found in log files, application files, configuration files, and many other places.

    Data in transit is commonly delineated into two primary categories – data that is moving across public or “untrusted” networks such as the Internet, and data that is moving within the confines of private networks such as corporate Local Area Networks (LANs). A related concept is data in use, which refers to data that is being processed. One example would be a bank balance transaction update, which needs to occur in a secure tamper-proof environment.
An extensive reading for the paranoid home user: https://www.sans.org/reading-room/white ... lies-34675

For any given risk you can do either:
  • Avoided the risk
    Mitigate the risk
    Transfer the risk
    Accept the risk
After you identify your particular situation, you will have to decide what will you do with the identified risks that my affect you.

If we take the example of Keepass and the memory space concern, I would start asking my self some basic questions to bring down the paranoia to common sense:
  • Who uses Keepass?
  • Where is installed?
  • How many people use this computer?
  • How many people can install software in this computer?
  • Is this computer in a secure location? How easy is get hands-on this device? How many people access the surroundings? Who are they?
  • Is all the software installed in this PC trustworthy and vetted?
  • From which sources do the software came from? (3rd party repos, random internet websites, pirated software bought around the corner, etc)
  • Do you use a portable version of Keeppass that you virtually run in any random computer where you go?
For anything to affect the memory space first you need to run a malicious software in parallel to be able to intercept your Keepass data, I think ASLR can help you: https://en.wikipedia.org/wiki/Address_s ... domization.

From here you have to decide what will you do?

A: Avoid the risk:
You won't run keepass in un-trusted computers
You won't install random software from random resources.
You won't share your PC.

B: Mitigate the risk:
You will find tools to protect your system (ASLR, Selinux?, etc.)
Use a good and expensive Antivirus designed for Linux with on-access scanning feature (hoping that the malicious software is in the database definition and is detected when run)

C: Transfer the risk:
Don't use Keepass, use a password vault service that has some kind of insurance (if you lose your precious data you will be compensated for your loss)

D: Accept the risk:
You don't care about that particular risk you will move on with your life because you have more important things to do (take off the tinfoil hat).

An easy way to push security to practical limits is start with improving your physical security, continue with OS hardening then secure your local network and communications. At some point you will have to build your own policies or "code of conduct".

And remember that risks can be accepted as well.

For example I chose not to use full disk encryption because it does not make sense for me. Back in 2003 I built my first PC with my own budget at that time I bought a nice 120GB IDE 7.2K RPM disk, since then I've move like 4 times in the same country and then moved to 2 different countries back and forth today I still have that hard disk, I never lost it, was always in my possession and didn't experience any burglary in any of the places that I lived. I also do not like laptops that much either.
English Invader
Level 4
Level 4
Posts: 247
Joined: Thu Apr 23, 2015 11:53 am

Re: Pushing security to the practical limits (Discussion)

Post by English Invader »

If you want to be really hard-core, you'll stop using Intel or AMD processors and only use ARM because of the following:
http://blog.invisiblethings.org/2015/10 ... rmful.html

The concern here is that the Management Engine (or Platform Security Processor in the case of AMD) gives the processor manufacturer a back door to install any software they like without you knowing anything about it and also leaves a potential vulnerability for hackers to exploit.

My personal opinion is that the only way a hacker would get as far as the BIOS would be if your OS was compromised and as long as you don't click on any dodgy links and password protect the installation/removal of all software you should be safe enough. Any software that AMD or Intel install is most likely there to help the processor interact with the rest of the motherboard and concerns about spyware or hidden surveillance is just paranoid conjecture.

It should also be noted that the author of the report is one of the creators of Qubes OS which provides security by turning every application into a virtual machine which seems like a very slow and inefficient way of managing a desktop OS.
Ark987

Re: Pushing security to the practical limits (Discussion)

Post by Ark987 »

English Invader wrote:If you want to be really hard-core, you'll stop using Intel or AMD processors and only use ARM because of the following:
http://blog.invisiblethings.org/2015/10 ... rmful.html

The concern here is that the Management Engine (or Platform Security Processor in the case of AMD) gives the processor manufacturer a back door to install any software they like without you knowing anything about it and also leaves a potential vulnerability for hackers to exploit.

My personal opinion is that the only way a hacker would get as far as the BIOS would be if your OS was compromised and as long as you don't click on any dodgy links and password protect the installation/removal of all software you should be safe enough. Any software that AMD or Intel install is most likely there to help the processor interact with the rest of the motherboard and concerns about spyware or hidden surveillance is just paranoid conjecture.

It should also be noted that the author of the report is one of the creators of Qubes OS which provides security by turning every application into a virtual machine which seems like a very slow and inefficient way of managing a desktop OS.
That's an interesting topic, I also want to point out that security is by nature too much of black & white, we should try to make conscious decisions about it.

I didn't knew about this I was shocked when I was reading about that. I love to build my own machines, but I'm not familiar with the ARM architecture so I decided to search for ARM motherboards and I found this: http://b2b.gigabyte.com/products/produc ... id=5422#ov
When I scroll down I've read "IPMI 2.0 Web interface", well then I've remember about this: https://www.rapid7.com/db/vulnerabiliti ... uth-bypass

The bottom line, if you are not careful you may be trading one vulnerability for another.

In my personal case I would simply try to mitigate the risk like being very strict about software installation in my PC as you mention.

But, what if you and I decide that from today we will only use x86 Intel/AMD systems for entertainment only. So we will only run Steam and Netflix for example, How much of a harm will be Intel ME or AMD PSP?

Also the trade-off in ARM is the amount of software available in that platform, remember the failure of Windows RT? I also try to avoid doing e-banking on tablets as much as possible, so I really don't know what I'm gonna do :roll:

In any case the author mention that a fix/workaround will be published, in worst case scenario Intel/AMD (hopefully) will release newer sockets with better security controls, nothing that a motherboard/CPU upgrade cannot solve and then we are just doing some sort of vulnerability management which we will have to do the rest of our life on any technology anyway.
uberdorf

Re: Pushing security to the practical limits (Discussion)

Post by uberdorf »

While Linux is great on security, it does have some user caused holes that can cause limited damage compared to the devastating damage it causes on Windows.

ADOBE FLASH Using adobe flash on firefox, for example, opens you up to malware, and even legitimate sites with bad flash advertising can infect your computer. A way to mitigate this is to change the browser setting to "ask to activate" instead of "always activate". I've looked in my logs and seen multiple failed attempts to access root after seeing suspicious advertising on a legitimate site.

ORACLE JAVA Installing real Java on your machine and then downloading suspect jar files can expose your Java installation to malware. Again, without root access the damage is limited to the Java itself, which is bad enough in my opinion.

Also keep in mind that Mint comes with the firewall turned off by default. You need to turn it on with your terminal, or by installing a GUI like GUFW from the repositories.

So if you open email and browse the internet in any OS, you will be exposed to malware. And if you use software with holes in it like mentioned above, and don't turn on your firewall, the risk is greater. The difference is that the malware is probably not going to take over your machine in Linux, unlike Windows. So if you email friends who run windows or connect to a network that uses windows machines, I think it is the right thing to do to scan for malware occasionally. I use ClamTK (beware of using the PUA option though, it can destroy your OS with false positives), and Comodo makes another free antivirus for Linux.
Habitual

Re: Pushing security to the practical limits (Discussion)

Post by Habitual »

Any OS is only as Secure as the nut behind the keyboard.
mike acker
Level 7
Level 7
Posts: 1517
Joined: Wed Jul 31, 2013 6:29 pm
Location: Kalamazoo, MI

Re: Pushing security to the practical limits (Discussion)

Post by mike acker »

Aug33 wrote: {snip}

Interesting, so it really is impossible to write perfect code, that is a bummer. Had hoped it would be possible with software that was feature perfected and opensource over a decade or more, can't be helped I guess. It's still puzzling why it is impossible though, but that is just a minor curiosity considering how much else there is to learn for now, I'll read up on it at a later date as I can imagine it probably is difficult to explain in a single forum post.{snip}
this is always an interesting debate . i think it was Edsger Dijkstra who advocated the all branch tested method of de-bugging as opposed to simple regression testing

I had 1 chance in a career of 40 years to try that -- while our company was pursing an ESOP as part of a larger buy-out . the product we produced ran for 5 years with no PMRs .

this does not help with beginners' errors like the one in HEARTBLEED . As I understand it the programmer in the Heartbleed bug accpted a data-count variable without checking it . A beginner's mistake; and the worse as the variable in question was program control data .

AFAIK only a good peer review helps to find that sort of thing . In the end, the best one can do in "de bugging" is to verify that the program performs to specification . which simply moves the problem detection issue into the specification -- and -- programming "best practice" techniques -- such as validating inputs before using them. a lot of guys who got hit with SQL/Injection or buffer overflow bugs probably wish they hadn't had to learn this the hard way .

Today we face worse problems : we are unlikely to write anything from "scratch" : libraries of tools are used so that mundane chores do not have to be done over and over . and this is in accord with Edsger Dijkstra's Rules for Structured Programming: any one thing is to be defined only once -- and after that referenced -- by macro, subroutine call, &c

which brings us to the Modern Day : Program Quality should be treated as a ZERO DEFECT process. We must all remember: zero defects isn't something we get: it's something we do . In case of the program library and compiler my part should be to verify the digital signature on these components before I use them . way too much corruption today is facilitated by a lack of authentications . As Mr. Reagan said: Trust,-- but verify .
¡Viva la Resistencia!
Ark987

Re: Pushing security to the practical limits (Discussion)

Post by Ark987 »

I can only see one problem with free and open source projects in a voluntary basis, most of the people who are involved are seeking for a "rewarding experience and enjoyment".

When we start pushing security, we will have to face strict rules that must be followed by all contributors. One way to approach this is by following a good guidance as: https://www.owasp.org/index.php/SAMM#tab=Browse_Online

Specifically the "best practices", as you mention: https://www.owasp.org/index.php/SAMM_-_Construction

And the "debugging part": https://www.owasp.org/index.php/SAMM_-_Verification

There are some other important details like the programmer experience that have a greater impact and influence in the quality of the code, but I'm afraid that at some point the project in question could make a turn from being fun and enjoyable to become frustrating and tedious to participate when such strict rules are in place.

EDIT: Expanding a bit more on Heart-bleed.

It is interesting to see how almost every major company in the world and regular Joes at home where using the technology but non of them, not even me, bothered to check on security by at least hiring someone to at least review the code. It is very easy to point a direct finger to the guy who made a mistake.
But, was security ever considered as part of the day-to-day process in that project?

After that big breaking news it turns out that the project was struggling with funds and security testing was just a dream, then suddenly companies realized about something: http://www.bankinfosecurity.com/openssl ... -6893/op-1

Similar thing occurred with TrueCrypt, the main project was not funded, but suddenly a couple of thousands of $$$ was collected to "criticize" , sorry I mean, to do a security audit http://istruecryptauditedyet.com/.
Last edited by xenopeek on Thu Nov 12, 2015 1:23 pm, edited 1 time in total.
Reason: remove quoted previous post; don't needlessly quote posts
mike acker
Level 7
Level 7
Posts: 1517
Joined: Wed Jul 31, 2013 6:29 pm
Location: Kalamazoo, MI

Re: Pushing security to the practical limits (Discussion)

Post by mike acker »

Ark987 wrote:{snip}

For anything to affect the memory space first you need to run a malicious software in parallel to be able to intercept your Keepass data, I think ASLR can help you: https://en.wikipedia.org/wiki/Address_s ... domization.

{snip}
I'm not sure ALSR is really needed all that much in Linux: Linux generally should be running "text" (executable code) on READ|EXECUTE pages and data on READ|WRITE pages . see memset();

if you remember from way back -- the C compiler offered a "compact" model. This created a program in a single 64K page -- called xxx.com type of program -- as opposed to xxxx.exe type of programs . the regular model of C would then provide you with 1 64K page for your executable and another 64k page for your data . remember, in those days, they used 16 bit addressing . working from this pattern it's logical to apply READ\EXECUTE to the code page and READ|WRITE on the data page . clearly if this is done properly ASLR and DEP -- are not needed: an attacker cannot modify the code page -- nor can he execute attack code in a data page . this is an implementation of memory protection .

unless I'm on the wrong track -- memory protection is a key difference between Linux and other software that doesn't bother with such matters.
¡Viva la Resistencia!
topherbeats

Re: Pushing security to the practical limits (Discussion)

Post by topherbeats »

This thread is brilliant. There's not enough Linux-focused privacy info out there nowadays, at least not as "findable" as Mac and Windows resources.

Feedback wanted, please. I just poured this 10,000+ guide out: http://fried.com/privacy -- and I really want to make sure it contains as much Linux-focused privacy tips/tools as it can.

Would really appreciated your thoughts, feedback and suggestions for what to include.

Thanks guys!
Chris
ZakGordon
Level 5
Level 5
Posts: 925
Joined: Thu Feb 12, 2015 11:07 am

Re: Pushing security to the practical limits (Discussion)

Post by ZakGordon »

Just read an interesting article on arstechnica about security and Linux, so thought this might be the place to share that:

'Getting a Linux box corralled into a DDoS botnet is easier than many think':

http://arstechnica.co.uk/security/2015/ ... any-think/
Laptop overheating? Check link here:itsfoss guide . Also a move from Cinnamon to XFCE can give a -5 to -10 degrees C change on overheating hardware.

Build a modern dual-boot Ryzen Win7/Linux Mint PC:Tutorial
Ark987

Re: Pushing security to the practical limits (Discussion)

Post by Ark987 »


Not much to learn from it, if you run a server you have to maintain it, simple as that. Running a server is not just install and forget and that is what happening there, outdated software version with security holes that are never patched or miss configured.

https://www.owasp.org/index.php/SAMM_-_ ... dening_-_1

Also the software mention in the article is a very specialized product Elasticsearch
Locked

Return to “Chat about Linux”