Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I posted this a few days ago on a cPanel forum website, but nobody has given me any feed back. I'm hoping that viewers here can let me know.
A few days ago I was getting hourly reports that two of the sub-domains on my CENTOS 5.4 server running cPanel 11.24.4 under WHM 11.24.2 had suspicious processes running. I couldn't figure out what they were, so I rebooted the server. Those messages have not returned.
However, in my Logwatch email, in the Named section, I have the following messages;
**Unmatched Entries**
/etc/named.conf:13: using specific query-source port suppresses port randomization and can be insecure.: 1 Time(s)
adjusted limit on open files from 1024 to 1048576: 1 Time(s)
network unreachable resolving './NS/IN': 2001:500:2f::f#53: 1 Time(s)
network unreachable resolving '1.115.74.204.sbl.spamhaus.org/TXT/IN': 2001:7b8:3:1f:0:2:53:2#53: 1 Time(s)
network unreachable resolving '1.193.124.98.sbl.spamhaus.org/TXT/IN': 2001:7b8:3:1f:0:2:53:1#53: 1 Time(s)
... 1,071 more entries in between ...
network unreachable resolving 'zupuctv.cn/NS/IN': 2001:dc7:1000::1#53: 1 Time(s)
network unreachable resolving 'zupuctv.cn/NS/IN': 2001:dc7::1#53: 1 Time(s)
the working directory is not writable: 1 Time(s)
using default UDP/IPv4 port range: [1024, 65535]: 1 Time(s)
using default UDP/IPv6 port range: [1024, 65535]: 1 Time(s)
using up to 4096 sockets: 1 Time(s)
I don't understand what's happening or what I should do about it. Any suggestions will be deeply appreciated.
That appears to be the signature of a DDOS attack against an authoritative nameserver, and I believe your servers are participating in that attack:
Quote:
"...is actively under a DOS where lots of people's dns servers around the world are being queried with bogus sourced dns requests not from port 53 for 'NS? .'. This then bounces back to their authoritative nameservers which are getting traffic overload." http://markmail.org/message/ydiqnztzmz5qmusf
Thanks for the reply. I did not adjust the limit of the open files, so I guess the hackers did. I read through the links you provided and about BCP 38, but this stuff is really over my head.
I am wondering if there is an IP address that I could ban which would stop my participation in the DoS attacks, or if there's a port I can exclude.
I want to be a good citizen in the Internet community, as long as I have the skill set to accomplish this. I did run a grep looking for a file that had one of the IP addresses that was in the warning message, but never found one. Do you think this list of "network unreachable resolving" is stored somewhere on my system?
I am wondering if there is an IP address that I could ban which would stop my participation in the DoS attacks, or if there's a port I can exclude.
Since the DDOS seems to be targeting an authoritative DNS nameserver, blocking that nameserver's IP address would also block your user's access to the domains served by that nameserver. Better to find and kill the malware. And make sure the hackers can't sneak back in by the same door they used last time.
Please take a few steps back and realise the OP indicated his lack of knowledge of GNU/Linux. He only presented a shred of information in his OP. I suggest you don't dwell on that for too long as none of it adheres to the kind of information we would like to see used in a default examination of a (perceived) compromised system. If you don't know what I'm talking about feel free to search the Linux Security forum for any incident handling threads and feel free to ask.
Quote:
Originally Posted by smeezekitty
probably some sort of malware that launnches a DDOS.
get your server offline ASAP.
This is the Linux Security forum, not your /General playground: we deal with facts, not guesswork. If you want to contribute to an investigation in a way that is constructive for the OP please read some incident response threads/docs, ask what you should do or else please don't post. Thanks for understanding.
Quote:
Originally Posted by WebsiteCaptain
A few days ago I was getting hourly reports that two of the sub-domains on my CENTOS 5.4 server running cPanel 11.24.4 under WHM 11.24.2 had suspicious processes running. I couldn't figure out what they were, so I rebooted the server. Those messages have not returned. (..) I don't understand what's happening or what I should do about it.
If you don't understand things then the best thing to do is to do nothing. Ask for advice before doing anything. By rebooting you wilfully destroyed volatile user, process and network data. Also do not wait days before asking for advice.
Here's a list of the unique process names from that list...does anything look unusual?
Note it would be trivial to modify argv[0] to make a process appear as if it is running as something else. Most current toolkits come with a default tool to do just that.
What would be in order would be to:
- contain the situation by shutting down all unnecessary services (one only needs SSH access) and raising the firewall to only allow traffic to and from the administration IP (or range),
- a complete filesystem integrity check (Aide, Samhain or even tripwire, else the package management tools that come with the distribution, else verification against packages from a trusted repo),
- a scan of everything else installed outside of the scope of package management, temp dir files, auth, logs.
...none of it adheres to the kind of information we would like to see used in a default examination of a (perceived) compromised system. If you don't know what I'm talking about feel free to search the Linux Security forum for any incident handling threads and feel free to ask.
OK, I did a little browsing, and see that you've expressed this frustration before:
Quote:
I have little time to spend but I also realize LQ is low on members with proper background knowledge and Incident Response capability (considering only those members who have demonstrated it and as I want to see it, namely: helpful, structured and of a certain quality). http://www.linuxquestions.org/questi...1/#post3691804
I'm amenable to helping where I can, but I'm still learning too. I know enough to be dangerous, and try not to post where my lack of knowledge exceeds my knowledge. Perhaps this would be a good time to compile a "best practice" incident response procedure?
OK, I did a little browsing, and see that you've expressed this frustration before
+1, good you've found that post! The thread kind of outlines what we would like to know from the OP.
Quote:
Originally Posted by Jim Bengtson
I'm amenable to helping where I can, but I'm still learning too.
...which is an excellent starting point. That's why I'm just offering you remarks and pointers. I'd figure you'd be able to get things going from there, right?
Quote:
Originally Posted by Jim Bengtson
Perhaps this would be a good time to compile a "best practice" incident response procedure?
Sadly enough we're still pointing to the http://web.archive.org/web/200801092...checklist.html (which I'd appreciate people pointing to if they do not have any IR caps or wait for help), the rest is pretty much "documented" (heh) in the threads we've posted here since 2001 ;-p Collating it seems useful but time isn't on my side (even the Rootkit Hunter 1.3.6 release deadline keeps slipping back). If you feel up for doing it I'll help you with it.
If you feel up for doing it I'll help you with it.
I'll do what I can, as time allows. This looks like a good starting point:
Quote:
In any type of incident the investigator should be focused on obtaining the following information:
1. System date and time
2. Who is logged in to the system (including remote-access users, if applicable)
3. Open network ports
4. Applications associated with the open ports
5. All running processes
6. Timestamps and checksums on all files
7. Systems that have current or had recent connections to the system
8. System event logs
9. Possible forensic duplication of system hard drive and/or physical memory
It is very important to preserve and not destroy or alter any evidence obtained during the initial response. While it is preferred that no changes occur to the system, depending on the tools that are used, there are times when footprints are left by the investigator. Complete documentation of the steps taken must be kept in order to verify the data that was obtained.
Maybe we should break this out of the current conversation and create a LQ Wiki page for it? Continuing here might confuse the OP we're trying to help.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
