4000+ failed ssh logins from external IP

4491 SSH login failures in the last 24 hours: … first 4487 messages skipped … 09 Sep 08:20:30: Failed password for root from 91.234.39.60 port 40628 ssh2 09 Sep 08:20:58: Failed password for root from 86.102.131.54 port 45092 ssh2 09 Sep 08:21:01: Failed password for root from 179.33.186.151 port 52143 ssh2 09 Sep 08:21:12: Failed password for root from 91.234.39.60 port 41092 ssh2

2025-09-09 08:21:21 (Australia/West)

How would i check to see if this could be malicious. Also, is there a way to check if my SSH is externally exposed?

It’s safe to say the above indicates that your SSH is externally exposed :slight_smile:

6 Likes

I’d consider it a near-certainty that it is.

Why don’t you know this already?

It’s obvious that it is. The question is why you’re forwarding the SSH port from your firewall (you do have one, right?) to your NAS.

4 Likes

IPv6

In case you have IPv6 network:

  • I see your source IP is an IPv4 address, so this I think doesn’t matter, I just leave it here for reference
  • Make sure you have firewall blocking incoming connections by default from WAN to LAN
  • Should be (should underlined) the default for home routers, but you never know…

IPv4

  • By default we have NAT here, which has the side effect of blocking incoming connections unless forwarding rules say otherwise.

What else?

Since I have no details about your setup, I can only guess… :slight_smile: The followings could also cause the symptom you experience:

  • NAS server is directly plugged in to the Internet Provider’s connection box (no router, no firewall, nothing)
  • DMZ ?
1 Like

I just installed truenas about 2 weeks ago, all i have on it so far are a few apps like game servers. Nothing worth stealing at this point.

So we know the problem, how do i fix it. Firewall? Havnt set one up yet and i dont have a hardware firewall. Just my netgear router.

Intruders can do a lot more than take stuff files/data from your server, here’s a short list, they can:

  • use it as springboard into the rest of your network
  • use it to mine cryptocurrency
  • use it in a “bot net” to attack others, sort of making you complicit
  • put stuff on your server that you may not want to be associated with

Rudimentary protection from outside threats has been included in every consumer router I have ever dealt with and it would take manual effort from someone to disable or sidestep that. It comes in the form of Network Address Translation, or NAT for short. I think it’s fair to say that it’s a standard feature and has been for a generation or more.

A simplified explanation follows
Most routers have a WAN/Internet port that gets an outward facing IP. Whether or not that IP is publicly accessible depends on your Internet Service Provider (ISP).

Your other gear should be connected to the LAN ports. The LAN is your internal network.

Network traffic intended to reach the outside from say, your computer, goes into the router through the LAN ports, routing magic happens, and the data gets sent out through the WAN port to your ISP. Responses go back the same path. This works because your router keeps tidy records on which IP’s you’re currently communicating with. There’s also a time aspect. Just because your computer communicated once with a certain IP an hour ago doesn’t mean that IP gets a free pass forever and ever.

If an outside IP tries to initiate a connection that your router can’t link to an already established still ongoing link, the router will dismiss or drop it, because it’s clearly invalid, possibly malicious. In short, a sane network will block all incoming traffic unless it can be linked to something a local client has initiated.

Sometimes you may want to allow an outside IP to start the connection. One way to do that is using port forwarding. This tells the router to pass all incoming traffic marked with a certain number (a port) onward to whatever local client IP you picked. Examples of when this comes up is if you want to run a local server.

Another option is to set a system up as a DMZ. This lazily tells the router to pass all traffic onward to a specific IP. In short I will say that this has mostly fallen out of favour. It’s a heavy handed tool of limited use today.

It’s possible you have enabled port forwarding on your router, or you set your TrueNAS server up as the DMZ. Both of these are a bad idea because TrueNAS isn’t hardened to withstand the constant pokes and prods from malicious outside entities.

Lastly, it’s possible you’ve connected your TrueNAS server incorrectly. Many homes have what is called Customer-Premises Equipment (CPE). That gear is sometimes ISP owned and seen as the final point in the ISP:s network infrastructure. You connect your WAN port on your router to the CPE and everything on your network goes through the router’s LAN ports. Never connect anything else to the CPE even if it has multiple “free” ports unless specifically told to do so by your ISP. I would still second guess any ISP telling me to connect my server directly to the CPE, it’s massive security risk. Some ISP’s offer multiple public IPs and it may be compelling to use them, but there are substantial security implications of bypassing NAT for the uninitiated, and great care should be taken when doing it.

3 Likes

…which acts as a firewall. The only way anyone from outside would have access to try to log in via SSH would be if you forwarded ports from outside to your NAS. Why would you have done that?

1 Like

AFAIK, game servers like to use UPnP. The modern UPnP allows only port forwarding for the very (LAN) IP that issues the request. But it seems like you are running game servers as (docker) apps. So your game servers have the same IP as your TrueNAS.

It’s a long shot, but I suspect that one of your game servers has been hacked and is now making UPnP requests for the SSH port. Not familiar with netgear stuff, but perhaps its GUI can show active UPnP leases.

Also, if one of your game servers is actually hacked, you are in the danger zone, as the hacker could already have access to your LAN.

Again, this is only my suspicion; can’t say for sure.

1 Like

Good theory. Personally, I never allow UPnP as it’s a huge security hole.

2 Likes

For the record, I don’t think that modern UPnP is a security hole, at least in a SOHO case. And I didn’t see any convincing counterpoint.

For example, if my hypothesis of a hacked game server is right – the issue is not with UPnP per se, but with an external service that is not in DMZ.

Given that a port mapped via UPnP allows the entire planet to access that port and attempt to break in via the software listening on that port, I’d say that more than adequately meets the definition of a security hole.
But in the end, it’s your network, so you do you and I’ll keep my firewall closed to all incoming connections.

1 Like

And how does that differ from manual port forwarding?

Internal systems can do it without the owner of the home router even knowing. Definitely worse.

2 Likes

When you are speaking about internal systems, do you mean rogue systems or totally legit systems which won’t work without port forwarding?

Both. For a static port forward I need to actively configure my uplink router/firewall. OTOH I might bring a new gaming console for Christmas and that might open ports in my firewall without me even knowing.

Unless I do not run UPnP at all - which is the case.

I prefer explicit configuration over “magic” everywhere. E.g. OPNsense used to automatically open IPsec and ISAKMP in the firewall for peers configured in the VPN subsystem. That is no longer the case and I very much prefer it that way. I have an alias group named “IPsec peers” with all of them a member in that group. And firewall rules to allow the traffic of course.

That way when I look at my policy I immediately see the intent and the resulting configuration. Implicit documentation by explicit configuration. With legible names for objects even months later you can see what should work in case you need to find out why it doesn’t.

Kind regards,
Patrick

Or hack your entire lan. Both scenarios can be true; why stop just with opening ports?


While the rest of the message was interesting to read, it is not related to the security of modern UPnP (in my opinion).

That is rarely the intention of consumer electronics gear and so not my primary threat model. Stupid security protocol implementations to “make things work” on the other hand …

Plus >10 year old operating systems, SSL libraries, curl, … yes I fully expect these things in any appliance, be it in my home, my car, …

Ok. Let’s assume it didn’t hack your lan. You set the port forward for the console to “make things work”. Your console has then been hacked through that very port.

What is the difference with the upnp scenario? Took you longer to “make things work”? And then you must remove your forwards when the console is gone/sold/etc.? Well, some devices make infinite upnp leases (which may or may not survive router reboot), so the second point is a little bit made up (so does UPnP “security issues”).


EDIT: Just to be precise. I was talking about modern UPnP IGD in this whole discussion (which allows forwarding ports ONLY to the device performing UPnP IGD lease request).

  1. I never do that. I do not open ports for devices that I do not trust. If a device doesn’t work without some “cloud” connection and worst case a back connection into my home, I send it back.

  2. Even if I do trust the device I isolate it from my trusted LAN.

  3. Opening an inbound port is a conscious decision. UPnP opens ports without users even knowing.

Nice said. That was (almost) my entire point.

It’s a matter of taste in my opinion. At least in SOHO environment.