August 2019 - Test - lists.nanog.org

Re: syn flood attacks from NL-based netblocks
by Töma Gavrichenkov 19 Aug '19

19 Aug '19

On Mon, Aug 19, 2019, 9:24 PM Florian Brandstetter <florianb(a)squareflow.net> wrote: > Load balancing is done on Layer 4 or Layer 3 when routing, so your > ingress connection will have the same hash as the outgoing connection > (unless the source port of the connection changes on the ACK - which it > really should not). > If the hash is symmetric, yes. No wonder topology issues would have more impact, my point was that there are also other things to look at here. -- Töma >

1 0

syn flood attacks from NL-based netblocks
by Jim Shankland 19 Aug '19

19 Aug '19

Greetings, I'm seeing slow-motion (a few per second, per IP/port pair) syn flood attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, and BCP 38 not yet fully adopted). Why is this syn flood different from all other syn floods? Well ... 1. Rate seems too slow to do any actual damage (is anybody really bothered by a few bad SYN packets per second per service, at this point?); but 2. IPs/port combinations with actual open services are being targeted (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs with those services running), implying somebody checked for open services first; 3. I'm seeing this in at least 2 locations, to addresses in different, completely unrelated ASes, implying it may be pretty widespread. Is anybody else seeing the same thing? Any thoughts on what's going on? Or should I just be ignoring this and getting on with the weekend? Jim

12 25

Centurylink Looking Glass fail
by Ca By 19 Aug '19

19 Aug '19

Paging someone at Centurylink to fix your looking glass. https://lookingglass.centurylink.com None of the functions in any of the cities work Your network is kind of a big deal, so please try to provide visibility to your routing state so the rest of us can do our day-job, on Sunday

2 1

new BGP hijack & visibility tool “BGPalerter”
by Job Snijders 16 Aug '19

16 Aug '19

Dear NANOG, Recently NTT investigated how to best monitor the visibility of our own and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were specifically looking how to get near real-time alerts funneled into an actionable pipeline for our NOC & Operations department when BGP hijacks happen. Previously we relied on a commercial “BGP Monitoring as a Service” offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we saw greater potential for a self-hosted approach designed specifically for custom integrations with various business processes. We decided to write our own tool “BGPalerter” and share the source code with the Internet community. BGPalerter allows operators to specify in great detail how to distribute meaningful information from the firehose from various BGP data sources (we call them “connectors”), through data processors (called “monitors”), finally outputted through “reports” into whatever mechanism is appropriate (Slack, IRC, email, or a call to your ticketing system’s API). The source code is available on Github, under a liberal open source license to foster community collaboration: https://github.com/nttgin/BGPalerter If you wish to contribute to the project, please use Github’s “issues” or “pull request” features. Any help is welcome! We’d love suggestions for new features, updates to the documentation, help with setting up a CI regression testing pipeline, or packaging for common platforms. Kind regards, Job & Massimo NTT Ltd [1]: https://ris-live.ripe.net/

8 10

really amazon?
by Dan Hollis 16 Aug '19

16 Aug '19

Amazon, you really should know better. Source ip: 54.240.4.4 https://search.arin.net/rdap/?query=54.240.4.4 Source Registry ARIN Kind Group Full Name Amazon SES Abuse Handle ASA152-ARIN Email email-abuse(a)amazon.com >>> RCPT To:<email-abuse(a)amazon.com> <<< 550 #5.1.0 Address rejected. 550 5.1.1 <email-abuse(a)amazon.com>... User unknown >>> DATA <<< 503 #5.5.1 RCPT first Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=<email-abuse(a)amazon.com>, ctladdr=<goemon(a)sasami.anime.net> (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown

30 56

ARIN Fantasy WHOIS: NET-216-179-183-0-1
by Ronald F. Guilmette 16 Aug '19

16 Aug '19

As if to underscore the point I just tried to make about the fundamental unreliability of ARIN WHOIS records, I just stumbled onto this rather curious entity which was apparently given a sub-allocation of 216.179.183.0/24 beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10: OrgName: Rogers Communications Inc OrgId: RC-82 Address: E 2nd St,Campbell City: Gillette StateProv: WY PostalCode: 82716 Country: US RegDate: 2012-01-10 Updated: 2012-01-10 Ref: https://rdap.arin.net/registry/entity/RC-82 Other that the fact that it has an oddly similar name to one of Canada's largest and most well-known Internet and cell phone companies, the only other thing that's rather remarkable about it is that it was given the 216.179.183.0/24 block, by Azuki, Inc. in 2012. What's odd about that? Well, only the fact that this *Wyoming* incarnation of Rogers Communications had apparently already died and gone to Valhalla some 14 years earlier, in 1998: https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=0700232420041061300… Moral of the story: Don't ever let anybody tell you that ghosts... even ghosts of long dead companies... aren't real or that they do not walk among us. Their immortal auras pervade the very ether we breath. And they have their own IPs, apparently. But, you know, if your customers are getting hack attacks emmanating from 216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who you gonna call?" (Hint: Don't waste your time calling the number in the WHOIS record. It's just some bloody preschool.) Regards, rfg

3 2

Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17
by Ronald F. Guilmette 15 Aug '19

15 Aug '19

Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ) Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg

17 38

AT&T Wireless Calls Failing to Level - 3 DID's
by Ahmed Jalal 15 Aug '19

15 Aug '19

Hi, I am trying to get in touch with someone at AT&T to look into call failures to our DID's in the southern Mississippi region. Please let me know if I am in the wrong list. Any help would be greatly appreciated. Best Regards

2 1

Service function chaining technologies in service provider networks
by Tim Upthegrove 15 Aug '19

15 Aug '19

Hi folks, I am wondering if service provider networks are actively implementing service function chaining, and if so, what kinds of technologies they are using in the network to steer traffic to services. Segment routing was suggested to me as an option that could work, and it seems like a good fit; however, I have no clue how widely deployed it is specifically for service function chaining. At this point I'd just like to understand what some of the common deployment models are from anyone who is willing to share. Thanks, -- Tim Upthegrove

1 0

OT: Tech bag
by Dovid Bender 15 Aug '19

15 Aug '19

Hi, Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. TIA.

14 15