To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode . You’ll also get 20% off an annual premium subscription.
Counter to nmap point: You're not trying to protect the server from a dedicated attacker by changing the port, you're trying to stop the bots (which cannot for feasibility reasons nmap every server on the internet) which try simple brute forcing. Would be interesting to see how the volume compared with even the most obvious of the alternatives, I imagine it would be far lower.
RE: feasibility:- Tools such as masscan and zmap make it much easier to scan the entire Internet now. If a threat actor wants to find exposed ssh ports on the Internet, they can do so in a feasible amount of time. (Shodan is a prime example) Changing to port really only stops automated dumb scripts that do brute forcing, and even then, it depends on the port you change to. For me, it's not worth changing due to the added complexity.
@@dreamsofcode The thing is, there is no added complexity, you just made it up. Regardless of whether you change the port or not, you'll have a place to store credentials (for you, or your team, again, changing the port is irrelevant here) and saving 2 pieces of data in that place (port-less host and key) is exactly as complex as saving also 2 pieces of data (host with port, and key). In the real world, there is not added complexity whatsoever.
@@themrubios Except there is added complexity. You have to store it for ssh config, for any IaC, for any CICD, security teams need to be aware of the change etc etc etc. Just because you disagree or may not have encountered those issues, doesn't mean something is "made up".
@@dreamsofcode You completely ignore his point of it protecting where mass scanning is not feasible. It doesn't matter if tools make it easier there is still a time and resource factor involved.
Nowadays I usually block port 22 on the (cloud) firewall and use Tailscale SSH to connect to my servers and secure it through the ACLs. If I need to access port 22 through some other software/service I use the subnet router feature and access it via the local IP.
The reason to change the ssh port is to keep the network logs clear for finding real attacks (on other ports/services) instead of all those half-baked useless password attempts towards ssh you see every 2 seconds! Edit: the servers shouldn't be ssh port changed only the gateway/firewall with port forwarding a bit like a haproxy for HTTP.
@@se_mat Yeah, for servers in an internal network I think changing the port is more of a hassle than a real gain, because you now have to be extra carefull when applying firewall rules. What's even worse is, when the company does not have all servers use the same port (was a bit of a pain at work because some servers had the default, then some newer servers had the changed port, and new servers use the default again because the server team said "yeah it's probably not worth the hassle" lol)
Other tools can help to reduce log spam, but honestly it's kinda trivial to filter out the preauth for brute forcing when it comes to log analysis. Also it really depends what port you changed to, not every port change will prevent brute force attempts.
@@dreamsofcode The thing is, you are rather inconsistent in what you say. a) changing the sshd config for 1 dev is ok but for a team, it's an 'issue and high complexity' b)Allowlisting for your home private ip is a better method!? Are you kidding me? That is less complex? I'm subscribed to you and saying "if only I watched the whole thing" while I watch all your nonlive tutorials (and learned about Kanata, thx for that) is a lowball to user retention.
Not really. I've seen some comments saying having a larger log file makes it harder to see actual security threats, but honestly that's kinda a weak argument imho, there's plenty of tools to filter noise.
I don't actually recommend doing this, because it introduces more points of failure, but a fun one is to run an SSH tarpit on port 22. Personally I just use wireguard and ssh that only listens on the wireguard interface with only public-key auth method (and no tarpit. I used to use a tarpit just to get a feel for how many bots are attempting to attack me, but you have to trust that the tarpit is secure and doesn't have any other bugs that would allow RCE)
Haha, I set up a server around 10 years ago, following the best practices according to some site at that time. And those were mostly: key-auth only, prevent root login, fail2ban and a non-standard port. Interesting to see that not much has changed since then.
Dumb question, but instead of using an IPv4 address, can we use an IPv6 address to SSH into a machine? I believe some ISP's do give customers an IPv6 along with their CGNAT IPv4 address.
I only changed my port NAT port forwarding from 2242 to 22 for one reason and one reason only. On my port 22 I already got a gitlab server who need to been exposed on port 22 for Git. Except for this case I don’t change SSH port on client exposed production server, only force SSH key for connection.
1. Change your port from 22 to a random value 2. Make an SSH Honeypot on port 22 with an intentionally bad defense to make a hacker believe that he did break into your system. Put any fake random data there.
@@edismHoneypot may be on a different server if we put a proxy before our servers. Random port 43234 on that proxy will be forwarded to a 22 port on a production server, but port 22 will be forwarded to a Honeypot server. It is very difficult to ddos such a thin layer as a proxy. We can even put fail2ban on that proxy to protect real 43234 port
@@dreamsofcode Honeypots are a valid security measure, and there is no reason to think that setting up a honeypot is the same as security through obscurity. With a random ssh port under 1000-1024 you can have a real ssh session, and a honeypot. The pros of a good honeypot WITH GOOD LOGGING, and a ssh port following that criteria will have pros that outweight the cons imo. Cowrie can let you properly ssh using the port if you enter something like a correct password or do something obscure but maybe its best left to a entirely diffrent port.
You should also mention using a VPN such as Tailscale (which I really recommend), which would allow you to not expose the port to the public internet at all. Also, I feel like SSH bruteforcing is being displayed as a severe security issue when it really isn't. It is practically impossible bruteforce an SSH key.
You're correct. SSH Bruteforce isnt a security issue with correct setup. It's the only real benefit of changing the standard port and imho it's not worth it due to other caveats. Using a VPN is another good idea!
I am with you on this one, I generally don't change SSH from 22, honestly, it is annoying. I use Jenkins and Ansible a lot and configuring each node and the port gets tiresome very quickly. The tradeoffs are not really worth it, unless its a honeypot.
yo that's me 0:23 I think you're missing the point of changing the port. The idea is to reduce exposure as much as possible. You briefly touched on it at 11:40 with the allow list but you can take it a step further with the SSH bastion (which mention on my original comment). The bastion can run on a non-default port and your target server run on port 22. My end goal is not to become a random target of a bot attack. Additionally, knowing that someone that is targeting me can't access the server through SSH unless I have the bastion online is something that makes me sleep better at night.
Hey, thank you for the comment in the last video, I always like these discussions 😁. I think it's kinda impossible to not be the target of a bot attack, instead my preference to add in security to handle it rather than trying to "hide the door". There's a lot of research out there that states changing the port doesn't really help with anything, so it's better to focus on improving security through other methods.
@@dreamsofcode yap, just changing the port and letting it permanently sit there at the end of the would yield the same result as you outlined in the video the bots will eventually find it. the upside of the bastion is that you only turn it on when needed. my philosophy when hosting anything is to only exposing the minimal amount of stuff necessary. i.e a website should only need port 80 and 443, exposing SSH or the database to the public would just increase the attack surface (some shared hosting providers were like this). we agree on the core concept that just hiding is not security, I just think our approach to addressing the issue is different. while I favor stealth and limited exposure, yours is focused on limits and time outs. the thousands of machines running sshd on port 22 and still chugging a long are the proof that the software is just that good. still, the day another vulnerability is revealed to the public I know I won't fret - just upgrade the bastion image to the latest version, remote into my target machines through it and upgrade their sshd.
@@kRySt4LGaMeR Agreed! It's very much a personal preference. I think your approach of limiting your bastion and keeping the core services unexposed is a decent one. Btw theres 18 Million machines detected by shodan running ssh on port 22!
Just changing the port you reduce by a lot, but really by a lot the bot scan. Yes that doesn't change the security, but reduce the load / server job... Just try to look at your auth log file with SSH on port 22 without crowdsec/fail2ban... It's just permanent try/retry/scan from bots... Multiple connexion every minute. Just by changing the default port you can go down to 1 attempt every hour, or even far less...
I suggest running a honeypot like cowrie on port 22 and ssh on some other part! As you said, if the attacker goes to port 22 and tries to connect to it and see 'connection refused', they will 100% run a nmap scan, however, if your running cowrie, in some cases you can directly ssh using cowrie (with things like failed password attacks being sent to the honeypot) but to be more secure run ssh on a diffrent port altogeather.
People misunderstand security by obscurity all the time. Imagine if you could not give out your email address to anyone in order to prevent them from reading your emails. Instead you should start from the assumption that they can get the name of the thing they are trying to access, and then ensure that even with that information, they can't do anything with it, by using proper auth etc. People who don't understand security put things behind unauthenticated URLs all the time and then hope that nobody guesses the URL. People say defence in depth, but often one weak layer of defence gives a false sense of security and then other layers are missed.
Kinda made a video about a topic that you destroyed with your own arguments here IMO. I still don't see any positives on keeping 22 here. And most of the drawbacks are not a big deal in comparison to the benefits. Also most people just don't fit into big corporations as a whole, they would not be watching such a YT channel but rather using complex overpriced tools for their infrastructure. Also speaking about it being a bit more difficult and tricky to use. Hm yeah, use "admin" as a password then. Even easier than dealing with SSH keys. 🤷🏻♂️ Mentioning fail2ban + other tips is nice tho. But unrelated. 👍🏻
Don't change the port. It's such a useless step that you're just wasting time. Set up a good firewall, use certificates, use IP filtering, and configure it securely. Don't waste time changing the port. Apart from being a waste of time, it makes you look like a clown to any reasonable security minded person.
My guess is the easiest way for people hiding it is through SNI by tunneling it over the HTTPS port (mmproxy is needed to keep the real IP, probably the proxy haproxy which can do SNI routing and PROXY protocol).
The last time I had an SSH server running at home I changed the port to 1024, but in reality I should probably just've kept it at 22. I had a couple of portforwarded ports, like 1024, 2048 and 4096, but it really did get difficult to keep track of what ran where, so this time around I might just go ahead and not bother. A hardened SSH config should be plenty of security. No need to rely on luck. 😂
Each team member would have their own key pair, and the public key is what is put on the server's allow list. The private key doesn't leave the users device.
@@includenull each public key i think you mean, but still you'd then still need to get each private key to each member. I don't quite get how that's different from getting a config file to each member
When you put a fence around your house, you don't stop anyone who **really wants** to get in. But you do prevent crimes of opportunity. Changing the default port is like putting up a fence.
22 часа назад
I don''t believe that anybody is arguing that security through obscurity is good. They are simply saying that changing the port reduces the number of attempts you will get. By A LOT. There are bots out there that just scan for open ssh ports. Not specifically for your server but ANY server. You will get less of these. That is a win. The end.
I'm sure I covered those points but: 1. It depends what port. 2222 isn't going to stop brute force. 2. There are bots that scan for open ssh on all ports, not just 22, it's incredibly trivial to do. 3. There are other security issues with changing off of 22. I would recommend watching the full video. You may disagree, but you should question why you disagree with me.
@@kinseywk Port knocking pattern could be found out by observing the traffic (without being able to read the content). I think Wireguard is doing this better. It just responds if the connect request was encrypted with the correct key.
While changing the port doesn't really hide the fact SSH is running on it, doing that along with things like implementing ban triggers on scanning would help a lot. Take for example putting the port on a high port, someone scans your ports to find ssh and your IPS/IDS system would trigger on the scan and ban the source IP. This would cause the attacker to be outed and after would have no chance to exploit the SSH port as an example. I don't say this is fool proof as bots can slow down the scan to avoid threshold triggers but it will take them a looong time and they would have to make the port scan non linear. This causes time and resources to find the port as they have to do it slowly and keep track of already scanned ports. Another thing people do is port knocking which requires a sequence of ports to be hit (think combination lock) before SSH is allowed (this is kind of a PITA for the authorized users but there are apps that will help). In the end, its always about layers of the onion security practice and implementing these don't hurt the overall security.
Correct me if I am wrong, but I think what 2020-s4t is saying it's that with ipv6 their scanners will never find your IP (unless you expose it, but then reverse proxies)
@@someoneunknown6894 ahh fair. Can SSH be configured to only bind to an ipv6 address? Otherwise it seems you'd need to disable ipv4 entirely, which would prevent tons of machines from being able to connect to your server. Maybe fine for many use cases but not if you're exposing services like APIs, mail servers, etc
One day haha. Ipv6 is a great solution for random scanning, but it's not a catch all. Attackers are starting to collect lists of known IPv6 addresses with services running and if there's anything else hosted then the address will get logged as active.
I can't believe you made such a great video, explaining every reason in detail, only for people to continue writing how wrong you are without a good reason Good for the algorithm I guess :D
what's wrong if we use only root with a sufficiently strong password and change no config i don't bother myself doing all that stuff like disabling root and password auth i studied security and cryptography extensively for several years and i know a rightly chosen password can be as strong as a 2048 bit RSA key and even stronger. indeed 2048 bit RSA is considered about 112 bits in strength some sources mention 80 bits as an acceptable minimum, but u can increase it if u are in doubt... but afaik, there is no point in more than 128 bits u can calculate the strength of any random thing if u know how although in reality there are many other factors to consider, but for both passwords and keys the situation is more or less the same
A sufficiently strong password should theoretically be fine as long as it's not mistyped, misplaced or phished. Id still disable root out of good hygiene, even if you need to su - in.
@@dreamsofcode oh albeit my use cases were not that much important so far i have some VPSes and use them mainly to circumvent my country's censorship and sometimes foreign censorship or embargoes i wrote a program (scripts... indeed windows batch files!) that automates almost all of the tasks that i need and encountered so far i just need to insert VPS IPs and username (root) and passwords in a config file... then the scripts do almost everything for me, like creating tunnels in several ways, opening interactive shell, file transfer, debugging capabilities, even creating and deleting users that their specs can be inserted in the config file too, and many other things, details and trivia. i think it has grown to more than a hundred files and more that a thousand lines of code indeed i often don't even change the default root password that is given to me via the web page when the VPS is created! i simply copy and paste that info into the config file. it seems to me that those randomly generated passwords by the system should be reasonably strong, although i can change them quite easily with my script and it can even update the password in the config file itself
Why do you keep rambling about how this doesn't make attacks impossible bla bla, it literally does NOT matter - it does make it harder (although not significantly), the load is reduced, you won't have as many spammy bots as you would have otherwise - it is an additional layer that has some benefits, not a standalone security measure, but this fact does not mean you shouldn't do it at all! With this reasoning, lots of measures are "totally useless" and not worth doing...
It has little to no benefits depending on the port you choose, and has a number of drawbacks. I argue that the drawbacks outweigh the benefits due to the fact there are other more secure approaches one can take. I'm sorry you feel that my well constructed argument, time and effort and most of all, opinions, are "rambling"
did u watch and listen to what he said about complicity and. added sec risks? did u actually work with a huge dev team to understand the terror of complexities? calling explanation rampling just showcases you immaturatity
@@GreatTaiwan if you think sharing the fact that a new instance has another ssh port is a hassle, chances are your security is lackluster in other places as well. You already have to exchange the host, IPs, possibly a vpn access, another port really isn't all that hard to share. I guess I can reason with the "the drawbacks outweigh the benefits", still don't think it's worth creating an independent video sharing all the way you can misconfigure your tools and the problems you may have sharing a simple number with your team
Hahaha this argument is a joke!!! If you really want to be safe, just move the ssh to a different unprivileged port, keep the default port "open" and use iptables to detect and ban port scans and also use fail2ban to protect the ssh service.
this is literally my VPS setup lol, my VPS is up 3 years from now on and no marks of botting in auth.log, forgetting what your secret ssh port is 100 percent skill issue
Also keep in mind that port 2222 is useful when you don't have root access (actually port under 1024 can be used without root, but you need a particular permission I cannot recall)
Now imagine if the hacker just scans the whole internet. It would be much harder to scan 65k ports than let's say 10 most frequent ones for every machine. I heard you can scan single port for all ips of the internet pretty fast.... Although, in case of a targeted attack this obfuscation would help
Couple orders of magnitude greater but far from difficult. The entire IPv4 internet + all 65k ports is still less work than a /64 in IPv6 and attackers are starting to get a handle on finding targets on IPv6. Service fingerprinting isn't that hard and tends to be part of the process in determining if there is a known bug they can exploit before expending the effort of brute forcing.
Make ssh only available trought wireguard VPN and pubkey auth only and run a honeypot on 22 and 23. Block all IPs trying to login with password. Share bkocklists between servers.
Don't discuss security online. Most people don't know what they're talking about. They'll happily propagate bad practices like security by obscurity, but shun you for acting in your average customers interest by hashing on the client AND the server.
Haha. Either way, I like to share my opinion, hopefully backed up with some reasons as to why I have it. Most people are pretty respectful on my channel as well which I'm grateful for, even if they disagree with me, they're still courteous!
You start to talk about automated bots but then "Let''s pretend I'm attacker"... Port change does not work against attackers. It is against bots. You can just compare auth.log size with 22 active and changed.
Did you watch the entire video? I started at the beginning (security through obscurity), then looked at automated attacks, which still continued even though I changed my port...
Can confirm, what the host said are very true. Changing SSH port generally causes more issues than it "intends to solve", a lot of "enterprise" software discovery protocol relies on default tcp/udp:22, and more often than not, it's fixed. Asset inventory, up-time monitoring, service mapping tools, compliance and security tools will be affected. To "improve security", the lowest hanging fruit will be to use hardening baseline, recommendations such as NIST IR 7966, ANSSI will work perfectly fine. The general direction is to only support latest ciphers, algorithms and protocol version. Fail2ban is great, classic go to solution, others like crowdsec and sshguard are also very decent solutions. Firewall is great, traditional iptable, ufw, or "next gen" will do, something like cloudflare or azure application firewall is even better. MFA is also great. There are a lot of solutions, but then, the best case is still not exposing SSH to public internet at all, as there are always going to be zero-days, and maintaining the service and its dependencies are not always fun.
It's not any more "dangerous" to run SSH on port 22 than it is on 42069 or any other random port. Are there pros to changing the port? Arguably, yes, but it's not safer. In fact, believing you're safer because of such is in itself dangerous, it's a false sense of security. There are minimal benefits (for other trade-offs), but security is not one of them.
@@themrubios Yes, it is. Because: Increased Exposure to Automated Attacks: Port 22 is the default port for SSH and is commonly targeted by automated bots and malicious actors scanning for open SSH services. Keeping SSH on port 22 makes your system more likely to be discovered and attacked. Higher Risk of Brute-Force Attempts: Attackers often use scripts to perform brute-force attacks on port 22, trying numerous username and password combinations to gain unauthorized access. This not only poses a security risk but also consumes system resources. Log File Clutter: Frequent unauthorized access attempts can clutter your log files, making it more difficult to identify legitimate issues or more sophisticated attacks hidden among the noise. Avoidance of Simple Scanning Tools: Many automated scanning tools only check default ports. By changing the SSH port, you can avoid these basic scans and reduce the number of attack attempts. Defense in Depth: While changing the default port is not a standalone security measure, it adds an extra layer to your overall security strategy. It's a part of the "defense in depth" approach, where multiple security measures are implemented to protect the system. Reduced Attack Surface: Minimizing exposure by altering default configurations helps reduce the attack surface. Attackers often exploit default settings, assuming they are less likely to be secured properly. Compliance with Security Best Practices: Many security guidelines and compliance frameworks recommend changing default ports and configurations to enhance security. Not doing so might be considered negligent in certain professional environments. Psychological Deterrent: Even though determined attackers may scan all ports, changing the SSH port can deter less skilled attackers who rely on easy targets with default settings. For these reasons, leaving SSH on port 22 can be considered dangerous as it makes your system a more obvious and accessible target for potential attackers.
