Nick Jennings wrote:
> Thanks Chris and Tim,
>
> I will look into a way of adding IPs to /etc/hosts.deny to at least
> lock out hosts which have attacked.
>
> I was also curious about the effectiveness of disabling ICMP requests,
> and also using the firewall to block port scanning. I'm wondering if
> this is worth doing (is it really *that* effective in deterring
> attacks?) and if there are any downsides to this?

The only icmps you can block that impede scanning are necessary for your
network to function.

If I want to test to see whether there's a POP3 server at 9.1.1.1 I'm
not going to ping it first, I'll just open the connexion.

If 9.1.1.1 is running a POP3 service, it has to respond. If it's not,
then the admin can choose between rejecting the connexion attempt or
dropping it.

Inside _my_ networks, I reject (except for the students). The rest I
drop; they get an extended timeout. It can slow scanning down, but I
could construct a scan that would not slow down a lot: just try another
address:port each n seconds regardless.


>
> Thanks,
> Nick
>
>
> On Wed, 2008-01-30 at 10:37 -0600, Chris Adams wrote:
>> Once upon a time, Nick Jennings <nick@(protected):
>>> Thanks for your response. I should have mentioned that this server is
>>> meant to be a hosting server for both web and mail, and there is no way
>>> to effectively restrict based on trusted clients.
>>>
>>> Is there anything else perhaps more general for if not preventing, then
>>> deterring and slowing down this kind of attack?
>> Basically, if you plug a server into the Internet, it _will_ be
>> attacked. POP, IMAP, SMTP, SSH, FTP, and more will be probed, looking
>> for valid usernames/passwords (so always enforce password security on
>> your users).
>>
>> I know denyhosts (in EPEL) can watch the SSH log and add bad IPs to
>> /etc/hosts.deny, but I don't know if it can parse dovecot log entries as
>> well.

Do some googling on denyhosts, there are those who denigrate it.

There's not much I can do with /etc/{deny,allow}.hosts that I cannot
also do with iptables. Since I run a fairly comprehensive firewall on
the server, that's where I prefer to do stuff.

What you might consider is opening an otherwise unused port (21, 389,
1433) and configure tcpwrappers to respond. Here's a POC:
mail:~# tail -5 /etc/hosts.deny

false: ALL: spawn (echo attack from @%h | \
          /usr/bin/mail -s %d-%h root) &


mail:~#

It could just as well block the connecting adddress or its /24 subnet.

Here's what it's protecting:
mail:~# cat /etc/xinetd.d/telnet
# default: off
# description: An internal xinetd service which gets the current system time
# then prints it out in a format like this: "Wed Nov 13 22:30:27 EST 2002".
# This is the tcp version.
service telnet
{
     disable      = no
     socket_type   = stream
     protocol     = tcp
     user        = games
     wait        = no
     flags       = NAMEINARGS
     server       = /usr/sbin/tcpd
     server_args   = /bin/false
}
mail:~#




--

Cheers
John

-- spambait
1aaaaaaa@(protected)
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list