>read up about fail2ban and precautions
>decide to install it just for future reference
>run it for a day, come back
>multiple attempts of ips trying to get into my ssh in just one day
Are these bots just all automated trying to break into every site out there or is someone attacking my site?
My sshd log, I think they all immediately give up when it asks for an RSA key.
I never bothered with fail2ban.
SSH on port 22, we know for a fact that this is done by root or a root-process since no other user could possibly open that port. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE. You have no way of knowing if you are talking to the real SSH server or not. This reason, and this reason alone makes it that you should NEVER EVER use a non-privileged port for running your SSH server.
On to the next reason not to change ports: A lot of applications actually EXPECT ssh traffic on port 22. Now this might be a debate wether or not those programs are developed properly, but it’s a fact. Even though you can easily change the port in many applications but not all of them do. Trust me, it WILL be annoying for developers, sysadmins and users to operate on your SSH-port 52241, especially since they are using 20 boxes, each with a different SSH port.
>SSH on port 22, we know for a fact that this is done by root or a root-process since no other user could possibly open that port. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE. You have no way of knowing if you are talking to the real SSH server or not. This reason, and this reason alone makes it that you should NEVER EVER use a non-privileged port for running your SSH server.
I don't see how this could be any less secure. Are you talking about when your server is compromised anyone could set up a fake ssh deamon?
I agree that taking another port is security by obscurity but it does make it a lot less likely you will be targeted. Of course this shouldn't be an actual defense mechanism.
>On to the next reason not to change ports: A lot of applications actually EXPECT ssh traffic on port 22. Now this might be a debate wether or not those programs are developed properly, but it’s a fact. Even though you can easily change the port in many applications but not all of them do. Trust me, it WILL be annoying for developers, sysadmins and users to operate on your SSH-port 52241, especially since they are using 20 boxes, each with a different SSH port.
Idk what tools you are using but this should not be an argument, ever. Yes there are preferred ports but this should never mean you can't run some service on another port. If your tool can't handle that your tool is shit and should be discarded. All major ssh clients accept a port number for a reason mate.
>You have no way of knowing if you are talking to the real SSH server or not.
That's why host keys exist, and you need root to read them even to start sshd on an unprivileged port.
I agree with you that it potentially makes it less secure and makes it a large hassle for users but they won't be able to fake the server's host key, so this shouldn't really be an issue.
It's just another root privilege thing handling your network traffic, stop using it. If your ssh config is sound, it's pointless. If not, fix it instead of adding software on top of your broken shit.
>stops the ddos
Also unless you have a super shit password that's in a dictionary there is no way in hell to brute force it over network before the sun expires. sshd has built in limits to mitigate this. And if you're using key based login, it's simply impossible.
>This port can be opened without a privileged account [...]
If the port has already been opened, no second (independent) process can open and listen on the same port. You'd need to kill the first process first (and we're talking about a root process here). So if you setup an SSH password honeypot, you'd have to open a separate port:
1.) I don't connect to that port. The SSH server I know of is running on a different port.
2.) If there is somebody doing that on my server, I've got bigger issues than fake SSH servers.
>A lot of applications actually EXPECT ssh traffic on port 22. Now this might be a debate wether or not those programs are developed properly, but it’s a fact.
And it's also a fact I don't use such applications *because* they were not developed properly. If you're using half-assed programs for security-related applications, you deserve every security problem that arises as a consequence.
The OpenSSH client supports non-standard ports. Everything else is an overlay (git, for example). The overlay either supports non-standard ports, or it is just some kind of quickly written script that can be fixed. We don't need "Enterprise-quality" software that cannot even be bothered to use SSH properly.
Yes. They're from random places worldwide so probably all just from botnets.
I'm sure they just attack IPs on an autodialer style basis, this started literally as soon as i set up this VPS.
Funny thing is, I have password login completely disabled so I don't know why they keep trying.
I should probably disable these emails too. I like to have them just for reference but they will fill up my hard disk.
start using key based login, thenChallengeResponseAuthentication no
Done. don't use fail2ban, don't use some stupid iptables script. Those are for people who don't know what they're doing.
If you use password based authentication, yes.
I am not sure about fail2ban, but using an iptables rule can help to mitigate DDoS attacks by taking load off of the SSH daemon.
That is a terrible guide.
Don't use some iptables script, use iptables.
Why are you disabling PAM?
No, FTP is literally slower - especially for parallel downloads.
So much extra connection overhead. I've absolutely never had an FTP download be any faster than a HTTP download. Usually it's the exact opposite, with HTTP significantly outperforming FTP.
>>45819698# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
Not if you set PasswordAuthentication and ChallengeResponseAuthentication to no.
RSA is outdated. ECDSA is the new hotness. Much more security with significantly smaller key sizes.
As for the FTP debate, FTP is faster for binary data because it's not a purely textual protocol. For small files, HTTP is clearly superior because establishing an HTTP transfer has less packets overhead than FTP.
Since you use http can you give me a good, free, reliable http upload/download script? Haven't been able to find one. thanks.
This has been my reason for ftp so far.
They scan networks and tries to do a dictionary attack on those that has port 22 open.
I get them all the time even though I don't have my IP Address broadcast anywhere.
There's this interesting honeypot software called Kippo that would create a fake SSH server and chroot and record everything the attacker does.
You do need to login, idiot.
With FTP you always login.
Your client is just using the anonymous account and the server is just ignoring the password.
What about using a VPN and then using SSh to login on port 22 on 10.8.0.1. That would be more secure. Use strong keys.
>using 'security through obscurity' unironically
>FTP sends fewer packets, therefore less overhead and more file transfer bandwidth, therefore less time to acquire desired data therefore faster.
Except it doesn't.
>HTTP GET /picturesofcats.jpg.exe HTTP/1.1
>HTTP/1.0 200 OK
File follows as contiguous TCP stream. 1.5 packets of overhead (one from user, .5 from server for headers and shit).
Each line is one packet.
>Client: USER anonymous
>Server: 331 User name okay, need password.
>Client: PASS anonymous
>Server: 230 User logged in, proceed.
>Client: Type I
>Server: 200 OK
>Client: RETR /picturesofcats.jpg.exe
>Server: 150 File status okay; about to open data connection
Server opens a whole new fucking TCP connection to send the data, + 2 packets for handshake.
>Server: 226 Closing data connection, file transfer successful
That's an overhead of, count 'em, eleven packets.
FTP is fucking awful for file transfers.
It is a fact that all changing the port is going to do is create more work for people trying to use the server.
No sophisticated attacker is going to stop because you change the port it was listening on.
>very straightforward to both install and use.
How is it that?
On windows you need to install three other things first, and it's complicated on android too. Setting up the server with passwords and so on seem even worse.
Compared to ftp that is install exe/apk-->done
And server wise ftp servers have a simple UI for account management.
Secondly, it's a command line tool, more complicated to use than easy UI clients, especially on android devices that don't even have a keyboard...
Third, does it even support streaming?
>Are these bots just all automated trying to break into every site out there or is someone attacking my site?
I have operated dozens of servers.
This always happens.
It's just botnets looking for more servers to take over, then using those servers to take over even more.
Not having an easy to guess password is all you need to be safe.
And a few login attempts per second isn't going to cause noticeable slowdowns.
No one with a zero day for OpenSSH is going to mass scan the whole IPv4 address space and try it on everything.
Also, if you have the time to scan everything you have time to scan every port.
>exploiting your SSH server
My server has a whitelist of addresses that can connect to it enforced by iptables and ip6tables.
He explained why the transfer of one file is slower.
But there is also something slowing down multiple files.
ie: 1000 1KB files take many times longer to transfer than one 1MB file.
>No sophisticated attacker is going to stop because you change the port it was listening on.
But 99.999% of attacks aren't sophisticated at all.
Nobody gives a fuck about OP's data.
It's just dumb botnets randomly attacking servers.
And you think that the person which has a zero day in OpenSSH is not going to have the resources to scan every port?
Hell, you could just scan ports 2222, 2221, etc, and get a bunch horribly insecure servers run by people who think changing the port secures anything.
>windows and android
Oh, you should have mentioned you were targeting cancerous system
>Third, does it even support streaming?
Streaming as in playing a file while downloading/uploading? If so, I do that all the time with HTTP, and so does youtube. Best streaming protocol in existence.
>But 99.999% of attacks aren't sophisticated at all.
>It's just dumb botnets randomly attacking servers.
So you don't even need to change the port in the first place because they already have no chance at getting in. You just proved my point.
You are retarded. Just shut up.
1. FTP is really slow at opening new connections, and due to the protocol design you need to open a different connection for each single file you want to upload. For small files, the overhead starts dominating the actual file size, so you end up with abysmal slowdowns.
2. zip archives are most likely compressed, and compression most likely saves fucktons of bandwidth
I wasn't the one suggesting the port change.
I leave mine on defaults just to avoid confusion when colleagues need to log in.
I thought it was about preventing the long log files and status e-mails full of break-in attempts?
They can be mildly annoying.
The key part is
>Server opens a whole new fucking TCP connection to send the data, + 2 packets for handshake.
Opening a TCP connection is expensive, sending a thousand files means opening a thousand seperate TCP connections, which means 2000 packets (plus all kinds of overhead for any intervening level 4 routers, firewalls and NSA/Chinese deep-packet-inspection systems).
>targeting cancerous system
I'm targeting all systems other than iOS, but that's just because I don't know anyone with an iOS device.
>Streaming as in playing a file while downloading/uploading
I guess it was a pretty stupid question, but no, I mean as in playing the file over network without saving it.
It would be done like this in android:
open file manager-->click on ftp server-->click on movies folder-->click on movie--> Movie plays
How would it be done with curl?
Open terminal-->type command to list movies folder--> Type command for curl to download-->navigate to download folder-->Play movie-->delete movie afterwards
It would be a lot easier and faster to do with the browser instead of curl then...
it's due to the chattiness of ftp
lets say you have a latency of 100ms, and can do 2MB/s
lets say you have 200 20k files, that's 2 seconds worth, theoretically (no overhead)
so the http one takes 100ms to ask the server for each file, then it responds with the file (lets say instantly)
you have to add 200 (number of files) by 100ms (latency for each request)
so now it's 22 seconds all up
with ftp, going with the example of 11 packets per request, that's 11*100ms, or 1.1 seconds per file, with 200 files, that's 220 seconds ontop of the minimum 2 seconds!
One way would be to write the file to STDOUT, pipe into whatever application. This is default behavior in curl.
However, then you don't get nice stuff like seeking (which HTTP supports) - that requires a bit of application support. Fortunately, ffmpeg implements it, and therefore so does absolutely everything else (VLC, mpv, MPC-HC etc.)
I rapidly skipped through this thread, but I would like to ask what do you guys do to make sure your box isn't compromised?
So far I've setup fail2ban, disabled root login, restricted the rights of my allowed ssh user, am using a strong password (can't use a key for reasons) and I am frequently checking the output of last, just in case.
Anything else I should absolutely do?
>I have tried it (do you even own a server????) and it does stop the attacks.
I have a large network of servers.
I do computer security for a living.
Like I said in a previous post, my servers have an explicit whitelist of addresses that can connect to it enforced by iptables and ip6tables. I also force ECDSA public private key authentication.
Changing the port does nothing but make it annoying to configure client software in my case because I have a secure network.
>People who leave their port on 22 are more likely to have an insecure password.
Having a good password is irrelevant when the attacker has a zero day for OpenSSH.
Jesus Christ, in the scenario where someone has a zero day for OpenSSH it is most likely going to be a state funded attacker.
Do you really think that the United States does not have the ability to scan every port of every address on the IPv4 internet in a decent time frame?
>to 2:05 in a mkv
Well depends on what you mean as application support, The ftp client supports it and does all the work. Video player doesn't.
Sadly this is only available on android it seems. Would love to have it on desktop.
So your FTP player implements the Matroska header specification, parses PTS information, figures out where in the bitstream 2:05 corresponds to, and seek to that position - all without the player even telling it to?
Yeah, sure, I believe you
So you admit you never tried changing the port and have no idea how botnets react to it.
All I am saying is: I have tried it and it does stop botnets.
Do I claim it;s necessary? - NO
Do I claim it isn't annoying? - NO
I have never done it on my systems but I have seen what it does on other peoples.
>I have tried it and it does stop botnets.
What I saying is that having proper security (iptables) will already stop botnets, sophisticated attackers, and will not be annoying. So there is no good reason to change the port.
No. The player thinks it has the whole file.
The player " implements the Matroska header specification, parses PTS information, figures out where in the bitstream 2:05 corresponds to, and seek to that position"
and then tries to read the data (that isn't there yet), and as it reads the FTP client downloads the data. Kind of like how other network shares work, and frankly, the only way it should work.
>Use systemd's journalctl, logrotate, or just truncate the logs then.
It's still nice to be able to see the genuine login attempts.
For example to see if a colleague has logged in over the holidays.
There are a lot of ways to do this.
Honestly, it is just a policy thing with us. You are not going to get a non-ECDSA key added into the Puppet configuration because I am the sole one who authorizes keys.
I am sure there is a good way to disable other key types for the daemon, but in my case that is not necessary.