|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Criminals, The Network, and You [Was: Something Else]
On Tue, Sep 18, 2007 at 02:42:43PM -0400, Sean Donelan wrote: > Instead of they suck, it might be more useful to highlight providers of > similar scale which you think do a good job which others could emulate. A first-order examination of the data suggests that Cox may be doing something pro-active. The number of IP addresses on their network engaged in recent spam delivery attempts is considerably less than that from others, e.g.: Comcast: 1240 Verizon: 1594 Cox: 25 Of course, that could be due to the relative sizes of the networks involved, but a second-order examination of the same data suggests something more: the abuse-emitting IP addresses on Cox's network do not appear to show up repeatedly over long periods of time. Contrast with those on Comcast and Verizon, where it's quite common to see the same ones in the logs for days/weeks/months. This suggests to me that Cox is actually paying attention to abuse outbound from their network and is either disconnecting or quarantining hosts which emit it. > Some people think that users on dynamic addresses should be read-only, and > not allowed to operate servers or send messages. Like most forms of > red-lining, it tends to become self-fulling. Of course, I've never suggested any such thing. Users of such ISPs should normally be using their own ISPs outbound mail server(s), a solution which is perfectly adequate for the overwhelming majority of users. And it should be no problem for them to use other mail servers, using SMTP AUTH (with TLS or SSL) or via HTTP. But the days when direct-to-MX traffic is acceptable from all addresses are as gone as those when operation of an open SMTP relay was acceptable. Moreover, those who wish to operate servers (and whose ISPs permit that operation per their TOS) should have no difficulty in having the ISP assign them non-generic DNS/rDNS, and/or assign them static address space which is reserved for such users. > Unlesss accept all those messages from those addresses and check them, you > really don't know the false positive rate. You only know the > self-reported complaint rate; which is usually a fraction of the actual > false positive rate. Actually, I know quite a bit more than that. But since this is NANOG and not an anti-spam discussion list, I elected not to delve into the rather lengthy details of the methodology used to ascertain the FP rate. But *briefly* and glossing heavily, when a particular IP address (with generic rDNS, let's say): - fails to wait for the SMTP greeting - fails to send a QUIT - fails to retry when given a deferral response - retries immediately when given a deferral response - attempts delivery to an MX that hasn't been an MX for years - attempts delivery to a domain whose MX record hasn't been pointed to this MX for years - HELOs as ebay.com (or similar) - HELOs as a non-existent domain - HELOs as a very-recently-registered domain - HELOs as something different each time it connects - HELOs as *my* MX or a domain handle by it - attempts to send mail with a putative sender @paypal.com (or similar) - attempts delivery repeatedly with different putative senders/different putative sender domains - attempts to send mail with putative senders whose domain does not exist or does not resolve - attempts to send mail with a putative senders whose domain has A or MX records which resolve to invalid network space - attempts to send mail with a putative sender whose domain has very suspicious DNS records [1] - attempts to send mail from a putative sender using a known-spammer-owned domain - attempts to send mail from a putative sender using a domain which resolves to DROP-listed space. [2] - attempts to send mail from a putative sender using a very-recently-registered domain - attempts to send mail from a putative sender using *my* domain - attempts delivery to spamtraps - attempts delivery to never-existed addresses - attempts delivery to one-off addresses available only in SMTP reject notices - attempts delivery of messages whose headers contain known spamware signatures - attempts to send mail whose body-part contains URIs which match well-maintained lists of spammer-controlled URIs - has already been noted by other independent observers as attempting spam delivery to their MX's - passive-OS-fingerprints as running Windows - is listed in the A or NS records of a known spammer domain (see [1] again) - has been noticed carrying out other attacks, e.g., attempting exploitation via HTTP, SSH, etc. - and so on or multiple of the above (as is the case most of the time), then it's very, very unlikely that refusal of the traffic constitutes a FP. ---Rsk [1] A recent example: segron.com, queried yesterday (a query today will likely return different values, BTW): segron.com a 62.214.228.21 segron.com a 75.47.248.183 segron.com a 79.113.34.148 segron.com a 79.120.16.19 segron.com a 80.133.250.133 segron.com a 81.198.35.132 segron.com a 85.179.60.176 segron.com a 89.110.23.181 segron.com a 89.178.60.48 segron.com a 89.212.0.195 segron.com a 121.137.164.24 segron.com a 121.200.140.244 segron.com a 218.254.186.186 segron.com a 221.126.244.121 segron.com a 221.127.158.128 which resolve to: i3ED6E415.versanet.de adsl-75-47-248-183.dsl.lsan03.sbcglobal.net 79-113-34-148.rdsnet.ro p5085FA85.dip.t-dialin.net e179060176.adsl.alicedsl.de pppoe-181.23.110.89-adsl.spbnit.ru 89-178-60-48.broadband.corbina.ru 89-212-0-195.dynamic.dsl.t-2.net 244.140.200.121.megaegg.ne.jp cm218-254-186-186.hkcable.com.hk (5 addresses yield NXDOMAIN) Clearly, segron.com's "web site" is being hosted on hijacked systems. [2] See http://www.spamhaus.org/DROP/ for details, but the gist is that this short and very carefully maintained list enumerates network space which is either hijacked or 100% spammer-controlled or both.
|