Re: Spamming of NANOG list members
On 5/31/19 5:53 PM, Bryan Holloway wrote: Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Intriguing. I've not yet received a single one. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Spamming of NANOG list members
On 5/31/2019 8:05 PM, Richard wrote: > On 5/31/19 8:07 PM, Niels Bakker wrote: >> * br...@shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: >>> Anybody else noticed a significant uptick in these e-mails? >>> >>> When I first saw this thread, I hadn't seen any. A couple days later, >>> I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) >> >> Yes. It's pretty annoying. And somebody seems to be burning through >> a lot of stolen credentials. I wonder what the success rate is... >> >> >> -- Niels. >> >> > I am getting several a day as well as ugly MS Word based trojan. > > They come to me from all over the world with the subject line: > > "NANOG Payment Remittance Advice" > > I agree with Niels, someone or some spamming outfit is burning > > through quite a bit of stolen credentials. > > Richard Golodner > > Infratection > It's Emotet (again). Cheers, - ferg -- Paul Ferguson Principal, Threat Intelligence Gigamon Seattle, WA USA
Re: Spamming of NANOG list members
On 5/31/19 8:07 PM, Niels Bakker wrote: > * br...@shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: >> Anybody else noticed a significant uptick in these e-mails? >> >> When I first saw this thread, I hadn't seen any. A couple days later, >> I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) > > Yes. It's pretty annoying. And somebody seems to be burning through > a lot of stolen credentials. I wonder what the success rate is... > > > -- Niels. > > I am getting several a day as well as ugly MS Word based trojan. They come to me from all over the world with the subject line: "NANOG Payment Remittance Advice" I agree with Niels, someone or some spamming outfit is burning through quite a bit of stolen credentials. Richard Golodner Infratection
Re: Spamming of NANOG list members
* br...@shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Yes. It's pretty annoying. And somebody seems to be burning through a lot of stolen credentials. I wonder what the success rate is... -- Niels.
Re: Spamming of NANOG list members
Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?)
Re: PSA: change your fedex.com account logins
The one-off email scheme is not predictable. It is randomly generated string of characters. $ ./randgen jvtMDluV0lwnlY5O So you can totally eliminate that possibility entirely. -Dan On Fri, 31 May 2019, Jason Kuehl wrote: Is it possible, yes. I've seen it several times now at my place of work. Targeted attacks are a thing. On Fri, May 31, 2019 at 2:53 AM Mike Hale wrote: Oh for fucks sake. Really? You two are questioning someone who subscribes to Nanog over Fedex? You really think it's more likely that someone is targeting Dan Hollis (whoever he is) instead of Fedex leaving something else exposed? On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: Dan Hollis wrote: Phishing scheme didn't happen. fedex has had a number of major compromises so it's not a stretch that their user database was stolen and sold to spammers. The other possibility is that your one-off email scheme is predictable, and someone knows you use FedEx, and that someone is targeting specifically you, and this obvious phishing email is a red herring for the exploit you didn't see. Be concerned. -- S.C. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.ku...@gmail.com
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 757484 Prefixes after maximum aggregation (per Origin AS): 290744 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 361416 Total ASes present in the Internet Routing Table: 64395 Prefixes per ASN: 11.76 Origin-only ASes present in the Internet Routing Table: 55392 Origin ASes announcing only one prefix: 23824 Transit ASes present in the Internet Routing Table:9003 Transit-only ASes present in the Internet Routing Table:277 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table:26 Number of instances of unregistered ASNs:29 Number of 32-bit ASNs allocated by the RIRs: 27191 Number of 32-bit ASNs visible in the Routing Table: 22216 Prefixes from 32-bit ASNs in the Routing Table: 99727 Number of bogon 32-bit ASNs visible in the Routing Table:21 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:256 Number of addresses announced to Internet: 2845014656 Equivalent to 169 /8s, 147 /16s and 122 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 253034 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 204745 Total APNIC prefixes after maximum aggregation: 60806 APNIC Deaggregation factor:3.37 Prefixes being announced from the APNIC address blocks: 200889 Unique aggregates announced from the APNIC address blocks:82494 APNIC Region origin ASes present in the Internet Routing Table:9777 APNIC Prefixes per ASN: 20.55 APNIC Region origin ASes announcing only one prefix: 2710 APNIC Region transit ASes present in the Internet Routing Table: 1458 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4784 Number of APNIC addresses announced to Internet: 772744832 Equivalent to 46 /8s, 15 /16s and 38 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:225546 Total ARIN prefixes after maximum aggregation: 105128 ARIN Deaggregation factor: 2.15 Prefixes being announced from the ARIN address blocks: 224578 Unique aggregates announced from the ARIN address blocks:105785 ARIN Region origin ASes present in the Internet Routing Table:18488 ARIN Prefixes per ASN:12.15 ARIN
Re: BGP prefix filter list
On 2019-05-31 01:18 +, Mel Beckman wrote: > No, that's not the situation being discussed. Actually, that *was* the example I was trying to give, where I suspect many are *not* following the rules of RFC 1930. > As I've pointed out, a multi homed AS without an IGP connecting all > prefixes is non-compliant with the BGP definition of an AS. Your > Tokyo/DC example is additionally non-compliant because it doesn't > have a single routing policy. It has two policies. That this may > work in certain circumstances doesn't make it compliant with the > standard. So, an *organization* with one Tokyo office and one DC office, each having a PI prefix, and with their own Internet connection(s), and no private interconnect with an IGP connecting the sites. They can handle this in several ways: 1) Use the same ASN for both sites, each site announcing only its own, prefix over eBGP to its ISPs. They won't be able to receive the other site's prefix over eBGP, since the loop detection in BGP will see the common ASN in the announcments from the other site and drop it, but that can be easily handled by the sites adding static routes via their ISPs (or by just getting default routes from their ISPs). This violates RFC 1930; I agree with that. But does it fail in the real world? Will ARIN/APNIC revoke their ASN and/or prefixes due to violating RFC 1930? Will the rest of the Internet try to route the Tokyo prefix to DC, or vice versa, due to them being originated from the same ASN? Any other problems? 2) Get a separate ASN for each site. Continue with not having an IGP between the sites, and continue with announcing different prefixes from each site. They can however now receive each others prefixes over BGP. This does not violate RFC 1930; nowhere in that document does it say that an organization can only have a single ASN. But will ARIN/APNIC be willing to give out two ASNs to that one organization? Does the answer change if it is not one site in Asia and one in America, but one site in every US state? Or one such site in each of the 290 municipalities in Sweden (and pre- sumably trying to get ASNs from RIPE instead of ARIN)? 3) Pay the high fees for getting private interconnects between the continents (or for each of the 290 offices in the Swedish example), and let all sites announce all of each others prefixes, acting as transits for reaching the other sites. This obviously costs more money. I have never priced such an interconnect, so I don't know how much it would cost, but I expect it to be fairly expensive. Also: what happens if the interconnect breaks, partitioning the AS? Then they are in effect at situation (1), violating RFC 1930, with of course the same questions/problems. 4) Pay the high fees for private interconnects, use the same ASN at both sites, but let each site announce the other's prefix with larger amounts of AS path prepending so "no-one" tries to send their traffic to the wrong site. This also violates RFC 1930, as far as I understand, as the two sites have different routing policies. But does it cause any real- world problems? Does the IP police arrest them? Will the rest of the world ignore the policies and send their traffic to the wrong site since the prefixes are originated from the same ASN? I suspect that there are a fair number of organizations that does one of (1), (2) or (4) above, and I *believe* that it actually works. And some of the things I see in our ISP's BGP tables looks like at least some people are doing (4), or possibly (1). RFC 1930 might be the law on the book, but does people actually follow it? Or is it just an outdated law that no-one knows or cares about, but no-one has bothered to formally deprecate? (The parts of RFC 1930 implying that we should have migrated to IDRP by now are obviously not in touch with current reality. :-) My personal feelings is that requiring (3) would be a bad thing, as it would cost lots of money. (2) is OK, but I think many people would forget or ignore getting a separate ASN for each site. But I have only a little experience in running BGP, and have only done so for a single-site organization (or at least single-site in terms of where we have our Internet connection). Answers to the questions I make above are appreciated. /Bellman signature.asc Description: OpenPGP digital signature
Re: PSA: change your fedex.com account logins
* r...@gsp.org (Rich Kulawiec) [Fri 31 May 2019, 16:18 CEST]: [...] This is hardly surprising: many of them are spammers-for-hire, many of them use invasive tracking/spyware, and none of them actually care in the slightest about privacy or security -- after all, it's not *their* data, why should they? Which is why we now have GDPR. Care, or get fined. Which are some of the many reasons that outsourcing your mailing lists is a terrible idea, doubly so when it's quite easy to run your own with Mailman (or equivalent). Unfortunately it's not that easy; the few large remaining mail hosters at best have opaque procedures when it comes to accepting mail. -- Niels.
Re: PSA: change your fedex.com account logins
On Fri, May 31, 2019 at 01:17:19PM +, Richard wrote: > When I have looked into this type of issue for my unique addressing > some did trace back to back-end db hacks (e.g., adobe), but I found > that the most likely culprit was the 3rd-party bulk mailer that > handled the organization's marketing mail. It could be a non-zeroed > disk thrown into the trash or an inside job, but it almost always > traced back to one or two bulk mailing companies. FYI, I've been running numerous experiments in this area for many years using unique non-guessable non-typo'able addresses. Explaining the results in full would take many pages, so let me summarize: 3rd party bulk mailers leak like sieves. "How?" remains an open question: could be that they're selling, could be that they have security issues, could be that insiders are selling on their own, could be any number of things: it's really not possible to say. But they are unquestionably leaking. This is hardly surprising: many of them are spammers-for-hire, many of them use invasive tracking/spyware, and none of them actually care in the slightest about privacy or security -- after all, it's not *their* data, why should they? Which are some of the many reasons that outsourcing your mailing lists is a terrible idea, doubly so when it's quite easy to run your own with Mailman (or equivalent). ---rsk
Re: PSA: change your fedex.com account logins
> On May 31, 2019, at 2:17 PM, Richard > wrote: > > > >> Date: Friday, May 31, 2019 08:04:13 -0400 >> From: Jason Kuehl > >> Is it possible, yes. I've seen it several times now at my place of >> work. Targeted attacks are a thing. >> Dan Hollis wrote: Phishing scheme didn't happen. fedex has had a number of major compromises so it's not a stretch that their user database was stolen and sold to spammers. > > When I have looked into this type of issue for my unique addressing > some did trace back to back-end db hacks (e.g., adobe), but I found > that the most likely culprit was the 3rd-party bulk mailer that > handled the organization's marketing mail. It could be a non-zeroed > disk thrown into the trash or an inside job, but it almost always > traced back to one or two bulk mailing companies. The most common issue for quite a while was malware on the windows desktops of employees with access to the companies ESP account. The web browser saves username and password to autofill the ESPs web interface in a very predictable place. Malware exfiltrates that. Bad guys compromise ESP account, download all the lists they can find (and then start spamming on the company dime). That's why ESPs pushed quite so hard to get multifactor authentication of some sort adopted by their customers. But a lot of them didn't do that (partly, I suspect, because the ESP account was accessed by multiple employees) and even if they did that didn't stop the lists that had already been downloaded. Actual compromises of the ESP, or bad behaviour of it's employees, seem to be rather rare but customer account compromise is everywhere. Cheers, Steve
Re: PSA: change your fedex.com account logins
> Date: Friday, May 31, 2019 08:04:13 -0400 > From: Jason Kuehl > Is it possible, yes. I've seen it several times now at my place of > work. Targeted attacks are a thing. > >> > >> > Dan Hollis wrote: >> > >> > Phishing scheme didn't happen. >> > >> > fedex has had a number of major compromises so it's not a >> > stretch that their user database was stolen and sold to spammers. >> > When I have looked into this type of issue for my unique addressing some did trace back to back-end db hacks (e.g., adobe), but I found that the most likely culprit was the 3rd-party bulk mailer that handled the organization's marketing mail. It could be a non-zeroed disk thrown into the trash or an inside job, but it almost always traced back to one or two bulk mailing companies.
Re: Flexible OTN / fractional 100GbE
Hi Adam, Le 31/05/2019 à 13:48, adamv0...@netconsultings.com a écrit : There's got to be vendors out there having an optical chasses with a combination of OTN and ethernet cards for the revenue side of the chasses -look at transmode/Infinera maybe? For now the only vendor which seems to fit the bill is ECI, with their Apollo (and maybe Neptune) lines. But it's far more expensive and less dense that what StrataDNX-based OCP switch could do. Most OTN vendors I got feedback from insists on using their "point and click" NMS which is a PITA in terms of productivity and forbids automation. It simply bares them from my wannabe-future-proof network. On the "looking ahead" notion, is it really impossible to build low latency packet-switched networks? As you know selling full rate L1 circuits will render your core mostly empty (...all that BW that could be monetized). Packet-switching at flexible bandwidth requires buffering, while OTN with CBR only channels would map frames to the uplink' bitstream in real-time. This allows for a 250ns port-to-port latency instead of 450ns for the best-of-breed, and up to 4µs for looked-up switching or routing. Also there won't be jitter on muxponded circuits, while buffering eliminates deterministic latency. And you also got right to the point : most customers will never fill their pipes, so there's extra gain to get from that hybrid box. It's my understanding that some of the largest networks are already working on it, but it's "classified material" for now. I may as well postpone my deployment waiting for their R to be contributed to the OCP project, but I'd rather contribute instead. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Re: PSA: change your fedex.com account logins
Is it possible, yes. I've seen it several times now at my place of work. Targeted attacks are a thing. On Fri, May 31, 2019 at 2:53 AM Mike Hale wrote: > Oh for fucks sake. > > Really? > > You two are questioning someone who subscribes to Nanog over Fedex? > You really think it's more likely that someone is targeting Dan Hollis > (whoever he is) instead of Fedex leaving something else exposed? > > On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: > > > > Dan Hollis wrote: > > > > Phishing scheme didn't happen. > > > > fedex has had a number of major compromises so it's not a stretch that > > their user database was stolen and sold to spammers. > > > > > > The other possibility is that your one-off email scheme is predictable, > and someone knows you use FedEx, and that someone is targeting specifically > you, and this obvious phishing email is a red herring for the exploit you > didn't see. > > > > Be concerned. > > > > -- S.C. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.ku...@gmail.com
RE: Flexible OTN / fractional 100GbE
> From: NANOG On Behalf Of Brandon Martin > Sent: Thursday, May 30, 2019 9:16 PM > > I see what you're getting at. It sounds like you want to light up a 100Gb > wave, put some committed "dedicated wavelength" services on it, then take > whatever's left and hand it off on 100GbE for best-effort/general Internet > traffic. > There's got to be vendors out there having an optical chasses with a combination of OTN and ethernet cards for the revenue side of the chasses -look at transmode/Infinera maybe? Otherwise I guess it doesn't matter whether the ethernet cards are part of the optical chasses or a standalone PE on the stick. If customer wants full OTN-step rate plug into optical chasses if customer needs fractional rate plug into (Broadcom) PEs hanging off of the optical switch. On the "looking ahead" notion, is it really impossible to build low latency packet-switched networks? As you know selling full rate L1 circuits will render your core mostly empty (...all that BW that could be monetized). adam
Re: Flexible OTN / fractional 100GbE
Hi Radu, There might be some misunderstanding here. I don't care about what's sold or done *today*, I'm thinking ahead of what newer hardware and software will allow us to build in the (near) future. That's probably something most of us lack : freedom to look ahead, rather than being swamped in yesterday's concerns. In that specific case, I'm the middleman buying fat pipes and selling slices from them. Should I stick to good'ol L2VPNoMPLS-TP ? Or does newer gear let me do things in a slightly better way ? May SDN allow me to fine-tune my network to fit functional needs or is technology still a barrier to efficient use-cases ? As an optimist, I chose the former, and love to engage in such debates with my peers, as long as I can avoid backward-thinking "We've always done it that way" assertions. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Re: Flexible OTN / fractional 100GbE
On Thu, May 30, 2019, at 09:41, Jérôme Nicolle wrote: > Yup. Should it hard-drop ? Buffer ? Both are unthinkable in OTN terms > (is that a cultural thing ?). It's what packet networks are made for. > And that's why an alien device, with support for Ethernet, OTN and > programmable pipelines, could bridge the gap, allowing for a more > efficient use of optical bandwidth. Hi Jerome, When you buy the kind of services that end-up being delivered on OTN, you expect to have a capacity that is dedicated to you, and only to you, and if you don't "use" it nobody else will. And you agree with the constraints that come with that (not protected, or protection is an extra paid option). Than comes the fact that Ethernet is *NEVER* "fractional". It is either 0 (ZERO) or line-rate. It's the amount (in time) of ZERO present over several microseconds (often "several" == "several millions") that gives (by doing an average) the "sub-rate" bandwidth. So no, hard-drop or buffer on OTN are not only "cultural issues", their absence is technically part of the OTN promise. If you are willing to accept to share unused bandwidth, then MPLS based services are the way to go, and you have that choice in a vast majority of the cases. You loose the hard guarantee of bandwidth availability and you usually get some trace of jitter.
Re: PSA: change your fedex.com account logins
Oh for fucks sake. Really? You two are questioning someone who subscribes to Nanog over Fedex? You really think it's more likely that someone is targeting Dan Hollis (whoever he is) instead of Fedex leaving something else exposed? On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: > > Dan Hollis wrote: > > Phishing scheme didn't happen. > > fedex has had a number of major compromises so it's not a stretch that > their user database was stolen and sold to spammers. > > > The other possibility is that your one-off email scheme is predictable, and > someone knows you use FedEx, and that someone is targeting specifically you, > and this obvious phishing email is a red herring for the exploit you didn't > see. > > Be concerned. > > -- S.C. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Re: PSA: change your fedex.com account logins
Dan Hollis wrote: > Phishing scheme didn't happen. > > fedex has had a number of major compromises so it's not a stretch that > their user database was stolen and sold to spammers. The other possibility is that your one-off email scheme is predictable, and someone knows you use FedEx, and that someone is targeting specifically you, and this obvious phishing email is a red herring for the exploit you didn't see. Be concerned. -- S.C.
