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.
Security through duplicity is literally why the human body has two of everything. Your approach is against nature. Redundancy be the Lord's way. Yield and accept the downvotes you have earned.
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.
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.
I have port knocking setup. You have to send a specific collection of packets or even one of a specific type and port 22 will then remain open for a short period of time to allow connection, and only be open for the host actually doing the knocking. Other than this, the port remains closed and nobody can access it. EDIT: Since people have asked, here's my implementation. No extra software is required other than a modern day sprinkling of iptables matching rules with ipsets. 1. Create an SSH ipset -> "ipset create SSH hash:ip family inet" 2. Create an iptables matching rule (of your required flavour, this would be particular properties of the secret packet you want to match, maybe based on protocol type, port, length, contents, ttl etc) and jump to the SET module using the “-j SET --add-set SSH src --exist --timeout 60" construct. So when the kernel sees a specific type of packet, add the originating SRC IP address to the SSH IPSet for 60 seconds. 3. Create a follow up rule which allows SSH TCP SYN connections incorporating the entries in the SSH IPSet via "-p tcp --syn --dport 22 -m set ! --match-set SSH src -j REJECT --reject-with tcp-reset" which translates to - if the originating source IP is not in the SSH IPSet, respond with a connection reset packet to make the port look closed, otherwise, allow the connection through to the SSH daemon.
just looked it up, port knocking is clever but easily bypassed by people with packages sniffing. For a home server would be great but there is a reason it isn't common for big companies.
@@scheimong No software. I have updated my original comment. This is on the likes of StackOverflow etc if you go hunting deep enough, and is actually where I learnt that iptables now has support for the IPSet module (and has done for a number of years now).
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.
What i did once is to host a honeypot on port 22 and the real ssh in another port. I don't recall getting any login attempts to the real ssh, but hackers had fun in the honeypot lol
@@anandsharma7430 You sort of just countered your own point. If someone doesn't have access to IPv6, then they can use an IPv4-to-IPv6 VPN. Furthermore, if you're just using your own VPS, then this point hits harder. That's because, chances are, you're tech nerdy enough to know how to get an IPv6 VPN -- especially if you're to the point of being worried about the connection logs. As such, I only see your point being feasible when a _company_ is using SSH. Even then, chances are, the more experienced technicians would likely be operating the network. And, if there is a case where a technician just happens to not have IPv6 access, then they can receive help from the other technicians so that they can install an IPv4-to-IPv6 VPN. Then, for a start up (who likely has far from experienced technicians), I severely doubt that they would be as worried about it to begin with.
@@bndlett8752 But I did mention IPv4 to IPv6 VPN as "easy". I didn't get your point. The point of a company having superior technicians is good enough. But you shifted the goalpost to company from individual. A $5/month VPN maybe cheap to you, but it is not a negligible expense to the whole world, especially students and beginners outside USA/EU and with no VC funding.
You can also use port knocking with a fairly tight configuration like open only the knocking IP and only for port 22 otherwise drop the packets on the ground. Port knocking can allow you to have a system that's pretty much invisible to the outside world until it gets the right knock sequence. Yes I use this on a server on the internet along with reverse proxies to get access to my home network.
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.
Please downvote these tech hipster videos proposing Dindu Nuffin as "our security". It looks like some kind of ban baiting that targets English intellectuals.
imho you explained in details the most important content thats a lot of peoples ignore everyday in the context of cybersecurity, by example, we can also harden the "discoverability" of important ports by using some advanced techniques like: "Port Knocking" or "Single Packet Authentication", there's so much scientific papers explaining these most advanced topics to help us to hardening the internet side ports, i think thats a good point to consider when u looking for the advanced techniques
Changing the default SSH port improves security. No amount of words can talk this away. However, it does so by annoying any system user and gives you barely any security improvement. But it does give you some. Needless to say, I also never change the port, as SSH is typically NOT the application voulnerable to attacks. Some zero-day exploits we all don't know excluded. And obviously it is absurd to portscan any real server. The scanner's IP is blocked after the 5th closed port access or sooner. A botnet must be used for such a scan.
If you have a non-static ip address at your home, you can set up a dyndns service (also good for the VPN to your home network) and then set up a cronjob on the VPS that (maybe once per hour or something like this) checks the dyndns ip of your home network and adjusts ufw rules automatically to only allow the ip of your dyndns for ssh. In cases where you need urgent access but the ip just changed, with most providers, you can login to your VPS via a direct console over the administration panels of your hoster and manually add the ip again so that it works again.
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.
I still change the default ssh port on servers with public addresses not to improve security but just to avoir bot scans filling my logs but that's all, I don't expect more by doing so
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)
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.
I haven't seen this suggested before, but instead of just changing the SSH port, make SSH only listen on IPv6. Most bots don't bother scanning IPv6, because mapping entire IPv6 networks by brute force tends to be impossible due to the sheer size of these networks. Won't stop attackers who know what they're doing, but it sure will stop any automated bots from spamming your server's logs. And naturally, combine that with fail2ban and other protection mechanisms. At that point port change becomes optional.
@@GreatTaiwan it's been said in the video that ports 1-1000 are special ones that require apps exposing those ports to have elevated privileges thus a little more trustworthy. Other point is that security through obscurity is just probability reducer not true security and it's not worth the hustle. By all means you can use nonstandard port but in terms of security it's meaningless. Regarding port knocking, that's a technic were you block access to one or more ports unless you try connecting to predefined ports in a proper sequence. Effectively that's a passcode
@@DanielosCompaneros yep, If I was gonna go out of my way to change the port of my ssh (and thus change my configs), might as well do something more worthwhile like port knocking instead
11:18 don't forget to not only disable password auth, but also keyboard-interactive auth, both can offer essentially password auth, just different mechanism
Security by obscurity is not a bad thing, as long as it is not the only security you rely on. "It's just a matter of time" is not an argument against it. The only reason doors work is because they prevent thieves from getting into your house for a short period of time. Pretty much any door can be opened given enough time and the right tools, but thieves will typically try to open a door for 2-5 minutes at most, and if that doesn't work, they'll move on. That's why many doors are designed to withstand attacks for only 5 to 10 minutes, because that's enough time to get the job done. Within 8 to 12 minutes, these doors can be forcibly opened, but the risk of getting caught is too high. Your "it's just a matter of time" argument translates to "doors are useless, they wouldn't stop a dedicated thief from breaking into your house", and while the last part is true, I bet nobody will agree with the first part. And if you try to port scan my IP address, my firewall will detect that and simply pretend that all ports are closed for all requests from the same source, in other words, you would have maybe 10 attempts to guess the right port before you are permanently banned.
Whenever I give a downvote to a video I like to leave a comment to explain my self. Here goes: The video very strongly says (or implies) again and again that security through obscurity is no security at all. This is absolutely wrong. Nobody claimed that security through obscurity alone is good, especially for targeted attacks. However, that does not mean that it's no security at all! While I agree that your proposals are good, they are not an alternative to changing the port. Both can be used together. Whether changing the port is a good idea very much depends on your use-case. But security trough obscurity (while not decreasing security otherwise) IS added security! (By the way: The analogy with the locked drawer and the book is misleading at best. A better analogy for the port change would be hiding your save behind a picture or something. Point is: it's still locked.)
Hear, hear. Imagine ssh backdoor got into the repo(it didn't get only because it was badly written). Now if ssh port was default, none of hardening attempts would matter at all. Changing port, alongside IP ban for port scanning, would be the only method to stop the attack
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.
Here’s what I for my servers: 1. Disable root ssh login 2. Disable SSH passwd auth 4. Allow ssh only from localnet ips 5. Open only app required for incoming traffic If ssh from outside of localnet is required, simply connect vpn first to the local network.
All you have to do is port scan the device and you will be able to find which ports are open, it's better to restrict which IP addresses can talk to port 22, like only allowing your admin device(s), or only allowing the local network addresses to talk to the port.
Interesting points. I will never do it again 😀 My way of hardening is enforcing the login with a private key instead of username and password. It is a bit clunky because you have to carry your private key around if you ever want to use it from somewhere else. However, it should be one of the better solutions to the ssh security problem.
I'd still suggest to disable port 22. If a new SSH zero-day is found, bots will be spraying the attack against every open :22 they can find. If you choose a random port then the attack would have to be a lot slower and more thorough, which they usually don't care about - they care about getting enough servers in their botnet, not all the servers.
I also see no issue with distributing port numbers alongside distributing key info. You should be distributing the public keys used by each server, so adding the random port number is not so tricky
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!
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.
I just want to point out that there are non-security reasons why ssh may be exposed on non-standard ports, the main one being conflicts - the port may be forwarded to some other box (be it physical or virtual). 2222 is common for this purpose - which is likely why it's at the top of that list.
I think we can all agree just changing the standard port wont do much, but you would usually do that just as a finishing touch on top of other things just to reduce the amount of automated crap. I usually go with non-standard port + fail2ban + other ssh hardedning (Such as disabling password logins altogether)
Changing the port is considered "security through obscurity" ONLY if that's the ONLY measure you take. There's no reason it can't be additional to other security measures.
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.
it's more like putting the door in an unconventional place. not using fence would be like doing netcat --exec "bash" instead of ssh and relying on bash not running as root.
Maybe it would be a good idea to change it and set up some kind of honey pot? So you block connections that are trying to reach the 22 port and or other ports in case of a port scan like nmap?
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.
Sure you can do that. However a better approach is to disable password authentication and instead use either SSH keys for authentication or another auth service such as Kerberos.
this example is not a vaild one, the good way is firewall block 22 and only open for a randon port, if people try 22 they only get timeout as if the ip is offline
Alternatives: - SSH over TOR or I2P (especially useful if port 22 is blocked or the system is behind NAT) - Port Knocking eg: using HYP (Hide Your Ports) with TOTP Likely best to at least deny access with password, use pubkey only and obviously no access to root
On lightweight servers, anything you can do to reduce attack volume will also substantially increase performance. Azure charges something like $150 per month per bastion host when it’s easy enough to roll your own for $50 per month on scrappy virtual hardware with the same if not better security, but every optimization counts to achieve good performance. If you are counting dollars, or your CFO is counting dollars, just switch the damn port and train your user base to use the correct connection options. It’s not even about security.
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.
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 have a multiple VPSs. One of them i use for experiments. It's been on a non-standard port for over a year. It's received zero attempts. When i switch it to port 22, it takes less than an hour to receive it's first attempt. So I doubt bots are port knocking.
@@LtSich This exactly. The thing is, most attacks aren't that sophisticated. They just go for the low hanging fruit / the easy prey. Yes, against a targeted attack changing the port is close to useless. But that's not the point. That's not what this is done to defend against. This whole video is like “you shouldn’t wear a seatbelt while driving because it won't stop crocs from being able to eat you” ->> okay I guess? 🤷🏻♂
none do. I run hundreds of servers and no high number ports have ever been scanned in over 2 decades. Only main popular ports are scanned. needless to say, still setup your ssh correctly.. no password, no root login, key only. but using non standard port 5 digits long is good for resources and your log sanity. If you EVER see a scan you can watch it. Vs seeing 5000000000 scans per day on default port
I installed a tar pit listening on port 22 and it wasted decades of bot's time in a couple of months. My actual port wasn't connected by any bot yet and if there is an attempt, you know somebody is serious.
If you pose as an attacker you have a stronger motivation to break the remote machine. Instead a bot 99% of time knock on port 22 and move on. I completely agree that changing ssh port is not an increase of security, but: it doesn't cost anything, does not arm the system or have any big cons, and in most cases, the annoying bots move forward. Plus: hardening SSH is not in contrast listening to another port, you can use both with no issues... IMHO.
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!
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.
@@dreamsofcode zero noise > more work ironic coming from a guy whom just made a video where the entire point is "omg it's more complex" (when in reality it is less complex and less work)
Three points: The fact that you aren't filtering port 22, simply having it closed counts against you. On the internet facing servers you should really be filtering anything not necessary for the functioning of the service. This gives far less information to the attacker. The second is that you aren't 'hiding the mechanism' of the security. Hiding the mechanism would be more like running something with a handrolled cypher. Configuration of listening ports is not really a mechanism, it is simply a way to side-step a lot of the dumb scanners and bots out there. This means it is far easier to see scans and other attempts without additional noise. In addition, if you use some portscan detection, you can block the scanners well before they manage to scan much of your port range. The last point is that there is a principle called defence in depth. This means that many controls should work together to improve your security stance and if any one fails, it shouldn't matter much. Changing the port is just one mitigation. Others may be things like fail2ban, blocking whole IP ranges you would never SSH from, disabling password and root logins, and potentially other things like using bastion servers/jump boxes... Each of these in isolation is just one part of a good security stance and forcing allowed connections to use a very narrow configuration to be permitted makes it really obvious when things are abnormal.
You might have overlooked the fact that some people don't use 2222 to obscure anything. They just have another server behind the same ip, they want to ssh on and need an other port to forward from their static ip to. Internally they will be using 22 again on that machine in their internal network. A better solution is to host a vpn on your ip, connect to that and then from inside the network do ssh locally
Port knocking via UDP? I guess a bad idea in areas with high latency or bad connectivity. The order when which packet arrives via UDP does not have to be sequential. Port knocking via TCP opens additional ports. At the end, you have again the problems with the tooling in bigger teams. Just open the ssh port and don't be afraid. Update your servers and if you got an update for sshd, then restart the service. Active ssh sessions stays open, if you restart sshd.
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. 😂
An open port is open, so changing it is not about security. Less noise is good. If you believe a different port is complicated for some people, then you shouldn't be working with them in the first place.
I changed my default ssh port on home box for two reasons. One, it keeps all the shodan and other automated scans down. Second, it lets me bypass firewall restrictions when doing port forwarding through my house from outside networks. My port is not on the list of your uncommon port scans. Someone find it every 3 or 4 months, tries to mess around and gives up after I ban their IP range, and usually it doesn't even come to that.
At work, the only way to SSH into any of our linux servers is if you are on the actual network, which means either plugged in physically (We only have wifi in our distribution centre) or by VPN'ing into the network, which only works if your router supports Cisco's DMVPN. Outside of that, the only other method is RDP via the RDP Gateway, but that only gets you as far as the terminal services servers and no further. Security is best practiced by only exposing what you need to and nothing else. Here at home, my work provided Cisco router has SSH enabled for internal use only, I don't expose anything beyond 2 ports, 1 of those is wireguard. I stopped being amazed years ago by what people expose to the internet, I mean, do you really want people being able to see your homes security cameras? That's a surefire way of giving a person an easier way to observe what you do in order to rob the place!
The idea of having SSH exposed to the internet (on any port) is inconceivable to me. At the very least you would firewall ssh to only be accessible from your IP address, ideally the port would be on a private interface only accessible from a VPN or private management network.
TLDR; Changing default SSH port can hide your ssh service significantly if you are the only one who has to access it (or just a few). It starts to become an issue when your server has multiple users in an organisation who need to ssh into it.
Since it's standard practice to remap the SSH port, don't you people think that virtually any script does this now? nmap and its port-scanner isn't optimized for speed, if you remap the port you can already discredit most of the lower range system ports and start in the higher numbers. Don't remember what tool we used in our IT-sec class, but we discovered a remapped port in a few milliseconds. If there's a botfarm out there with nothing better to do, by all means, it will find your remapped port. Just use an SSH key to log in, disable password logins, blocklist IPs with more than 5 failed attempts and your SSH is good. SSH really isn't a Swiss cheese full of security loopholes. With proper hardening like this, it's incredibly difficult for an attacker to even get close to a successful login.
Nmap will almost always find your SSH server regardless of the port if used properly. I only changed my SSH port so I could use 22 for my Gitea instance instead :D
Automated bots that only test port 22 aren't that big of a security risk unless you're not actually trying to protect your server. I would suggest just disabling passwords, and/or requiring your SSH identities with a master certificate and requiring cert checks for both server and client identities. That way you can easily revoke and refresh identities as needed AND you don't have to worry about bots hammering your server. It's one command to sign an SSH key, and then you just pop the public key of the signer on all devices, and signees are checked against it
you know I just want to Chang sports to whatever I want without someone telling me it's wrong because "they" will find it anyway, or some badly implemented app or service having that port hard-coded. otherwise I propose a new type of security by obscurity: rotating ports. you create a trusted list of ports held by both machines and randomly rotate through them.
i want to say one thing before watching the video. i don't change ssh ports but i just use a firewall with a single whitelisted ip i use to connect to the server
I looked into and your arguments for not changing standard ssh port are valid but there is one instance where changing standard ssh port is viable option. If you have ssh server you plan to access from outside your network than it's good idea to change standard port. All devices on your local network can use standard port.
I was wondering, wouldn't it also be good to outright "ban" anyone outside your country from attempting SSH connections or have even stricter fail2ban rules for them, and also ban any public VPN or Tor IPs from connecting to SSH? This way, even if someone was trying to brute force your VPS, they would have to use residential proxies, which cost money (and a decent amount), further disincentivizing bad actors
Well know ports are well known for a reason. No one talks about changing https to something other than the well known port, never using the same reasons as ssh. It's a listening socket either way.
In my case, I use a non-standard port for ssh, however, I have 5-10 ssh "servers" listening AND an ssh server. Fail2ban is configured such that if there's a connection to the fake ssh servers, then changes the iptables configuration to block that IP address from the real port with a "connection refused". The other 10 servers are just sandboxes which run at VERY limited resources. If there's a port scan which searches sequentially, it will never find the real server (which is what nmap does). I've tried using nmap to brute-force but failed multiple times to find the real port. (that is only the first step of my security, though)
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).
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
The hardening seems like a lot of extra work. Couldn’t the server be placed behind a NAT/FireWall and use Tailscale or some mesh VPN setup to access? This way only authed tailscale clients can access the server?
Only allowing ssh from your VPN tunnel is a very good option. However, it's not an excuse to ignore all other options of securing your server. Defence in depth is the best policy.
Bros never been on Shodan. Change your port numbers people, and open more ports for those scanners and things trying to knock, ban them when they try to connect. Boom, done.
Shodan even wrote a blog about why changing port numbers is pointless 🤣
หลายเดือนก่อน +31
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.
But on the other hand: a) No one could nmap the whole internet, nmap is quite slow b) If someone wants to hack you, you're already hacked (changing your port doesn't protect from targeted nation state hackers, it protects from drive by botnets) c) Changing your port from 22 to *anything else* will cut your random password / connection attempts from hundreds per second to 0 per second d) This makes it a f*ck load easier to read your auth logs
Good points but: a) Zmap or masscan can be done in minutes. b) correct c) I showed in the video changing to Port 2222 and was still be scanned as well. Additionally If you changed from port 22 and left open, you'd be popped. 100s per second is also not my experience. d) it does, but it's not the only way to do so. Additionally without a proper security mechanism in place, you can still be session flooded.
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.
Security through duplicity is literally why the human body has two of everything. Your approach is against nature. Redundancy be the Lord's way. Yield and accept the downvotes you have earned.
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 having to specify the port in all ssh based services for potentially multiple users is added complexity that is not necessary.
@@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.
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)
@@se_mat exactly my thoughts when I saw the title lol
He literally talks about this in the video.
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.
I have port knocking setup. You have to send a specific collection of packets or even one of a specific type and port 22 will then remain open for a short period of time to allow connection, and only be open for the host actually doing the knocking. Other than this, the port remains closed and nobody can access it.
EDIT: Since people have asked, here's my implementation. No extra software is required other than a modern day sprinkling of iptables matching rules with ipsets.
1. Create an SSH ipset -> "ipset create SSH hash:ip family inet"
2. Create an iptables matching rule (of your required flavour, this would be particular properties of the secret packet you want to match, maybe based on protocol type, port, length, contents, ttl etc) and jump to the SET module using the “-j SET --add-set SSH src --exist --timeout 60" construct. So when the kernel sees a specific type of packet, add the originating SRC IP address to the SSH IPSet for 60 seconds.
3. Create a follow up rule which allows SSH TCP SYN connections incorporating the entries in the SSH IPSet via "-p tcp --syn --dport 22 -m set ! --match-set SSH src -j REJECT --reject-with tcp-reset" which translates to - if the originating source IP is not in the SSH IPSet, respond with a connection reset packet to make the port look closed, otherwise, allow the connection through to the SSH daemon.
@@parkamark can you please share what software you're using for this?
@@scheimongthere is an article in the arch wiki of port knocking
@@scheimong knockd
just looked it up, port knocking is clever but easily bypassed by people with packages sniffing. For a home server would be great but there is a reason it isn't common for big companies.
@@scheimong No software. I have updated my original comment. This is on the likes of StackOverflow etc if you go hunting deep enough, and is actually where I learnt that iptables now has support for the IPSet module (and has done for a number of years now).
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.
This is the way
This
any blog about this?
@@GreatTaiwanTailscale in their docs has a section describing how to do it, very helpful
This is the way
2222 is often just used if you just want to expose a second service using SSH, like from a container or another NATed host.
What i did once is to host a honeypot on port 22 and the real ssh in another port.
I don't recall getting any login attempts to the real ssh, but hackers had fun in the honeypot lol
only allow ipv6 to connect and not ipv4. Congrats you just stopped about 99.99% of all those ssh attacks 😅
This tip doesn't scale. A lot of the world's ISPs still use IPv4-only. You need IPv4-to-IPv6 VPN (easy) or tunnel (harder) to circumvent that.
Lol I'm dead
@@anandsharma7430The ongoing joke with ipv6 is that, "it will be adopted.... eventually". Nobody uses it, not even the bot scripts
@@anandsharma7430 You sort of just countered your own point. If someone doesn't have access to IPv6, then they can use an IPv4-to-IPv6 VPN. Furthermore, if you're just using your own VPS, then this point hits harder. That's because, chances are, you're tech nerdy enough to know how to get an IPv6 VPN -- especially if you're to the point of being worried about the connection logs.
As such, I only see your point being feasible when a _company_ is using SSH. Even then, chances are, the more experienced technicians would likely be operating the network. And, if there is a case where a technician just happens to not have IPv6 access, then they can receive help from the other technicians so that they can install an IPv4-to-IPv6 VPN.
Then, for a start up (who likely has far from experienced technicians), I severely doubt that they would be as worried about it to begin with.
@@bndlett8752 But I did mention IPv4 to IPv6 VPN as "easy". I didn't get your point. The point of a company having superior technicians is good enough. But you shifted the goalpost to company from individual. A $5/month VPN maybe cheap to you, but it is not a negligible expense to the whole world, especially students and beginners outside USA/EU and with no VC funding.
Not exposing SSH to the public at all is the only solution.
It's arguably the best.
Not exposing the server to the public overall. Just using a VPN to connect to it. 👌🏻
What about the server that hosts your VPN? @@kissu_io
@@kissu_io or skip the VPN and do SDP/Zero Trust instead.
You can also use port knocking with a fairly tight configuration like open only the knocking IP and only for port 22 otherwise drop the packets on the ground. Port knocking can allow you to have a system that's pretty much invisible to the outside world until it gets the right knock sequence. Yes I use this on a server on the internet along with reverse proxies to get access to my home network.
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.
If not misconfigured ssh is 100% safe. There is no need to do something different.
Please downvote these tech hipster videos proposing Dindu Nuffin as "our security". It looks like some kind of ban baiting that targets English intellectuals.
Shoot, I think I have fail2ban on my server. I do have tailscale, so it really isn't as big of an issue compared to earlier
fail2ban & duo 2FA works pretty good. Users who do not exist in Duo cannot even login.
@@pred4507 well, I'd argue with that - have you come across the recent xz backdoor story?
Nothing is 100% secure!
imho you explained in details the most important content thats a lot of peoples ignore everyday in the context of cybersecurity, by example, we can also harden the "discoverability" of important ports by using some advanced techniques like: "Port Knocking" or "Single Packet Authentication", there's so much scientific papers explaining these most advanced topics to help us to hardening the internet side ports, i think thats a good point to consider when u looking for the advanced techniques
Changing the default SSH port improves security. No amount of words can talk this away. However, it does so by annoying any system user and gives you barely any security improvement. But it does give you some.
Needless to say, I also never change the port, as SSH is typically NOT the application voulnerable to attacks. Some zero-day exploits we all don't know excluded.
And obviously it is absurd to portscan any real server. The scanner's IP is blocked after the 5th closed port access or sooner. A botnet must be used for such a scan.
If you have a non-static ip address at your home, you can set up a dyndns service (also good for the VPN to your home network) and then set up a cronjob on the VPS that (maybe once per hour or something like this) checks the dyndns ip of your home network and adjusts ufw rules automatically to only allow the ip of your dyndns for ssh.
In cases where you need urgent access but the ip just changed, with most providers, you can login to your VPS via a direct console over the administration panels of your hoster and manually add the ip again so that it works again.
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.
so i can't raget other ports with port knocking ?
I still change the default ssh port on servers with public addresses not to improve security but just to avoir bot scans filling my logs but that's all, I don't expect more by doing so
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)
@@insu_na port 22 SSH honeypot sounds interesting lol
Ahaha I often do that. -j TARPIT is awesome 😎
I'm definitly interested in seeing more videos around keeping your machine safe while being exposed to the internet!
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.
I've added cowrie on to another video idea! Great suggestion.
The Lockpicking Lawyer has a great talk about security by obscurity
I haven't seen this suggested before, but instead of just changing the SSH port, make SSH only listen on IPv6. Most bots don't bother scanning IPv6, because mapping entire IPv6 networks by brute force tends to be impossible due to the sheer size of these networks. Won't stop attackers who know what they're doing, but it sure will stop any automated bots from spamming your server's logs.
And naturally, combine that with fail2ban and other protection mechanisms. At that point port change becomes optional.
Port knocking is a good option to hide any port including ssh. I'd do that in addition to your steps
why we can't target none standard ports?
@@GreatTaiwan it's been said in the video that ports 1-1000 are special ones that require apps exposing those ports to have elevated privileges thus a little more trustworthy. Other point is that security through obscurity is just probability reducer not true security and it's not worth the hustle. By all means you can use nonstandard port but in terms of security it's meaningless. Regarding port knocking, that's a technic were you block access to one or more ports unless you try connecting to predefined ports in a proper sequence. Effectively that's a passcode
@@DanielosCompaneros yep, If I was gonna go out of my way to change the port of my ssh (and thus change my configs), might as well do something more worthwhile like port knocking instead
11:18 don't forget to not only disable password auth, but also keyboard-interactive auth, both can offer essentially password auth, just different mechanism
Security by obscurity is not a bad thing, as long as it is not the only security you rely on. "It's just a matter of time" is not an argument against it. The only reason doors work is because they prevent thieves from getting into your house for a short period of time. Pretty much any door can be opened given enough time and the right tools, but thieves will typically try to open a door for 2-5 minutes at most, and if that doesn't work, they'll move on. That's why many doors are designed to withstand attacks for only 5 to 10 minutes, because that's enough time to get the job done. Within 8 to 12 minutes, these doors can be forcibly opened, but the risk of getting caught is too high. Your "it's just a matter of time" argument translates to "doors are useless, they wouldn't stop a dedicated thief from breaking into your house", and while the last part is true, I bet nobody will agree with the first part. And if you try to port scan my IP address, my firewall will detect that and simply pretend that all ports are closed for all requests from the same source, in other words, you would have maybe 10 attempts to guess the right port before you are permanently banned.
Whenever I give a downvote to a video I like to leave a comment to explain my self. Here goes: The video very strongly says (or implies) again and again that security through obscurity is no security at all. This is absolutely wrong. Nobody claimed that security through obscurity alone is good, especially for targeted attacks. However, that does not mean that it's no security at all! While I agree that your proposals are good, they are not an alternative to changing the port. Both can be used together. Whether changing the port is a good idea very much depends on your use-case. But security trough obscurity (while not decreasing security otherwise) IS added security! (By the way: The analogy with the locked drawer and the book is misleading at best. A better analogy for the port change would be hiding your save behind a picture or something. Point is: it's still locked.)
Hear, hear. Imagine ssh backdoor got into the repo(it didn't get only because it was badly written).
Now if ssh port was default, none of hardening attempts would matter at all. Changing port, alongside IP ban for port scanning, would be the only method to stop the attack
2:44 good idea to hide it in a book that surely nobody would ever touch ;-)
Instead of hiding it in the book; highlight certain words, then write the page numbers on a slip of paper and put THAT slip in the safe.
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.
Until they ddos the honeypot lol
@@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
You could always put a tarpit on 22 as well.
Still! I prefer to just leave it and set up better security instead.
No. Better to have the "hacker" move on to something else instead.
@@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.
Here’s what I for my servers:
1. Disable root ssh login
2. Disable SSH passwd auth
4. Allow ssh only from localnet ips
5. Open only app required for incoming traffic
If ssh from outside of localnet is required, simply connect vpn first to the local network.
All you have to do is port scan the device and you will be able to find which ports are open, it's better to restrict which IP addresses can talk to port 22, like only allowing your admin device(s), or only allowing the local network addresses to talk to the port.
Interesting points. I will never do it again 😀
My way of hardening is enforcing the login with a private key instead of username and password. It is a bit clunky because you have to carry your private key around if you ever want to use it from somewhere else. However, it should be one of the better solutions to the ssh security problem.
If you don't have a static ip, you can also restrict access to your ISP's subnets
This is a good idea!
@@dreamsofcode and how would u find your "ISP's subnets"
@@GreatTaiwan you check icann for your ISP and which subnets they bought
I'd still suggest to disable port 22. If a new SSH zero-day is found, bots will be spraying the attack against every open :22 they can find. If you choose a random port then the attack would have to be a lot slower and more thorough, which they usually don't care about - they care about getting enough servers in their botnet, not all the servers.
I also see no issue with distributing port numbers alongside distributing key info. You should be distributing the public keys used by each server, so adding the random port number is not so tricky
Thanks for the video!
I think it would be great to have videos about hardening specific services.
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 i think this whole back & forth is with the following point: "why not both"
@@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!
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.
I just want to point out that there are non-security reasons why ssh may be exposed on non-standard ports, the main one being conflicts - the port may be forwarded to some other box (be it physical or virtual).
2222 is common for this purpose - which is likely why it's at the top of that list.
Banana cursor is cursed- such a psychopath 😂😂😂❤
Video coming soon!
@@dreamsofcode banana cursor spinning for an OS spinner tho? 👀
I think we can all agree just changing the standard port wont do much, but you would usually do that just as a finishing touch on top of other things just to reduce the amount of automated crap. I usually go with non-standard port + fail2ban + other ssh hardedning (Such as disabling password logins altogether)
Changing the port is considered "security through obscurity" ONLY if that's the ONLY measure you take. There's no reason it can't be additional to other security measures.
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.
it's more like putting the door in an unconventional place. not using fence would be like doing netcat --exec "bash" instead of ssh and relying on bash not running as root.
@@themisir Nop. Your analogy makes no sense at all.
10:53 scp also reads the ssh config file, and so does rsync.
OpenSSH 9.8 introduced a new option `PerSourcePenalties`, which provides similar brute-force protection to fail2ban and has nice defaults.
Maybe it would be a good idea to change it and set up some kind of honey pot? So you block connections that are trying to reach the 22 port and or other ports in case of a port scan like nmap?
look up endlessh -- essentially allows you to block attackers indefinitely, and gives you bonus points for making the internet safer.
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.
Sure you can do that. However a better approach is to disable password authentication and instead use either SSH keys for authentication or another auth service such as Kerberos.
Amazing video man. Could you make a long video explaining in detail. It would be amazing.
this example is not a vaild one, the good way is firewall block 22 and only open for a randon port, if people try 22 they only get timeout as if the ip is offline
Alternatives:
- SSH over TOR or I2P (especially useful if port 22 is blocked or the system is behind NAT)
- Port Knocking eg: using HYP (Hide Your Ports) with TOTP
Likely best to at least deny access with password, use pubkey only
and obviously no access to root
key only
wireguard for access (cannot tell if port is open or not) / easier than port knocking
On lightweight servers, anything you can do to reduce attack volume will also substantially increase performance. Azure charges something like $150 per month per bastion host when it’s easy enough to roll your own for $50 per month on scrappy virtual hardware with the same if not better security, but every optimization counts to achieve good performance. If you are counting dollars, or your CFO is counting dollars, just switch the damn port and train your user base to use the correct connection options. It’s not even about security.
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.
But in the real world are bots even port scanning? Or do they just check 22 and move on otherwise?
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 have a multiple VPSs. One of them i use for experiments. It's been on a non-standard port for over a year. It's received zero attempts. When i switch it to port 22, it takes less than an hour to receive it's first attempt. So I doubt bots are port knocking.
@@LtSich This exactly. The thing is, most attacks aren't that sophisticated. They just go for the low hanging fruit / the easy prey.
Yes, against a targeted attack changing the port is close to useless. But that's not the point. That's not what this is done to defend against.
This whole video is like “you shouldn’t wear a seatbelt while driving because it won't stop crocs from being able to eat you” ->> okay I guess? 🤷🏻♂
none do. I run hundreds of servers and no high number ports have ever been scanned in over 2 decades. Only main popular ports are scanned.
needless to say, still setup your ssh correctly.. no password, no root login, key only. but using non standard port 5 digits long is good for resources and your log sanity. If you EVER see a scan you can watch it. Vs seeing 5000000000 scans per day on default port
I installed a tar pit listening on port 22 and it wasted decades of bot's time in a couple of months. My actual port wasn't connected by any bot yet and if there is an attempt, you know somebody is serious.
If you pose as an attacker you have a stronger motivation to break the remote machine.
Instead a bot 99% of time knock on port 22 and move on.
I completely agree that changing ssh port is not an increase of security, but: it doesn't cost anything, does not arm the system or have any big cons, and in most cases, the annoying bots move forward.
Plus: hardening SSH is not in contrast listening to another port, you can use both with no issues...
IMHO.
SSH hardning video please.
I would love a dedicated video on hardening SSH!!
Me thinking I would be fun and quirky with 69420 but I see you chose 42069 😅
Haha! 69420 is greater than 65k unfortunately so not a valid port 😭
@@dreamsofcode maybe I misremember. I use Twingate/tailscale anyway so only exposed on my wifi :). I should probably switch back to 22…
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.
Yes this is what I'm being using for more than a year now and it's great.
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!
We're implementing Teleport at work right now, planning to roll out RBAC for as many assets as possible, I'd love to hear your hot takes DoC
Is a large log file a security risk? Idk why this is a problem since brute-forcing an ssh key is impossible
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.
@@dreamsofcode zero noise > more work
ironic coming from a guy whom just made a video where the entire point is "omg it's more complex" (when in reality it is less complex and less work)
Three points:
The fact that you aren't filtering port 22, simply having it closed counts against you. On the internet facing servers you should really be filtering anything not necessary for the functioning of the service. This gives far less information to the attacker.
The second is that you aren't 'hiding the mechanism' of the security. Hiding the mechanism would be more like running something with a handrolled cypher. Configuration of listening ports is not really a mechanism, it is simply a way to side-step a lot of the dumb scanners and bots out there. This means it is far easier to see scans and other attempts without additional noise. In addition, if you use some portscan detection, you can block the scanners well before they manage to scan much of your port range.
The last point is that there is a principle called defence in depth. This means that many controls should work together to improve your security stance and if any one fails, it shouldn't matter much. Changing the port is just one mitigation. Others may be things like fail2ban, blocking whole IP ranges you would never SSH from, disabling password and root logins, and potentially other things like using bastion servers/jump boxes...
Each of these in isolation is just one part of a good security stance and forcing allowed connections to use a very narrow configuration to be permitted makes it really obvious when things are abnormal.
This video is a godsent, just yesterday i was asking myself this question:D
You might have overlooked the fact that some people don't use 2222 to obscure anything. They just have another server behind the same ip, they want to ssh on and need an other port to forward from their static ip to. Internally they will be using 22 again on that machine in their internal network. A better solution is to host a vpn on your ip, connect to that and then from inside the network do ssh locally
Port knocking via UDP? I guess a bad idea in areas with high latency or bad connectivity. The order when which packet arrives via UDP does not have to be sequential. Port knocking via TCP opens additional ports. At the end, you have again the problems with the tooling in bigger teams. Just open the ssh port and don't be afraid. Update your servers and if you got an update for sshd, then restart the service. Active ssh sessions stays open, if you restart sshd.
PLEASE MAKE A VIDEO ON YOUR LINUX/NIX OS SETUP it looks soooo good
@dreamsofcode, 11:23 Based on what you said, the PasswordAuthentication property should be set to "no" instead of "yes", right?
Please do a video on SSH hardening tips and tricks 😊
What i do is set up an SSH honeypot on port 22, and the real SSH service on a different (higher) port
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. 😂
An open port is open, so changing it is not about security. Less noise is good. If you believe a different port is complicated for some people, then you shouldn't be working with them in the first place.
Omg hi kneeko
Hi! 😄
I changed my default ssh port on home box for two reasons. One, it keeps all the shodan and other automated scans down. Second, it lets me bypass firewall restrictions when doing port forwarding through my house from outside networks.
My port is not on the list of your uncommon port scans.
Someone find it every 3 or 4 months, tries to mess around and gives up after I ban their IP range, and usually it doesn't even come to that.
At work, the only way to SSH into any of our linux servers is if you are on the actual network, which means either plugged in physically (We only have wifi in our distribution centre) or by VPN'ing into the network, which only works if your router supports Cisco's DMVPN. Outside of that, the only other method is RDP via the RDP Gateway, but that only gets you as far as the terminal services servers and no further.
Security is best practiced by only exposing what you need to and nothing else.
Here at home, my work provided Cisco router has SSH enabled for internal use only, I don't expose anything beyond 2 ports, 1 of those is wireguard.
I stopped being amazed years ago by what people expose to the internet, I mean, do you really want people being able to see your homes security cameras? That's a surefire way of giving a person an easier way to observe what you do in order to rob the place!
The idea of having SSH exposed to the internet (on any port) is inconceivable to me. At the very least you would firewall ssh to only be accessible from your IP address, ideally the port would be on a private interface only accessible from a VPN or private management network.
Couldn’t agree more. Security through Obscurity gives also a wrong feeling of safety
SSH on IPv6 only is my version of "reducing complexity" as well as "reducing auth log spam".
TLDR; Changing default SSH port can hide your ssh service significantly if you are the only one who has to access it (or just a few). It starts to become an issue when your server has multiple users in an organisation who need to ssh into it.
Do you have a video on port knocking? Did a search and you don't. Could you discuss the pros and cons of port knocking?
The first time I discovered the logs of login attempts, I immediately setup an IP white list. To only allowed connections from trusted IP addresses.
Yeah please do make a video in hardened SSH
Since it's standard practice to remap the SSH port, don't you people think that virtually any script does this now? nmap and its port-scanner isn't optimized for speed, if you remap the port you can already discredit most of the lower range system ports and start in the higher numbers. Don't remember what tool we used in our IT-sec class, but we discovered a remapped port in a few milliseconds. If there's a botfarm out there with nothing better to do, by all means, it will find your remapped port. Just use an SSH key to log in, disable password logins, blocklist IPs with more than 5 failed attempts and your SSH is good. SSH really isn't a Swiss cheese full of security loopholes. With proper hardening like this, it's incredibly difficult for an attacker to even get close to a successful login.
Thanks for the content, and thanks for the shoutout!
Thank you for the support!
Nmap will almost always find your SSH server regardless of the port if used properly. I only changed my SSH port so I could use 22 for my Gitea instance instead :D
Automated bots that only test port 22 aren't that big of a security risk unless you're not actually trying to protect your server. I would suggest just disabling passwords, and/or requiring your SSH identities with a master certificate and requiring cert checks for both server and client identities. That way you can easily revoke and refresh identities as needed AND you don't have to worry about bots hammering your server. It's one command to sign an SSH key, and then you just pop the public key of the signer on all devices, and signees are checked against it
Also, if you're really paranoid (or love future-proofing), I would recommend looking at libOQS and quantum-safe SSH identities!
Wonderful video! Convinced me
2:55 The word is innocuous.
you know I just want to Chang sports to whatever I want without someone telling me it's wrong because "they" will find it anyway, or some badly implemented app or service having that port hard-coded.
otherwise I propose a new type of security by obscurity: rotating ports. you create a trusted list of ports held by both machines and randomly rotate through them.
Thanks for the video!
i want to say one thing before watching the video. i don't change ssh ports but i just use a firewall with a single whitelisted ip i use to connect to the server
I looked into and your arguments for not changing standard ssh port are valid but there is one instance where changing standard ssh port is viable option. If you have ssh server you plan to access from outside your network than it's good idea to change standard port. All devices on your local network can use standard port.
I miss the setup of having 2 ssh deamons, one at 22 and no possible way to login (fake one) and on a 'random' port.
ONLY changing the port would be security through obscurity. but doing it on top of other hardenings is NOT, as you even demonstrate in this video.
that banana cursor is horrendous. love it :D
My home server is running Endlessh on port 22, while ssh is running on a non standard port. Nothing critical on it, so good enough for my needs.
I was wondering, wouldn't it also be good to outright "ban" anyone outside your country from attempting SSH connections or have even stricter fail2ban rules for them, and also ban any public VPN or Tor IPs from connecting to SSH? This way, even if someone was trying to brute force your VPS, they would have to use residential proxies, which cost money (and a decent amount), further disincentivizing bad actors
Well know ports are well known for a reason. No one talks about changing https to something other than the well known port, never using the same reasons as ssh. It's a listening socket either way.
would love to see something on fail2ban
maybe on non standard setups like nginx running in a docker container
In my case, I use a non-standard port for ssh, however, I have 5-10 ssh "servers" listening AND an ssh server. Fail2ban is configured such that if there's a connection to the fake ssh servers, then changes the iptables configuration to block that IP address from the real port with a "connection refused". The other 10 servers are just sandboxes which run at VERY limited resources.
If there's a port scan which searches sequentially, it will never find the real server (which is what nmap does).
I've tried using nmap to brute-force but failed multiple times to find the real port.
(that is only the first step of my security, though)
you can maybe allow a user and the hostname would be a domain configured with dyndns
This is an interesting idea!
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).
doesn't key auth require processes to share keys with a team regardless? how is that different from sharing an ssh config file?
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
@@fuseteam they generate their own keys so the private keys are never shared
@@includenull hmmmm fair, the public key would be shared with the admin, who adds it in 🤔
The hardening seems like a lot of extra work. Couldn’t the server be placed behind a NAT/FireWall and use Tailscale or some mesh VPN setup to access? This way only authed tailscale clients can access the server?
Only allowing ssh from your VPN tunnel is a very good option. However, it's not an excuse to ignore all other options of securing your server. Defence in depth is the best policy.
Great video!
Bros never been on Shodan.
Change your port numbers people, and open more ports for those scanners and things trying to knock, ban them when they try to connect.
Boom, done.
Shodan even wrote a blog about why changing port numbers is pointless 🤣
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.
@@dreamsofcode Is there a reason you don't use port knocking to get the best of both worlds?
@@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.
But on the other hand:
a) No one could nmap the whole internet, nmap is quite slow
b) If someone wants to hack you, you're already hacked (changing your port doesn't protect from targeted nation state hackers, it protects from drive by botnets)
c) Changing your port from 22 to *anything else* will cut your random password / connection attempts from hundreds per second to 0 per second
d) This makes it a f*ck load easier to read your auth logs
Good points but:
a) Zmap or masscan can be done in minutes.
b) correct
c) I showed in the video changing to Port 2222 and was still be scanned as well. Additionally If you changed from port 22 and left open, you'd be popped. 100s per second is also not my experience.
d) it does, but it's not the only way to do so. Additionally without a proper security mechanism in place, you can still be session flooded.