>have website
>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?
>>45818537
>that font rendering
you just gave my eyes cancer
>>45818537
probably chink bots
>>45818537
They randomly attack everyone.
Use RSA keys exclusively for authentication and it will be virtually impossible to break.
My sshd log, I think they all immediately give up when it asks for an RSA key.
I never bothered with fail2ban.
>>45818560
>>45818608
Thanks i'll look into getting RSA.
>>45818617
good luck with that :^)
>>45818537
>installed fail2ban 10 minutes ago
>2 banned IPs already
what is going on?
Changing the default port will stop 99.999% of them.
>>45818739
Botnets
>>45818742
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.
>>45818813
>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.
>>45818813
So move to 21 or something
>>45818922
ohu
>>45818922
But then what am I going to host my FTP server on?
>>45818922
FTP typically uses port 21.
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>>45818929
>>45818930
ssh deprecates ftp
>>45818922
i would have said 222, but w/e
anything under 1024 is privileged
>>45818937
Check your privilege ciseontos scum
>>45818911
>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.
>>45818943
how does it feel to be part of the unprivileged 1024-65535?
>>45818957
feels bad...
>>45818911
"WARNING WARNING WARNING WARNING
Someone might be up to something nasty.."
Just bots. My access logs say that there are IPS trying to access non existent phpmyadmin pages all the damn time (I don't use SQL)
>>45818537
Don't use fail2ban, use iptables and ip6tables rules.
It doesn't support IPv6, is relatively slow, and is much less sophisticated.
>>45818813
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.
>>45818929
type in your ftp-application
sftp://[ipaddress] and use your ssh root login for example as username and password.
>>45818929
There is never a good reason to use FTP.
If you are already running SSH just use SFTP.
>>45819073
public file store?
ftp://ftp.mozilla.org/pub/
>>45819134
HTTP is better in every way
>>45819134
There is no good reason to use FTP instead of HTTP or HTTPS.
>>45818537
Most of their endgame is to add to the botnet. I've been running Kippo (as SSH honeypot) for a few years now and the only thing they ever attempt to download is *nix backdoors.
>>45818537
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.
>>45818813
If someone has access to your server to the point where they can run such scripts on your server, you're already completely fucked anyway.
>>45819309
It's not pointless. People can still attack/brute force your SSH. Fail2ban stops the ddos attacks on it.
>>45819319
>people can brute force your SSH
Can they, now?
>>45819319
>stops the ddos
Oh boy
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.
>>45818813
>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.
>>45818950
Guess that's to support my point.
>>45818963
What are you implying exactly?
does /g/ have a good comprehensive 'this is how you setup your server so the chinese don't botnet you' guide? feel like i'm missing some basics (like using iptables over fail2ban)
>>45819481
https://wiki.installgentoo.com/index.php?title=Setting_up_a_Server
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.
>>45819312
Not true. They might not yet have access to all the sensitive data or more privileged users.
>>45819481
start using key based login, thenChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM 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.
>tfw only my own login in my entire log
feelsgoodman.
>>45819332
If you use password based authentication, yes.
>>45819360
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.
>>45819469
>implying that it will warn you about host keys being incorrect.
>>45819538
>If you use password based authentication, yes.
But who does this?
>>45818929
How about that newly freed port 22?
>>45819548
Because it is enabled by default on just about everything, most people.
>>45819156
Its faster
>>45819573
>FTP packets fly faster than HTTP packets
>This is what spergs actually believe
>>45819615
FTP sends fewer packets, therefore less overhead and more file transfer bandwidth, therefore less time to acquire desired data therefore faster.
Are you from /v/ or something?
>>45819481
https://help.ubuntu.com/stable/serverguide/index.html
https://help.ubuntu.com/stable/serverguide/firewall.html
https://wiki.archlinux.org/index.php/Secure_Shell
https://wiki.archlinux.org/index.php/SSH_keys#Security
>>45819502
That is a terrible guide.
>>45819520
Don't use some iptables script, use iptables.
Why are you disabling PAM?
>>45819573
>>45819640
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.
Use an ssh keyfile.
Deactivate logins without keyfile.
Don't bother with changing ports.
>>45819573
In no way is FTP faster.
The time that it takes just to initially connect and login to FTP amounts to more than you could every possibly hope to save.
>>45819668
Are you being serious? I need to know, please and thank you.
>>45819649
On some systems password logins are handled by PAM. If you leave it enabled, password logins will still be possible.
>>45819680
https://www.kernel.org/pub/
ftp://www.kernel.org/pub/
See for yourself.
>>45819700
Did you just suggest to do a speed test between an encrypted protocol and an unencrypted one?
>>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'.
UsePAM yes
Not if you set PasswordAuthentication and ChallengeResponseAuthentication to no.
>>45818560
>>45818617
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.
>>45819710
Yes, I did.
The initial connect and directory navigation are still significantly faster with HTTPS than FTP.
Not to mention there extremely little overhead for the encryption.
>>45819615
>>45819156
>>45819140
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.
>>45819710
He also thinks you need to login into kernel.org/pub.
too funny
>>45818537
It's random. Ranges are attacked, every website gets loads of attacks.
>>45819751
>good, free, reliable http upload/download script
wget or curl
>>45818537
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.
>>45819757
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.
https://tools.ietf.org/html/rfc1635
>>45818537
I made a bot like that anon, they randomly go for IPs. A good way to avoid them is to block ping responses. It sounds stupid but it will work a charm
>>45819769
>wget or curl
I need something that is available on all platforms (preferable with no install) and that is easy to install and use.
>>45819789
So I do but I don't. Got it.
>>45818537
OP.
Listen.
Change the ssh port.
When you do this, there are no attemps at all.
>>45819835
Your client does it automatically.
>>45819838
Faggot.
Listen.
That is security through obscurity.
When you do this, there is no security at all.
>>45819870
security through obscurity is the first line of defence
WHEN that fails you still have your standard defence.
But keep going with your retard opinions.
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.
>>45819846
fucking bloated piece of shit.
>>45819830
wget and curl are both cross-platform and very straightforward to both install and use.
Nothing fancy required for either.
Not sure what else you require
>>4581>>45819870
>using 'security through obscurity' unironically
>>45819640
>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:
>Client:
>HTTP GET /picturesofcats.jpg.exe HTTP/1.1
>Server:
>HTTP/1.0 200 OK
>Content-Length: 65535
>Content-Type: application/octet-stream
File follows as contiguous TCP stream. 1.5 packets of overhead (one from user, .5 from server for headers and shit).
FTP:
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.
>>45819932
Sending many files (like a website consisting of 1000's of files) over FTP is also slow as fuck.
Much faster to zip, upload, and then use SSH to unzip.
Why is that?
>>45819875
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.
>>45819932
Hyper Text Transfer Protocol is better than File Transfer Protocol for transfering files.
HTTP should change its name to just TP.
>>45819975
>It is a fact
/v/ ->
>>45819974
he just explained in detail why
>>45819975
It's going to stop bots from exploiting your SSH server on the default port AKA zero-day exploits.
>>45819978
whatever happened to JPGTP, GIFTP, CSSTP, SWFTP, JSTP, and so on?
>>45819901
>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?
If I only forward my FTP port, could Internet hackers (the masked man known as 4chan) get into anything but the FTP?
>>45818537
>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.
>>45819984
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.
>>45820020
>Also, if you have the time to scan everything you have time to scan every port.
top kek
every port takes as much time as a new ip
you do the math
>>45819982
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.
>>45820036
Are you a moron? Obviously if one single file is slower, 1000 single files will be slower.
>>45819975
>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.
>all the people shitting on fail2ban
What's wrong with it other than the fact that it automates some of the work for you, which I'm sure is a bad thing for some of you?
>>45820028
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.
>>45820050
I mean both over FTP, so both have the FTP overhead he explained.
>>45820004
>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.
>>45820067
You are a moron.
Say one file has X overhead.
This means that n files have X^n overhead.
Math.
>>45820051
>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.
>>45820065
People who leave their port on 22 are more likely to have an insecure password.
I have tried it (do you even own a server????) and it does stop the attacks.
>>45820065
>not going to have the resources to scan every port?
Do the math, please. And stop replying because you realize you're a dumbfuck.
>>45820083
You are retarded. Just shut up.
>>45819974
Two reasons:
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
>>45820084
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.
>>45820036
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).
>>45820110
2000 packets of overhead from the handshaking, that is.
>>45820083
Let's say overhead is 100%
1MB x 2 -> 2MB
1024 x 1KB x 2-> 2MB
>hurrr muh maths
>>45820125
It's not bandwidth that you should be worried about.
>>45820068
>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.
>>45820068
>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...
>>45820125
That's not how overhead works, retard. It depends on the number of files, not their size. Overhead for 1 file: ~100 kB. Overhead for 1000 files: ~100 MB.
>>45820036
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!
>>45820146
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.)
>>45820180
Why is ffmpeg so god-tier
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?
>>45820191
Years of hard work
>>45820085
>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.
>>45819503
>using POP3
>>45820180
>that requires a bit of application support
It doesn't in FTP, luckily.
>>45819993
Deprecated.
>>45820086
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?
>>45820239
Okay then, tell me how to seek to 2:05 in a mkv file over FTP without application support.
>>45820239
He's talking about your client application, I think.
>>45820270
>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.
>>45820307
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
>>45820209
>such aspergers
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
>>45820320
>FTP player
FTP client*
>>45820327
Enjoy your security through obscurity. I bet you think the new reCAPTCHA stops bots as well
>>45820336
AGAIN: I never claim it's a security measure, just a way to shorten log files and reports.
>>45820327
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.
>>45820351
Use systemd's journalctl, logrotate, or just truncate the logs then.
>>45820320
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.
>>45820419
Oh, so you're just mounting a network partition?
SSH does that. No idea if HTTP does, but it should be possible in theory.
>>45820380
>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.
>>45820516
Then just remove all the failed attempts from the logs with grep or a similar tool.
>>45820434
>so you're just mounting a network partition
Yeah basically, but the ftp client does it all automatically.
>>45820201
>(can't use a key for reasons)
Whose constraint is this?
>>45820209
>I also force ECDSA public private key authentication.
Care to share the config for this?
>>45820604
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.
