Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
2 added 20 characters in body
source | link

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 that this system is compromised simply on the basis of this logfile. Anyone who runs a web-facing SSHD has seen this before, over and over, for years. Fix up the SSHD installation on this host, then investigate the system at 172.25.1.1.

Follow SSHD best practices such as these ...

Disable password authentication in favor of key-based authentication:

# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no

As mentioned, disable root logins:

PermitRootLogin no

Add allowed users to sshd_config:

AllowUsers myusername the_other_sysop_guy

If you do the last one, the log message will change from 'invalid user' to "illegal user".

Depending on your business situation, you can also think about firewalling the SSHD port (allow SSH only from authorized IP addresses) or changing it to using a different port (which is really security by obscurity, but most attacks of this nature are actually scripted). Alas, the fact that the attacker appears to be inside your LAN might cause these to not offer as much help as they would otherwise.

Incidentally, that fact that the device is at 1.1 makes me wonder if they've gotten into your router? ;-)

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 that this system is compromised simply on the basis of this logfile. Anyone who runs a web-facing SSHD has seen this before, over and over, for years. Fix up the SSHD installation on this host, then investigate the system at 172.25.1.1.

Follow SSHD best practices such as these ...

Disable password authentication in favor of key-based authentication:

# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no

As mentioned, disable root logins:

PermitRootLogin no

Add allowed users to sshd_config:

AllowUsers myusername

If you do the last one, the log message will change from 'invalid user' to "illegal user".

Depending on your business situation, you can also think about firewalling the SSHD port (allow SSH only from authorized IP addresses) or changing it to using a different port (which is really security by obscurity, but most attacks of this nature are actually scripted). Alas, the fact that the attacker appears to be inside your LAN might cause these to not offer as much help as they would otherwise.

Incidentally, that fact that the device is at 1.1 makes me wonder if they've gotten into your router? ;-)

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 that this system is compromised simply on the basis of this logfile. Anyone who runs a web-facing SSHD has seen this before, over and over, for years. Fix up the SSHD installation on this host, then investigate the system at 172.25.1.1.

Follow SSHD best practices such as these ...

Disable password authentication in favor of key-based authentication:

# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no

As mentioned, disable root logins:

PermitRootLogin no

Add allowed users to sshd_config:

AllowUsers myusername the_other_sysop_guy

If you do the last one, the log message will change from 'invalid user' to "illegal user".

Depending on your business situation, you can also think about firewalling the SSHD port (allow SSH only from authorized IP addresses) or changing it to using a different port (which is really security by obscurity, but most attacks of this nature are actually scripted). Alas, the fact that the attacker appears to be inside your LAN might cause these to not offer as much help as they would otherwise.

Incidentally, that fact that the device is at 1.1 makes me wonder if they've gotten into your router? ;-)

1
source | link

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 that this system is compromised simply on the basis of this logfile. Anyone who runs a web-facing SSHD has seen this before, over and over, for years. Fix up the SSHD installation on this host, then investigate the system at 172.25.1.1.

Follow SSHD best practices such as these ...

Disable password authentication in favor of key-based authentication:

# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no

As mentioned, disable root logins:

PermitRootLogin no

Add allowed users to sshd_config:

AllowUsers myusername

If you do the last one, the log message will change from 'invalid user' to "illegal user".

Depending on your business situation, you can also think about firewalling the SSHD port (allow SSH only from authorized IP addresses) or changing it to using a different port (which is really security by obscurity, but most attacks of this nature are actually scripted). Alas, the fact that the attacker appears to be inside your LAN might cause these to not offer as much help as they would otherwise.

Incidentally, that fact that the device is at 1.1 makes me wonder if they've gotten into your router? ;-)