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
- SSH into the NAS and do
#ps -ef
Post the output of this
Also do
# top
And look for anything suspicious that might be using lots of resources. # apt-get update; apt-get install chkrootkit; chkrootkit; #paste the output
I suggest backing up data, factory default, copy data back. Consider the OS compromised and don't trust it.
ProServer:~# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Sep24 ? 00:01:00 init [2]
root 2 0 0 Sep24 ? 00:00:00 [kthreadd]
root 3 2 0 Sep24 ? 00:03:28 [ksoftirqd/0]
root 6 2 0 Sep24 ? 00:00:00 [migration/0]
root 7 2 0 Sep24 ? 00:00:00 [migration/1]
root 9 2 0 Sep24 ? 00:02:15 [ksoftirqd/1]
root 11 2 0 Sep24 ? 00:00:00 [khelper]
root 158 2 0 Sep24 ? 00:00:08 [sync_supers]
root 160 2 0 Sep24 ? 00:00:00 [bdi-default]
root 162 2 0 Sep24 ? 00:00:00 [kblockd]
root 163 2 0 Sep24 ? 00:00:00 [kacpid]
root 164 2 0 Sep24 ? 00:00:00 [kacpi_notify]
root 165 2 0 Sep24 ? 00:00:00 [kacpi_hotplug]
root 272 2 0 Sep24 ? 00:00:00 [khubd]
root 279 2 0 Sep24 ? 00:00:00 [md]
root 380 2 0 Sep24 ? 00:00:00 [rpciod]
root 407 2 0 Sep24 ? 00:19:16 [kswapd0]
root 472 2 0 Sep24 ? 00:00:00 [fsnotify_mark]
root 474 2 0 Sep24 ? 00:00:00 [aio]
root 490 2 0 Sep24 ? 00:00:00 [nfsiod]
root 506 2 0 Sep24 ? 00:00:00 [crypto]
root 523 2 0 Sep24 ? 00:00:00 [kthrotld]
root 568 2 0 Sep24 ? 00:00:00 [scsi_tgtd]
root 600 2 0 Sep24 ? 00:00:00 [scsi_eh_0]
root 603 2 0 Sep24 ? 00:00:00 [scsi_eh_1]
root 606 2 0 Sep24 ? 00:00:00 [scsi_eh_2]
root 609 2 0 Sep24 ? 00:00:00 [scsi_eh_3]
root 612 2 0 Sep24 ? 00:00:00 [scsi_eh_4]
root 615 2 0 Sep24 ? 00:00:00 [scsi_eh_5]
root 628 2 0 Sep24 ? 00:00:00 [bond0]
root 692 2 0 Sep24 ? 00:00:00 [kstriped]
root 695 2 0 Sep24 ? 00:00:00 [ksnapd]
root 696 2 0 Sep24 ? 00:00:00 [kondemand]
root 697 2 0 Sep24 ? 00:00:00 [kconservative]
root 700 2 0 Sep24 ? 00:00:00 [usbhid_resumer]
root 809 2 0 Sep24 ? 00:02:49 [md0_raid1]
root 815 2 0 Sep24 ? 00:00:03 [md1_raid1]
root 822 2 0 Sep24 ? 00:53:16 [md2_raid5]
root 828 2 0 Sep24 ? 01:37:36 [md3_raid5]
root 864 2 0 Sep24 ? 00:01:42 [kjournald]
root 874 2 0 Sep24 ? 00:00:32 [flush-9:0]
root 925 1 0 Sep24 ? 00:00:00 udevd --daemon
root 1423 2 0 Nov18 ? 00:01:37 [kworker/0:0]
root 1921 1 0 Sep24 ? 00:00:00 /usr/sbin/acpid -c /etc/acpi/eve
root 1927 1 0 Sep24 ? 00:00:00 /usr/sbin/raidard
root 1964 1 0 Sep24 ? 00:00:32 /usr/sbin/sshd
root 1973 2 0 Sep24 ? 00:00:00 [kdmflush]
root 2002 2 0 Sep24 ? 00:04:17 [jbd2/dm-0-8]
root 2003 2 0 Sep24 ? 00:00:00 [ext4-dio-unwrit]
root 2064 1 0 Sep24 ? 00:00:00 /usr/sbin/quota_nld
daemon 2069 1 0 Sep24 ? 00:00:00 /sbin/portmap
root 2123 1 0 Sep24 ? 00:00:56 /sbin/syslogd -m 0
daemon 2131 1 0 Sep24 ? 00:00:00 /usr/sbin/atd
root 2136 1 0 Sep24 ? 00:00:03 /sbin/klogd -x -c 3
root 2149 1 0 Sep24 ? 00:01:59 /usr/sbin/cupsd
21 2151 1 0 Sep24 ? 00:00:00 /usr/bin/dbus-daemon --system
root 2153 1 0 Sep24 ? 00:00:24 /usr/sbin/cron
root 2175 1 0 Sep24 ? 00:00:00 /usr/sbin/rpc.rquotad
root 2179 1 0 Sep24 ? 00:00:00 /sbin/rpc.statd -p 32765 -o 3276
root 2201 2 0 Sep24 ? 00:00:00 [lockd]
root 2202 2 0 Sep24 ? 00:00:00 [nfsd4]
root 2203 2 0 Sep24 ? 00:00:00 [nfsd4_callbacks]
root 2204 2 0 Sep24 ? 00:00:21 [nfsd]
root 2205 2 0 Sep24 ? 00:00:21 [nfsd]
root 2207 1 0 Sep24 ? 00:00:00 /usr/sbin/rpc.mountd
nobody 2250 1 0 Sep24 ? 00:03:39 proftpd: (accepting connections)
root 2259 2 0 Sep24 ? 00:00:00 [target_completi]
root 2260 2 0 Sep24 ? 00:00:00 [LIO_rd_mcp]
root 2264 2 0 Sep24 ? 00:06:55 [iscsi_ttx]
root 2265 2 0 Sep24 ? 00:21:26 [iscsi_trx]
root 2266 2 0 Sep24 ? 00:07:10 [iscsi_ttx]
root 2267 2 0 Sep24 ? 00:18:46 [iscsi_trx]
root 2268 2 0 Sep24 ? 00:45:20 [iscsi_ttx]
root 2269 2 0 Sep24 ? 01:52:14 [iscsi_trx]
root 2270 2 0 Sep24 ? 00:00:56 [iscsi_ttx]
root 2271 2 0 Sep24 ? 00:02:20 [iscsi_trx]
root 3198 1 0 Sep24 ? 00:02:13 ifplugd -i bond0 -q -f -d0 -w -I
root 3210 1 0 Sep24 ? 00:02:08 ifplugd -i eth0 -q -f -u0 -d0 -w
root 3248 1 0 Sep24 ? 00:00:00 /usr/sbin/cnid_metad -l log_info
root 3252 1 0 Sep24 ? 00:00:00 /usr/sbin/ntpd
root 3262 1 0 Sep24 ? 00:03:04 /usr/sbin/afpd -U uams_dhx.so,ua
root 3278 1 0 Sep24 ? 00:02:07 ifplugd -i eth1 -q -f -u0 -d0 -w
root 3308 1 0 Sep24 ? 00:01:56 /usr/sbin/minidlna
root 3443 1 0 Sep24 ? 00:17:50 /frontview/bin/monitor_enclosure
admin 3679 1 0 Sep24 ? 00:01:38 /lib/nut/hidups -x lowbatt_pct=5
admin 3687 1 0 Sep24 ? 00:03:22 /sbin/upsd
root 3699 1 0 Sep24 ? 00:03:08 /sbin/upsmon -p
avahi 3718 1 0 Sep24 ? 00:02:26 avahi-daemon: running [ProServer
root 3721 1 0 Sep24 ttyS0 00:00:00 /sbin/getty -L ttyS0 9600 tty1
root 6874 2 0 Nov15 ? 00:00:00 [kworker/1:2]
cisco 7991 1 85 Nov12 ? 20-05:26:00 /usr/local/apache/bin/httpd -
root 9033 1964 0 13:29 ? 00:00:00 sshd: root@pts/1
root 9039 9033 0 13:30 pts/1 00:00:00 -bash
root 9996 1 0 Dec03 ? 00:00:05 /usr/sbin/apache-ssl -f /etc/fro
root 12290 2 0 Sep30 ? 00:53:23 [LIO_fileio]
cisco 13669 1 0 Nov11 ? 00:00:00 /bin/sh ./start 198
root 13676 2 0 18:02 ? 00:00:01 [kworker/u:1]
root 15084 2 0 Dec01 ? 00:00:00 [iscsi_np]
root 17125 2 0 Dec02 ? 00:00:25 [LIO_fileio]
root 17284 2 0 Dec02 ? 00:00:34 [flush-253:0]
root 19411 2 0 21:18 ? 00:00:00 [kworker/u:0]
cisco 20320 32750 0 22:54 ? 00:00:00 /usr/sbin/sshd
root 20562 2 0 Nov12 ? 00:01:16 [kworker/1:0]
cisco 21764 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21765 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21767 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21768 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21769 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21770 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21771 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21772 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21773 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21774 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21775 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21776 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21777 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21778 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21779 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21780 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21781 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21782 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21784 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21785 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21787 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21788 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21791 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21792 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21793 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21795 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21796 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21799 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21802 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21803 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21804 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21805 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21806 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21808 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21809 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21811 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21812 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21813 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21814 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21817 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21819 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21822 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21823 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21824 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21826 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21827 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21830 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21831 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21832 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21834 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21835 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21836 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21838 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21839 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21840 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21841 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21843 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21844 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21845 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21846 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21847 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21848 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21849 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21850 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21852 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21853 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21854 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21855 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21856 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21858 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21859 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21861 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21862 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21863 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21864 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21866 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21869 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21870 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21872 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21873 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21874 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21876 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21877 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21878 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21879 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21880 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21883 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21884 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21889 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21892 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21893 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21895 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21896 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21897 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21899 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21900 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21903 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21904 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21905 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21906 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21908 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21913 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21915 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21918 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21921 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21923 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21924 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21926 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21932 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21936 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21940 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21941 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21942 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21943 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21944 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21946 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21948 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21949 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21950 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21954 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21955 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21956 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21963 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
cisco 21975 20320 0 23:00 ? 00:00:00 /usr/sbin/sshd
root 21976 2 0 23:00 ? 00:00:00 [iscsi_np]
admin 22006 9996 0 23:00 ? 00:00:00 /usr/sbin/apache-ssl -f /etc/fro
root 22012 1 0 23:00 ? 00:00:00 /usr/bin/rsync --no-detach --dae
root 22022 1 0 23:00 ? 00:00:00 /bin/bash /usr/sbin/squeezeboxse
root 22027 22022 10 23:00 ? 00:00:03 /usr/bin/perl /usr/sbin/squeezeb
cisco 22033 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22034 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22035 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22036 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22037 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22038 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22039 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22040 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22041 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22043 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22044 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22045 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22046 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22047 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22048 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22050 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22051 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22052 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22053 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22054 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22056 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22057 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22058 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22060 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22061 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22063 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22067 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22068 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22069 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22070 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22071 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22072 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22073 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22075 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22076 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22077 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22078 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22079 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22080 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22081 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22082 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22083 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22084 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22085 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22086 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22087 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22088 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22089 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22091 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22092 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22093 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22094 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22095 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22096 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22097 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22098 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22100 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22101 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22102 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22103 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22104 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22105 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22106 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22107 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22108 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22109 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22111 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22112 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22113 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22114 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22115 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22116 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
root 22117 1964 0 23:01 ? 00:00:00 sshd: root@pts/2
cisco 22119 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22120 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22121 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
cisco 22122 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
root 22123 22117 0 23:01 pts/2 00:00:00 -bash
cisco 22132 20320 0 23:01 ? 00:00:00 /usr/sbin/sshd
root 22133 22123 0 23:01 pts/2 00:00:00 ps -ef
milli 22543 3262 0 Dec04 ? 00:00:03 /usr/sbin/afpd -U uams_dhx.so,ua
admin 25677 3248 0 Dec04 ? 00:00:00 /usr/sbin/cnid_dbd /c/michelle 7
root 27038 1 0 Oct04 ? 00:03:56 /usr/sbin/nmbd -D
root 27039 27038 0 Oct04 ? 00:00:05 /usr/sbin/nmbd -D
root 27042 1 0 Oct04 ? 00:00:15 /usr/sbin/smbd -D
root 27047 27042 0 Oct04 ? 00:00:00 /usr/sbin/smbd -D
admin 28735 3248 0 Dec04 ? 00:00:00 /usr/sbin/cnid_dbd /c/family 8 5
root 31002 2 0 02:06 ? 00:00:00 [kworker/0:1]
cisco 32664 13669 0 Dec02 ? 00:00:00 /bin/bash ./a 198.61
cisco 32750 32664 0 Dec02 ? 00:00:00 /bin/bash ./a 198.61
top - 23:06:03 up 72 days, 4:00, 3 users, load average: 2.27, 74.60, 146.55
Tasks: 324 total, 3 running, 321 sleeping, 0 stopped, 0 zombie
Cpu(s): 60.8%us, 11.0%sy, 0.0%ni, 27.3%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st
Mem: 1021112k total, 911732k used, 109380k free, 21536k buffers
Swap: 524272k total, 15256k used, 509016k free, 431340k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7991 cisco 20 0 13556 1612 600 R 100 0.2 29130:33 perl 21908 cisco 20 0 2048 832 300 S 1 0.1 0:01.78 sshd
21940 cisco 20 0 2048 832 300 S 1 0.1 0:01.91 sshd 21764 cisco 20 0 2560 1600 456 S 1 0.2 0:02.02 sshd
21799 cisco 20 0 2560 1344 300 S 1 0.1 0:02.04 sshd 21808 cisco 20 0 2560 1344 300 S 1 0.1 0:02.04 sshd
21811 cisco 20 0 2560 1344 300 S 1 0.1 0:02.05 sshd 21831 cisco 20 0 2560 1344 300 S 1 0.1 0:02.07 sshd
21835 cisco 20 0 2560 1344 300 S 1 0.1 0:02.10 sshd 21840 cisco 20 0 2560 1344 300 R 1 0.1 0:02.14 sshd
21841 cisco 20 0 2560 1344 300 S 1 0.1 0:02.09 sshd 21848 cisco 20 0 2560 1344 300 S 1 0.1 0:01.78 sshd
21864 cisco 20 0 2048 832 300 S 1 0.1 0:01.80 sshd 21903 cisco 20 0 2048 832 300 S 1 0.1 0:01.81 sshd
21906 cisco 20 0 2048 832 300 S 1 0.1 0:01.70 sshd 21942 cisco 20 0 2048 832 300 S 1 0.1 0:01.82 sshd
22050 cisco 20 0 1920 660 256 S 1 0.1 0:01.66 sshd 22060 cisco 20 0 1920 660 256 S 1 0.1 0:01.71 sshd
22063 cisco 20 0 1920 660 256 S 1 0.1 0:01.84 sshd 22080 cisco 20 0 1920 660 256 S 1 0.1 0:00.40 sshd
22081 cisco 20 0 1920 660 256 S 1 0.1 0:01.69 sshd 22093 cisco 20 0 1920 660 256 S 1 0.1 0:01.66 sshd
22095 cisco 20 0 1920 660 256 S 1 0.1 0:01.55 sshd 22109 cisco 20 0 1920 660 256 S 1 0.1 0:01.85 sshd
22135 cisco 20 0 1920 660 256 S 1 0.1 0:00.34 sshd 22181 root 20 0 2460 1176 788 R 1 0.1 0:00.58 top
21765 cisco 20 0 2560 1600 464 S 0 0.2 0:02.02 sshd 21767 cisco 20 0 2560 1344 300 S 0 0.1 0:00.69 sshd
21772 cisco 20 0 2560 1344 300 S 0 0.1 0:02.06 sshd 21776 cisco 20 0 2560 1344 300 S 0 0.1 0:00.73 sshd
21778 cisco 20 0 2560 1344 300 S 0 0.1 0:00.72 sshd 21780 cisco 20 0 2560 1344 300 S 0 0.1 0:00.68 sshdchirpa wrote: # apt-get update; apt-get install chkrootkit; chkrootkit; #paste the output
I suggest backing up data, factory default, copy data back. Consider the OS compromised and don't trust it.
Chirpa, could you elaborate on the commands above?
Should I issue them after I back up the data?
How was OS compromised?
No one knew the root password except for the Netgear people who could pull up the ticket!
Why was I asked to provide root password in the first place? I thought it was strange at the time, but I trusted that was the established procedure. I believe I was later told that they really didn’t need my root password to log in. There was some sort of code that they asked me for that I got from the LED screen, I believe, and I think they used that to log in. This whole thing is bizarre!
What about my data? Did the hackers get to that too? I have all kind of sensitive information stored on the ReadyNAS (such as bank accounts, etc.)- It will install checkrootkit and run it. This software looks for common rootkits (hidden exploit tools) on the system.
You can issue them now, may give some clues on how the box is compromised.
The ID they ask for only gets them to the system, they would still need a password to log into if you changed it (EnableRootSSH).
Hopefully your data is okay, but if someone got on the box, its hard to say.
The 'cisco' user account is not something on the system by default. Hopefully there are logs on the system still that may give clues, if they haven't been removed.
Contact Support again, ask for L3, and work with them on it. - Chirpa
Thanks for your advice.
The
username was created by me. I use it for backups to the ReadyNAS from my Cisco gear, and this user only gets FTP access to the shares where I store the backups.cisco
I actually provided the root password to Netgear on their request. So, if someone got a hold of my root password, that was the only place I have ever disclosed my ReadyNAS root password. I thought it was a very insecure and imprudent way for them to get my root password. I have learned my lesson.
Later, a different engineer showed me to to put the NAS in the tech support mode and acquire a code. Supposedly, in the tech support mode, there’s no need to open SSH access to the ReadyNAS from the Internet. Instead, the ReadyNAS sends packets that create dynamic NAT rules and open pinholes in the firewall for Netgear support personnel to log in to the ReadyNAS without having to ask user to open access through the router.
I’ve back up all of my data to an external USB drive using FrontView, and am now ready to factory default my ReadyNAS. However, when I looked at the USB drive, I noticed that every folder contained in the root of each ReadyNAS share was copied to the root of the USB drive. Once I start copying data from the USB drive back to the factory-defaulted ReadyNAS, how do I make sure that appropriate folders are copied to appropriate shares? - The cisco user, did you ever via SSH change the default shell for them? Normal users don't get bash access by default, so FTP guy would be limited to FTP. May have been a ProFTPd exploit somehow that got them escalated privileges. If a shell was set for that user, likely a bruteforce or something let them in. FTP is not secure, sends password in plain text, not hard to sniff it.
- if you left ssh open its very likely the readynas itself was brute-forced into, or some priviledge escalation exploit as chirpa suggested.
I once had my pro hacked/rooted and found it making connections to russia and other strange countries.
This is a perfect case where a 'factory default without losing data' would come in handy.
In any case, I would definately ensure you have backups and triple checked it for any corrupted or compromised files, then do a boot menu factory default.
you may also want to have a close look @ viewtopic.php?f=35&t=35366
viewtopic.php?f=7&t=42835&p=240082&hilit=+hacked#p240082 TeknoJnky wrote:
This is a perfect case where a 'factory default without losing data' would come in handy.
The hacking may not have just affected the OS partition. It's already been explained elsewhere why an option to factory default without losing data is not going to happenmdgm wrote: The hacking may not have just affected the OS partition.
If the system is deleted/formatted and installed from firmware, then it doesn't really matter if something is on the data partition because the system is just going to load the system and mount the data volume, not run anything previously compromised.It's already been explained elsewhere why an option to factory default without losing data is not going to happen
Yes I am well aware of that, that does not mean I can't keep asking. Besides, I don't believe Chirpa officially speaks for the readynas team anymore.
I certainly don't understand why anyone would be *against* the option, if factory defaulting and keeping the data did not solve the problem, you could always do the full default and start with a clean data volume too.
You do realize it takes *DAYS* to backup and restore multiple terabytes of data.. and that is not even using usb, it can take a week or more to restore via usb.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
