NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS Pro Business Hacked/Compromised
I have a real problem. About a month ago, my ISP (Time Warner) quarantined my public IP. When I called them, I was told that there was a complaint from Europe that my public IP was trying to brute force the root password on one of their servers. Time Warner re-enabled my Internet access and told me to scan all of my computers for viruses and trojans. I have mostly Macs at home, but I do have one Windows VM. I ran multiple anti-virus programs and scanners and found nothing. So, I hoped the problem would go away by itself.
Today my public IP was quarantined again by Time Warner. When I called them, they told me that another sysadmin complained about my public IP trying to brute force the root password on their server. This time it got my attention (partly because I work from home and I need Internet, so I can’t have this happening again). Additionally, this time Time Warner threatened to disconnect my account to “protect themselves” from the liability.
So, I decided to change my router’s public IP address, thinking that someone may be spoofing my IP, and the attack really does not come from within my network. As soon as I changed the MAC address on the router’s WAN interface and acquired a new IP, I decided to clear the NAT table to get rid of the connections that could be hung due to my public IP having just changed. Once I cleared the NAT table, I issued the “show ip nat translations” command in the Cisco router and saw this:
This is just a small excerpt. There were literally hundreds of fresh NAT rules with random public IP addresses and destination port 22 (which is SSH). The reason I’m posting this here is because the inside source IP (192.168.200.30) is my ReadyNAS Pro Business.
So, it appears that the ReadyNAS is scanning hundreds (and probably thousands) of IPs on the Internet trying to establish a connection on port 22 (SSH).
The following output is from the log of the server belonging to the guy who complained to Time Warner about my public IP attacking his server on December 2, 2012. This log was emailed to me by Time Warner today.
The 174.98.137.x IP address is the public IP that my Cisco router had before me getting a new IP (174.98.157.x) today.
Finally, below is an excerpt from the log that was emailed to me by the person who complained about my IP trying to brute force the user login into one of his servers back in early November, 2012:
This attack lasted for over 40 minutes with hundreds of user names tried.
Back in June of 2012, my ReadyNAS started misbehaving. It would become unresponsive once every two to three weeks, and I had to power cycle it with the power button in order to bring it back online. I contacted Netgear support and they worked with me for several months to determine what the problem was. The case # is 19196769. Netgear asked me to provide SSH access to the ReadyNAS for them and even asked me to give them the root password, which I pasted in the ticket notes. Later, it appeared that the root password was not required for them to have access to the RadyNAS, but they had asked for it, and I gave it to them. Additionally, I kept the SSH access open for them for several months. My suspicion is that my ReadyNAS was somehow compromised because of this SSH access being open for several months. I killed it in November after I had the first incident with Time Warner quarantining my IP and when I saw the log with my IP trying to SSH to a server in Europe with various user names. Back then I suspected this brute-force attack was launched from my ReadyNAS because I saw that there was a login registered from a Netgear IP around the time when the attack was reported. There was no reason for Netgear to log in to my ReadyNAS on November 12 (because all the troubleshooting of my original problem had been finished), so I suspected that it was their automated login server that continued to log in to their customer devices for as long as the SSH access was opened. I could not understand why Netgear’s login server would be launching brute-force attacks from my ReadyNAS against public IPs on the Internet. I asked this question of the Netgear Engineer to whom my case was assigned (the case was still open), but he assured me that was not Netgear that was doing this brute-force SSH login attempts. Back then, I had no proof that the attacks were coming from my ReadyNAS - it was just a hunch. I did kill the SSH access to my ReadyNAS from the outside on that day, though.
However, tonight I have clear proof that the ReadyNAS is trying to scan multiple addresses on the Internet, attempting to connect on port 22 (SSH). I really need someone’s help on this. I may have exposed my ReadyNAS to the Internet and that got it compromised. I just need help from Netgear to get to the bottom of this. Currently, I disconnected my Netgear from the network, so I’ve lost all the services that it was providing. I tried to create an access list in the Cisco router to deny all traffic from the ReadyNAS to the Internet and log that traffic, but as soon as I applied the access list to the Cisco router’s interface, my Cisco router crashed. That just shows how much traffic is being generated by the ReadyNAS to the Internet.
I think this is a serous problem, and I need help. My ReadyNAS is still under warranty, but I am appealing to Netgear here to notice this post and expedite help. Going through the support portal takes months, and the tickets get closed for no reason, and I just cannot go through it now. This requires serous escalation ASAP.
Please HELP!
Today my public IP was quarantined again by Time Warner. When I called them, they told me that another sysadmin complained about my public IP trying to brute force the root password on their server. This time it got my attention (partly because I work from home and I need Internet, so I can’t have this happening again). Additionally, this time Time Warner threatened to disconnect my account to “protect themselves” from the liability.
So, I decided to change my router’s public IP address, thinking that someone may be spoofing my IP, and the attack really does not come from within my network. As soon as I changed the MAC address on the router’s WAN interface and acquired a new IP, I decided to clear the NAT table to get rid of the connections that could be hung due to my public IP having just changed. Once I cleared the NAT table, I issued the “show ip nat translations” command in the Cisco router and saw this:
tcp 174.98.157.x:37546 192.168.200.30:37546 198.61.172.84:22 198.61.172.84:22
tcp 174.98.157.x:37546 192.168.200.30:37546 198.61.173.118:22 198.61.173.118:22
tcp 174.98.157.x:37547 192.168.200.30:37547 198.61.173.134:22 198.61.173.134:22
tcp 174.98.157.x:37548 192.168.200.30:37548 198.61.173.211:22 198.61.173.211:22
tcp 174.98.157.x:37552 192.168.200.30:37552 198.61.167.35:22 198.61.167.35:22
tcp 174.98.157.x:37552 192.168.200.30:37552 198.61.176.11:22 198.61.176.11:22
tcp 174.98.157.x:37556 192.168.200.30:37556 198.61.169.190:22 198.61.169.190:22
tcp 174.98.157.x:37556 192.168.200.30:37556 198.61.176.144:22 198.61.176.144:22
tcp 174.98.157.x:37559 192.168.200.30:37559 198.61.175.172:22 198.61.175.172:22
tcp 174.98.157.x:37562 192.168.200.30:37562 198.61.169.61:22 198.61.169.61:22
tcp 174.98.157.x:37563 192.168.200.30:37563 198.61.172.72:22 198.61.172.72:22
tcp 174.98.157.x:37565 192.168.200.30:37565 198.61.172.54:22 198.61.172.54:22
tcp 174.98.157.x:37567 192.168.200.30:37567 198.61.173.200:22 198.61.173.200:22
tcp 174.98.157.x:37570 192.168.200.30:37570 198.61.175.119:22 198.61.175.119:22
tcp 174.98.157.x:37572 192.168.200.30:37572 198.61.175.236:22 198.61.175.236:22
tcp 174.98.157.x:37581 192.168.200.30:37581 198.61.176.14:22 198.61.176.14:22
tcp 174.98.157.x:37584 192.168.200.30:37584 198.61.168.226:22 198.61.168.226:22
tcp 174.98.157.x:37584 192.168.200.30:37584 198.61.169.5:22 198.61.169.5:22
tcp 174.98.157.x:37589 192.168.200.30:37589 198.61.175.197:22 198.61.175.197:22
tcp 174.98.157.x:37589 192.168.200.30:37589 198.61.176.147:22 198.61.176.147:22
tcp 174.98.157.x:37590 192.168.200.30:37590 198.61.169.86:22 198.61.169.86:22
tcp 174.98.157.x:37594 192.168.200.30:37594 198.61.176.172:22 198.61.176.172:22
tcp 174.98.157.x:37595 192.168.200.30:37595 198.61.173.111:22 198.61.173.111:22
tcp 174.98.157.x:37599 192.168.200.30:37599 198.61.171.119:22 198.61.171.119:22
tcp 174.98.157.x:37599 192.168.200.30:37599 198.61.173.166:22 198.61.173.166:22
tcp 174.98.157.x:37611 192.168.200.30:37611 198.61.173.114:22 198.61.173.114:22
tcp 174.98.157.x:37616 192.168.200.30:37616 198.61.171.31:22 198.61.171.31:22
tcp 174.98.157.x:37627 192.168.200.30:37627 198.61.176.11:22 198.61.176.11:22
tcp 174.98.157.x:37632 192.168.200.30:37632 198.61.167.35:22 198.61.167.35:22
tcp 174.98.157.x:37632 192.168.200.30:37632 198.61.176.223:22 198.61.176.223:22
tcp 174.98.157.x:37634 192.168.200.30:37634 198.61.169.190:22 198.61.169.190:22
tcp 174.98.157.x:37635 192.168.200.30:37635 198.61.175.232:22 198.61.175.232:22
tcp 174.98.157.x:37638 192.168.200.30:37638 198.61.171.168:22 198.61.171.168:22
tcp 174.98.157.x:37642 192.168.200.30:37642 198.61.172.54:22 198.61.172.54:22
tcp 174.98.157.x:37647 192.168.200.30:37647 198.61.171.168:22 198.61.171.168:22
tcp 174.98.157.x:37647 192.168.200.30:37647 198.61.175.172:22 198.61.175.172:22
tcp 174.98.157.x:37648 192.168.200.30:37648 198.61.175.119:22 198.61.175.119:22
tcp 174.98.157.7:37651 192.168.200.30:37651 198.61.173.222:22 198.61.173.222:22
This is just a small excerpt. There were literally hundreds of fresh NAT rules with random public IP addresses and destination port 22 (which is SSH). The reason I’m posting this here is because the inside source IP (192.168.200.30) is my ReadyNAS Pro Business.
So, it appears that the ReadyNAS is scanning hundreds (and probably thousands) of IPs on the Internet trying to establish a connection on port 22 (SSH).
The following output is from the log of the server belonging to the guy who complained to Time Warner about my public IP attacking his server on December 2, 2012. This log was emailed to me by Time Warner today.
id=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-x.triad.res.rr.com user=root
Dec 2 12:39:20 us-dads sshd[23552]: Failed password for root from 174.98.137.x port 43391 ssh2
Dec 2 12:39:20 us-dads sshd[23553]: Received disconnect from 174.98.137.x: 11: Bye Bye
Dec 2 12:39:21 us-dads sshd[23554]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-042.triad.res.rr.com user=root
Dec 2 12:39:23 us-dads sshd[23554]: Failed password for root from 174.98.137.x port 43683 ssh2
Dec 2 12:39:23 us-dads sshd[23555]: Received disconnect from 174.98.137.x: 11: Bye Bye
Dec 2 12:39:24 us-dads sshd[23556]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-042.triad.res.rr.com user=root
Dec 2 12:39:26 us-dads sshd[23556]: Failed password for root from 174.98.137.x port 43949 ssh2
Dec 2 12:39:26 us-dads sshd[23557]: Received disconnect from 174.98.137.x: 11: Bye Bye
The 174.98.137.x IP address is the public IP that my Cisco router had before me getting a new IP (174.98.157.x) today.
Finally, below is an excerpt from the log that was emailed to me by the person who complained about my IP trying to brute force the user login into one of his servers back in early November, 2012:
Nov 11 13:00:42 198.15.118.135 sshd[68261]: Did not receive identification string from 174.98.137.x
Nov 12 07:35:14 198.15.118.135 sshd[27345]: Invalid user admin from 174.98.137.x
Nov 12 07:35:21 198.15.118.135 sshd[27347]: Invalid user miquelfi from 174.98.137.x
Nov 12 07:35:35 198.15.118.135 sshd[27353]: Invalid user admin from 174.98.137.x
Nov 12 07:35:56 198.15.118.135 sshd[27365]: Invalid user admin from 174.98.137.x
Nov 12 07:36:17 198.15.118.135 sshd[27367]: Invalid user sunil from 174.98.137.x
Nov 12 12:01:02 198.15.118.135 sshd[42892]: Invalid user fax from 174.98.137.x
Nov 12 12:01:03 198.15.118.135 sshd[42894]: Invalid user pgsl from 174.98.137.x
Nov 12 12:01:04 198.15.118.135 sshd[42896]: Invalid user postgres from 174.98.137.x
Nov 12 12:01:06 198.15.118.135 sshd[42898]: Invalid user postgres from 174.98.137.x
Nov 12 12:01:08 198.15.118.135 sshd[42902]: Invalid user raimundo from 174.98.137.x
Nov 12 12:01:09 198.15.118.135 sshd[42904]: Invalid user joan from 174.98.137.x
Nov 12 12:01:10 198.15.118.135 sshd[42906]: Invalid user johan from 174.98.137.x
Nov 12 12:01:11 198.15.118.135 sshd[42908]: Invalid user sebastian from 174.98.137.x
Nov 12 12:01:12 198.15.118.135 sshd[42910]: Invalid user agate from 174.98.137.x
Nov 12 12:01:13 198.15.118.135 sshd[42912]: Invalid user administrator from 174.98.137.x
Nov 12 12:01:15 198.15.118.135 sshd[42916]: Invalid user alexandre from 174.98.137.x
Nov 12 12:01:16 198.15.118.135 sshd[42918]: Invalid user joseluis from 174.98.137.x
Nov 12 12:01:18 198.15.118.135 sshd[42920]: Invalid user ppazmino from 174.98.137.x
Nov 12 12:01:19 198.15.118.135 sshd[42922]: Invalid user utilidades from 174.98.137.x
Nov 12 12:01:20 198.15.118.135 sshd[42924]: Invalid user utilized from 174.98.137.x
Nov 12 12:01:21 198.15.118.135 sshd[42926]: Invalid user ams telecom from 174.98.137.x
Nov 12 12:01:22 198.15.118.135 sshd[42928]: Invalid user dedlogistica from 174.98.137.x
Nov 12 12:01:23 198.15.118.135 sshd[42930]: Invalid user dsantiago from 174.98.137.x
Nov 12 12:01:24 198.15.118.135 sshd[42932]: Invalid user marcia from 174.98.137.x
Nov 12 12:01:28 198.15.118.135 sshd[42934]: Invalid user consultoria from 174.98.137.x
Nov 12 12:01:30 198.15.118.135 sshd[42936]: Invalid user primaveras from 174.98.137.x
Nov 12 12:01:35 198.15.118.135 sshd[42938]: Invalid user salvatore from 174.98.137.x
Nov 12 12:01:36 198.15.118.135 sshd[42940]: Invalid user commercials from 174.98.137.x
Nov 12 12:01:37 198.15.118.135 sshd[42942]: Invalid user cart as from 174.98.137.x
This attack lasted for over 40 minutes with hundreds of user names tried.
Back in June of 2012, my ReadyNAS started misbehaving. It would become unresponsive once every two to three weeks, and I had to power cycle it with the power button in order to bring it back online. I contacted Netgear support and they worked with me for several months to determine what the problem was. The case # is 19196769. Netgear asked me to provide SSH access to the ReadyNAS for them and even asked me to give them the root password, which I pasted in the ticket notes. Later, it appeared that the root password was not required for them to have access to the RadyNAS, but they had asked for it, and I gave it to them. Additionally, I kept the SSH access open for them for several months. My suspicion is that my ReadyNAS was somehow compromised because of this SSH access being open for several months. I killed it in November after I had the first incident with Time Warner quarantining my IP and when I saw the log with my IP trying to SSH to a server in Europe with various user names. Back then I suspected this brute-force attack was launched from my ReadyNAS because I saw that there was a login registered from a Netgear IP around the time when the attack was reported. There was no reason for Netgear to log in to my ReadyNAS on November 12 (because all the troubleshooting of my original problem had been finished), so I suspected that it was their automated login server that continued to log in to their customer devices for as long as the SSH access was opened. I could not understand why Netgear’s login server would be launching brute-force attacks from my ReadyNAS against public IPs on the Internet. I asked this question of the Netgear Engineer to whom my case was assigned (the case was still open), but he assured me that was not Netgear that was doing this brute-force SSH login attempts. Back then, I had no proof that the attacks were coming from my ReadyNAS - it was just a hunch. I did kill the SSH access to my ReadyNAS from the outside on that day, though.
However, tonight I have clear proof that the ReadyNAS is trying to scan multiple addresses on the Internet, attempting to connect on port 22 (SSH). I really need someone’s help on this. I may have exposed my ReadyNAS to the Internet and that got it compromised. I just need help from Netgear to get to the bottom of this. Currently, I disconnected my Netgear from the network, so I’ve lost all the services that it was providing. I tried to create an access list in the Cisco router to deny all traffic from the ReadyNAS to the Internet and log that traffic, but as soon as I applied the access list to the Cisco router’s interface, my Cisco router crashed. That just shows how much traffic is being generated by the ReadyNAS to the Internet.
I think this is a serous problem, and I need help. My ReadyNAS is still under warranty, but I am appealing to Netgear here to notice this post and expedite help. Going through the support portal takes months, and the tickets get closed for no reason, and I just cannot go through it now. This requires serous escalation ASAP.
Please HELP!
25 Replies
Replies have been turned off for this discussion
- I’m trying to unmount the data partition using the following command per instructions above:
umount -r /c
and I’m getting this message:
umount: /c: device is busy
umount: /c: device is busy
What does this mean?
Thanks! - Something is accessing files there, like CIFS/AFP/NFS data mount. Are all the clients disconnected?
chirpa wrote: Something is accessing files there, like CIFS/AFP/NFS data mount. Are all the clients disconnected?
No, clients are not disconnected. I did disconnect NFS and iSCSI.
I just tried the “umount -lr /c” and it seemed to have worked. I could no longer see any folder under /c
Then I mounted again, and was able to see folders in /c
Then, I tried the “umount -r /c” command again, and it seemed to have worked without the error message.- So, I’ve performed the steps listed earlier, and it seems I’ve gotten rid of the trojan/worm/whatever that was infecting my ReadyNAS. At least, I no longer see any attempts to connect to random hosts on the Internet on port 22 (SSH).
A few things to note.
1. When I restored the firmware (using the paperclip method), as the ReadyNAS was booting, it displayed the private IP address it received from the local DHCP server, but after the ReadyNAS booted all the way, the LED screen switched to displaying IP address 65.152.109.110. This address seems to be geographically located in western Arkansas. At the same time, I was able to log into the ReadyNAS using the private IP it initially displayed on the LED screen. Can anyone explain why it was showing this public IP on the ReadyNAS? Incidentally, once I restored all of my ReadyNAS settings from the Config Backup, the LED screen started showing my private static IP address just as it’s supposed to do.
2. I restored the settings from the Config Backup that I made before I followed the method described above. I noticed that my Logitech Media Server (aka Squeezebox Server, SqueezeCenter, etc.) was no longer able to obtain “My Apps” installed under my profile on mysqueezebox.com. After several times of installing, uninstalling, disabling, enabling Logitech Media Server, and even restarting the ReadyNAS, I realized that DNS servers were not configured on the ReadyNAS. So, when I restored the ReadyNAS configuration from the Configuration Backup, DNS servers did not get restored. It’s probably a bug in the current firmware 4.2.22. As soon as I added DNS servers, I was able to log in to Logitech Media Server with mysqueezebox.com credentials, and “My Apps” showed up in the Logitech Media Center.
3. This one is major and important! My existing iSCSI target is no longer listed under Volumes -> Volume Settings -> iSCSI. However, if I SSH to the ReadyNAS and navigate to /c/.iscsi, the iSCSI target (file size is 68 GB) is still present there. So, how do I get the ReadyNAS to recognize that iSCSI target and make it available in Volumes -> Volume Settings -> iSCSI? I need to enable it and start using it.
Thanks! - I figured out how to get ReadyNAS to see the existing iSCSI target. The reason that I had and iSCSI target in the /c/.iscsi directory was that I “factory defaulted while preserving the data partition” based on the directions from another thread that is linked to in this thread. I also re-posted these directions a few posts above.
I would never suggest that one should attempt to “factory default while preserving the data partition” method without first having made a full backup of all the data, but in my case, everything went well, so I did not need to use the backup (which I had made right before attempting this method).
When you do backup the iSCSI share, you get both the actual iSCSI file system in the form of a file “target_name>~0” as well as another file named “<target_name>~0.conf”. The latter file is a copy of the file:
/etc/iedt.conf
However, the first line of the “iedt.conf” file is missing from the “<target_name>~0” file.
When you do the “factory default while preserving the data partition” method, it wipes out the “iedt.conf” file but it preserves the “<target_name>~0” file. So, before attempting the “factory default while preserving the data partition” method, you should copy your “iedt.conf” file to a data partition. In fact, you could copy it to the same location where your iSCSI target is located. You can do something like this:
cp /etc/ietd.conf /c/.iscsi/
Once you do the “factory default while preserving the data partition” and then restore the firmware, using the paperclip method, you can copy the “iedt.conf” file to /etc/, like this:
cp /c/iscsi/iedt.conf /etc/
Finally, in FrontView, you should navigate to Volumes > Volume Settings > iSCSI, uncheck “Enable iSCSI support”, click Apply, then check “Enable iSCSI support” and click Apply again. You are done!
At this point, you can use your iSCSI initiator to connect to your iSCSI target.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
