Disabling root ssh is very good Idea

Found a few good sites with too much information: They all boil down to giving SUDO access to one of your other accounts and disabling ssh access for the root account. Your can still login as root through your datacenters provisioned KVM since it emulates a local keyboard and video display. In case you ever get locked out or your IP banned for some reason.

As a failsafe, you might consider putting the public IP of a trusted source in the
/etc/hosts.allow file in case you get locked out accidentally. That why you know that all you need to do is go to that place to restore access to your account. It could be your office's public IP, or campus university public IP, or just another server you have control over.

Once you have SUDO access on another account:
Just edit /etc/ssh/sshd_config and make sure this line PermitRootLogin no , reads as so.

Upgraded most of my boxes to Debian 7 Wheezy and ISPCONFIG

For the most part I'm happy to be on Debian 7 with ISPCONFIG, as DTC was taking forever to update their code to make it Debian 7 compatible; and my clients were installing software requiring the latest PHP and MYSQL. So I really didn't have much of a choice in the matter.

I like and dis-like a few things about ISPCONFIG.

LIKES:

• Offers and Handles multiservers very well.
• easy to install guides
• well documented
• many howto guides for just about every option
• cheap billing module

DISLIKES:

• creating a website or sub-domains does not automatically create a DNS entries/mail domains/etc, you have to expect your customers to know what they are doing. It's not as user-friendly in that aspect. It would be nice if it offered a dummy mode or wizards for users. In this aspect DTC was nice to do everything for you when you added a domain. Then you just had to do any customizations required, but the basics where created for you.

Hacked by FreshJoomlaTemplates.com

Beware with some of the free templates from freshjoomlatemplates.com as they have scripts embedded in them that can take over your site and use it to send spam.

I already had a bad experience that cost me days of downtime and having to move my server to a different colo.

The up-side is that my new service has never been interrupted by DDOS attacks so far.

Limiting recursive lookups in Bind

Limiting recursive lookups in Bind is a good idea for several reasons:

1. Why give free DNS service to the entire internet.
2. A source of denial of service flood attack.
3. Increases traffic, which may increase costs.
4. Increases CPU usage.

In /etc/bind/named.conf.options:
 acl "trusted" {
     111.222.333.444/55;
        127.0.0.1;
     localhost;
     localnets;
 };

options {
        directory "/var/cache/bind";
        auth-nxdomain no;    # conform to RFC1035
        additional-from-auth no;
        additional-from-cache no;
        allow-query { any; };
        allow-recursion { trusted; };
        allow-query-cache { trusted; };

};

Binding postfix to use a specific ip address.

Now-a-days with SPF records and such, it's always a good idea to limit postfix to use the ip address specified in the spf record to prevent your mail from being marked as spam. This is only necessary if your server has more that one ip bound to it. 

In /etc/postfix/main.cf add:
smtp_bind_address = 111.222.333.444

This will limit your postfix server to using the ip specified.

IP / Spam Damage control

Once you've plugged your holes, and rid your mail server of spam; you need to assess the damage.

If you send a lot of mail though Hotmail, you might consider joining their SNDS site which tells you if your being blocked by their site, and gives you your IP status history, and an excerpt of offending mail headers.

The offending mail header is really helpful to finding out who is sending out the spam.

In the example above, you can clearly see that the sender is "bogdan@fx.ro". This might be helpful if you are having trouble tracking down the culprit at the server level.

I recently learned of another service which I use religiously now called SENDERBASE. You can check the status of your IP on a more global scale, and see if server are still receiving spam from you.

So this is now part of my morning routine. I peruse both sites for my IP reputation. This will give me a heads-up before your IP provider contacts you about it. You can say that you've already fixed the problem.

addendum: If your listed on sites like spamcop, ipblacklist, and others of the like; most of them do provide a way to get de-listed. You will of course need to provide information about what occurred, and what you did to eliminate the issue.

Joe's DataCenter, not for the faint of heart.

Hi guys, just thought I'd post my recent experience.

I had a server at Joes DataCenter. They unplugged me and gave me the silent treatment for days. They would not allow me to communicate with them through phone nor their ticket system.

They did this on the grounds that I was damaging their IP reputation by spamming.

Although there were previous occasional incidents of users having changed their passwords to something like 1234 and getting picked-up by a spambot; and spamming for a few days. What caused this last and final rift was a COM_JCE exploit on Joomla CMS software. JDC couldn't seem to wait until I was able to patch all the 35+ sites to remedy the problem. They unplugged my server; and discontinued my service.

They were however nice enough to allow me to extract some important data belonging to one of my customers after several days of down time. But only after I called another company to pickup my server for data-recovery services.

So if you're a bullet-proof super-admin that never has any issues, their service is great. If you're like me and are learning as you go, you might look elsewhere.

Needless to say, I had them packup and ship my server to another colo-service provider.