James B. Byrne <byrnejb@...> writes:
>
> Over the weekend one of our servers at a remote location was
> hammered by an IP originating in mainland China. This attack was
> only noteworthy in that it attempted to connect to our pop3 service.
>
> We have long had an IP throttle on ssh connections to discourage
> this sort of thing. But I had not considered the possibility that
> other services were equally at risk. Researching this on the web
> does not reveal any comprehensive list of vulnerable ports or
> services. Most discussion centres on ssh, then some on ftp, and
> relatively few regarding pop3.
>
> So, my questions are these:
>
> 1. Should I throttle all new connections regardless of destination
> ports? In other words: are there any legitimate reasons that a
> single IP would require more than one new connection every 30
> seconds or so?
>
> 2. Moving pass the obvious and unhelpful "everything", what services
> are particularly vulnerable to these types of attacks? Does a list
> exist anywhere?
>
> Regards,
>
Hi -
I went though a similar process back when the DNS cache poisoning attacks
were coming fast and furious. The question to answer is, "Are there
legitimate reasons why the same IP address will apparently make multiple
connection requests for a particular service?" For DNS the answer was a
resounding "no" since the source nameserver should cache the results of the
query.
For POP3 the answer is more dependent on your particular organization. As an
example, is there a remote office that will generate a number of connection
requests when everyone egts to work in the morning; all apparently from the
same IP address? If there are no such legit reasons why a number of requests
could occur in a short period of time, a simple firewall throttling rule may
be sufficient. I have an article on my blog describing the firewall rules I
used to throttle and then block DNS cache poisoning attacks at:
http://davenjudy.org/davesBlog/node/41
One of the other replies also suggested "fail2ban" which may be more
appropriate anyway since you really want to look at failed logins; not just
connection attempts.
Cheers,
Dave
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
