- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 61, Issue 6
by Marilson 21 Nov '16

21 Nov '16

Peter, You are being the victim of a swindler. He is passing himself off as a well-known lawyer, Mark J. Silberman, to take your money. If you make contact - munged (at) gmail.com - you will know how he acts. Report to antispam_gdnoc(a)189.cn. Marilson From: anti-abuse-wg-request(a)ripe.net Sent: Sunday, November 20, 2016 9:00 AM To: anti-abuse-wg(a)ripe.net Subject: anti-abuse-wg Digest, Vol 61, Issue 6 Send anti-abuse-wg mailing list submissions to anti-abuse-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/anti-abuse-wg or, via email, send a message with subject or body 'help' to anti-abuse-wg-request(a)ripe.net You can reach the person managing the list at anti-abuse-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-abuse-wg digest..." Today's Topics: 1. Re: New on RIPE Labs: Reasons Dynamic Addresses Change (Ramakrishna) 2. What's the point in this type of spam ? (peter h) 3. Re: What's the point in this type of spam ? (ox) ---------------------------------------------------------------------- Message: 1 Date: Sat, 19 Nov 2016 06:41:43 -0800 From: Ramakrishna <ramapad(a)cs.umd.edu> To: anti-abuse-wg(a)ripe.net Subject: Re: [anti-abuse-wg] New on RIPE Labs: Reasons Dynamic Addresses Change Message-ID: <CAAYmKkJ3DjUf7bd9pUktFwr8QjV3QtNAWMF41VzTeFbqskE4kQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" > ok... so first of all the address changes within DTAG and most other german SOHO DSL providers, from what i heard back then, goes back to the days of dialup... a couple of years ago they apparently still were forced by law (or something) to also offer DSL on a 'charge per time use' basis, and also disconnect virtual channels every once in a while, something to do with anti-competition to the telephone dialup network.. which apparently is why most german dsl providers still do that. Ah, thanks for providing the historical context for why German DSL providers change addresses so frequently. I am skeptical, however, that there is a law requiring German DSL providers to disconnect virtual channels 'every once in a while' because I asked several German colleagues about such a law and they were unable to find one (I would be delighted if you can point me to one!). > secondly... if your authentication and telling users apart has anything to do with layer 3, your authentication method is just crap, not well thought of, etc. There are other use-cases for IP addresses as end-host identifiers that I outlined in my post (such as counting the number of users in a system by counting the number of distinct IP addresses). I am personally interested in measuring outages by pinging IP addresses belonging to residential CPEs. My premise for detecting outages is that an address that sends responses to active probes is alive and well, and that a previously responsive address that has stopped responding to probes could be experiencing an outage. This premise is incorrect when I am pinging a dynamic address that has been withdrawn from the CPE; thus, I would love to analyze dynamic reassignment behavior across ISPs. I agree that using IP addresses for identifying users for authentication purposes isn't ideal but sometimes, IP addresses are the easiest way to identify users. Other times, they are the only ways to identify users. For example, if one is defending against a DoS attack, the most straightforward and efficient approach is to blacklist that IP address temporarily. How long that address can continue to remain in the blacklist is the question that we aim to answer. > as for wikipedia, it also leaks ips all over the place. (basically inciting users to ddos each other,although probably a less common result than with IRC.) Well, wikipedia is only one example of a well-known company that employs IP address based blacklists. In private conversation with Google and several content-delivery networks (including one where I interned earlier this year), I learned that IP addresses are very much a part of host-reputation systems. So although IP addresses as end-hosts isn't ideal, it's a common assumption and our work shows that the assumption can actually even be valid for weeks at a time in North American ISPs. Cheers, Rama http://www.cs.umd.edu/~ramapad/

1 0

What's the point in this type of spam ?
by peter h 20 Nov '16

20 Nov '16

The last days i have been sent a number of these threats, they come from different addresses ( stolen computers ) but contain no links or attatchements. Is the goal to harass the gmail user ( it's munged by me to protect an innocent person ) Received: from 14.145.207.224 ([113.68.244.108]) by ipsec.se (8.13.6/8.13.6) with SMTP id uAILTOwC091474 for <peter(a)ipsec.nu>; Fri, 18 Nov 2016 22:29:32 +0100 (CET) Message-Id: <201611182129.uAILTOwC091474(a)ipsec.se> Received: from unknown (HELO localhost) (mark.silberman78@gmail.com@177.205.66.120) by 113.68.244.108 with ESMTPA; Sat, 19 Nov 2016 05:29:22 +0800 From: m-**-.-munged-78(a)gmail.com To: peter(a)ipsec.nu Subject: You are hacked! Date: Sat, 19 Nov 2016 05:21:56 +0800 Content-Type: X-UID: 5404 X-Length: 910 Your email peter(a)ipsec.nu has been hacked and spam is sent to all your contacts! If you don't have a lawyer, you may contact me at <munged>@gmail.com Best Regards, M**- m**-.-munged-78(a)gmail.com -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )

2 1

Re: [anti-abuse-wg] New on RIPE Labs: Reasons Dynamic Addresses Change
by Ramakrishna 19 Nov '16

19 Nov '16

> ok... so first of all the address changes within DTAG and most other german SOHO DSL providers, from what i heard back then, goes back to the days of dialup... a couple of years ago they apparently still were forced by law (or something) to also offer DSL on a 'charge per time use' basis, and also disconnect virtual channels every once in a while, something to do with anti-competition to the telephone dialup network.. which apparently is why most german dsl providers still do that. Ah, thanks for providing the historical context for why German DSL providers change addresses so frequently. I am skeptical, however, that there is a law requiring German DSL providers to disconnect virtual channels 'every once in a while' because I asked several German colleagues about such a law and they were unable to find one (I would be delighted if you can point me to one!). > secondly... if your authentication and telling users apart has anything to do with layer 3, your authentication method is just crap, not well thought of, etc. There are other use-cases for IP addresses as end-host identifiers that I outlined in my post (such as counting the number of users in a system by counting the number of distinct IP addresses). I am personally interested in measuring outages by pinging IP addresses belonging to residential CPEs. My premise for detecting outages is that an address that sends responses to active probes is alive and well, and that a previously responsive address that has stopped responding to probes could be experiencing an outage. This premise is incorrect when I am pinging a dynamic address that has been withdrawn from the CPE; thus, I would love to analyze dynamic reassignment behavior across ISPs. I agree that using IP addresses for identifying users for authentication purposes isn't ideal but sometimes, IP addresses are the easiest way to identify users. Other times, they are the only ways to identify users. For example, if one is defending against a DoS attack, the most straightforward and efficient approach is to blacklist that IP address temporarily. How long that address can continue to remain in the blacklist is the question that we aim to answer. > as for wikipedia, it also leaks ips all over the place. (basically inciting users to ddos each other,although probably a less common result than with IRC.) Well, wikipedia is only one example of a well-known company that employs IP address based blacklists. In private conversation with Google and several content-delivery networks (including one where I interned earlier this year), I learned that IP addresses are very much a part of host-reputation systems. So although IP addresses as end-hosts isn't ideal, it's a common assumption and our work shows that the assumption can actually even be valid for weeks at a time in North American ISPs. Cheers, Rama http://www.cs.umd.edu/~ramapad/

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 61, Issue 4
by Marilson 18 Nov '16

18 Nov '16

Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart (Ronald F. Guilmette) doorn(a)custom-connect.com rutger(a)custom-connect.com janwillen(a)custom-connect.com support(a)peeringdb.com custom-connect.net IP 89.42.168.1 – RIPE NCC Abuse Contact Finder = abuse(a)xconnect24.com abuse(a)xconnect24.com: BAD, why? gsc(a)custom-connect.com: OK but all is spam for them – belive it or not, they do not like spam... aliyun.com – bad reputation with Zhejiang Taobao and Alibaba.com Llc IP reported as Blacklisted Proxy/VPN detected Alibaba and the forth thieves, fiction or reality? Marilson From: anti-abuse-wg-request(a)ripe.net Sent: Friday, November 18, 2016 9:00 AM To: anti-abuse-wg(a)ripe.net Subject: anti-abuse-wg Digest, Vol 61, Issue 4 Send anti-abuse-wg mailing list submissions to anti-abuse-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/anti-abuse-wg or, via email, send a message with subject or body 'help' to anti-abuse-wg-request(a)ripe.net You can reach the person managing the list at anti-abuse-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-abuse-wg digest..." Today's Topics: 1. Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart (Ronald F. Guilmette) ---------------------------------------------------------------------- Message: 1 Date: Thu, 17 Nov 2016 14:46:56 -0800 From: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> To: routing-wg(a)ripe.net, anti-abuse-wg(a)ripe.net Subject: [anti-abuse-wg] Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart Message-ID: <70069.1479422816(a)segfault.tristatelogic.com> If anybody can give me an email for any of these principals of Xconnect42, Inc. (Netherlands) aka AS260, I'd appreciate it. I tried to reach somebody (anybody) at their company via the address I found online for the company <gsc(a)custom-connect.com> but never got any response. That was a week ago. I'm real interested to have these guys explain to me why they are peering with the following ASNs, which all appear to have one and only one BGP peer, i.e. Xconnect24, Inc. AS7971 AS10505 AS6560 AS14029 AS37135 AS37137 Note that each and every one of the above six Afrinic-issued ASNs appears to be announcing routes to gobs and gobs of IPv4 space... mostly prevously abandoned AFRINIC space, but also, in the case of AS10505, numerous /17 hunks of Chinese IPv4 space... to which the ASNs in question do not appear to have any relationship, and where a great deal of the relevant IPv4 address space has been filed up to the brim by U.S.A. based snowshoe spammers, including, apparently, at least one convicted felon and former drug trafficker. Note also that two of the /17 routes currently being announced by AS10505 are for IPv4 space allocated by APNIC to Aliyun Computing, Ltd. which Bloomberg lists as a subsidiary of retail giant Alibaba, currently having a market cap of $232.4 bellion dollars (USD). I dunno. maybe it's just me, but I somehow think that a Chinese company worth almost a quarter of a trillion dollars probably doesn't really need to enlist the help of a long-dead South African ISP to route parts of their space for them. http://imgur.com/a/uR0qQ So anyway, I'd really like to have a brief chat with any or all of the following three gentlemen about all this: CEO - Olav van Doorn https://nl.linkedin.com/in/olavvandoorn Co-founder Jan Willem Meijer: https://www.loth.nl/company-profile-custom-connect/ CTO - Rutger Bevaart https://nl.linkedin.com/in/rutgerbevaart If anybody can put me in touch, I'd apperciate it. Thanks. Regards, rfg End of anti-abuse-wg Digest, Vol 61, Issue 4 ********************************************

1 0

Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart
by Ronald F. Guilmette 17 Nov '16

17 Nov '16

If anybody can give me an email for any of these principals of Xconnect42, Inc. (Netherlands) aka AS260, I'd appreciate it. I tried to reach somebody (anybody) at their company via the address I found online for the company <gsc(a)custom-connect.com> but never got any response. That was a week ago. I'm real interested to have these guys explain to me why they are peering with the following ASNs, which all appear to have one and only one BGP peer, i.e. Xconnect24, Inc. AS7971 AS10505 AS6560 AS14029 AS37135 AS37137 Note that each and every one of the above six Afrinic-issued ASNs appears to be announcing routes to gobs and gobs of IPv4 space... mostly prevously abandoned AFRINIC space, but also, in the case of AS10505, numerous /17 hunks of Chinese IPv4 space... to which the ASNs in question do not appear to have any relationship, and where a great deal of the relevant IPv4 address space has been filed up to the brim by U.S.A. based snowshoe spammers, including, apparently, at least one convicted felon and former drug trafficker. Note also that two of the /17 routes currently being announced by AS10505 are for IPv4 space allocated by APNIC to Aliyun Computing, Ltd. which Bloomberg lists as a subsidiary of retail giant Alibaba, currently having a market cap of $232.4 bellion dollars (USD). I dunno. maybe it's just me, but I somehow think that a Chinese company worth almost a quarter of a trillion dollars probably doesn't really need to enlist the help of a long-dead South African ISP to route parts of their space for them. http://imgur.com/a/uR0qQ So anyway, I'd really like to have a brief chat with any or all of the following three gentlemen about all this: CEO - Olav van Doorn https://nl.linkedin.com/in/olavvandoorn Co-founder Jan Willem Meijer: https://www.loth.nl/company-profile-custom-connect/ CTO - Rutger Bevaart https://nl.linkedin.com/in/rutgerbevaart If anybody can put me in touch, I'd apperciate it. Thanks. Regards, rfg

1 0

New on RIPE Labs: Reasons Dynamic Addresses Change
by Mirjam Kuehne 14 Nov '16

14 Nov '16

Dear colleagues, Please find this new article on RIPE Labs by Ramakrishna Padmanabhan: Reasons Dynamic Addresses Change Rama looked at why dynamic addresses change and found ISPs that renumber periodically, most commonly every 24 hours or a multiple of 24 hours. He also found that outages influence address changes. This also has an affect on IP address based blacklisting. https://labs.ripe.net/Members/ramakrishna_padmanabhan/reasons-dynamic-addre… Kind regards, Mirjam Kuehne RIPE NCC

2 1

Educating ISPs to properly process Abuse/Spam
by Reza Farzan 09 Nov '16

09 Nov '16

2 1

Mirai Threat Summary - the IoT attacks last week - Arbor
by Nash, Steve 28 Oct '16

28 Oct '16

Arbor Networks ASERT Threat Summary Date/Time: 28102016 2100UTC Title/Number: Mirai IoT Botnet Description and DDoS Attack Mitigation Recommendations - October 2016 - v1.1. Severity: Warning Distribution: TLP WHITE (see <https://www.us-cert.gov/tlp>) Categories: Availability Authors: Roland Dobbins & Steinthor Bjarnason ---- Description: Since its inception in August of 2016, the Mirai ‘Internet-of-Things’ (IoT) botnet, comprised largely of Internet-enabled digital video recorders (DVRs), surveillance cameras, and other Internet-enabled embedded devices, has been utilized by attackers to launch multiple high-profile, high-impact DDoS attacks against various Internet properties and services. Mirai serves as the basis of an ongoing DDoS-for-hire ‘booter’/‘stresser’ service which allows attackers to launch DDoS attacks against the target(s) of their choice in exchange for monetary compensation, generally in the form of Bitcoin payments. While the original Mirai botnet is still in active use as of this writing, multiple threat actors have been observed customizing and improving the attack capabilities of the original botnet code, and additional Mirai-based DDoS botnets have been observed in the wild. The original Mirai botnet (henceforth referred to as ‘the Mirai botnet’, or ‘Mirai’, unless otherwise indicated) currently consists of a floating population of approximately 500,000 compromised IoT devices worldwide; relatively high concentrations of Mirai nodes have been observed in China, Hong Kong, Macau, Vietnam, Taiwan, South Korea, Thailand, Indonesia, Brazil, and Spain. Additional Mirai concentrations have been also been observed in multiple countries located in North America, Europe, and Oceania. Mirai is capable of launching multiple types of DDoS attacks, including SYN-flooding, UDP flooding, Valve Source Engine (VSE) query-flooding, GRE-flooding, ACK-flooding (including a variant intended to defeat intelligent DDoS mitigation systems, or IDMSes), pseudo-random DNS label-prepending attacks (also known as DNS ‘Water Torture’ attacks), HTTP GET attacks, HTTP POST attacks, and HTTP HEAD attacks. While none of the DDoS attack capabilities of Mirai observed to date are new or unique, it is a flexible DDoS attack generation system and can launch high-volume, non-trivial DDoS attacks when wielded by a capable attacker. Mirai features segmented command-and-control, which allows the botnet to launch simultaneous DDoS attacks against multiple, unrelated targets. Vulnerable IoT devices are subsumed into the Mirai botnet by continuous, automated scanning for and exploitation of well-known, hardcoded administrative credentials present in the relevant IoT devices. These vulnerable embedded systems are typically listening for inbound telnet access on TCP/23 and TCP/2323. Given the prevalence of continuous scanning for vulnerable nodes across the entire IPv4 Internet address space, mean time to compromise of a vulnerable IoT device is 10 minutes or less, which means that compromised devices which are switched off or simply rebooted will almost certainly be re-compromised in short order, unless proactive steps are taken to shield TCP/23 and TCP/2323 access to the devices. Once an IoT device has been subsumed into the Mirai botnet, it immediately begins scanning for other vulnerable devices to compromise. This scanning takes place against destination ports TCP/23 and TCP/2323. As noted above, multiple threat actor groups are actively working to expand and improve the DDoS attack capabilities of Mirai-variant botnets. Some alterations in the DDoS attack capabilities of at least one Mirai-derived botnet have been observed in the wild. ---- Collateral Impact: The potential collateral impact of DDoS attacks launched by the Mirai botnet can be highly significant, depending upon the target selection and efficacy of a given attack. Outbound/crossbound DDoS attacks launched by Mirai bots can cause significant network performance issues or outages for broadband access network operators. Threat actors may significantly increase the rate of scanning for vulnerable systems, which could lead to an inadvertent DDoS attack on scanned/scanning systems and networks. ---- Mitigating Factors: The DDoS attack capabilities of Mirai which have been observed to date are well-known and can be successfully mitigated by implementing industry-standard Best Current Practices (BCPs) and by utilizing intelligent DDoS mitigation systems (IDMSes) such as Arbor SP/TMS and APS to defend the targets of these attacks. It is possible (and recommended) for network operators to actively scan for both vulnerable and compromised IoT devices on their networks and the networks of their customers, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action. It is possible (and recommended) for network operators to identify likely compromised IoT devices by detecting and classifying outbound/crossbound TCP/23 and/or TCP/2323 activity originating from these devices, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action. In order to inhibit scanning for vulnerable IoT devices, it is possible for broadband access network operators to implement access-control lists (ACLs) at a situationally-appropriate point in the network topology to prohibit high-port TCP traffic destined for TCP/23 and TCP/2323 on their customer access networks. Such policies wold typically be implemented as ingress ACLs on the coreward interfaces of broadband customer aggregation gateways. Operators should gauge the benefits of enforcing a network access policy of this nature vs. potential negative effects, if any, and should thoroughly test any proposed anti-scanning ACLs prior to deployment. ---- Recommended Actions: All relevant network infrastructure, host/application/service, and DNS Best Current Practices (BCPs) should be implemented by network operators with public-facing network infrastructure and/or Internet properties. Network operators should export flow telemetry (e.g., NetFlow, IPFIX, s/Flow, cflowd/jflow, Netstream, et. al.) from their peering/transit/customer aggregation edges and Internet data center (IDC) distribution edges to anomaly-detection/traffic visibility systems Arbor SP, which provide the ability to detect, classify, and traceback DDoS attack traffic. Network operators should make use of DDoS mitigation mechanisms such as source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMSes) such as Arbor TMS and APS in order to mitigate DDoS traffic sourced from Mirai-based botnets. ---- Applicable Arbor Solutions: Arbor APS, Arbor SP, Arbor TMS. ---- References: <http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/> <https://www.arbornetworks.com/blog/asert/rio-olympics-take-gold-540gbsec-su…> <https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/> <https://www.arbornetworks.com/network-visibility-product/arbor-networks-sp> <https://www.arbornetworks.com/ddos-protection-products/arbor-tms> <https://www.arbornetworks.com/ddos-protection-products/arbor-aps> <https://tools.ietf.org/html/rfc5635> <https://tools.ietf.org/html/rfc5575> ---- Steve Nash CEng MIET Consultant Engineer EMEA Arbor Networks: The security division of NETSCOUT +44 (0) 772 029 1359 (m) Follow Arbor on Twitter: @arbornetworks | www.arbornetworks.com

1 0

Draft Minutes - AAWG at RIPE72
by Brian Nisbet 26 Oct '16

26 Oct '16

Colleagues, I must apologise, I believed that I had sent out the minutes from the working group session at RIPE72, but (prompted by Kurtis in the NCC Services WG) I've just realised that I never did. The draft minutes are online here: https://www.ripe.net/participate/ripe/wg/anti-abuse/minutes/ripe-72-anti-ab… Please send any feedback to me about these over the next two weeks and we'll go from there. Obviously we will not be declaring these as accepted at the working group session at 12:00 CEST tomorrow. Thanks, Brian Co-Chair, RIPE AAWG -- Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/

1 0

Host Europe GmbH AS8972 - seems to be fully rogue
by Sergey 17 Oct '16

17 Oct '16

Hello, First of all, I'm pretty sure nobody cares. However, I believe it's my obligation (at the very least) to report on massive abuse operation which I notice. I receive tons of spam e-mails from Russian or Ukrainian spammers sent from this allegedly "one of Europe's leading hosting providers". Below are just unique spam sources for last 24 hours, but I'm receiving tens of e-mails from each of them and it lasts for a long time already: Received: from elefanters.eu (mail.elefanters.eu [85.25.155.41]) Received: from embarione.ru (mail.embarione.ru [62.75.236.150]) Received: from hebraica.eu (mail.hebraica.eu [62.75.236.204]) Received: from informazion.eu (mail.informazion.eu [188.138.127.156]) Received: from intermagic.eu (mail.intermagic.eu [62.75.236.205]) Received: from bookigemse.ru (mail.bookigemse.ru [85.25.226.162]) Received: from cooperhant.ru (mail.cooperhant.ru [62.75.236.138]) Received: from airpotes.ru (mail.airpotes.ru [62.75.236.136]) Received: from footingers.ru (mail.footingers.ru [85.25.208.94]) Received: from minderse.eu (mail.minderse.eu [85.25.226.216]) Received: from excluzivem.eu (mail.excluzivem.eu [85.25.226.204]) (Notice also that the .EU TLD seems to be another spammers' heaven.) All abuse complaints sent at abuse(a)plusserver.de are defiantly dismissed. By making this public I'd like to hear something from them. However, I have almost no doubt that this autonomous system advertising hundreds of IPv4 prefixes is 100% rogue.

3 2