[SATLUG] SATLUG Outage

Daniel J. Givens daniel at rugmonster.org
Fri Nov 6 09:59:08 CST 2009


On 11/05/2009 11:37 PM, Bruce Dubbs wrote:
> Daniel J. Givens wrote:
>> Bruce,
>>
>> For whatever reason, your firewall rules had sections of Rackspace
>> blocked. I haven't received any mail from the list in months since
>> moving my mail to an IP in the DFW data center. Please audit the
>> blocked networks you had listed before putting them back up.
>
> I haven't put them back yet, but send me directly the IP addresses you
> want to ensure don't get blocked and I'll make that happen.
>
> The problem is that I really don't like many thousands of attempts to
> guess a password via ssh and many thousands more trying to use the mail
> server as an open relay, which it isn't. Most of the attempts are from
> Asia or Europe.
>
> -- Bruce

My sending IP's are:

sh-srv1.rugmonster.org has address 98.129.169.9
sh-srv2.rugmonster.org has address 67.23.43.28 (migrating to)

The blocking of whole chunks of the Internet is pretty bad practice 
considering the nature of this public list/organization. Just the fact 
that you had sections of Rackspace, the provider for the server, blocked 
illustrates that quite poignantly.

Generally, as long as you're using strong passwords, brute-force login 
attempts via SSH are not of particular concern, as it's unfortunately 
common. Using IPTables to limit SSH access to only certain IP addresses 
is the best solution, but not always feasible. In that case, you can use 
something like Fail2Ban on your server. Fail2ban scans log files like 
/var/log/secure and bans IP that makes too many password failures. It 
updates iptables rules automatically to block access for a set amount of 
time.

Another option that stops bots trying to log in via SSH is to change the 
port the service listens on. On my servers, I have SSH listening on port 
2022 and have entries on my client machines for the hosts in 
~/.ssh/config to automatically use that when connecting.

Since Fail2Ban works by matching regex in any log file, you can 
configure it to block IPs for any kind of malicious activity. Therefore, 
you could tailor it to block anyone that is trying to use the server as 
an open-relay. Again, as long as the server is configured properly, that 
shouldn't be a concern.

You can also stop a lot of improper mail activity by configuring your 
mail server with some sane rules. For example, with Postfix, I use the 
following in /etc/postfix/main.cf:

smtpd_delay_reject = yes
smtpd_helo_required = yes
disable_vrfy_command = yes

smtpd_helo_restrictions =
	permit_mynetworks,
	reject_non_fqdn_helo_hostname,
	reject_invalid_helo_hostname,
	reject_unknown_helo_hostname,
	permit

smtpd_sender_restrictions =
	permit_sasl_authenticated,
	permit_mynetworks,
	reject_non_fqdn_sender,
	reject_unknown_sender_domain,
	permit

smtpd_recipient_restrictions =
	permit_mynetworks,
	permit_sasl_authenticated,
	reject_unauth_pipelining,
	reject_non_fqdn_recipient,
	reject_unknown_recipient_domain,
	reject_unauth_destination,
	reject_rbl_client bl.spamcop.net,
	reject_rbl_client zen.spamhaus.org,
	permit

Since permit_sasl_authenticated comes before any of the restrictions, it 
doesn't matter where I'm sending from as long as I authenticate.

If you're just worried about your logs getting cluttered up, use 
something like logwatch to parse the logs and pull out the interesting 
stuff. That alone shouldn't be a reason to block chunks of the Internet, 
preventing access to what would be legitimate users.

--
Daniel


More information about the SATLUG mailing list