All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
really, aren't most servers full of security holes?
I created a pretty simple JVM-based application to run on a VPS. While programming the app was pretty simple, deploying it was not. I wanted to achieve 2 things: a secure system and a (mostly) automated deployment. Long story short... became a mini-expert on Ansible, Docker, web server, while minding lots of security concepts like disabling root logins, requiring key exchange, redirecting ports, keeping passwords/secrets out of source, shutting down unnecessary services, etc.
The point is, I know how much work I've done, and I still feel my server isn't all that secure for a variety of reasons. The guides around the web vary in comprehensiveness and in details. I doubt that many VPS customers have dedicated as much time to locking down their server... and many are running far more services than my 1 app. Which means that most probably have enormous security holes. Agree or disagree? Or am I the one doing it all wrong?
Comments
No public ip
Yes, my servers are full of security holes.
However, if you attack my server, I'll take away your cookies and tell Santa to put you on the naughty list.
The following IPs please stop attacking my servers. You have been warned.
https://www.dailymotion.com/video/x1azaw
Lots of one-man operations probably have pretty insecure servers/services, yeah. They learn over time by experience, though, figuring out they should try harder every time someone successfully breaks in. Hopefully they aren't doing anything too valuable.
Bigger companies have experts securing the servers (the work you did only needs to happen once and can be applied to a large number of servers), auditing the code, looking for attempted exploits, monitoring logs, tracking for intrusions, regularly scanning for service vulnerabilities, etc.
A few advices: fail2ban, iptables blocking all the incomings, knock and door to let you in and 2 step verification for ssh login.
Ipset + blacklist or even better white list + iptables + fail2ban is usually fine. Number of "fail2ban bans" has been decreased a lot since I set up a decent Ipset blacklist...
SSH keys, Fail2Ban, IPtables to whitelist only IPs you know, etc.
Yes, sorry, I was talking about solo/small companies, the typical customers of the VPS providers on this site. For sure, major enterprises that can support full-time IT teams will have better security... although, those companies are also much more likely to be attacked, and it seems like the attackers are reasonably successful.
The more holes you have, the more aerodynamic it is.
In the end, you just doge these attacks.
Security should be baked into every guide for how to setup a server as well as every guide for how to code. When it becomes the baseline, it's no longer extra work.
In theory, yes, but premise error. Actually having good and "secure" configs is NOT making a system secure, it merely helps to not make it even worse (in terms of security) than it already is.
The real problem is largely out of reach; it starts with the hardware (both X86 and Arm are a security nightmare, and keep in mind that there actually are at least dozens of CPUs and MCUs in a server systems) and it reaches up over basically all commonly used OSs and up to pretty much all libraries and applications. One may have (or be able to get) the source code of much of those but evidently that's worthless. Remember "1000 eyes" and Heartbleed? Actually there were not even 4 eyes with capable minds behind the eye balls - although at least 2 of those eyes had the official task to look at the code and check it.
And even the vast majority of the developers behind all that code could not make it more secure. In fact most of them chose languages that make bugs likely and solid code unlikely and 95+% (realistically more like 99%) couldn't use real analyzers even if they had them.
Wrong. It's always extra work, and in fact rather complicated work that also requires knowledge many simply do not have and can not easily grasp.
Another very major problem is the "fun" attitude. Extremely few actually enjoy proper software development, which is very much about knowledge and discipline and very little about fun.
TL;DR No, sorry, you can't make your system secure with proper config and some scripts (like fail2ban). What you can - and should! - do is to not make it worse than it already is.
Also note that the best one can achieve, incl. "security experts" at large companies, is to not be easily hackable by script kiddies and 2nd and 3rd rate attackers. NSA and first rate attackers is something almost nobody, incl. large companies can defend against.
Also backups are important, really important.
This is true only in a sense of things you cannot control. There is no point in dwelling on 0days that are discovered once in a blue moon. I am more than aware that pretty much everything is inherently insecure, but from the perspective of a developer there are plenty of actionable things that can be done to make basic vulnerabilities much less likely.
Security in web applications is very different from the typical stack/heap vulnerabilities you get in C. This is what I was referring to, basic security against XSS/CSRF/SQLi/IDOR would be effective against the vast majority of web vulnerabilities discovered to date. Yet most courses don't teach you anything about these basic vulnerabilities.
I maintain that it's not hard to know the basics of web security, and in nearly every case a basic understanding of web security is enough to protect you against nearly every single attack.
I do heavily advocate for not using C/C++ whenever you can. Languages like Rust and Go are more than fast enough for pretty much every purpose.
There is nothing that is "properly secure" but it's completely useless to be putting a rant about it on a thread about server security, if it's something nobody here can fix then why even bother.
Even humans are full of holes.
Which one?
One can have access to the source code of multiple, incl. significant, OSs, as well as to diverse software of major importance. So your "cannot control" is nonsensical.
Cute. Sorry but web applications are usually neither developed by software engineers nor are they all software (on servers).
That may or may not be the case but the title of this thread (and accordingly my post) is not about web stuff but about servers in general.
Hahaha, you really seem to be one of those web developer guys ...
Well, a quite considerable part of my job is exactly that. Plus, a guy putting C, C++, Rust, and Go next to each other arrogates to judge whether my post was a "rant" and "useless"? Seriously? Congrats, in case your goal was to confirm and actually worsen my already very negative professional view on "web developers" you succeeded.
I'm surprised you still have IPv4 enabled on your servers. Or sshd.
Anything to share with IPv6 addresses or you don't receive any attacks with v6?
Read this to make it more stronger
https://beginnercoder.quora.com/Why-are-programmers-so-well-paid-even-if-that-job-is-pretty-easy-Im-also-a-programmer-its-easy-68
@jsg
So you're just gonna single handedly fix all the security problems in all the software you use? Be my guest!
Ah so you subscribe to the wonderful belief that people who make websites aren't engineers. Google doesn't seem to agree with you on that. but if you really want to explain why this is the case, I'd love to hear it. I gave one example here but if you do any amount of searching you'll find plenty of "web" software engineering positions from large tech companies.
Well you haven't really justified why your rant was any more useful than a rant about something nobody can fix. "Oh you have access to the source code" is no justification for why someone should fix every memory corruption bug that exists. How useful is it for anyone?
"I wOnT TakE OpInIoNs FrOm a WeB DeVeLoPer" is a crappy argument. You make it because you have no other way to explain why or how someone is supposed to do anything about the problems you propose. Instead, you bring up the fact that the world is insecure purely so you can drag in your field of work and rant about how terrible the state of the world is. If you really believe that what you said is at all actionable by anyone here, then find that person and get them to talk about why its so useful.
For gods sake OP mentioned specifically that their program runs on the JVM, its not rocket science to think that they can't fix security issues in the Linux kernel.
I think its clear to anyone who's actually read the OP's post that he isn't talking about low level memory corruption or CPU architecture exploits. It isn't difficult to make a reasonably secure program that runs on the JVM or any other high level language for that matter.
Nice. although (1.e.) is a bit off because software engineers do not build mathematical models but they work with them and often implement them.
(In my eyes funny) side note: analysis and verification, mostly static but also dynamic, may look somewhat like code but it's basically pretty much pure math (with a notation that is halfway amenable to software engineers). And that (being pretty much pure math) is in fact a, probably even the, reason why analysis and verification are done rarely/only by very few developers.
"Can control" != "fix all problems."
Your assertion to which I responded was
.
(a) Hahaha!
(emphasis mine)
(b) Just because some company calls someone "engineer" that doesn't make him one.
I've had it with you. I do not have to justify anything based on some idiot willy nilly and cluelessly calling it a "rant".
That's not what I said. In fact I will take opinions from a web developer if it was about crapscript, css, etc - but not on matters that evidently are far beyond his reach.
(a) Java is very different from C in quite a few regards, some of them critical wrt many linux problems.
(b) You of course don't know it but actually Java has and supports some approaches and tools for formal verification.
(c) OP expressly said "I wanted to achieve ... a secure system" (possibly with some Java application running on it)
You are so utterly clueless that it almost hurts.
This morning there were a few machines requesting my homepage repeatedly.
The following IPs requested the homepage more than 1000 times within 3 minutes.
Three of them are IPv6.
Please stop this behavior or I'll delete your Fortnite.
Moreover, a few IPs (all IPv4) are somehow causing Caddy to log error
aborting with incomplete response; write: connection reset by peerand occasionally crash.As a result, my website was offline intermittently for 40 minutes.
The last two are now prohibited from visiting my website.
If the IP owner is reading this, please write an apology letter and I'll unban you.
In a number of jurisdictions, Engineer is a protected legal term (like doctor or lawyer). Engineers have received training in their field, have code of ethics, apprenticeship shit, and legal liability. This may not be completely accurate rough description, but it's a big difference between someone who is doing web development without prior education and one that is a member of a professional Association (ie, IEEE).
I'm not an engineer, but I work in engineering. I can do the exact same thing as an Engineer, just not as an Engineer. I'm a "Technologist" just like I'd argue most software is done by "Developers” and not "Software Engineers".
Edit: you'll note Google specifically said minimum requirements was a Bachelor's degree but they really want masters and PhDs engineering their shit. I wonder how the self taught get hired at Google, probably solving one of those hard billboard questions.
To be fair, most Unix-derived (and z/OS-derived if you to be pedantic) operating systems are not "full of security holes" out of the box. Not to say that over the last 50 years there haven't been some, but if you put one on the internet and let it idle for a year, it's unlikely to be compromised.
Note that in this scenario I'm assuming:
OTOH, if you install $RANDOM_WEB_APP from github, all bets are off.
Even then, what is "insecure"? Someone can remotely get root? Someone can read SSL traffic and decrypt it? Someone with physical access to the datacenter or hypervisor can silently enter your VM?
Over the hundreds if not thousands of VMs I've put on the Internet in my life, the only time I had any kind of security issue was with a cacti monitoring 0-day, and I shouldn't have had it internet-exposed to begin with.
Of course, the only issue that I know of...
That is problem number one. '(widely or at all) known vulnerabilites' != 'existing vulnerabilities'
Depends on the definition, but usually when I dig deeper I find that almost always "security hole" is understood to mean "dangerous or well-known vulnerability". I can understand that but it's wrong.
Secure (in that context) means the absence of vulnerabilities or at least the absence of known vulnerabilities.
Also, warning: The question "what can evil guys do with a vulnerability*" is only relatively losely related to "is my system secure?".
The sad fact is that most OS, incl. all more or less widely used ones, do have thousands upon thousands of bugs, most of which don't open significant vulnerabilites, but keep in mind that only a single one is needed to create very significant damage.
Even more sad is the fact that we still are at a relatively early stage wrt. formal verification, let alone actually usable tools plus only a frighteningly small part of developers master and use more than some (rather primitive) clang compiler switches. GCC, for instance, had the first rudimentary static analysis only in v. 10 (current is 11.1).
Another important factor are languages themselves. The vast majority of PL didn't pay any attention to "safety" (a rather lose term but I guess it transports well enough what I mean) and those that do are unwieldy and/or complex and/or cumbersome and/or rather exotic and/or largely focusing (too) tightly on one, e.g. the space domain (like Rust).
Which basically translates to even if more software engineers had the good will they would have to walk a very bothersome road and be put back again and again by problems.
And finally add to that that the relevant knowledge is taught in rather few uni courses (competently).
Caddy has always kinda buggy and unstable, try using nginx. Yes, it's written in C and @jsg wouldn't approve, but it's HTTP protocol handling is more robust and doesn't crash as much as Caddy.
FWIW: Nope, I'd take nginx over caddy every day and twice on sundays.
There is no security baked in because the leading distributions are heavily influenced by the 3LAs.
The distributions put out by Redhat, Debian and Ubuntu should come with the security protocols and the administration tools baked in from the very start, instead of expecting users and server administrators to do it themselves.
There has been no genuine commitment to make security administration easy from the early times. In the past the first thing you did when installing a Redhat or Centos system was to disable SELinux because it frustrated everything. These guys who claimed to be serious about making Linux secure didn't even seem to have the sense to put in easily accessible administration tools.
20 years on nothing has basically changed, because there is no genuine commitment right from the very top.
It is silly to expect the 3LAs who are among the biggest IT spenders (they carry a lot of clout) whose job is to spy and monitor everything there is to support the development of configurations that frustrate them in their ability to do their job.
When the NSA offers cryptographic standards who do they think their fooling and why i is the Linux community silent on their obvious deception?
You should check the
systemd analyze-securityand theProtect*=primitives. It is notoriously easy to enable, although systemd got a lot of hate because Linux people generally don't like easy stuff and insist on doing everything the old way.This is probably the only time you're correct, but all the better cryptographers are working for the government, and you'd need to get the same amount of clout as the government to ask private companies to implement your standard.
Wtf are you talking about? I think you just love saying "3LA". But feel free to post the number of lines of code committed by the "3LA". It's like you're thinking the Snowden docs didn't change anything.
What?
Dude, this is done because we don't RTFM. If you're a paid server administrator and not using SELinux, you're probably incompetent. Security is hard, expecting it to be easy means you don't understand the problem.