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
This term seems widely misunderstood and violated all over LET by random security specialists albeit means nothing. Security is usually consisted by several layers. To system who have already decent security setup obscurity add another layer of many. It's not replacement for security, but layer to to weed out the crap.
Once again, https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/
Everything I have suggested is layered security. SSH Keys + fail2ban + port knocking if you are paranoid. Not obscurity. NEVER change SSH port.
Obscurity adds a false sense of security.
Everyone is allowed to their opinion. This will be my last on the subject.
ssh off 22 helps keep the logs a bit cleaner, so there's that
Oh, god, did you read this article at all? Just don't put it on a non privileged port (keep it below 1024).
By the way "Now, there are few reasons why people would do this, all of them incorrect and dangerous. Some of those reasons I will not even mention, just to protect the people who actually use them" part from linked article made me chuckle.
Thanks, @Silvenga. Relating it specifically to an act of 'superficially covering up known flaws' and basing security on the gamble that others don't know about them makes more sense. The phrase still seems somewhat conceptually incoherent to me, but if it's standard engineer-speak, I'm not one to contest it.
If I were, I would suggest that a system with 'no security flaws' (ostensibly) might necessarily have to be instantiated in a sense that is 'more obscure' than a system with merely obscured flaws. That discussion is probably beyond the scope of this thread, though.
Maybe, although having a more obscure system will itself increase the chance of flaws. A simple system is easier to maintain and conceptualize - this is what they teach in schools now. Open source software can not be secured through obscure because of the amount of peer review.
Ahh, yeah, so it comes down to tensions/contradictions between proprietary and open source, then, interesting. Phrase is starting to become less objectionable now.
Any way an attacker can identify said white listed IP address by, say, using a sniffer? Just curous how fool proof this kind of security layer is...?
@MCHPhil: thank you for outlining port knocking here. An elegant, simple and effective security layer. This said, I'm in favor of changing the SSH port# too (to another one below 1024), if for no other reason than to take some load off the box (avoid having to process all those automated break in attempts).
@aglodek, it wouldn't be hard to identify the IP because it'd be encapsulated in the TCP/IP packets. Since the SSH handshake requires a conversation between client and server, spoofing the IP won't do much good. I'm not a security/network guru, but know enough to know that 70 years of computer science has led to this being best practice.
If changing SSH to a non-default port makes you think your box is more secure, and helps you sleep at night, then that's great. Certain techniques work for some users, while others don't. Perhaps if you feel that you have a better method, you should share it. Repeatedly attacking others' credibility without just cause is not a form of contribution in my mind.
Changing the port only serves to cut down on log clutter (assuming you aren't already accessing SSH via a whitelisted IP) and make is more difficult to run stuff like rsync or the like because you have to actually remember to add the port number instead of using the defaults.
I used to run SSH on port 22 using CSF for blocking anyone who were trying to bruteforce my box. I used keys from the start, so leaving SSH open wasn't too much of a risk, but I got sick of the blocked attempt spam/log garbage so I just blocked SSH from everything except a few IPs. No more attempts are logged from people trying to get into my box.
I guess the same thing could be applied by changing the port, but that goes back to the whole security through obscurity where SSH is listening on a different port, but a port scan would tell an attacker exactly what they need to know, so it's not even that effective - it just stops the bots.
Apparently you don't know how to setup iptables.
A port scan would not work with properly setup iptables rules.
I just used ssh keys instead of password,
sshd_config : PasswordAuthentication no ; UsePAM no
is that enough to provide a more secure way or i must install failban/iptables ?
vim ~/.ssh/config Host your.host.com Port your-custom-ssh-port... and rsync/git/etc works without specifying a port every time.
Mod_security with a good ruleset (e.g., Atomic Corp) and configured to evaluate both GET requests and POST requests is always essential.