Apparently, my original post was not as clear as I thought.

Password authentication on the workstation is disabled and port 22
is not forwarded by the firewall.

Fail2ban would not answer the question of where the SSH access is coming
from on the LAN.  If something on the LAN is forwarding SSH connections,
knowing that the IP is in China does not give me info about where this
is happening.


On 1/30/20 5:41 PM, Roger Heflin wrote:
Echoing what samuel says.  If you have non-local ip address from lot
of different ranges, then port 22 from internet is being forwarded by
something to this server.

I have a port 22 forwarded to a machine, and it does get almost
continuous attempts (many an hour) trying various accounts.

#1: disable root from logins like you have.
#2: whatever account you could use to login should be something
abnormal (ie not mike, john, or a common name or software product), as
then the will be attempting against non-existent accounts and never
get in.
#3: whatever password you do have needs to be something good and
something not compromised from one of your other accounts, it would be
hard for them to even use a compromised password for you so long as
they don't have a way to know this computer is yours and it gets even
harder if the account in #2 is not something that you use on anyone
else website that could be compromised and linked to the username.
#4: install and configure fail2ban and it will block ip addresses
after a few attempts, and whitelist anything on your own subnet you
fully trust.

On Thu, Jan 30, 2020 at 3:23 PM Samuel Sieb <sam...@sieb.net> wrote:

On 1/30/20 1:12 PM, Michael Eager wrote:
When I look at /var/log/secure or run journalctl on my workstation, I
see failed SSH login attempts from a variety of IP addresses.  The
attempts are every 3-12 minutes.

The workstation is on a LAN behind an EdgeRouter firewall.  No Internet-
accessible ports are forwarded to the workstation.  The LAN has a
variety of servers, NAS boxes, WiFi access points, WiFi-connected
laptops, etc.

A typical /var/log/secure entry looks like this:
Jan 30 12:43:50 redwood sshd[21228]: Invalid user jackiehulu from
124.204.36.138 port 37394
Jan 30 12:43:51 redwood sshd[21228]: Received disconnect from
124.204.36.138 port 37394:11: Bye Bye [preauth]
Jan 30 12:43:51 redwood sshd[21228]: Disconnected from invalid user
jackiehulu 124.204.36.138 port 37394 [preauth]

I'm assuming that something on the network has been compromised,
allowing SSH login attempts on the LAN.  Other than turning off
each server/AP/laptop/etc, one at a time, to find when the accesses
stop, is there any way to find out where the SSH attempt is coming from?

  From the attacking IP address, unless you're in China, your computer
must be internet accessible somehow.  That's not an IP address on your
LAN, right?
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Reply via email to