NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Port scanning on 22
Has anyone else ever seen a ReadyNAS device port scanning on port 22?
My network administer shut down access to our NAS because of this kind of scanning on tcp/22. He's assuming the device is compromised, but he's unfamiliar with ReadyNAS devices. From his description, compromise seems likely, though I'd be surprised, because I use a very strong SSH password and have always kept the device updated.
Before I troubleshoot, does anyone know if any of the standard ReadyNAS daemons (e.g., RAIDar) scan on 22?
My network administer shut down access to our NAS because of this kind of scanning on tcp/22. He's assuming the device is compromised, but he's unfamiliar with ReadyNAS devices. From his description, compromise seems likely, though I'd be surprised, because I use a very strong SSH password and have always kept the device updated.
Before I troubleshoot, does anyone know if any of the standard ReadyNAS daemons (e.g., RAIDar) scan on 22?
16 Replies
Replies have been turned off for this discussion
- RAIDar picks up broadcasts from the ReadyNAS. That wouldn't be over port 22, AFAIK.
How about what model and firmware of ReadyNAS you are running? - It's a ReadyNAS Pro 6 running RAIDiator 4.2.26.
- By default, the ReadyNAS will not go out and scan port 22 for anything.
Generally, compromised systems will have random files in the root directory ( / ). - RAIDar broadcast:
Just ran RAIDar and did a packet capture.
151 is my computer, 159 is my NAS.
13936 2014-09-05 11:45:56.287110000 10.200.100.151 255.255.255.255 UDP 70 Source port: 63586 Destination port: 22081
13937 2014-09-05 11:45:56.287848000 10.200.100.159 255.255.255.255 UDP 288 Source port: 22081 Destination port: 63586 - mgruhn, are you using rsync over SSH for backup? That would use port 22.
Maybe check the backup jobs, and see if there is something configured there that isn't used any more.
Also, you could try making your own packet capture and contacting support. - Good thought. I was using rsync for back up. But looking at the traffic, I'm becoming more convinced that this isn't normal behavior.
Here's a sample of traffic from the NAS that my network admin sent me. Looks to me like it's been compromised, since the traffic is originating from random ports and scanning consecutive IPs. So I'm likely to start by reinstalling the OS, unless anyone has a better thought:
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
2014-09-04 14:29:16.918 27.456 TCP xxx.xxx.119.65:59402 -> 117.158.26.180:22 5 5050 1
2014-09-04 14:29:21.494 23.328 TCP xxx.xxx.119.65:32775 -> 123.199.130.45:22 3 3030 1
2014-09-04 14:29:23.766 20.832 TCP xxx.xxx.119.65:44328 -> 113.171.0.11:22 3 3030 1
2014-09-04 14:29:29.398 15.232 TCP xxx.xxx.119.65:17167 -> 107.167.20.45:22 2 2020 1
2014-09-04 14:29:29.494 14.880 TCP xxx.xxx.119.65:9301 -> 124.232.137.60:22 2 2020 1
2014-09-04 14:29:30.549 14.176 TCP xxx.xxx.119.65:4251 -> 101.227.247.122:22 2 2020 1
2014-09-04 14:29:32.725 11.424 TCP xxx.xxx.119.65:5257 -> 124.227.190.231:22 2 2020 1
2014-09-04 14:29:32.885 11.584 TCP xxx.xxx.119.65:10806 -> 61.191.49.114:22 2 2020 1
2014-09-04 14:29:33.109 11.776 TCP xxx.xxx.119.65:18852 -> 124.207.150.66:22 2 2020 1
2014-09-04 14:29:34.389 9.920 TCP xxx.xxx.119.65:29843 -> 118.201.38.106:22 2 2020 1
2014-09-04 14:29:35.509 9.088 TCP xxx.xxx.119.65:18352 -> 120.70.237.7:22 2 2020 1
2014-09-04 14:29:38.067 6.496 TCP xxx.xxx.119.65:24972 -> 137.117.184.24:22 4 2100 1
2014-09-04 14:29:38.227 6.432 TCP xxx.xxx.119.65:26467 -> 182.254.154.122:22 2 2020 1
2014-09-04 14:29:38.355 6.624 TCP xxx.xxx.119.65:40208 -> 107.167.20.45:22 3 3030 1
2014-09-04 14:29:39.027 5.632 TCP xxx.xxx.119.65:40697 -> 117.158.26.178:22 2 2020 1
2014-09-04 14:29:41.139 3.040 TCP xxx.xxx.119.65:38643 -> 107.167.20.45:22 2 2020 1
2014-09-04 14:29:41.779 2.304 TCP xxx.xxx.119.65:8352 -> 137.117.184.24:22 3 2060 1
2014-09-04 14:29:42.515 2.144 TCP xxx.xxx.119.65:28628 -> 180.153.154.25:22 3 2060 1
2014-09-04 14:29:42.675 1.888 TCP xxx.xxx.119.65:62818 -> 180.153.154.25:22 3 2060 1
2014-09-04 14:29:43.121 1.728 TCP xxx.xxx.119.65:1027 -> 118.201.38.106:22 2 2020 1
2014-09-04 14:29:43.281 1.440 TCP xxx.xxx.119.65:10550 -> 112.54.82.50:22 2 2020 1
2014-09-04 14:29:43.984 0.000 TCP xxx.xxx.119.65:50252 -> 112.54.82.50:22 1 1010 1
2014-09-04 14:29:43.984 0.000 TCP xxx.xxx.119.65:7401 -> 112.64.17.13:22 1 1010 1
2014-09-04 14:29:43.984 0.000 TCP xxx.xxx.119.65:41660 -> 113.171.0.11:22 1 1010 1
2014-09-04 14:29:44.016 0.000 TCP xxx.xxx.119.65:55918 -> 117.78.5.76:22 1 1010 1
2014-09-04 14:29:44.015 0.000 TCP xxx.xxx.119.65:51076 -> 113.160.32.20:22 1 1010 1 - Looks like a worm to me. An OS reinstall wouldn't fix a worm. You would need to factory default.
- How can I do that without losing data?
- Officially you can't. Well officially you should have a backup which means that you never lose data because of the reset because you can always pull it from somewhere else.
Officiously this should be possible but really risky. It would involve SSH into the box, erasing everything except your data and doing a reinstall (since there is nothing on /, all files should be created). That said I am not sure that :
1 - the reinstall will be enough for the system to reboot
2 - that no data will be erased in the process
3 - that the virus/worm will not reinstall himself from the data partition
You can't, and if the system has been hacked you probably shouldn't try.mgruhn wrote: How can I do that without losing data?
Ideally you'd back up your data volume over the network, zero the drives to get rid of any root kits, and then do a completely install. I wouldn't save/restore the NAS configuration either, I suggest you do it from scratch.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
