How To Secure A Linux Server

loay

An evolving how-to guide for securing a Linux server.

https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

yoursunny

Most effective way to secure a Linux service:
systemctl poweroff

关机保平安 poweroff to guarantee peace

root

In case of emergency, one could also tell the linux server to simply: halt

Encoders

is focused on at-home Linux servers. All of the concepts/recommendations here apply to larger/professional environments but those use-cases call for more advanced and specialized configurations that are out-of-scope for this guide

bo hoo billion worth of LES businesses won't be able to use this guide.

to chime in, this bloke have good explanation for beginner stuff and there's also other video about lelnux security if you're interested

Fritz

@yoursunny said:
Most effective way to secure a Linux service:
systemctl poweroff

关机保平安 poweroff to guarantee peace

Real men never turn on their VPS.

xleet

@loay said:
An evolving how-to guide for securing a Linux server.

https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

Are you Anchal, the author? I will try to give you constructive, serious feedback, unlike the posts above.

The document is very long, almost "stream of consciousness", which makes it hard to read. It needs a carefully written overview that explains each of the steps, why they are important, etc. (You include that in each section, but the reader lacks the "big picture.") Some of the procedures are distro-specific. Finally, it seems like overkill for a basic Linux desktop in a typical home use.
-> Who is your target audience? A typical home user? A highly skilled Linux user? I wonder - If they have the technical skills to follow your complex document and procedures, do they need it in the first place?

I would consider dividing your document into a high-level overview document that describes your overall goals, security concepts, and design, and provides an ordered list of the recommended procedures to achieve them. That overview could have links to separate, individual procedures that can stand on their own for those who find them directly. Investing time in a "big picture overview" document would help a lot in my opinion.

loay

@xleet said:

@loay said:
An evolving how-to guide for securing a Linux server.

https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

Are you Anchal, the author? I will try to give you constructive, serious feedback, unlike the posts above.

The document is very long, almost "stream of consciousness", which makes it hard to read. It needs a carefully written overview that explains each of the steps, why they are important, etc. (You include that in each section, but the reader lacks the "big picture.") Some of the procedures are distro-specific. Finally, it seems like overkill for a basic Linux desktop in a typical home use.
-> Who is your target audience? A typical home user? A highly skilled Linux user? I wonder - If they have the technical skills to follow your complex document and procedures, do they need it in the first place?

I would consider dividing your document into a high-level overview document that describes your overall goals, security concepts, and design, and provides an ordered list of the recommended procedures to achieve them. That overview could have links to separate, individual procedures that can stand on their own for those who find them directly. Investing time in a "big picture overview" document would help a lot in my opinion.

No, I am not the author but I found it useful and shared it with the community. It is comphernsive at-home Linux servers secuirty guide as stated but the author.

xleet

I am glad you found it useful. I doubt it will be useful to many others in its current form. It is well-intentioned, but I believe that it needs considerable work to become useful to others. The first task would be to determine the target audience and tailor it for them.

lapua

yabs please

mfvps

only use ufw for security. is it enough?

bliss

Only install software from official repositories will be enough.
No unknown binaries.

emperor

Why you even need to secure it?

deank

Just turn it off.

loay

@emperor said: Why you even need to secure it?

Sorry, I posted this Just relaized that every low end provider is using solusvm and similar control panels.

bobqu

change 22 port
block ping

alt

I watched a course by Trevor Sawler, is pretty nice.
https://udemy.com/share/104vFE3@cWrxF32KmNJGMYlt1kH1qoKC033MTdVg9ft6U56sRFLJ4UxFOBlyBu-pM4z0RWj_9w==/

havoc

I feel like a lot is moving more towards security via isolation & designing stuff from ground up to have very small attack surfaces in the first place.

People seem quite fond of throwing some complex piece of software onto the open web and then trying to patch up all the holes which is quite back to front

ralf

@havoc said:
I feel like a lot is moving more towards security via isolation & designing stuff from ground up to have very small attack surfaces in the first place.

Yeah, I prefer a single service per VM with very restrictive firewall rules on the host so that they can only talk to the places they're intended to.

That way even if the worst case happens and someone finds a remote-code exploit in the service, their payload won't be able to connect anywhere which massively limits the scope of what they can achieve.