[SATLUG] SATLUG Outage
Channing.ML at channingc.com
Channing.ML at channingc.com
Fri Nov 6 12:01:17 CST 2009
Daniel J. Givens wrote:
> On 11/05/2009 11:37 PM, Bruce Dubbs wrote:
>> Daniel J. Givens wrote:
>>> 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 220.127.116.11
> sh-srv2.rugmonster.org has address 18.104.22.168 (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 =
> smtpd_sender_restrictions =
> smtpd_recipient_restrictions =
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
> 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.
If I may also add to the list OSSEC for IDS, if you are going that
route. For ssh, I prefer to add an 'ssh_allow' group to the system, add
my account to that group, and ensure that the following is in my
sshd_config "AllowGroups ssh_allow".
I would like to say thank you for being the administrator for these
several years. Your time is appreciated.
More information about the SATLUG