Hot answers tagged

63

Yes it looks like you are experiencing a brute force attack. The attacker is in on a class B private address, so it is likely to be someone with access to your organization's network that is conducting the attack. From the usernames it looks like they are running though a dictionary of common usernames. Have a look at 'How to stop/prevent SSH bruteforce' ...


61

Why is this so bad? Because there are tons of bots just scanning the web for open ports and trying to log in, once a scanner bot finds an open SSH port it may be queued for another bot (or botnet) to try to brute force the password. One of the risks here is that eventually, they may succeed in figuring out the password and take control of the server. ...


40

Yes, this looks exactly like a brute-force attack and after googling admins phoenix piglet rainbow it looks like this is the wordlist the attacker is using: https://github.com/hydrogen18/kojoney/blob/master/fake_users Check out line 116 onwards. The wordlist is being used in the exact same order. This appears to be a generic wordlist as it also present on ...


39

Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources. Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally ...


28

Yes, you're being bruteforced. But I don't think you should worry about any bruteforce you detect coming from the internet. You should, however, be worried about brute-force attacks coming from your own network. Being bruteforced is very common, and as long you don't use passwords for SSH (or use good passwords), the attack won't be successful at all ...


25

The main risk is that the initial connection can be intercepted by a Man-In-The-Middle, so an attacker can retrieve the password. The first time a user connects to an SSH server, something similar to the following is displayed: $ ssh scanme.nmap.org The authenticity of host 'scanme.nmap.org (45.33.32.156)' can't be established. ECDSA key fingerprint is ...


19

Quick note added about fail2ban, as a lot of people have been mentioning it: The frontend is a corporate firewall, the backend only sees the redirection/proxy that comes from the firewall. So no, 172.25.1.1 is not an internal machine compromised. Fail2ban in the backend would only block all possibility to use SSH for stretches at a time as it only sees ...


18

Like Steve Sether said, this is not a man-in-the-middle attack. How dangerous is it? In some cases, buffer overflow attacks are possible. Your private SSH keys can be leaked to an attacker. According to the page: SSH roaming enables a client, in case an SSH connection breaks unexpectedly, to resume it at a later time, provided the server also ...


11

I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad? I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack? The very strong benefit of disabling password SSH logins is really in preventing default accounts with weak passwords ...


8

You are surviving the attack, from appearances. SSH is doing what it's supposed to do. However, see below for some steps you should take ASAP to ensure continued survival. Also, and unfortunately, a system inside the network has been compromised. Too common these days. You should ascertain the nature of this apparently interior attack, but do not assume ...


8

Do as many mitigations as you can. Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat. Not every threat can be protected against while still remaining ...


7

You are basically correct. It is obfuscation. Obfuscation is not without value, but you should not rely on it. The first answer is correct, BTW, that it is good practice to host management services such as SSH on a separate network (i.e., not the internet).


7

could cause remote code execution No remote code execution. No man-in the middle as it was cleared up by Mark. Everything is explained in the Qualys analysis as already linked. But in short: The vulnerable thing is implementation of the Roaming feature in client. Client stores buffer of not send bytes if the connection is suspended. The vulnerable, ...


5

You can try Wizcraft's block list, and format it accordingly. At the time of my post, this blocklist was last updated on Thursday, 24-Dec-2015 11:01:52 MST. Keep in mind, Taiwan is not part of Mainland China, but that Hong Kong now belongs to, and is controlled by Beijing. If you only use your server in America exclusively, you could use all of those rules ...


5

The standard look from the logs seem to be a common brute force attack as the names enlisted in the logs are from a standard dictionary being used. Even the common word-lists consider these as the primary target usernames. Also, the injection is from a Private Class B IP. Don't worry though, as long as the passwords that you have enforced are strong enough ...


5

This is a good question. The dedicated page from OpenSSH only says: OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some ...


4

No. The session key under which the data is actually encrypted is derived randomly.


3

Another thing to consider is the possibility of vulnerabilities (albeit known for some time or zero-day) in the sshd daemon itself, which could be exploited by an attacker. To mitigate this, it's best to open sshd only to users working from known IPs that you trust, or through a VPN, if possible.


3

Since all SSH logins to your server are redirected via the same local IP address, I would advise to use fail2ban with care, if you decide to use it. Installing fail2ban on the same server as sshd will result in the IP 172.25.1.1 being blocked on the spot. After that, nobody will be able to login via SSH to your server. If you can install fail2ban on the ...


3

To answer your questions in order: You can see all authorized keys by running the following script with root privileges. #!/bin/bash for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do if [ -s "${X}/.ssh/authorized_keys" ]; then echo "### ${X}: " cat "${X}/.ssh/authorized_keys" echo "" fi done Any valid user may create ...


2

You can use Meterpreter for pivoting. There's a good tutorial described in Metasploit Unleashed. meterpreter > ipconfig Citrix XenServer PV Ethernet Adapter #2 - Packet Scheduler Miniport Hardware MAC: d2:d6:70:fa:de:65 IP Address : 10.1.13.3 Netmask : 255.255.255.0 MS TCP Loopback interface Hardware MAC: 00:00:00:00:00:00 IP Address : ...


2

You can encrypt your key file and ssh will prompt you password to decrypt when you are connecting to your server. ssh-keygen -p [-f keyfile] ssh-keygen will prompt for a password used to encrypt the key.


2

This is really broad question and not exact. There are two ways how to use GSSAPI for SSH logins: GSSAPI Key Exchange - not implemented in openssh, but distributed as a patch (part of RHEL, Fedora, but probably also Debians) GSSAPIAuthentication - part of openssh GSSAPI Key Exchange The plus is certainly the manageability - with GSSAPI key exchange you ...


2

There are a few different reasons why it is safer to use public key authentication rather than password authentication: The secret key never leaves the client machine, thus it is harder to intercept the secret key than the password. This is important in case an attacker perform a mitm-attack against your first connection where the host key is not ...


2

With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit. I have some notes here for using fwknop. I can also ssh into containers behind NAT with no port open externally.


2

The problem is in the thing, that the randomart is based on the fingerprint and not on the key itself. This implies that the hashes are different and therefore the ASCII arts too. For example my output when using the same client version and same key: Host key fingerprint is SHA256:v0I6xgzhRSheT19KVcglIbLven9u/xAaVC/GlpjODpo +---[ECDSA 256]---+ | .. ...


1

I suppose a good question would be why do you even have SSH open to the WAN, anyway? ... As others have mentioned, administering via a private network is the Holy Grail. The best approximation (and the reason I even bother to answer here) for a WAN connection is an IP wrapper or firewall ruleset that only allows SSH from a particular IP address. One such ...


1

It is a bit like moving SSH to a different port. You just hide something (poorly) and that shouldn't be something to rely the security of a system on. It might throw off the attackers that really don't know what they are doing (and they will not get into ssh anyway if it is setup properly) but is useless otherwise.


1

Here you go: Generete SSH keys + protect them with password Allow only specific user to login (AllowUsers) Allow from specific IP username@192.168.1.1 Change default port Create firewall rules and last thing install fail2ban.


1

`perl -e 'print "pam," x 10000'` is executed in subshell, prints 10000 times pam divided by comma (,). The returned string is used as an argument for -oKbdInteractiveDevices= option (see manual page for ssh): KbdInteractiveDevices Specifies the list of methods to use in keyboard-interactive authentication. Multiple method names must be ...



Only top voted, non community-wiki answers of a minimum length are eligible