What attack could this be???

darrel · 02-14-2005, 05:57 PM

Hello All,

I have a security question. I’m running Red Hat 9.0 on an Intel box and it looks like yesterday I suffered some sort of Trojan or DDOS attack. The network came to a halt! When running the TOP command I found that Apache was eating 96% of the CPU and the command was 'm'.

Even after disconnecting from the network (I unplugged the Ethernet) the Firestarter Firewall GUI was showing attempts from my own IP Address for Trin 00, Trinity 3, Back Orfice and ms-rpc. A reboot seemed to stop it for the time being.

Can anyone tell me what it might have been??

I’m running the Firestarter Firewall and have only allowed ports open for SSH, httpd, smtp and DNS. However a netstat –l (below) shows open ports on 651, 32768. I have Myql databases running as well. Should I be concerned?? Any ideas or advice would be much appreciated.

BTW Apache, mysql, named & sendmail have been updated using up2date

Thanks in advance
Darrel

Code:

 
[root@www]# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 *:mysql                 *:*                     LISTEN      
tcp        0      0 *:x11                   *:*                     LISTEN      
tcp        0      0 my.domian.com.au  :http *:*                     LISTEN      
tcp        0      0 my.domian.com.au:domain *:*                     LISTEN      
tcp        0      0 localhost.locald:domain *:*                     LISTEN      
tcp        0      0 *:ssh                   *:*                     LISTEN      
tcp        0      0 *:smtp                  *:*                     LISTEN      
tcp        0      0 localhost.localdom:rndc *:*                     LISTEN      
tcp        0      0 *:https                 *:*                     LISTEN      
udp        0      0 *:32768                 *:*                                 
udp        0      0 *:651                   *:*                                 
udp        0      0 my.domian.com.au:domain *:*                                 
udp        0      0 localhost.locald:domain *:*  

mydomian.com.au has been substituted for the real address

nonzero · 02-14-2005, 09:23 PM

/var/log/security
/var/log/messages
/var/log/httpd
/var/log/apache/###_log
adnauseum

nz

darrel · 02-14-2005, 10:45 PM

Quote:

Originally posted by nonzero
/var/log/security
/var/log/messages
/var/log/httpd
/var/log/apache/###_log
adnauseum

nz

Yep, looked in all the usual spots but nothing jumps out at me. I did nmap of the machine and I get this:

Code:

22/tcp     open        ssh
25/tcp     open        smtp
53/tcp     open        domain
80/tcp     open        http
443/tcp    open        https
651/tcp    filtered    unknown
3306/tcp   open        mysql
6000/tcp   open        X11

I'm very concerned about port 651 because I have explicitly blocked it through the firewall.

/var/log/messages is full of these statements ....
Feb 15 16:50:38 www kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:4b:aa:50:38:08:00 SRC=172.23.0.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=48202 PROTO=UDP SPT=67 DPT=68 LEN=308

/var/log/secure has only allowed SSH entries
var/log/httpd/domain-access_log has regular page views

Any other thoughts ... ????/

Capt_Caveman · 02-15-2005, 06:02 AM

Use lsof -i to get a listing of what files/PIDs have those ports open. If you don't get a filename, trace back the PID in /proc/<PID>/cmdline.

Verify the integrity Apache/httpd binary with 'rpm -V httpd' , in fact you may want to verify everythng with 'rpm -Va'. I'd also recommend download chkrootkit or rootkit hunter and running a scan on the system.

Fwiw, port 32768 is usually the first unpriveldge port used by default in linux so that may not mean much, but the apache/m oddness is usually an indication of eggdrop (an ircbot).

Also a good idea to look through the system for abnormal directories and hidden files (especially in /tmp), as well verify that /etc/passwd looks normal, check the output of 'last' for odd logins.

Those kernel log msgs look like standard bootp/dhcp broadcasts from 172.23.0.1, does that IP look familiar? It is IANA reserved and it's broadcast, so it's got to be locally generated.

btw, Redhat stopped supporting RH 9.0 almost a year ago, so if you've been relying on Redhat for updates using up2date, then your system has been getting updated for almost a year.

darrel · 02-16-2005, 05:01 PM

I just want to say thanks for the great suggestions for checking my install

It's very very much appreciated.

As for the machine in question, I checked the tmp directory and deleted two files, cback.pl and bot.txt and although I looked inside them I couldn't quite understand what they did. I figured if they are tmp it wouldn't hurt to delete them (especially with names like that)!

I tried to run lsof but although it was in the /usr/sbin/ it wouldn't run. So I download and installed from scratch, rebooted and everything seems ok for the time being. I also downloaded chkrootkit and run it - it didn't find anything.

What would be the best thing to do considering I'm running Red Hat 9.0 should I (and can I) upgrade to Fedora and would that break many of my existing services eg http, sendmail & mysql?

Thanks again
Darrel

Capt_Caveman · 02-16-2005, 05:25 PM

Did you re-install the whole system or just the lsof -i binary? It's starting to sound like you definitely need to do a complete re-install. The presence of those cracking tools in /tmp indicate that someone had at least system access and with your system not being updated for a year there would be multiple vulnerabilities that would allow privilege elevation (getting root fairly easily). The fact that you couldn't run lsof, even though it was installed on the system is definitely reason to be very concerned.

If you really want to stick with Redhat 9.0, you can ditch up2date and use YUM to grab updates from The Fedora Legacy Project which does maintain a repository of current updates for Redhat 9. There are instructions on their site for modifying the yum.conf file so that it points to the proper repository, then have yum automatically update your system nightly. You can back up and copy over necessary DBs and configs that you can manually inspect, but don't backup any binaries from the system.

scattered · 02-16-2005, 08:12 PM

Quote:

Originally posted by darrel
...
/var/log/messages is full of these statements ....
Feb 15 16:50:38 www kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:4b:aa:50:38:08:00 SRC=172.23.0.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=48202 PROTO=UDP SPT=67 DPT=68 LEN=308
...
Any other thoughts ... ????/ [/B]

They are DHCP broadcast requests, but the source IP is

NetRange: 172.16.0.0 - 172.31.255.255
CIDR: 172.16.0.0/12
NetName: IANA-BBLK-RESERVED
NetHandle: NET-172-16-0-0-1
Parent: NET-172-0-0-0-0
NetType: IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment: This block is reserved for special purposes.
Comment: Please see RFC 1918 for additional information.

not supposed to be on the Internet. If that source IP is coming from outside,
your firewall rules need to block them. I'd be re-installing if I felt the machine
was compromised, assuming you have separate /home, copy /etc and your
kernel configs somewhere safe and nuke the OS partition with dd if=/dev/zero ...
format and reinstall.

Clark Bent · 02-24-2005, 08:34 PM

Most interesting thread. As eluded to previously, those IP address ranges are not publicly routed. They are private IP addresses within the class B range. And the protocol in use is UDP. I don't see how that could even be spoofed. Would love to hear a update on this one.

peacebwitchu · 02-26-2005, 12:15 PM

More than likely 32768 is used by bind, you can verify this in Bind reference manual( ARM).

darrel · 02-26-2005, 04:37 PM

Hello All,
Thanks for all your help.. it is much appreciated!!!

After recieving all the great advice from this forum, I realised I just couldn't be confident that the machine wasn't still compromised. So I did a back up and then did a complete/fresh install of Fedora Core 3, updated every package on the system, new root passwords etc ... Hopefully everything is ok now. Everything seems to be going well again

Thanks
Darrel

Capt_Caveman · 02-26-2005, 10:10 PM

Cool. Make sure to spend some added time securing your system now, so that you don't end up facing the same problems later on. Turn off un-necessary services and do yourself a big favor by enabling nightly YUM updates with 'chkconfig yum on'. Also remember that fedora is releasing new versions approx every 6 months and currently plans to support them on a "three-and-out" basis, meaning that you'll need to find a new place for upgrades after 2 new versions have been released.