64 bit web servers are a significant step up in computer architecture and deliver higher performance, security and reliability of hosted web applications on such servers.  Here is the hardware configuration of our new 64 bit Linux (RHEL 5) server:

• Quad Core Intel Xeon 5520 Processor
• 6 GB DDR 1333 Registered RAM
• 64 bit RHEL 5 OS and applications
• Raptor 300 GB 10K RPM HDDs
• RAID 10 Disk Array
• Plesk 9.5 Control Panel

This shiny new 64 bit server is ready to host your website and unleash the power of the 64 bit computing platform for your website, email and hosted apps. You can view our 64-bit Linux Hosting Plans online get in touch with us for any queries on our plan features.

Reference: Wikipedia – 64 bit

Note: There is a rating embedded within this post, please visit this post to rate it.

Follow the below steps redirect to the 80 port.

Login to your Linux server as super user i.e. ‘root’.

Create a file under /etc/xinetd.d/ folder as http_redirector

# vi /etc/xinetd.d/http_redirector

Now add the following entries in the files.

service http_redirector
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
user = root
wait = no
port = 80
redirect = 127.0.0.1 8089
log_type = FILE /tmp/httpredirector.log
}

Restart the xinetd service.

# service xinetd restart

That’s all you are done.

To hide the information, add/change the following two apache directives in Apache configuration file /etc/httpd/conf/httpd.conf

ServerTokens ProductOnly
ServerSignature Off

Now you need to restart your web server using the following command

# service httpd restart

Now the output for apache header looks like below

Server: Apache

Hide PHP Version in Apache from remote user’s requests

In your php.ini (the typical path is /etc/php.ini) locate the line containing “expose_php = On” and set it to Off:

expose_php = Off

Now you need to restart your web server using the following command

# service httpd restart

After making this change PHP will no longer add its signature to the web server header. Though, this step in itself will not make your server more secure, it will prevent remote hosts to easily see that you have PHP installed on the system and what version of Apache you are running on your web server.

At Diadem Technologies we take extreme precaution and safeguard of our mailing services to ensure continuous and reliable availability of our mailing services to our clients. We have all our servers located in the world’s leading datacenter which has a very secure environment with various levels of physical and hardware based protection to keep your data safe from different attacks and vulnerabilities. The servers have multi core Xeon processers and have RAID10 array of HDDs for complete data redundancy so that a hard disk crash would not affect the server operations and would not result in any loss of data on the server.

The servers are restricted to be accessed via the Public network so that no unauthorized access to the servers can be made. We use a secure encrypted VPN (virtual private network) connection that connects to the private backend network and hence the servers are only accessible to the legitimate admin users at our end.

For network level protection we have in place perimeter hardware firewalls by CISCO systems to block external threats along with CISCO GUARD DDOS (Distributed Denial of service) and CISCO Tipping point IPS (Intrusion prevention system). CISCO GUARD DDOS protects from requests that make a computer resource unavailable to its intended users and brings down the server to halt. CISCO Tipping point IPS is an advanced Intrusion prevention system that is used extensively in critical networks to monitor network and/or system activities for malicious or unwanted behavior and can react, in real-time, to block or prevent those activities. Network-based IPS, for example, will operate in-line to monitor all network traffic for malicious code or attacks. When an attack is detected, it can drop the offending packets while still allowing all other traffic to pass.

After passing through the various levels of security mentioned above we have more additional security features on the physical server for protecting the server /server applications and the inbound and outbound mails.

• At the server we have robust software based firewalls that have been customized to add another level of security in the server.
• We have SMTP connection tracking system to check all the connections that are being made to the server for sending or receiving mails. At this level various parameters of a mail are checked like if the IP of the sender is blacklisted in any third party Anti SPAM website, if the sender has a valid mail server, if the reverse DNS of the sender email server is valid.
• We have enabled greylisting on the server to cut down on SPAM mails before they can enter the server. We have advanced content filtering along with anti spam software, antivirus, malware and anti root kit signatures that are updated regularly to block emerging threats immediately.
• Once the mail is scanned with the above filters, we implement a new and unique technique to authorize defined servers only to server your emails through the use of SPF records. Any other servers would not be able to send or receive any mail on behalf of your domain. This will cut down spoofing of your emails.
• At the last stage we have SMTP authentication enabled that allows mails to be relayed through our servers only for those who are intended to send mails hence reducing the unwanted relaying of mails.

The above illustration highlights our commitment to ensure that we provide our clients with the best of breed technologies to ensure spam free, virus free, efficient and continuous availability of our mailing services for their operations.

If you are interested in knowing more about our web hosting services and plan details, you can look us up at www.diadem.co.in.

]]> http://www.diademblogs.com/linux/email-and-server-security-features-with-diadem-servers/feed 0 http://www.diademblogs.com/linux/alternate-smtp-port http://www.diademblogs.com/linux/alternate-smtp-port#comments Sat, 12 Sep 2009 04:20:58 +0000 ankur http://www.diademblogs.com/?p=518 Nowadays, quite a few ISPs block port# 25 which is the default SMTP port for relaying email for security purposes, so you need to configure an alternative port for SMTP connection.

Use instructions below to configure an additional alternate SMTP port in a Plesk Server running in Redhat Enterprise Linux Version 4/5 or CentOS version 5 in Qmail Server.

Choose any unused port and add it to the /etc/services file, for example:

smtp_alt        8425/tcp        mail            # Alternate SMTP Port
smtp_alt        8425/udp        mail            # Alternate SMTP Port (optional)

Make a copy of /etc/xinetd.d/smtp_psa to /etc/xinetd.d/smtp_psa_alt and correct service line within new file:

service smtp_alt

Below is a sample of smtp_psa_alt file.

service smtp_alt
{
socket_type     = stream
protocol        = tcp
wait            = no
disable         = no
user            = root
instances       = UNLIMITED
server          = /var/qmail/bin/tcp-env
server_args     = -Rt0 /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var
/qmail/bin/cmd5checkpw /var/qmail/bin/true
}

Restart xinetd and Qmail

service xinetd restart
service qmail restart

SMTP connections will be accepted on the both standard and 8025 ports. You may also need to reconfigure Horde IMP (webmail) settings so it uses the alternative SMTP port too. This can be done editing the following file in Horde webmail:

/etc/psa-horde/imp/servers.php file under smtpport parameter for both IMAP and POP3 servers.

In name, as well as operation, greylisting is related to whitelisting and blacklisting. What happens is that each time a given mailbox receives an email from an unknown contact (ip), that mail is rejected with a “421 Envelop failure”-message (This happens at the SMTP layer and is transparent to the end user). This, in the short run, means that all mail gets delayed at least until the sender tries again – but this is where spam loses out! Most spam is not sent out using RFC compliant MTAs; the spamming software will not try again later.

Spammers often adapt to this technique but that does not really make greylisting useless. This delay in new sender contacts also gives you a lot of extra power. This may be an hour, but in this hour there is a large chance that the mass mailer/spammer has been identified by the more conventional anti-spam software. Thus, when he retries it, is likely that we will know that the mail is a SPAM mail.

Three pieces of information from a delivery attempt, referred to a as a triplet are used to uniquely identify the relationship between a sender and a receiver:

• The Envelope Sender.
• The sending host’s IP address.
• The Envelope Recipient.

Perhaps the most significant disadvantage of greylisting is the fact that, like some other spam mitigation techniques, it destroys the near-instantaneous nature of email people have come to expect. A customer of a greylisting ISP can not always rely on getting every email in a pre-determined amount of time. However, the original specification for email states that it is not a guaranteed delivery mechanism and not an instantaneous delivery mechanism. This means that greylisting is a perfectly legitimate process and does not break any protocols or rules. Traditionally, greylisting is very good at flushing out poorly configured mail servers that cannot maintain state, queue email correctly, or retry delivery within a reasonably short time. Mail servers that are properly configured and fully conform to SMTP generally have no problems with greylisting techniques and delays are very small so as not to be a problem.

Some MTAs, upon encountering the temporary failure message from a greylisting server on the first attempt, will send a warning message back to the original sender of the message. The warning message is not a bounce message, but it is often formatted similarly to one and reads like one. This practice often causes the sender to believe that the message has not been delivered, when in fact the message will be delivered successfully at a later time.

Also, legitimate mail might not get delivered if the retry doesn’t come within the time window the greylisting software uses, or if the retry comes from a different IP address than the original attempt. When the source of an email is a server farm or goes out through an anti-spam mail relay service, it is likely that on the retry a server other than the original server will make the next attempt. Since the IP addresses will be different, the recipient’s server will fail to recognize that the two attempts are related and refuse the latest connection as well. This can continue until the message ages out of the queue if the number of servers is large enough. This problem can partially be bypassed by identifying and whitelisting such server farms in advance. However, it is not possible on a distributed network the size of the Internet to maintain a complete list of all such server farms.

It needs to be noted that such SMTP delivery server farming techniques can be construed as breaking RFCs detailed above since the original sending machine has absolved itself of the responsibility of mail delivery by tossing it back into the pool, which breaks the state of the mail delivery process.

Assuming you already have an existing domain (example.com) with the primary FTP user (jack) with password (schmidt) with home directory (/var/www/vhosts/example.com), and you wish to create additional ftp users (jill and bob) with the same access privileges as jack:

Procedure:

Login to server via SSH as root.

Issue the shell command:

#cat /etc/passwd |grep ‘jack’

This will show you a line similar to the following:

jack:x:10041:10001::/var/www/vhosts/example.com:/bin/false

The first number (after the 2nd colon : ) is 10041, so this is the UID of user jack. You will need this in the ‘useradd’ lines since useradd wants a number for the UID.

The second number (after the 3rd colon : ) is 10001, this is the GID (psacln), we won’t need that right now.

Then run the following shell commands to create the users and passwords:

#useradd -u 10041 -o -d /var/www/vhosts/example.com -g psacln -s /bin/false jill
#useradd -u 10041 -o -d /var/www/vhosts/example.com -g psacln -s /bin/false bob
#passwd jill (enter the new password and confirm it, does not have to be the same as jack’s)
#passwd bob (enter the new password and confirm it, does not have to be the same as jack’s)

You should now be able to use an FTP client to login with that user’s name and password.

User jill and bob should be able to see the example.com docroot just as user jack can. You should NOT be able to browse above the example.com docroot directory. All 3 users should have the same access to the files since they belong to the same group, so no matter which of the users created or edited the file(s), all should be able to access/edit/whatever the same files.

(NOTES: Since these are users defined at the OS level, when connecting with an FTP client, they would login with username ‘jill’, ‘bob’, or ‘jack’. They would NOT use ‘jill@example.com’. This also means that USERNAMES MUST BE UNIQUE.)

Subdomain FTP users:

If you wanted to change their default directory and limit them to a Plesk created subdomain docroot, in the useradd line above, you would change “/var/www/vhosts/example.com” to “/var/www/vhosts/example.com/subdomains/subname”. So if you wanted to create the same users, but for a subdomain called ‘admin’:

Then do the following shell commands to create the users and passwords:

#useradd -u 10041 -o -d /var/www/vhosts/example.com/subdomains/admin -g psacln -s /bin/false jill
#useradd -u 10041 -o -d /var/www/vhosts/example.com/subdomains/admin -g psacln -s /bin/false bob
#passwd jill (enter the new password and confirm it, does not have to be the same as jack’s)
#passwd bob (enter the new password and confirm it, does not have to be the same as jack’s)

Deleting an FTP user:

#userdel jill

(Note: this will not delete any files unless you use the -r option which you probably don’t want to do if they are sharing files!)
Note: There is a rating embedded within this post, please visit this post to rate it.