James B. Byrne <byrnejb at ...> 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