Darkmailer/DirectMailer spam script
by admin on Jul.22, 2009, under Email
FYI:
My server was blacklisted because of a ftp hack. The attacker uploaded a spam script which was sending out huge about of spam under a process named coms.cgi.
Please read the following from CBL
You MUST configure your web server to prevent DarkMailer/DirectMailer infections being able to spam the Internet. Take special attention to the references to “SMTP Tweak” below – locking down outbound port 25 by something like “SMTP Tweak” is the only way to permanently prevent your web server spamming the Internet.
We’ve heard rumors that the “SMTP Tweak in cPanel” doesn’t work. But enabling CSF SMTP_BLOCK does.
You can find out more detail on this by doing google searches for “YellSOFT DirectMailer” or “DarkMailer”, including screenshots of the control panel this software installs on your web server (the control panel in Russian).
See, for example, Darkmailer in Wikipedia and this thread in the CPanel Forum.
Note the references to “csf SMTP_BLOCK” and “WHM’s SMTP Tweak”
This detection is that of a spammer who has broken into your web server (usually) via cracked or keylogged FTP credentials. Once they’ve logged in via FTP, they install perl scripts that do the spamming. CPanel and Plesk installations are the most common infectees, but others (including Apache) are also subject to this problem.
ANY web server capable of running Perl scripts (whether Windows, UNIX, Linux, FreeBSD etc) and permits FTP access for customers/users OR EVEN administrators to change their web pages is potentially a victim of this spamware.
You can often identify this (on UNIX/Linux systems) by doing “ps” (process status) and finding many (often 10 or more) long-running processes named “.cgi”, “.php” or “.pl” that are owned by the same user as your web server instance. As an example, one infectee saw 25 copies of a “dm.cgi” program running under his Apache server’s userid.
There are two main versions of this spamware:
In the first, it works by uploading a series of “.php” and “.pl” scripts via FTP (you’ll see this in your FTP logs), and then invoking them via your web server. Once the programs are invoked, they delete themselves from the file system, but remain running.
In the second, the spamware is a “cgi” Perl script that does not delete itself. It can be called anything – eg: “dm.cgi”, “test.cgi” etc.
It will most often be in the cgi-bin directory, perhaps that of an individual user, not the system-wide one.
You also may find various files like “from.txt”, “replyto.txt” etc. There may also be a “sys” directory that contains a lot of “*.mx” files. This all has to be eradicated. Whether these exist depends on the configuration of the DarkMailer/DirectMailer spamware that is infecting your machine.
Dealing with this can be difficult, because as long as your FTP passwords can be cracked (or stolen from an infected web developer’s PC) it can come back at any time.
First: minimize FTP access. Secure/change all passwords. If you can do your customer uploads some other way, turn off FTP, or prevent FTP from writing directly into the web server’s document directory.
It is entirely possible that this spamware can be installed by other means (eg: FrontPage extensions), but we have not heard of it actually being done. Yet….
Second: Find the infection. If it’s the second version (“cgi”), you can find it, remove it and kill any running copies.
If it’s the first version, there’s nothing to find because it’s deleted itself, instead you have to stop the current processes running. The simplest way is to reboot the server. Or, if you can identify _all_ of the rogue processes, killing them should be enough. Just make sure they stay dead.
Third: Configure your system to absolutely prohibit any userid except root or your mail server’s userid (often “mailman” or something like that) from getting access to outbound port 25. In this way, even if you do get infected, the spamware can’t get email out to the Internet.
In the above links, take note of the references to “CPanel/WHM’s SMTP Tweak” and “CSF SMTP_BLOCK” – these are both patches/addon hacks to CPanel that can implement outbound port 25 restrictions. There are many other ways to accomplish this for other web servers, for example, IPTables on Linux, PF on FreeBSD etc.
Entourage/exchange: Access shared calendar
by admin on Jun.01, 2009, under Email
Open a Shared Calendar
To open a shared calendar in Entourage 2004 or Entourage 2008, do the following:
- Open Entourage.
- Click Calendar in the upper left corner of the window.
- Click File > Open Other User’s Folder….
- In the User: box, type the name or the ULID of the person whose calendar you want to open.
- Click OK.
- The shared calendar appears in the calendar list on the left side of the window.
- Select the shared calendar to view it.
Here are some tips:
- In step 2, above, type the last name first.
- Or type the first name only or the last name only.
Horder/IMP: Enable SMTP Auth
by admin on May.31, 2009, under Email
To enable SMTP Auth, you will need to modify the config.php file locate in /config/config.php line 50
Windows location with plesk . C:\Inetpub\vhosts\webmail\horde\config
Change the following line
$conf['mailer']['params']['auth'] = ‘0′;
to
$conf['mailer']['params']['auth'] = true;
**I recommend forcing everyone to authenticate when relaying email from your server. This includes php, asp mailer scripts
Plesk(SPF): Setting Up Support for Sender Policy Framework System
by admin on Feb.23, 2009, under Email
To set up support for Sender Policy Framework on your server:
1. Click the Server shortcut in the navigation pane.
2. Click the Mail icon in the Services group. The server-wide mail preferences screen will open on the Preferences tab.
3. Select the Switch on SPF spam protection check box and specify how to deal with e-mail:
* To accept all incoming messages regardless of SPF check results, select the Create only Received SPF-headers, never block option from the SPF checking mode drop-down box. This option is recommended.
* To accept all incoming messages regardless of SPF check results, even if SPF check failed due to DNS lookup problems, select the In case of DNS lookup problems, generate temporary errors option from the SPF checking mode drop-down box.
* To reject messages from senders who are not authorized to use the domain in question, select the option Reject mail if SPF resolves to fail from the SPF checking mode drop-down box.
* To reject the messages that are most likely from senders who are not authorized to use the domain in question, select the option Reject mail if SPF resolves to softfail from the SPF checking mode drop-down box.
* To reject the messages from senders who cannot be identified by SPF system as authorized or not authorized because the domain has no SPF records published, select the option Reject mail if SPF resolves to neutral from the SPF checking mode drop-down box.
* To reject the messages that do not pass SPF check for any reason (for example, when sender’s domain does not implement SPF and SPF checking returns the “unknown” status), select the option Reject mail if SPF does not resolve to pass from the SPF checking mode drop-down box.
4. To specify additional rules that are applied by the spam filter before the SPF check is actually done by the mail server, type the rules you need in the SPF local rules box.
We recommend that you add a rule for checking messages against the open database of trusted senders, for example, ‘include:spf.trusted-forwarder.org’. For more information on SPF rules, visit http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt.
5. To specify the rules that are applied to domains that do not publish SPF records, type the rules into the SPF guess rules box.
Specifying a/24 mx/24 ptr gives good results for spam filters scoring Received-SPF lines.
6. To specify an arbitrary error notice that is returned to the SMTP sender when a message is rejected, type it into the SPF explanation text box.
If no value is specified, the default text will be used as a notification.
7. To complete the setup, click OK.
Email: Domain has demonstrably > bogus MX
by admin on Jan.16, 2009, under Email
Domain has demonstrably > bogus MX
check your mx record and ensure they are actual mail servers.
