April 2020 - Test - lists.nanog.org

Abuse Desks
by Mike Hammett 30 Apr '20

30 Apr '20

I noticed over the weekend that a Fail2Ban instance's complain function wasn't working. I fixed it. I've noticed a few things: 1) Abusix likes to return RIR abuse contact information. The vast majority are LACNIC, but it also has kicked back a couple for APNIC and ARIN. When I look up the compromised IP address in Abusix via the CLI, the APNIC and ARIN ones return both ISP contact information and RIR information. When I look them up on the RIR's whois, it just shows the ISP abuse information. Weird, but so rare it's probably just an anomaly. However, almost everything I see in LACNIC's region is returned with only the LACNIC abuse information when the ones I've checked on LACNIC's whois list valid abuse information for that prefix. Can anyone confirm they've seen similar behavior out of Abusix? I reached out to them, but haven't heard back. 2) Digital Ocean hits my radar far more than any other entity. 3) Azure shows up a lot less than GCP or AWS, which are about similar to each other. 4) Around 5% respond saying it's been addressed (or why it's not in the event of security researchers) within a couple hours. The rest I don't know. I've had a mix of small and large entities in that response. 5) HostGator seems to have an autoresponder (due to a 1 minute response) that just indicates that you sent nothing actionable, despite the report including the relevant log file entries. 6) Charter seems to have someone actually looking at it as it took them 16 - 17 hours to respond, but they say they don't have enough information to act on, requesting relevant log file entries... which were provided in the initial report and are even included in their response. They request relevant log file entries with the date, time, timezone, etc. all in the body in plain text, which was delivered. 7) The LACNIC region has about 1/3 of my reports. Do these mirror others' observations with security issues and how abuse desks respond? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

26 58

Re: Abuse Desks
by Hal Murray 30 Apr '20

30 Apr '20

Mike Hammett said: > IMO, the answer is balance. > - Handful of SSH connection attempts against a server. Nobody got in, > security hardening did it's job. I don't think that is worth reporting. - > Constant brute force SSH attempts from a given source over an extended period > of time, or a clear pattern of probing, yes, report that. The bad guys have already gamed that system. If you have a zillion bots, you can have each bot try a different name/password on a large batch of IP Addresses. A victim only sees one try from each bot. The daily logwatch reports that land in my mailbox are full of ssh attempts that end with ": 1 Time". ----------- Matt Corallo said: > I'm open to ideas on what to do here, but the abuse system as it exists today > is clearly broken for me, and its clearly broken for AWS/GCP/Azure/OVH/etc - > have you ever tried emailing their registered abuse contacts? I have, the > problem doesn't go away and there are no responses. > especially given most of the real crap out there comes from hosting providers > like the above who don't have the bandwidth to respond. "don't have the bandwidth" is an interesting term. Is that because the problem is really hard and it would take a lot of bandwidth/money/whatever, or because they choose not to spend money on it and the rest of the net is letting them get away with it? ---------- Tom Beecher said: > Abuse departments should be properly handling LEGITIMATE abuse complaints. > Not crufty background noise traffic that is never going away. Agreed. But the abuse desk is the only place where somebody can find the signal in the noise, and with the current pattern, much of the signal is trying to hide in the noise. The abuse desk will only see the signal if people actually send in abuse reports and the abuse desk actually looks at them. ---------- Laszlo Hanyecz said: > A lot of this other stuff is just people abusing the abuse contacts to get > someone else taken offline. Phishing websites fall into this category - > it's not network abuse, it's just content someone doesn't like, and one way > to get it taken down is to threaten the network that carries the traffic for > it. I don't report phishing websites unless somebody spams me with the URL. -- These are my opinions. I hate spam.

2 1

CGNAT Solutions
by John Alcock 30 Apr '20

30 Apr '20

Afternoon, I run a small ISP in Tennessee. COVID has forced a lot of people to work from home. I am starting to run low on IP's and need to consider CGNAT. I do have IPV6 space, but we all know that until we force everyone to move to IPV6, we need to keep IPV4 up and running. I could buy more space, but I am really wondering if that is the best option. It is expensive. I know CGNAT devices are expensive as well, but it looks like I could stretch it out a bit. My thinking is to convert about 50% of my subscribers to CGNAT. I am interested in vendors or devices you have used in the past. I already know about the pitfalls many of my subscribers will have with CGNAT such as VPN's, Gamers, etc. What are your thoughts on CGNAT vendors? A10Networks F5Networks Others?

14 23

Re: CGNAT Solutions
by William Herrin 30 Apr '20

30 Apr '20

On Wed, Apr 29, 2020 at 5:27 PM Thomas Scott <mr.thomas.scott(a)gmail.com> wrote: > > cell-phone environment. A classic small ISP fills a different niche. > > I've dealt with traditional cable and fiber SP environments, but I'm curious how the architecture differs so drastically with T-Mobile to allow v6 to work so seamlessly. From working with their techs when turning up circuits, I don't feel like their architecture and the ones I've worked in differ too dramatically. My private cell service is through a tmo reseller, and I've only ever had a public v6 address on them. > > What allows them to work with v6 in such an efficient manner? A piece of client software is installed on every phone that presents an IPv4 address to the phone and then translates packets to IPv6 for relay over the network. This works because T-Mobile has considerable control over the phone. https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobil… Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

4 3

Re: Abuse Desks
by Mel Beckman 29 Apr '20

29 Apr '20

Jeff, FTPS The prosecution rests :) -mel On Apr 29, 2020, at 5:25 PM, Jeffrey Ollie <jeff(a)ocjtech.us> wrote: On Wed, Apr 29, 2020 at 10:43 AM Mel Beckman <mel(a)beckman.org<mailto:mel@beckman.org>> wrote: Is there any reason to have a root-enabled (or any) ssh server exposed to the bare Internet? Any at all? Can you name one? I can’t. That’s basically pilot error. Root enabled? No. Otherwise, yes. At $DAYJOB we have a SFTP server that is exposed to the internet so that we can exchange data files with various partners. Sure, in theory you could move that to an HTTPS server, but then you'd have to agree on some API and everyone on both ends would have to write and maintain server/client implementations of those APIs. -- Jeff Ollie The majestik møøse is one of the mäni interesting furry animals in Sweden.

1 0

Init7 wins peering case against Swisscom
by Fredy Künzler 29 Apr '20

29 Apr '20

==> Our press release in German: https://drive.google.com/open?id=1WSAmAQRBsdllyMMq7_FIeuE_-630ETL2 Translated with www.DeepL.com Init7 wins peering case against Swisscom Federal Administrative Court overturns ComCom decision On 22 April 2020, the Federal Administrative Court (BVGER) handed down a landmark decision in the IP interconnection ("peering") proceedings of Init7 against Swisscom, which have been ongoing since 2013, which confirms the validity of the complainant Init7. Init7 demanded that Swisscom continue a peering agreement concluded in 2011 on a zero-settlement basis (i.e. each partner bears its own costs). Swisscom had terminated this contract in 2012 and, undermining the "polluter pays" principle and the telecommunications law obligation to grant cost-oriented prices, demanded massively excessive compensation for peering from Init7. Init7 defended itself against this. In its judgement, based on several expert opinions of the Competition Commission (WEKO), the BVGER came to the conclusion that Swisscom was dominant - quote: "The respondent has a technical monopoly for access to its end customers". The court thus overturned the decision of the ComCom lower instance and ruled in favour of Init7 . ComCom must now set the cost-oriented price for peering. As with voice interconnection, this price for peering will be zero or close to zero. This means that Swisscom's additional demand of CHF 550,000 to Init7 is off the table. Init7 will also save the procedural costs of CHF 126,400 still imposed on it by the previous instance. The Federal Administrative Court's remarks are primarily relevant to an illegal cartel which Swisscom operated together with Deutsche Telekom (DTAG) until January 2016. It was ended thanks to the proceedings of Init7 under pressure from the WEKO after a preliminary investigation. The cartel enabled Swisscom to participate financially in the IP transit capacity sold by DTAG (revenue share). However, the ruling has a more far-reaching effect: In future, it will no longer be possible for providers with a strong market position and many broadband customers to artificially increase the price of IP interconnection through competitive agreements and to make it more difficult for smaller providers to access their customer base. The ruling is therefore significant in the fight for an open and discriminatory free Internet and should have an impact beyond Switzerland. This too, because it shows the telecom regulators once again that their laissez-faire attitude is out of place vis-à-vis providers with market power in the area of peering. The text of the judgement can be downloaded here (PDF, 42 pages, 31.7 MByte). https://drive.google.com/open?id=13nMQkj1abja-3cPBiQWiZaybsFIUkWa5 Translated with www.DeepL.com/Translator (free version) -- Fredy Künzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur https://www.init7.net/

1 0

Applications of MPLS in the metro area
by Etienne-Victor Depasquale 28 Apr '20

28 Apr '20

Hello ! I'm looking for what a network operator would consider a realistic reference deployment of MPLS within the metro area network. By "realistic reference", I'm asking about what a network operator would consider to be a typical, perhaps most common, application of MPLS technology. >From a bookish perspective, I understand MPLS well but have never implemented it in the scope of my current field of study (metro area networks). I would dearly like to get this "grounded" perspective from anyone who might care to share it. Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

3 5

Pearson VUE Contact...
by Michael Bullut 28 Apr '20

28 Apr '20

Greetings Team, Anyone from the aforementioned organization on this forum? I raised a query via their Customer Service Team but havent heard back from them. Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>* *E-mail:* *main(a)kipsang.com <main(a)kipsang.com>* *---*

1 0

Phishing and telemarketing telephone calls
by Matthew Black 27 Apr '20

27 Apr '20

Has anyone else noticed a steep decline in annoying phone calls since the FCC threatened legal action against three major VOIP gateways if they didn't make efforts to prevent Caller ID spoofing from scammers? Writing on behalf of myself and not any organization or employer. Please remove me from your mailing and contact lists.

13 23

NANOG 79 will be a virtual meeting 👉
by NANOG Marketing 27 Apr '20

27 Apr '20

*NANOG 79 will now be held as a virtual meeting — the in-person meeting in Boston has been canceled.* Due to the COVID-19 global pandemic, the NANOG Board of Directors and Staff have decided to cancel the in-person meeting in Boston. To ensure the safety of our community, NANOG 79 <https://nanog.org/meetings/nanog-79/> will now be held as a three-day virtual meeting, June 1-3, with an abridged program. Online registration and meeting details will be posted soon. Both speakers and attendees will participate remotely. The NANOG Program Committee is developing a program tailored to an online format, and has extended the Call For Presentations to May 7 <https://www.nanog.org/participate/call-presentations/>. All attendees registered for NANOG 79 in Boston should have been issued refunds by Friday, April 24, and Marriott Boston Copley Place <https://book.passkey.com/event/50047481/owner/249/landing/closed> will auto-cancel any rooms booked under the NANOG 79 hotel-room block. If the hotel did not cancel your reservation, or if you have further questions, please contact the hotel directly at +1-617-236-5800. We will announce when registration opens, and share program topics and highlights soon. Please contact us with any additional questions or concerns: nanog-support(a)nanog.org Sincerely, The NANOG Board of Directors and Staff

1 0