Posts filed under 'Linux'
On our Internet connected servers, besides using iptables to limit incoming connections, we are using TCP wrappers (hosts.allow and hosts.deny) to reject connections originating on untrusted networks.
Probably you’re already using iptables to block incoming traffic on port 22 (ssh), which is fine but what we want to do is increase security by using a more persistent method for blocking traffic. Don’t get me wrong, iptables’ rules can (and should) be made persistent but sometimes while trying new rules some key ports can be left open.
Basically, you have to modify two files: /etc/hosts.deny (to reject connections) and /etc/hosts.allow. The syntax for /etc/hosts.allow and /etc/hosts.deny files is as simple:
daemon : client_hostname_or_IP
The idea is to block all incoming traffic and just allow trusted IP addresses:
/etc/hosts.deny
# Block all incoming ssh traffic
sshd : ALL
/etc/hosts.allow
# Accept ssh connections from trusted networks
sshd : trusted_ip_1
sshd : trusted_ip_2
sshd : trusted_ip_3
Just don’t forget to include all your trusted IP addresses at hosts.allow, or you’ll be left out of your server next time you try to log in.
There are many other services that can be blocked using the presented method, take a look at you daemon’s documentation. Even if TCP wrappers are not supported, the daemon might provide an alternative blocking method.
August 23rd, 2006
Running a check on Apache’s default logs (/var/log/httpd/access_log), I found attempts to exploit the server thru a “backdoor” in Horde.
I haven’t fully checked what could be done with this exploit but certainly leaving the affected script unprotected is an open invitation for trouble.
To check it, just request the following to any webmail domain on your server (the following check if completely harmless as it will only run uname -a and show it’s results on the browser):
http://webmail.yourserver.com///horde//services/help/index.php?show=about&module=;%22.passthru(%22uname%20-a%22);’.
With some imagination and careful URL encoding, you can get commands to be executed under Apache’s account and privileges.
What I’ve done until further investigation is performed, is to modify the affected script so that nothing happens when the script is called (so far seems like the only downside is Horde’s Help system not working).
The affected script is index.php, located at /usr/share/psa-horde/services/help.
For some debugging, I’ve included the following code right before Horde’s code:
<?php
$request = print_r($_REQUEST, true);
$server = print_r($_SERVER, true);
mail("youremailaddress@example.com", "HORDE BOGUS REQUEST ".date("r"), "Requestn".$request."Servern$server", "From: "Server" <youremailaddress@example.com>");
die();
?>
That will send you by email any requests with headers to the script, be those legitimate or attempts to exploit your server.
I will update the topic as soon as I have time to correct the script.
This was verified with psa-horde-3.0.5-rhel4.build75050824.12.
UPDATE: The problem is solved on Plesk’s 7.5.4 build 75060413.12, which includes psa-horde-3.1.1-rhel4.build75060413.11.
August 13th, 2006
Recently I noticed that a new spider was going thru all of our sites, but there was something special about this one:
1. I couldn’t find any information for a web search engine, directory or anything similar that would explain a sort of legitimate usage of the recovered information.
2. It goes thru the site at an incredible page rate (about 120 files per minute…)
3. The spider seems to be poorly programmed. The logs show the spider going thru CSS, GIF, JPG and MPG files.
4. Some sites on the Internet mention a raise in the amount of spam after being visited by the psycheclone spider.
With an IP address lookup, I found that the requests come from McColo Corporation, with is assigned the range 208.66.192.0 to 208.66.195.255, so before taking any actions regarding psycheclone’s requests, I contacted McColo’s support service. Let’s see if they respond to my request. (At the time of this writing, there wasn’t an answer)
In the meantime, if you think psycheclone is a threat or problem for your server, you could block their requests with the following two methods:
Block McColo’s complete IP range using iptables
You could do this for port 80 (HTTP) or for all ports. Consider that this solution might keep you from providing services to legitimate users on that IP range.
To block all traffic:
iptables -I INPUT -s 208.66.192.0/255.255.252.0 \
-j REJECT --reject-with icmp-port-unreachable
To block only port 80:
iptables -I INPUT -s 208.66.192.0/255.255.252.0 \
-p tcp -m tcp --dport 80 -j REJECT \
--reject-with icmp-port-unreachable
If you decide to keep the iptables rules, don’t forget to make them permanent!
Modify your PHP scripts to stop serving content to the spider
With this approach, you’ll have to modify your PHP scripts so psycheclone’s request is redirected to another server (in this case McColo’s):
<?php
/* Insert at the beginning of the PHP page */
$reqAgent = $_SERVER['HTTP_USER_AGENT'];
if (stristr($reqAgent, "psycheclone") == TRUE) {
header("Location: http://mccolo.com/english/contact.html");
exit();
}
?>
June 26th, 2006
While I was designing a system that needed to send mass-customized emails from PHP, I faced two problems: a) change the envelope address (Return-path: header) and b) (most important) avoid overloading the server when sending the messages because of virus check.
Basically, I wanted to use a different sendmail configuration file from PHP to skip the relay-mail virus check from Amavis.
Please note that this script is to be called by a cron job as root to limit the number of messages sent on a batch; when getting the records from a database and sending the mails it’s quite easy to overload the server and get sendmail to stop accepting messages/connections.
Add the necessary logic to perform any additional checks, get the DB records and customize the content of the message accordingly.
This is the base code that will allow you to use a different sendmail configuration file:
<?php
$messg = "Here we put the content of the message.";
$sender = "email@example.com";
$sendmail = "/usr/sbin/sendmail -t -f $sender -C /etc/sendmail.nocheck.cf";
/*
Notice that sendmail is receiving three params:
-t Scan the To:, Cc:, and Bcc: from the message itself
-f Change the envelope (Return-path:) of the message
-C Use a different configuration file for sendmail, in this case the config file
skips the virus check
*/
$fd = popen($sendmail, "w");
fputs($fd, "To: recipient@example.comrn");
fputs($fd, "From: "Sender Name" <$sender>rn");
fputs($fd, "Subject: Finallyrn");
fputs($fd, "X-Mailer: Mailer Namernrn");
fputs($fd, $body);
pclose($fd);
?>
June 17th, 2006