Re: [Debian] Re: [Debian] Re: [Debian] Re: Undesired ssh login attempts
On Mon, 2018-06-11 at 15:28 +0300, Reco wrote: > I have two considerations on this then: > > 1) Abforementioned link says that (and that applies to aes256-ctr): > > * nonce reuse is catastrophic, confidentiality is completely lost > * leaks somewhat more information about the size of the plaintext > > Second I can live with, but first is a big "no" in my book. I have to agree. Thanks for pointing that out. > 2) ConnectBot is nice, but I prefer Termux with a proper Debian > chroot over it. I'll certainly look into that. > That way I'm certain that all the deficiencies/vulnerabilities > discovered in a foreseeable future receive a timely update. Ack. Thanks again, -Jim P. signature.asc Description: This is a digitally signed message part
Re: [Debian] Re: [Debian] Re: Undesired ssh login attempts
Hi. On Mon, Jun 11, 2018 at 08:04:35AM -0400, Jim Popovitch wrote: > On Mon, 2018-06-11 at 14:51 +0300, Reco wrote: > > Hi. > > > > On Mon, Jun 11, 2018 at 07:12:32AM -0400, Jim Popovitch wrote: > > > On Sun, 2018-06-10 at 14:27 +0300, Reco wrote: > > > > > > > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > > > > > > What's your thoughts on extending that a bit by adding aes256-ctr > > > to > > > that list? > > > > Don't use it, unless compatibility with certain Windows SSH clients > > is > > required. [1] is a good read on this Cipher. > > What I can consider is ADEAD variety of AES, but - I'm uncertain > > whenever it made its way to OpenSSH at all. It's not in Stretch's > > version of openssh, that's for sure. > > > > Hmmm. I was reading [1] earlier and felt that "Don't use it" applied > to CBC but not CTR. I use ConnectBot (Android SSH client app) and it > has a limited set of ciphers. I have two considerations on this then: 1) Abforementioned link says that (and that applies to aes256-ctr): * nonce reuse is catastrophic, confidentiality is completely lost * leaks somewhat more information about the size of the plaintext Second I can live with, but first is a big "no" in my book. 2) ConnectBot is nice, but I prefer Termux with a proper Debian chroot over it. That way I'm certain that all the deficiencies/vulnerabilities discovered in a foreseeable future receive a timely update. Reco
Re: [Debian] Re: [Debian] Re: Undesired ssh login attempts
On Mon, 2018-06-11 at 14:51 +0300, Reco wrote: > Hi. > > On Mon, Jun 11, 2018 at 07:12:32AM -0400, Jim Popovitch wrote: > > On Sun, 2018-06-10 at 14:27 +0300, Reco wrote: > > > > > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > > > > What's your thoughts on extending that a bit by adding aes256-ctr > > to > > that list? > > Don't use it, unless compatibility with certain Windows SSH clients > is > required. [1] is a good read on this Cipher. > What I can consider is ADEAD variety of AES, but - I'm uncertain > whenever it made its way to OpenSSH at all. It's not in Stretch's > version of openssh, that's for sure. > Hmmm. I was reading [1] earlier and felt that "Don't use it" applied to CBC but not CTR. I use ConnectBot (Android SSH client app) and it has a limited set of ciphers. Thanks, -Jim P. signature.asc Description: This is a digitally signed message part
Re: [Debian] Re: Undesired ssh login attempts
Hi. On Mon, Jun 11, 2018 at 07:12:32AM -0400, Jim Popovitch wrote: > On Sun, 2018-06-10 at 14:27 +0300, Reco wrote: > > > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > > What's your thoughts on extending that a bit by adding aes256-ctr to > that list? Don't use it, unless compatibility with certain Windows SSH clients is required. [1] is a good read on this Cipher. What I can consider is ADEAD variety of AES, but - I'm uncertain whenever it made its way to OpenSSH at all. It's not in Stretch's version of openssh, that's for sure. Reco [1] https://crypto.stackexchange.com/questions/18538/aes256-cbc-vs-aes256-ctr-in-ssh
Re: [Debian] Re: Undesired ssh login attempts
On Sun, 2018-06-10 at 14:27 +0300, Reco wrote: > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com What's your thoughts on extending that a bit by adding aes256-ctr to that list? tia, -Jim P. signature.asc Description: This is a digitally signed message part
Re: Undesired ssh login attempts
Roberto C Sánchez wrote: > On Sun, Jun 10, 2018 at 11:09:49AM -, Dan Purgert wrote: >> deloptes wrote: >> > Hi, >> > I recently get many of those, which means someone found out that ssh >> > external is on port 2 and is trying to do some evil work there. >> > Should I worry or do something? >> >> Use key-based auth only >> Ensure root ssh login is not allowed >> Perhaps fail2ban (or equivalent) >> Perhaps forget about funny ports (as they're "security by obscurity" at >> best). >> > In the past I was of a similar opinion regarding the use of a > non-standard port for SSH. However, some of clients do this and the > main observed benefit is less noise in the logs. As long as the > administrator understands that it does not improve security, and is > willing to deal with the occasional inconvenience of an alternate port, > there is nothing really wrong with it. Which is why I prefaced that option with "perhaps". Not that I've *never* used non-standard ports for services, but it's always with a reason (e.g. secondary service, less log noise, don't want the program to require root permissions, etc.) -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Re: Undesired ssh login attempts
On Sun, 2018-06-10 at 11:09 +, Dan Purgert wrote: > deloptes wrote: > > Hi, > > I recently get many of those, which means someone found out that > > ssh > > external is on port 2 and is trying to do some evil work there. > > Should I worry or do something? > > Use key-based auth only > Ensure root ssh login is not allowed > Perhaps fail2ban (or equivalent) > Perhaps forget about funny ports (as they're "security by obscurity" > at > best). I've generally used the following on machines that allow ssh login: AllowUsers root@ ... # may be impractical for systems that have many logins, but mine don't) PermitRootLogin prohibit-password (OpenSSH default) PasswordAuthentication no ChallengeResponseAuthentication no (Debian default) The private key for root access on a machine is owned by a dedicated administration account on the system, is unique to the machine, and is passphrase protected. On some machines the admin account is only accessible to access from the machine. On most systems the root password is a random string that was discarded after being set. SSH runs on port 22, since the attempt volume has not been high recently. The firewall denies port 22 access. These seemed to me a reasonable compromise between security and convenience. Tom Dial td...@acm.org > >
Re: Undesired ssh login attempts
Reco wrote: > You mean that all these connections originate from 197.159.128.171? > "iptables -I INPUT -s 197.159.128.171/29 -j DROP" will take care of it. > No this was just an example - they come from different IPs. Some days nothing, some days it is nothing. > While you're at it, write an abuse letter to Jonathan Lamptey - he? owns > problematic IP range according to AFRINIC. > > >> I think both are secure: for ssh no users with easy password allowed to >> login > > If you have password-enabled ssh with stock Ciphers, MACs, and Kex'es > enabled, and your only protection is non-standard ssh port - then you > are doing it wrong. > > Set these to /etc/ssh/sshd_config, and watch all those script-kiddies > cry as they won't be able to connect to you at all: > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > MACs > hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com > KexAlgorithms > curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 > > And forbid ssh password authentication. They've invented key-based > authentication for cases like yours 15 years ago. > > Thanks, this is a good advise I will investigate. In fact I have 2 ssh servers - one for internal network and one for external. External is allowed only for 3 users including me. When I upgraded to jessie or to stretch I also updated the cipher rules, but I will double check. >> and apache - no pages or stuff that would compromise. > > As long as this apache serves static HTML only then you're probably safe > indeed. Ok thanks for that - I think it is true as it is local server and there is nothing php - but just documentation. thanks regards
Re: Undesired ssh login attempts
On Sun, Jun 10, 2018 at 11:09:49AM -, Dan Purgert wrote: > deloptes wrote: > > Hi, > > I recently get many of those, which means someone found out that ssh > > external is on port 2 and is trying to do some evil work there. > > Should I worry or do something? > > Use key-based auth only > Ensure root ssh login is not allowed > Perhaps fail2ban (or equivalent) > Perhaps forget about funny ports (as they're "security by obscurity" at > best). > In the past I was of a similar opinion regarding the use of a non-standard port for SSH. However, some of clients do this and the main observed benefit is less noise in the logs. As long as the administrator understands that it does not improve security, and is willing to deal with the occasional inconvenience of an alternate port, there is nothing really wrong with it. Regards, -Roberto -- Roberto C. Sánchez
Re: Undesired ssh login attempts
On 10-06-18, Reco wrote: > Hi. > > On Sun, Jun 10, 2018 at 12:55:24PM +0200, deloptes wrote: > > Hi, > > I recently get many of those, which means someone found out that ssh > > external is on port 2 and is trying to do some evil work there. > > Should I worry or do something? > > Similar for apache web server. > > You mean that all these connections originate from 197.159.128.171? > "iptables -I INPUT -s 197.159.128.171/29 -j DROP" will take care of it. > > While you're at it, write an abuse letter to Jonathan Lamptey - he? owns > problematic IP range according to AFRINIC. > While that will certainly solve that problematic IP address, best practice would be to have some limit per IP address set in your firewall rules. In case of using iptables something like this should work: iptables I INPUT -p tcp --dport -i eth0 -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP That will limit to 3 attempts per minute per IP address for port which you use for SSH. If you use ufw for firewall, it would be simpler: ufw limit /tcp > > > I think both are secure: for ssh no users with easy password allowed to > > login > > If you have password-enabled ssh with stock Ciphers, MACs, and Kex'es > enabled, and your only protection is non-standard ssh port - then you > are doing it wrong. > > Set these to /etc/ssh/sshd_config, and watch all those script-kiddies > cry as they won't be able to connect to you at all: > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > MACs > hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com > KexAlgorithms > curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 > > And forbid ssh password authentication. They've invented key-based > authentication for cases like yours 15 years ago. > > Aye, key-based authentication is definitely way to go. Password authentication is bad for your health.
Re: Undesired ssh login attempts
On Sun, 10 Jun 2018 20:24:41 +0900 likcoras wrote: > On 06/10/2018 07:55 PM, deloptes wrote: > > Hi, > > I recently get many of those, which means someone found out that ssh > > external is on port 2 and is trying to do some evil work there. > > Should I worry or do something? > > > Similar for apache web server. > > I think both are secure: for ssh no users with easy password > > allowed to login and apache - no pages or stuff that would > > compromise. > > > > thanks for opinion > > > > regards > > > > Welcome to the Internet! > > If you're confident of your setup, you can safely ignore them. If > you're annoyed by the logs, you could set up something like fail2ban > to block connections from IPs that have made too many bad attempts > (although this could possibly be used to lock you out). > > My recommendation is the same as Dan's, consider disabling password > login to allow only pubkey authentication. Same with the ports, I > usually don't bother with using a non-standard port since it would, at > best, only reduce the volume of attacks and not really provide any > additional security. > I've found it reduces the volume of attacks by something very close to 100%, which I think is worth having in exchange for a truly trivial effort. or 2 are obvious ports to try, but not many people will try a full portscan across the Net. But yes, get rid of passwords completely, and make sure the private key you carry with you is well encrypted. -- Joe
Re: Undesired ssh login attempts
Hi. On Sun, Jun 10, 2018 at 12:55:24PM +0200, deloptes wrote: > Hi, > I recently get many of those, which means someone found out that ssh > external is on port 2 and is trying to do some evil work there. > Should I worry or do something? > Similar for apache web server. You mean that all these connections originate from 197.159.128.171? "iptables -I INPUT -s 197.159.128.171/29 -j DROP" will take care of it. While you're at it, write an abuse letter to Jonathan Lamptey - he? owns problematic IP range according to AFRINIC. > I think both are secure: for ssh no users with easy password allowed to > login If you have password-enabled ssh with stock Ciphers, MACs, and Kex'es enabled, and your only protection is non-standard ssh port - then you are doing it wrong. Set these to /etc/ssh/sshd_config, and watch all those script-kiddies cry as they won't be able to connect to you at all: Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 And forbid ssh password authentication. They've invented key-based authentication for cases like yours 15 years ago. > and apache - no pages or stuff that would compromise. As long as this apache serves static HTML only then you're probably safe indeed. Reco
Re: Undesired ssh login attempts
On 06/10/2018 07:55 PM, deloptes wrote: > Hi, > I recently get many of those, which means someone found out that ssh > external is on port 2 and is trying to do some evil work there. > Should I worry or do something? > Similar for apache web server. > I think both are secure: for ssh no users with easy password allowed to > login and apache - no pages or stuff that would compromise. > > thanks for opinion > > regards > Welcome to the Internet! If you're confident of your setup, you can safely ignore them. If you're annoyed by the logs, you could set up something like fail2ban to block connections from IPs that have made too many bad attempts (although this could possibly be used to lock you out). My recommendation is the same as Dan's, consider disabling password login to allow only pubkey authentication. Same with the ports, I usually don't bother with using a non-standard port since it would, at best, only reduce the volume of attacks and not really provide any additional security. Same with apache, if you think your server is secure, just let it be; there's nothing you can do, really. Maybe put your server behind some service that stops automated/malicious access (eg. CF) if you're into that kind of thing, I guess? Good luck!
Re: Undesired ssh login attempts
deloptes wrote: > Hi, > I recently get many of those, which means someone found out that ssh > external is on port 2 and is trying to do some evil work there. > Should I worry or do something? Use key-based auth only Ensure root ssh login is not allowed Perhaps fail2ban (or equivalent) Perhaps forget about funny ports (as they're "security by obscurity" at best). -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Undesired ssh login attempts
Hi, I recently get many of those, which means someone found out that ssh external is on port 2 and is trying to do some evil work there. Should I worry or do something? Jun 10 02:44:38 server sshd[3189]: debug1: Forked child 21583. Jun 10 02:44:38 server sshd[21583]: debug1: Set /proc/self/oom_score_adj to 0 Jun 10 02:44:38 server sshd[21583]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Jun 10 02:44:38 server sshd[21583]: debug1: inetd sockets after dupping: 3, 3 Jun 10 02:44:38 server sshd[21583]: Connection from 197.159.128.171 port 60976 on 192.168.40.40 port 2 Jun 10 02:44:38 server sshd[21583]: debug1: Client protocol version 2.0; client software version libssh-0.2 Jun 10 02:44:38 server sshd[21583]: debug1: no match: libssh-0.2 Jun 10 02:44:38 server sshd[21583]: debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3 Jun 10 02:44:38 server sshd[21583]: debug1: Enabling compatibility mode for protocol 2.0 Jun 10 02:44:38 server sshd[21583]: debug2: fd 3 setting O_NONBLOCK Jun 10 02:44:38 server sshd[21583]: debug2: Network child is on pid 21584 Jun 10 02:44:38 server sshd[21583]: debug1: permanently_set_uid: 109/65534 [preauth] Jun 10 02:44:38 server sshd[21583]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256 [preauth] Jun 10 02:44:38 server sshd[21583]: debug1: SSH2_MSG_KEXINIT sent [preauth] Jun 10 02:44:38 server sshd[21583]: Connection closed by 197.159.128.171 port 60976 [preauth] Jun 10 02:44:38 server sshd[21583]: debug1: do_cleanup [preauth] Jun 10 02:44:38 server sshd[21583]: debug1: monitor_read_log: child log fd closed Jun 10 02:44:38 server sshd[21583]: debug1: do_cleanup Jun 10 02:44:38 server sshd[21583]: debug1: Killing privsep child 21584 Jun 10 02:44:38 server sshd[21583]: debug1: audit_event: unhandled event 12 Similar for apache web server. I think both are secure: for ssh no users with easy password allowed to login and apache - no pages or stuff that would compromise. thanks for opinion regards
