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
None for me. Reverse Proxy or Cloudflare mean my backend servers are never touched unprotected. Easy way to keep out unwanted people
Personally, I keep several "honeypot" VPSes detecting attempts to connect to unadvertised ports (any - 22, 25, etc) and creating blacklist base on that.
ipset is a great tool to do such a filtering quickly and make it flexible.
I just took a look at a CentOS 7 VM i setup yesterday, there I left port 22 open. (I always change SSH port, but this time I had forgot). Over 11.700 failed login since yesterday.
I don't know if CSF work in CentOS 7 yet, so I'm using the standard firewall in CentOS 7.
And that would be why I don't even allow SSH open to the Internet as a whole. Whitelisting is a requirement imo.
I don't change default ports, security through obscurity is for suckers.
True, the only benefit of moving port is saving the CPU/bandwidth of the most basic scripts, hardcoded to connect to a specific port.
For the general question, port 80. Purely by numbers, vulnerable content management systems probably account for the most 'hacks'.
This is not an accurate statement.
I mean in terms of any port other than 80/443.
I change port to a non standard, and I just allow connections/login to root from my private IP (+ a couple of VPN IP's since I have a dynamic IP @ home).
No other users have access to the server, there is no other SSH user then root.
But I forgot both (it went little fast to get owncloud to work), so I left the 22 port open, and no IP restriction on the root user.
This is still an inaccurate statement.
For me my backend VPSes ain't been touched with CF/Reverse Proxies
You clearly do not understand how it works.
And what are 98% of the attackers? Right, suckers, script kiddies. Using scripts. Hardly ever even trying 2222 (which is not the smartest of all choices).
And btw., I know, that credo "security by obscurity is no security" is much beloved and quoted a zillion times a day.
And wrong.
Actually, security almost always is obscurity. What's encryption, for instance? Yes, it's obscurity albeit intelligent and mathematically sound obscurity.
The correct version of that credo is "simple obscurity alone is no security". "simple" and "alone" underlined.
Cloudflare only allows traffic via port 80/443.
With reverse proxy the VM that is sat on gets loads of bruteforces, backend wise no one attacks as IP isnt publicly posted and SSH is a new port
It still doesn't mean you are secure.
Obscurity is very much... the first line of Defense no matter what! Remembering a great term from one of my mentors "Security is not a product, its a process!"
Anyways -- which all ports are the most Vulnerable ?? which ones are most sniffed ? any Database/study of this available ?
All ports are vulnerable.
The most vulnerable ports are those with the most vulnerable software behind it.
Ports are a medium not a target.
No, because the encryption algorithm is free and open.
Using secure shell is security by design, changing the listening port of a vulnerable version thinking that this would prevent attacks is security through obscurity.
And what is for example the public key part? Its core is about obscuring the negotiation and exchnge of the key for the further on used symmetric encryption key.
Security by design? Have a look at the code, at the bug list, at heart bleed, at many nasty - and well justified - remarks of libressl developers. So many bugs that were part of the design? I have doubts.
Wrong. It does prevent attacks. OK, not all attacks (which security can offer that?) but quite some. Actually the vast majority, namely the brainless script kiddie attacks.
Again, that's just one attack and probably more an irritating than a dangerous one. But it's a very very frequent attack.
To avoid misunderstandings: My point is not that proper design based on sound mathematical foundations is bad. It certainly is not. It's good and it's important. But in the end it's a just a very sophisticated form of obscurity.
And I say that even trivial obscurity can be one (of an array of) useful element of defense. See -> script kiddie blocking by changing the port.
And even your beloved SSL has major obscurity elements, albeit probably not designed in with that purpose. Ask anyone what's a good private key. Probably 99 out of 100 times you'll hear something like "One with big keylength. 4096 bit RSA". In fact there are even articles in IT magazines telling that.
Well, that basically means that they have only a very rudimentary understanding of the math behind it. Because a good key is not primarily defined by keylength. The quality of the prime numbers are important. There are high quality 1024 keys and there are quite low level quality 4096 bit keys.
Now, what's that for most people? Magic. Obscurity.
And btw. What for that whole shebang? Right, to obscure, i.e. to make intransparent, to hide some information, namely the encrypted information.
P.S. And keep that "free and open". The fairy tale of the thousand eyes has bloodily and shamefully failed (heartbleed and many many more bug, anyone?).
In fact, I think that in real life the holy "free and open" religion has actually created a lot of harm.
On my servers the following ports receive the most hits (in approx. order):
TCP 22, 25, 23, 8080-8090, 3389, 9064, 80, 445, 3128, 1433, 443, 3306, 5900, 4899, 1080, 139, 21 ...
UDP 137, 1900, 19, 123 ...
To help block the attackers, see my example IPTables rules and port scan detection tutorial.
You should consider all ports vulnerable. Test and minimize accordingly.
I lol'd so hard at how Darwinian this is.
I don't have my iptable configured, but I don't expose many ports either. ssh/ftp/http/https/mysql/ntp ports for the most.
They attack the IPs. Directly. NOT through any website, or anything like that. There is NO need for you to publish the IP anywhere.
So the fact that you use CloudFlare, by itself (if you don't do anything else apart of that), will NOT protect you from these attacks.
What was your VPS company again? It's not in your signature but I honestly want to know...
Obscuring the exchange of the symetric key - are you fucking stupid? If that was obscured rather than encrypted/secured (which it is) it wouldn't be secure even the slightest bit as anyone would be able to MITM or decrypt your session.
Educate yourself on cryptography or fuck off, ignorant pricks like you cause our personal info to be dumped online because some jackass marketing company hired you to do their security
thankyou @hwdsl2, yours was the most "productive" post feeding the purpose of my thread!
Enjoying the conversation otherwise... Security sure is a well debated propaganda
@Traffic
Thanks. Many seem to think that Cloudflare works miracles and that their IPs somehow magically vanish into some kind of virtual high-security vault.
@Mitchell
Thanks for the demonstration of how many idiots replace knowing and proper mechanisms by religious belief systems.
You've failed to understand even the most basic principles.
WHY ist the sym. key exchange encrypted? You've mixed up a mechanism and a goal.
Just have a look at real-world security issues. Virtually all of them are implementation related. ECC 160 vs. RSA2048 is a purely academic question. Your server isn't cracked because the algorithm you used wasn't perfect (wikipedia saying there are attacks known that bring down the strength from 256 bits to 180 bits).
Your servers get cracked because e.g. OpenSSL is an extremely poor implementation of those secure algorithms. Or because some "Open Source = security" dumbass happily used table driven crypto, inviting and making easy a timing attack.
But OpenSSL is open source so it must be great, no? How come a gazillion "1000 eyes open source security" minions found themselves blitz-fucked by heartbleed?
Because like you they mixed up pretty everything, got wrong pretty everything, led holy wars for GPL, preached OpenSSL and 1000 eyes - instead of understanding even the basics and fucking check their shit even with just 4 eyes. Yes, that's how Heartbleed happened. 2 eyes (developer) were unexperienced and the other 2 eyes ("controller/maintainer") never looked properly and such failed to discover a pretty obvious problem.
That's what I'm saying, fixing openssl, rewriting it to libressl, that's security. Running a broken version and changing the port to "prevent" attacks, that's security through obscurity.
Changing the port would make it harder for some script-kiddies, but when one more knowledgeable would get around your host, you're risking to get compromised harder.
@UrDN
OK, now we're getting to a reasonable discussion.
And you are more or less right except for (your understanding of) obscurity.
Look: How many times have you been attacked by nsa or by evil russian professionals?
Probably never. Like 99% of us.
So our real problem isn't evil russian professional hackers or the nsa. Our problem is script kiddies, orbit cannon anonymous kiddies, or plain 14-years old "wizzzzards" in an evil mood.
Getting 90% or 95% of a problem solved ain't bad, no?
And btw. no a fixed OpenSSL (libreSSL) is not a complete solution either. Honestly, how many here know how to configure the algorithms used by Open/libreSSL, let alone actually doing it sensibly? And how many can and are willing to replace apache, php, etc.? And how many ever actually looked at the source code of the stuff they use, let alone spotted a bug or even fixed it?
Security is a very cumbersome and complex business. I know that because I work in that field. And yes, obscurity can be one layer of protection (but, you are right, certainly not the only one).
Being confronted with a gazilion of attacks and thousands and thousands of companies and people and infrastructure in serious trouble every single fucking day, getting rid of some "background noise" is valuable, trust me.