Re: dnssec keytrap vuln
For me, LinkedIn renders those links as tracker links only, so I can't tell what they are until I follow them. Also (in Crocodile Dundee voice): *That's* not a really long list. :D https://infosec.exchange/@tychotithonus/111924626712765292 \(disclaimer: my own work on tracking the DNSSEC validation DoS vulnerabilities - both CVE-2023-50387 ("KeyTrap") and CVE-2023-50868 (NSEC3 vuln) - improvements welcome) -- Royce Williams Tech Solvency On Sat, Feb 17, 2024 at 1:11 AM Dave Taht wrote: > Really long list of fixed dns servers here: > > > https://www.linkedin.com/posts/bwoodcock_a-bunch-of-really-hard-work-over-the-past-activity-7163284274660532224-vYKv > -- > 40 years of net history, a couple songs: > https://www.youtube.com/watch?v=D9RGX6QFm5E > Dave Täht CSO, LibreQos >
Re: NTP Sync Issue Across Tata (Europe)
Respectfully, that Wikipedia article (which is mostly about legit but unauthorized clients overwhelming a given peer) and your cites don't seem to cover what I was responding to - the "don't peer with public NTP because someone can flood your firewall and spoof the responses" problem. I just want to make sure that I'm understanding the distinction betwen this class and other classes of attack. Wouldn't a robust implementation of peering - say, seven peers, with the NTP algorithm handily selecting a subset to peer with for each cycle - require an attacker to know and overwhelm not just one, but a majority of the peer IPs? This is *not* to say that I'm advocating against maintaining local stratum 0s as part of a proper operator-grade NTP mesh. (My definition of "robust implementation" would include both local stratum 0 and a healthy serving of Internet stratum 1s). I'm just suggesting "don't peer with public servers" seems draconian given the deliberate design choices of the protocol. For this audience, this would recommend a tiered system where multiple mixed-stratum internal stratrum 0+1s would peer with each other, and maintain internal-facing consensus for all other downstream internal devices - such that the vast majority of internal peers would indeed not be talking to the public Internet (but the "parent" peers would, and have the mesh and mix that I describe). And I'm well aware of who I'm saying this to ... so I expect to find out where I'm wrong, as I keep digging. :D -- Royce On Sun, Aug 6, 2023 at 11:40 AM Mel Beckman wrote: > In a nutshell, no. Refer to my prior cites for detailed explanations. For > a list of real-world attack incidents, see > > https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse# > <https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse#:~:text=NTP%20server%20misuse%20and%20abuse%20covers%20a%20number%20of%20practices,the%20NTP%20rules%20of%20engagement.> > > > -mel > > On Aug 6, 2023, at 12:03 PM, Royce Williams > wrote: > > > Naively, instead of abstaining ;) ... isn't robust diversity of NTP > peering a reasonable mitigation for this, as designed? > > Royce > > On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman wrote: > >> William, >> >> Due to flaws in the NTP protocol, a simple UDP filter is not enough. >> These flaws make it trivial to spoof NTP packets, and many firewalls have >> no specific protection against this. in one attack the malefactor simply >> fires a continuous stream of NTP packets with invalid time at your >> firewall. When your NTP client queries the spoofed server, the malicious >> packet is the one you likely receive. >> >> That’s just one attack vector. There are several others, and all have >> complex remediation. Why should people bother being exposed to the risk at >> all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve >> already described. Having suffered through such attacks more than once, I >> can say from personal experience that you don’t want to risk it. >> >>
Re: NTP Sync Issue Across Tata (Europe)
Naively, instead of abstaining ;) ... isn't robust diversity of NTP peering a reasonable mitigation for this, as designed? Royce On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman wrote: > William, > > Due to flaws in the NTP protocol, a simple UDP filter is not enough. These > flaws make it trivial to spoof NTP packets, and many firewalls have no > specific protection against this. in one attack the malefactor simply fires > a continuous stream of NTP packets with invalid time at your firewall. When > your NTP client queries the spoofed server, the malicious packet is the one > you likely receive. > > That’s just one attack vector. There are several others, and all have > complex remediation. Why should people bother being exposed to the risk at > all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve > already described. Having suffered through such attacks more than once, I > can say from personal experience that you don’t want to risk it. > >
Re: FIDO2/Passkey now supported for 2FA for ARIN Online (was: Fwd: [arin-announce] New Features Added to ARIN Online)
On Tue, Jan 3, 2023 at 11:59 AM John Curran wrote: > FYI - ARIN Online now has FIDO2/Passkey as an option for two-factor > authentication (2FA) - this is a noted priority for some organizations. > John - this is a great step forward! Kudos to the tech team who helped make the leap - it can be daunting. Some feedback, take or leave as you see fit, based on my scars: First, thanks specifically for the support for unique key names (you might be surprised at how many services don't!), and for the FIDO2 support of on-key PINs. Second, I'd like to second ;) - but go beyond - Job's feature request for multiple-key support, both in count and additional UX. Support for *more* than two keys is recommended, to fit a wider variety of use cases and threat/risk models (connector availability, shared/role accounts, offsite key backup, etc etc). From my survey of 50 providers of U2F / FIDO / FIDO2, key-count support ramps up quickly from one (PayPal - come on, y'all!), two (Bank of America), and five (AOL/Yahoo and Coinbase), with the rest supporting *ten or more keys* (and yes, higher key counts have use cases, though user experience degrades above ten keys). And when multiple key support is added, please consider some UX around managing the list of keys (like allowing the user to *modify* key names without having to delete and re-add them, showing the timestamp, IP, OS family / platform, etc. from where the key was last used). Great key UX examples to emulate in this space include Dropbox and Google. (And showing the IP's ASN would be a uniquely ARIN twist. :D ) Third, please consider allowing a mix of authenticators (instead of the current exclusive choice among TOTP, FIDO2, and SMS). While it will be excellent to allow users to *eventually* opt into exclusive use of security keys (as with Google's Advanced Protection Program) ... doing so with a *single* key unacceptably shifts the risk model for some users. A mix allows users to manage their risk model directly, often by voluntarily using FIDO2 first to get the phishing resistance / origin verification of FIDO2, but mitigating single-key risk with fallback to TOTP (which may be more fluidly available than the 2FA recovery codes, etc.). But the hardest part - going from zero keys to any - is already done. Really appreciate it! Royce
Re: FYI - 2FA to be come mandatory for ARIN Online? (was: Fwd: [arin-announce] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts
On Fri, May 27, 2022, 9:55 PM Peter Beckman wrote: > Not to be confused with FIDO U2F, which is basically what TOTP 2FA is, > just implemented differently. > FIDO U2F is materially different from TOTP 2FA. With TOTP, there is no cryptographic validation of the requester / server. A user can be fooled into providing a TOTP code to the wrong site, or via phishing, or by an attacker simply making repeated authentication requests in the middle of the night until the user gets exasperated and provides the code. By contrast, even the original FIDO U2F spec authenticates the 'origin' - the server being authenticated *to*. I'm glossing over the details, but in essence, the browser compares the cryptographic signature, and if it doesn't match the expected origin, it won't complete the authentication. It is this property that virtually eliminated an entire class of phishing at Google: https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/ TOTP does not have equivalent phishing resistance. -- Royce >
CIDR string replacement
The recent thread on CIDR aggregation cleanup scripts reminds me that I'm looking for a similarly efficient implementation of a related tool. (I'm gearing up to write my own in Perl, but don't want to reinvent the wheel.) I'd like a fast, Unix-pipeline-ready tool that *replaces* all IPs within that range with a supplied string, using a simple config file as input, and ideally with autodetection of IP-address "word" boundaries, as in: $ cat cidr-replace.cfg 105.170.75.0/24|[Unitel] 209.112.128.0/18|[ACS] 209.165.128.0/18|[GCI] 192.0.2.0/24|[TEST-NET-1] 198.51.100.0/24|[TEST-NET-2] 203.0.113.0/24|[TEST-NET-3] $ echo "source,data1,data2,209.112.130.2,data3" | cidr-replace cidr-replace.cfg source,data1,data2,[ACS],data3 And I know this is kludgy, but it would also be useful for quick-and-dirty work if it had a flag to "append" the string using a known delimiter, as in: $ echo "source,data1,data2,209.112.130.2,data3" | cidr-replace --append ',' cidr-replace.cfg source,data1,data2,209.112.130.2,[ACS],data3 (But I'm happy to hack that last functionality into an existing script.) -- Royce
Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read
On Tue, Dec 31, 2019 at 7:46 AM Matt Harris wrote: > > On Tue, Dec 31, 2019 at 10:34 AM Royce Williams > wrote: > >> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris wrote: >> >>> >>> The better solution here isn't to continue to support known-flawed >>> protocols, which perhaps puts those same populations you're referring to >>> here at greatest risk, but rather to enable access to open technologies for >>> those populations which ensures that they can continue to receive security >>> updates from a vendor that doesn't have a big financial motive to deprecate >>> devices and force users to purchase upgraded hardware instead of just >>> receiving security updates to their existing devices. >>> >> >> Unfortunately, this is the high-tech privilege equivalent of saying "let >> them eat cake" - because of upgrade friction on mobile in under-resources >> areas (including, I might add, specific sub-populations of US consumers!) >> > > Perhaps more unfortunately, the other option - to continue supporting > known-flawed protocols - is simply saying "let them be victimized." > With the rise of state-level disinformation at scale, I see your point. > Accepting that we should instead support technologies that place those > very same populations at risk is coming from a place of privilege for the > reasons I mentioned previously: you live somewhere with relatively > peaceful/democratic governance, usually have at least some ISP choice, and > are likely not otherwise under the thumb of an oppressive regime at some > level of another - so when your browser makes a TLS1.0 connection, you > probably don't even think about it, much less worry about it, because you > don't have to. The populations we're discussing here, on the other hand, > all too often do. > > What it comes down to is a question of whether we want to solve what we > know today is a real problem or let it fester until abuse reaches an > untenable level in some big, news-headline-making way. One way we can > combat this specific issue is to make open technologies accessible. But > that requires major investment on our side of the world, and prior attempts > to do so (Ubuntu's open source phone OS for example) have largely been > commercial flops. > Indeed. Though a non-commercial (grass-roots, sponsored, or legislative) solution seems similarly unlikely. Royce
Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read
On Tue, Dec 31, 2019 at 7:32 AM Royce Williams wrote: > On Tue, Dec 31, 2019 at 7:17 AM Matt Harris wrote: > >> On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen wrote: >> >>> On 12/31/19 12:50 AM, Ryan Hamel wrote: >>> > Just let the old platforms ride off into the sunset as originally >>> > planned like the SSL implementations in older JRE installs, XP, etc. >>> You >>> > shouldn't be holding onto the past. >>> >>> >>> Because poor people anywhere on earth that might not have access to the >>> newer technology don't deserve access to Wikipedia, right? Gotta make >>> sure information is only accessible to those with means to keep "lesser" >>> people out. >>> >> >> The better solution here isn't to continue to support known-flawed >> protocols, which perhaps puts those same populations you're referring to >> here at greatest risk, but rather to enable access to open technologies for >> those populations which ensures that they can continue to receive security >> updates from a vendor that doesn't have a big financial motive to deprecate >> devices and force users to purchase upgraded hardware instead of just >> receiving security updates to their existing devices. >> > > Unfortunately, this is the high-tech privilege equivalent of saying "let > them eat cake" - because of upgrade friction on mobile in under-resources > areas (including, I might add, specific sub-populations of US consumers!) > > If there were reliable, official, clean replacement Androrid ROMs for > older hardware, the cottage industry of end-user phone repair in many > countries could take a perfectly good phone and get basic modern services > working on it. > > But there aren't - and there's little financial motivation for the phone > OEMs to provide one. And there isn't really much you can do to replace the > OS on an old iPhone, either. > > One of the best things that Google could do for the security of the > Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for > older phones with minimal backported security updates. I would expect that > such ROMs must actually exist internally, as needed for OEM patch > integration testing. > > The answer to why such ROMs will likely not be made publicly available is > left as an exercise for the reader. > But perhaps you were suggesting that a *grass-roots* effort to create such ROMs might be in order? I would love to donate to such a project. But short of a million-dollar grant, or legislation, I am not optimistic. Royce
Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris wrote: > On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen wrote: > >> On 12/31/19 12:50 AM, Ryan Hamel wrote: >> > Just let the old platforms ride off into the sunset as originally >> > planned like the SSL implementations in older JRE installs, XP, etc. >> You >> > shouldn't be holding onto the past. >> >> >> Because poor people anywhere on earth that might not have access to the >> newer technology don't deserve access to Wikipedia, right? Gotta make >> sure information is only accessible to those with means to keep "lesser" >> people out. >> > > The better solution here isn't to continue to support known-flawed > protocols, which perhaps puts those same populations you're referring to > here at greatest risk, but rather to enable access to open technologies for > those populations which ensures that they can continue to receive security > updates from a vendor that doesn't have a big financial motive to deprecate > devices and force users to purchase upgraded hardware instead of just > receiving security updates to their existing devices. > Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!) If there were reliable, official, clean replacement Androrid ROMs for older hardware, the cottage industry of end-user phone repair in many countries could take a perfectly good phone and get basic modern services working on it. But there aren't - and there's little financial motivation for the phone OEMs to provide one. And there isn't really much you can do to replace the OS on an old iPhone, either. One of the best things that Google could do for the security of the Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for older phones with minimal backported security updates. I would expect that such ROMs must actually exist internally, as needed for OEM patch integration testing. The answer to why such ROMs will likely not be made publicly available is left as an exercise for the reader. Royce
Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read
On Tue, Dec 31, 2019 at 6:12 AM Seth Mattinen wrote: > On 12/31/19 12:50 AM, Ryan Hamel wrote: > > Just let the old platforms ride off into the sunset as originally > > planned like the SSL implementations in older JRE installs, XP, etc. You > > shouldn't be holding onto the past. > > > Because poor people anywhere on earth that might not have access to the > newer technology don't deserve access to Wikipedia, right? Gotta make > sure information is only accessible to those with means to keep "lesser" > people out. > This. I visited a rural school in South Africa around 2008. For many things - such as using their cellphone provider's billing infrastructure to pay for third-party services via SMS - a switch to TLS 1.2 only would probably have no impact. But for educational purposes, their reliance on Wikipedia was dramatic - and they could *only* get to it from outdated phones that had been donated, scavenged, or cobbled together from parts. In the intervening years, the disposable-electronics culture has probably been a great boon to them, bringing better and more tech - but much of it is probably still pre Android 4.4.2 But perhaps Wikipedia's decision is based on actual data. I'd love to see percentages of their negotiated TLS ciphers, per country and per client type. Back in 2015, you could see them as discussed here: https://news.ycombinator.com/item?id=10194258 ... but I'm not sure where the equivalent data would be in the new Grafana data: https://grafana.wikimedia.org/?orgId=1 Royce
Re: BGP/dDos gift from NIST
On Wed, Dec 25, 2019 at 1:15 AM william manning wrote: > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf > I can't speak to the technical content, but this put a curdle in my morning coffee: "... that comprise the internet [sic]" . Et tu, NIST? I will die on this "capital "I" in *the* Internet" hill. ;) (And no, I don't care what the AP Stylebook decided to pull out of thin air, with no understanding of how the Internet works or what it means; the argument that "there are many possible internets" is specious, because that's not what "the Internet" means; to the extent that various other "internets" get balkanized out of the Internet, to the extent that they interconnect, *that* will always and forever be "the Internet".) What's next - geology textbooks calling our single, unique planet "the earth" ? (Which brings to mind a great illustration of why "the Internet" matters: if, by some happenstance of etymology, we referred to our planet solely as "the Planet", then there could be many other planets, but only one Planet.) (And regardless of what you call it ... thanks to each of you for operating your piece of it!) Royce
Re: D'oH III: In 3-D! Plot Twist from Google/Chrome, Vixie approves?
The difference is that Chrome won't use resolvers other than the ones you've configured yourself, and will simply opportunistically upgrade to DoH if they detect that those resolvers support it. In other words, there is no usurpation of administrative intent. Royce On Wed, Oct 30, 2019 at 7:30 AM Jay R. Ashworth wrote: > It's not clear to me whether Paul is expressing approval of the whole > shebang > at this point, or just the one change they've made, but, just on first > look, > I don't think that change addresses *my* distaste for DoH, as discussed in > last month's 100-poster. :-) > > > https://www.zdnet.com/article/dns-over-https-google-hits-back-at-misinformation-and-confusion-over-its-plans/ > > TL;DR: they (Chrome) won't enable DoH unless it's being run from an > internet > which they know supports it; there are apparently a list of 8-12 ISPs/etc > which are announcing such support. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 >
Re: NTP for ASBRs?
On Wed, May 8, 2019 at 11:12 PM Eric S. Raymond wrote: > Chris Adams : > > Once upon a time, Royce Williams said: > > > The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) > tracks > > > DST - and even leap seconds. They have much better reach than previous > > > similar clocks. > > > > Looks like somebody finally brought a clock to market that uses the > > new-format phase-modulated signal. Hopefully there'll be more, but with > > the WWVB funding threats, I wouldn't be surprised if companies don't > > want to invest in any new products that use it. > > Interesting - first device I've heard of that uses the new-format > fine modulation, and as NTPsec's tech lead I keep as close an eye on such > developments as anybody. > > Before this I had thought that a combination of clock vendors feeling > burned by > the modulation change and cheap GPSes entirely killed the market for > devices that > can get high-precision time from WWBV. > > Anybody know of anything fitting that description that you might want > to deploy in a data center as a Stratum 1? If such a creature exists I > shall > contrive to get my lunch hooks on one and write a driver for it. That would be fantastic. I mentioned it on Freenode when it first came out - but it may have escaped your attention. :) An eBay search for "EverSet ES100 WWVB BPSK Phase Modulation Receiver Kit" should prove fruitful. I have one - but I haven't had time to tinker with it yet. The kit comes with the double-antenna setup that appears to be key to the improved reception. In the clocks, the antennas are at 90 degrees relative to each other. Royce
Re: NTP for ASBRs?
On Wed, May 8, 2019 at 7:16 PM Bryan Holloway wrote: > On 5/8/19 7:55 PM, Brian Kantor wrote: > > On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: > >> 100% true. But there is also a practical side to this ... > >> > >> When a NOC-ling, in their own local timezone, says, "hey, what happened > >> two hours ago?", they have to make a calculation. And that calculation > >> annoyingly depends on the time of year in many if not most locales > >> worldwide. And to make matters worse, some folks change at different > >> times of the year, so, if you're a global network > >> > >> Hawai'i and Arizona can add/subtract without looking at the damn > >> calendar. I'm just sayin' I'd like to see more of that. > > > > Clocks are cheap. I have two on the wall; one is local time and > > the other is marked GMT. > > - Brian > > Cheap != free. Many clocks have to be set after a DST change. Clocks > that do this automatically are > cheap. > > I stand by my point. > > Disclaimer: I have two clocks. > Assuming that WWVB will persist (a medium-sized assumption) ... The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) tracks DST - and even leap seconds. They have much better reach than previous similar clocks. Mine work during daytime deep inside buildings in Alaska, far outside the traditional WWVB reach. They're also also simple and legible, which could make them a good NOC choice. Local timezone is adjustable, so you could easily run one on local time and one on UTC. They also change their hand positions to indicate low-battery status. Not cheap, but not too bad - price hovers around US$48-$52. Big fan. Royce
Re: Widespread Firefox issues
On Sat, May 4, 2019 at 8:02 AM Royce Williams wrote: > On Sat, May 4, 2019 at 7:40 AM Royce Williams > wrote: > >> On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: >> >>> >>> I will stick to the "clearly false" since it is now well to the point >>> where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are >>> disabled (and have been since forever), no studies have been loaded, and my >>> extensions still work quite fine, thank-you. Attempting to install a "new" >>> extension fails with a "bad signature" error. >>> >> >> Here's something interesting - a few times now, I've told Firefox to >> enable Studies and then restarted ... but the Studies setting reverted to >> being unchecked. >> >> Maybe one of my other paranoia-enabling extensions is toggling it off ... >> but if so, I haven't found it yet. Still investigating. >> > > Even stranger, I can manually toggle 'app.shield.optoutstudies.enabled' in > about:config ... and *that* persists across reboots ... but Studies *still* > aren't enabled (the about:preferences item is still unchecked, and the > "about:studies" area still indicates that they're disabled). > > There's definitely something weird about enabling/disabling studies. > > FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of Firefox > that had studies disabled before this issue emerged. On a very similar > setup, but one with a vanilla Firefox install that already had Studies > enabled, I can't recreate this symptom - even if I turn Studies off (either > using the GUI or with the about:config item). > Multiple people have replied offthread that they have the same symptom. This workaround worked for me: https://www.reddit.com/r/firefox/comments/bkk5ss/if_you_dont_want_to_wait_do_this/ Royce
Re: Widespread Firefox issues
On Sat, May 4, 2019 at 7:40 AM Royce Williams wrote: > On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: > >> >> I will stick to the "clearly false" since it is now well to the point >> where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are >> disabled (and have been since forever), no studies have been loaded, and my >> extensions still work quite fine, thank-you. Attempting to install a "new" >> extension fails with a "bad signature" error. >> > > Here's something interesting - a few times now, I've told Firefox to > enable Studies and then restarted ... but the Studies setting reverted to > being unchecked. > > Maybe one of my other paranoia-enabling extensions is toggling it off ... > but if so, I haven't found it yet. Still investigating. > Even stranger, I can manually toggle 'app.shield.optoutstudies.enabled' in about:config ... and *that* persists across reboots ... but Studies *still* aren't enabled (the about:preferences item is still unchecked, and the "about:studies" area still indicates that they're disabled). There's definitely something weird about enabling/disabling studies. FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of Firefox that had studies disabled before this issue emerged. On a very similar setup, but one with a vanilla Firefox install that already had Studies enabled, I can't recreate this symptom - even if I turn Studies off (either using the GUI or with the about:config item). Royce
Re: Widespread Firefox issues
On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: > > I will stick to the "clearly false" since it is now well to the point > where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are > disabled (and have been since forever), no studies have been loaded, and my > extensions still work quite fine, thank-you. Attempting to install a "new" > extension fails with a "bad signature" error. > Here's something interesting - a few times now, I've told Firefox to enable Studies and then restarted ... but the Studies setting reverted to being unchecked. Maybe one of my other paranoia-enabling extensions is toggling it off ... but if so, I haven't found it yet. Still investigating. Royce
Re: Comcast storing WiFi passwords in cleartext?
On Wed, Apr 24, 2019 at 8:33 PM Mike Bolitho wrote: > "than the relatively low risk of a database compromise leading to a >> miscreant getting ahold of their wireless password and using their access >> point as free wifi." >> > > And this is the thing, not only does someone have to 'hack' the database, > they also need to drive up to your house and sit in your driveway to get > free Internet. Of all the things to worry about, this is way down on my > list. > They could also remotely compromise *any* device that's currently (or about to be) in range of your access point, as a stepping-stone to gaining access to your network - without having to be physically anywhere near your driveway. Perhaps, for example, to make it look as though what they're doing is coming from your house. Royce
Re: plaintext email?
And just imagine what email threading might be like today ... ... if early email clients had defaulted to displaying the *bottom* of the thread (as if you'd scrolled there). Thoughtful UX design matters. -- Royce Williams Tech Solvency On Mon, Jan 14, 2019 at 8:39 PM wrote: > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > And now you're sitting here wondering what possible relevance that might > have > to some line or other - the only context you have at this point is that > it's a > reply to something you wrote. Actually, at this point you don't even have > that. > > So you may have read this entire thing and now you're still wondering what > possible relevance it may have to the thread. > > On Tue, 15 Jan 2019 00:24:30 -0500, b...@theworld.com said: > > Why dig through what you've already read to see the new comments? > > Or you can put the comment after, so everybody who reads text top to > bottom has > the context. I'm not away of any languages or writing systems that work > from > bottom to top, so that's pretty much everybody. And if people trimmed the > quoted material so only the parts being replied to are left, there's not > much > digging involved. > >
Re: Amazon now controls 3.0.0.0/8
Obligatory list of all known same-quad servers and their DNS status - corrections welcome: https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 If there is info about previous/historical use of these IPs, I'd like to find a way to incorporate that as well. -- Royce On Thu, Nov 8, 2018 at 4:31 PM Todd Underwood wrote: > google used 4.4.4.4 for DNS in the past (2010, IIRC). > > t > > On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: > >> >> I think it was the dial modem team that beat us to 4.4.4.0/24? >> >> -Steve >> >> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: >> >>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>> would have used 4.4.4.[123]. >>> >>> Johno >>> >>> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >>> >>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS >>> is incoming. >>> >>> -Matt >>> >>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >> https://news.ycombinator.com/item?id=18407173 Quoting from the post: " Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. Previous owner was GE. Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range. https://whois.arin.net/rest/net/NET-3-0-0-0-1.html https://whois.arin.net/rest/net/NET-3-128-0-0-1.html "
Re: Security team objectives
On Sun, Jul 29, 2018 at 8:58 PM wrote: > > On Mon, 30 Jul 2018 06:43:35 +0200, Ramy Hashish said: > > If you are going to start a security team in a newly founded IT > > organization, what will the objectives/results be? > > The answer will depend heavily on the organization that contains the IT > group. The right answers will be different for a bank, an ISP, a > Fortune500, or a large university. The location (country and > state/province) and legal requirements for the company will also > matter - I have to worry about FERPA, Comcast probably doesn't... Nevertheless, some broad common objectives exist. IMO, no one summarizes it better than Richard Bejtlich, in his "Defensible Network Architecture 2.0": https://taosecurity.blogspot.com/2008/01/defensible-network-architecture-20.html The corresponding metrics for measuring results/progress would be more specific to the type of org. Royce Royce
Re: Whois vs GDPR, latest news
On Sat, May 26, 2018 at 4:57 PM Dan Holliswrote: > I imagine small businesses who do a small percentage of revenue to EU > citizens will simply decide to do zero percentage of revenue to EU > citizens. The risk is simply too great. That would be a shame. I would expect the level of effort to be roughly commensurate with A) the size of the org, and B) the risk inherent in what data is being collected, processed, stored, etc. I would also expect compliance to at least partially derive from vendor/cloud/outsource/whatever partners, many of whom should be scaled/scaling up to minimally comply. I would also not be surprised if laws of similar scope start to emerge in other countries. If so, taking your ball and going home won't be sustainable. If small, vulnerable orgs panic and can't realistically engage the risk, they may be selecting themselves out of the market - an "I encourage my competitors to do this" variant. Naively ... to counter potential panic, it would be awesome to crowdsource some kind of CC-licensed GDPR toolkit for small orgs. Something like a boilerplate privacy policy (perhaps generated by answers to questions), plus some simplified checklists, could go a long way - towards both compliance and actual security benefit. In a larger sense ... can any org - regardless of size - afford to not know their data, understand (at least at a high level) how it could be abused, know who is accessing it, manage it so that it can be verifiably purged, and enable their customers to self-manage their portion of it?? I'm personally a big fan of undue diligence and all, but we need to advocate for some ... realistic scaling of response. Royce
Re: Yet another Quadruple DNS?
And FWIW, there are currently a few other other same-quad open resolvers: # IP - desc | CIDR | recursion-yes 1.1.1.1 - APNIC-LABS - Research prefix for APNIC Labs (now Cloudflare distributed public recursive DNS) | 1/8 | recursion-yes 8.8.8.8 - Google LLC (public recursive DNS) | 8.8.8/24 | recursion-yes 9.9.9.9 - Quad9 (public recursive DNS) | 9.9.9/24 | recursion-yes 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | recursion-yes 80.80.80.80 - Freenom DNS CLoud IP Space | 80.80.80/23 | recursion-yes 114.114.114.114 - NanJing XinFeng Information Technologies, Inc. | 114.114/16 | recursion-yes Full survey - with owners of the largest bit-boundary-aligned blocks that contain them - here: https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 Royce
Re: Yet another Quadruple DNS?
On Fri, Mar 30, 2018 at 5:30 AM, Christopher Morrowwrote: > > On Thu, Mar 29, 2018 at 10:32 AM, Stephane Bortzmeyer > wrote: > > > Public DNS resolvers still help against "ordinary" adversaries. (If > > your ennemy is the NSA, you have other problems, anyway.) If you're individually targeted by such an org, yes. If you want to raise the cost of slurping up everyone's traffic in bulk and then sifting/analytic-ing through it later, then some effort (encrypting/verifying everything feasible, using ciphers that support forward secrecy, MFA, etc.) is worthwhile. Bulk encryption is a reasonable response to bulk intercept. Raising the chances of *detecting* attempts at such interception is also warranted. I'm not aware of any browser extensions that incorporate the technique used by https://mitm.watch/ (or even if it's feasible at that layer), but that would be useful, too. > I think there's ample evidence that everyone's enemy is 'the nsa' (or other > nation-state-actors) isn't there? s/"nation-state"/"anyone who can intercept, alter, or inject traffic between you and your destination"/g. Of course, that neither solves the problem of manipulative use of your traffic *by* your destination (*cough*Facebook/everyone*cough*) nor the problem of compromise of the endpoint. Increasing intercept resistance does nothing for the former (only voting, or voting with your dollar, can impact that) ... but it can help with the latter (by making it harder for someone to compromise your endpoint by manipulating/mimicking traffic from your destination). (None of this is news to most of you, but IMO clarifying the breadth of the landscape has value). And of course, none of this is news to Stephane: https://tools.ietf.org/html/rfc7816 :) Royce
Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
On Thu, Mar 1, 2018 at 1:38 PM, Randy Bushwrote: > > > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, > > right? it's the only sane choice for 'fresh out of the box' network > > daemons: "Yes, it's running, yes I can healthcheck it locally to prove > > it's running" > > amidst all the hysterical pontification, i am having trouble finding any > release which has, by default, a port 11211 listener on any interface. ... for people using the OS package, and not compiling from source. Upstream, until two days ago, the default was to listen on all interfaces. https://github.com/memcached/memcached/wiki/ReleaseNotes156 The package maintainers were (thankfully) injecting additional sanity. Royce
Re: Suggestions for a more privacy conscious email provider
On Sun, Dec 3, 2017 at 10:31 AM, Grant Taylor via NANOGwrote: > On 12/03/2017 10:08 AM, Filip Hruska wrote: > >> It's kind of a pain to manage a mail server. >> > > I disagree. > > I have been running my own mail server for > 15 years and extremely happy > with it. > > I spend less than an hour a month needing to do things to it. Usually > that's just the same type of OS updates that I do to my workstation. > > Having my own mail server gives me a LOT more flexibility than relying on > someone else's mail server. For those of us who have the savvy to do so competently, sure. For others, the key word may be "provider". Setting up a Linode server on static IP space (to avoid being blacklisted), setting up greylisting, antivirus/antispam (maybe?), STARTTLS, etc. ... Maybe the OP is interested in outsourcing all of that - letting someone else stay current with patching, spammer tactics, etc. Royce
Re: Please run windows update now
On Fri, May 12, 2017 at 10:30 AM, Royce Williams <ro...@techsolvency.com> wrote: > My $0.02, for people doing internal/private triage: > > - If your use of IPv4 space is sparse by routes, dump your internal > routing table and convert to summarized CIDR. > > - Feed your CIDRs to masscan [1] to scan for internal port 445 (masscan > randomizes targets, so destination office WAN links won't saturate, but > local/intermediate might if you're not careful, so tune): > > sudo masscan -p445 --rate=[packets-per-second safe for your network] > -iL routes.list -oG masscan-445.out > > - Use https://github.com/RiskSense-Ops/MS17-010/tree/master/scanners (the > python2 one, or the Metasploit one if you can use that internally) to > detect vuln. the python one is not* a parallelized script, so consider > breaking it into multiple parallel runners if you have a lot of scale. > Note - I've learned that the detection rate for the Python script above is *much* lower than this nmap script. I recommend using the nmap script instead: https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/smb-vuln-ms17-010.nse > - If you're using SCCM/other, verify that MS17-010 was applied - but be > mindful of Windows-based appliances not centrally patched, etc. Trust but > verify. > > - In parallel, consider investigating low-hanging fruit by OU > (workstations?) to disable SMBv1 entirely. > > Royce > > 1. https://github.com/robertdavidgraham/masscan > >
Re: Please run windows update now
My $0.02, for people doing internal/private triage: - If your use of IPv4 space is sparse by routes, dump your internal routing table and convert to summarized CIDR. - Feed your CIDRs to masscan [1] to scan for internal port 445 (masscan randomizes targets, so destination office WAN links won't saturate, but local/intermediate might if you're not careful, so tune): sudo masscan -p445 --rate=[packets-per-second safe for your network] -iL routes.list -oG masscan-445.out - Use https://github.com/RiskSense-Ops/MS17-010/tree/master/scanners (the python2 one, or the Metasploit one if you can use that internally) to detect vuln. the python one is not* a parallelized script, so consider breaking it into multiple parallel runners if you have a lot of scale. - If you're using SCCM/other, verify that MS17-010 was applied - but be mindful of Windows-based appliances not centrally patched, etc. Trust but verify. - In parallel, consider investigating low-hanging fruit by OU (workstations?) to disable SMBv1 entirely. Royce 1. https://github.com/robertdavidgraham/masscan On Fri, May 12, 2017 at 10:02 AM, Alexander Maassenwrote: > Hail backups, and whoever keeps those ports accessible to the outside > without a decent ACL in the firewall, or restricting it to (IPsec) VPN's > should be shot on sight anyways. > > On Fri, May 12, 2017 7:35 pm, Ca By wrote: > > This looks like a major worm that is going global > > > > Please run windows update as soon as possible and spread the word > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > system-ransoms-demanded > > > > >
Re: WWV Broadcast Outages
On Mon, Mar 6, 2017 at 5:12 AM, Andrew Gallowrote: > > On 3/6/2017 3:55 AM, Majdi S. Abbas wrote: >> >> On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote: >>> >>> Any suggestions for gear and/or software that works with WWV (or CHU)? >>> Or general suggestions for non GPS sources of time? >> >> Hey Hal! >> >> In North America, WWV and CHU are pretty much it for accessible >> backups these days. Unfortunately time and frequency distribution is a >> niche that tends to get neglected (if not actively gutted) in US >> budgets. > > Agreed, but I'll share this- the recent FCC CSRIC V had a working group (4B) > that studied the reliability of time and frequency distribution. > https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability > > It may be of interest. Specifically, the "Network Timing Single Source Risk Reduction - Final Report" part: https://transition.fcc.gov/bureaus/pshs/advisory/csric5/WG4B_FinalReport_122116.docx My summary of its points: * Analysis of vulnerabilities in the "supply chain" of GPS * Assertion that GPS mitigations and alternatives are needed to reduce risk * Some likely characteristics of good mitigations and alternatives * A list of potential alternatives, their features, and their current state (L2C & L5 GPS, Galileo & GLONASS, LEO satelltes, commercial RF, antenna pattern optimization, NMA on L2C, sync over fiber, eLORAN, other RF sync, terrestrial beacons, and hybrid DME) >From the executive summary: The U.S. communications sector relies heavily on the Global Positioning System (GPS) to provide network time. GPS is a widely available, extremely precise timing source that is used across multiple infrastructure sectors. However, given the high dependence of the communications sector on GPS, the Federal Communications Commission (Commission) is interested in identifying ways to increase the resilience of communications networks by exploring complementary or backup solutions that could be employed to offer similar time precision as GPS in the event that GPS signals are lost. These solutions also need to be completely independent of GPS to significantly reduce any risk. This report addresses the problems associated with relying on GPS solutions, the ideal technical characteristics for systems to backup or supplement GPS, and our recommendations for possible backup solutions by the communications industry and others reliant on communications network timing sources. Royce
Re: SHA1 collisions proven possisble
On Wed, Mar 1, 2017 at 7:57 PM, James DeVincentis via NANOGwrote: [ reasonable analysis snipped :) ] > With all of these reasons all wrapped up. It clearly shows the level of hype > around this attack is the result of sensationalist articles and clickbait > titles. I have trouble believing that Sleevi, Whalley et al spent years championing the uphill slog of purging the global web PKI infrastructure of SHA-1 to culminate in a flash-in-the-pan clickbait party. Instead, consider how long it has historically taken to pry known-to-be-weak hashes and crypto from entrenched implementations. If this round of hype actually scares CxOs and compliance bodies into doing The Right Thing in advance ... then the hype doesn't bother me in the slightest. Royce
Re: SHA1 collisions proven possisble
We just need to keep the likely timeline in mind. As I saw someone say on Twitter today ... "don't panic, just deprecate". Valeria Aurora's hash-lifecycle table is very informative (emphasis mine): http://valerieaurora.org/hash.html Reactions to stages in the life cycle of cryptographic hash functions StageExpert reactionProgrammer reactionNon-expert ("slashdotter") reaction Initial proposal Skepticism, don't recommend use in practice Wait to hear from the experts before adding to your crypto library SHA-what? Peer review Moderate effort to find holes and garner an easy publication Used by a particularly adventurous developers for specific purposes Name-drop the hash at cocktail parties to impress other geeks General acceptance Top-level researchers begin serious work on finding a weakness (and international fame) Even Microsoft is using the hash function now Flame anyone who suggests the function may be broken in our lifetime Minor weakness discovered Massive downloads of turgid pre-prints from arXiv, calls for new hash functions Start reviewing other hash functions for replacement Long semi-mathematical posts comparing the complexity of the attack to the number of protons in the universe Serious weakness discovered Tension-filled CRYPTO rump sessions! A full break is considered inevitable Migrate to new hash functions immediately, where necessary Point out that no actual collisions have been found First collision found *Uncork the champagne! Interest in the details of the construction, but no surprise* *Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them* *Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts* Meaningful collisions generated on home computer How adorable! I'm busy trying to break this new hash function, though Send each other colliding X.509 certificates as pranks Claim that you always knew it would be broken Collisions generated by hand Memorize as fun party trick for next faculty mixer Boggle Try to remember how to do long division by hand Assumed to be weak but no one bothers to break No one is getting a publication out of breaking this What's this crypto library function for? Update Pokemon Wikipedia pages Royce On Thu, Feb 23, 2017 at 2:11 PM, J. Hellenthalwrote: > It's actually pretty serious in Git and the banking markets where there is > high usage of sha1. Considering the wide adoption of Git, this is a pretty > serious issue that will only become worse ten-fold over the years. Visible > abuse will not be near as widely seen as the initial shattering but > escalate over much longer periods. > > Take it serious ? Why wouldn't you !? > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Feb 23, 2017, at 16:40, Ricky Beam wrote: > > > On Thu, 23 Feb 2017 15:03:34 -0500, Patrick W. Gilmore < > patr...@ianai.net> wrote: > > More seriously: The attack (or at least as much as we can glean from the > blog post) cannot find a collision (file with same hash) from an arbitrary > file. The attack creates two files which have the same hash, which is > scary, but not as bad as it could be. > > Exactly. This is just more sky-is-falling nonsense. Of course collisions > exist. They occur in every hash function. It's only marginally noteworthy > when someone finds a collision. It's neat the Google has found a way to > generate a pair of files with the same hash -- at colossal computational > cost! However this in no way invalidates SHA-1 or documents signed by > SHA-1. You still cannot take an existing document, modify it in a > meaningful way, and keep the same hash. > > [Nor can you generate a blob to match an arbitrary hash (which would be > death of all bittorrent)] >
Re: Akamai and Instagram Ranges
On Sat, Jan 28, 2017 at 2:22 AM, Shahab Vahabzadehwrote: > > Hello Hello, > Can anybody help me to find out IP Address Ranges of Akamai and Instagram? > I wanna do some optimizations on my cache side? > Thanks I do not know the difference between Akamai's corporate blocks and those used for caching. I also do not know the value of what you're trying to accomplish. But searching naively, there are at least 7291 Akamai IP blocks: http://bgp.he.net/search?search%5Bsearch%5D=AKAMAI-AS=Search Those 7291 blocks can be summarized on bit boundaries down to 172 blocks: https://gist.github.com/roycewilliams/31c3eeb030bdd5f557d845c344933c67 Using this approach is a good start, but it cannot be complete. Some caches are colocated with ISPs and use their IP space. Royce
Re: DNS CAA records...
On Tue, Jan 17, 2017 at 3:04 PM, Eric Tykwinskiwrote: > So I’ve come across this on Qualys and just wondering if there’s any > practical examples out there in the wild. > I know some BIND guys are on here, so I’m sure I’m missing something from the > RFCs. > Just wanted to test this out on my play domains before putting it out in the > wild... As of 2016-12-31, here are CAA records for 143 domains: https://gist.github.com/roycewilliams/a5b2d26edf3b64ecf77a75f943de079f That gist contains all CAA (or unparsed/raw type 257) records as seen in the Rapid7 "DNS ANY" dataset [1] from 2016-12-31. Interestingly, google.com as noted by Nolan side-thread isn't in this dataset. Since "DNS ANY" is a superset of all DNS picked up by other scans, it may be that Rapid7's scanning isn't incidentally catching many CAA records. An explicit scan for CAA records (against, say, in all domains seen in DNS ANY) would likely be interesting. Also, I've requested that cPanel add CAA support to the DNS management tools. If that would be of use to you, feel free to upvote the feature [2]. Some good CAA refs are [3],[4],and [5]. Royce 1. https://scans.io/study/sonar.fdns 2. https://features.cpanel.net/topic/add-support-for-caa-dns-records-type-257 3. https://tools.ietf.org/html/rfc6844 4. https://sslmate.com/labs/caa/ (includes info on which CAs support them; it's early) 5. https://blog.dnsimple.com/2017/01/introducing-caa-records/
Re: Recent NTP pool traffic increase
On Thu, Dec 22, 2016 at 4:05 PM, Harlan Stennwrote: > This sort of misconfiguration will happen and the NTP Pool Project > clearly isn't the place to solve this problem overall. It *is* > something NTF is in a position to address. Harlan, could you be more specific about how NTF can address this? Would it require modification of the NTP protocol, or something else? Royce
Re: Wanted: volunteers with bandwidth/storage to help save climate data
On Wed, Dec 21, 2016 at 8:03 PM, Jason Hellenthal <jhellent...@dataix.net> wrote: > Simply put… if the data that is hosted on the sites aforementioned then cough > up the damn space and host it. Data space is cheap as hell these days, parse > it and get the hell on with it already. > > *Disclaimer* > not meant to single out any one party in this conversation but the whole > subject all together. Need someone to help mirror the data ? I may or may not > be able to assist with that. Provide the space to upload it to and the > direction to the data you want. But beyond all that. This subject is plainly > just off topic. Jason, understood. I clearly should have updated the subject line of the thread, as you're not the first to continue to respond to the subject line, instead of what I've been recently saying. :) My most recent reply was about some operational aspects of country-wide Signal blocking, not the OP topic. I would almost consider updating the subject accordingly ... but at this point, it's clear that transcendence of the amygdala will continue to elude us, and this thread would apparently rather die than suffer my attempts to beat it into a plowshare. :) Royce >> On Dec 21, 2016, at 22:16, Royce Williams <ro...@techsolvency.com> wrote: >> >> On Tue, Dec 20, 2016 at 7:08 AM, Royce Williams <ro...@techsolvency.com> >> wrote: >> >> [snip] >> >>> IMO, *operational, politics-free* discussion of items like these would >>> also be on topic for NANOG: >>> >>> - Some *operational* workarounds for country-wide blocking of >>> Facebook, Whatsapp, and Twitter [1], or Signal [2] >> >> [snip] >> >>> 2. >>> http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html >> >> Steering things back towards the operational, the makers of Signal >> announced today [1] an update to Signal with a workaround for the >> blocking that I noted earlier. Support in iOS is still in beta. >> >> The technique (which was new to me) is called 'domain fronting' [2]. >> It works by distributing TLS-based components among domains for which >> blocking would cause wide-sweeping collateral damage if blocked (such >> as Google, Amazon S3, Akamai, etc.), making blocking less attractive. >> Since it's TLS, the Signal connections cannot be differentiated from >> other services in those domains. >> >> Signal's implementation of domain fronting is currently limited to >> countries where the blocking has been observed, but their post says >> that they're ramping up to make it available more broadly, and to >> automatically enable the feature when non-local phone numbers travel >> into areas subject to blocking. >> >> The cited domain-fronting paper [2] was co-authored by David Fifield, >> who has worked on nmap and Tor. >> >> Royce >> >> 1. https://whispersystems.org/blog/doodles-stickers-censorship/ >> 2. http://www.icir.org/vern/papers/meek-PETS-2015.pdf
Re: Wanted: volunteers with bandwidth/storage to help save climate data
On Tue, Dec 20, 2016 at 7:08 AM, Royce Williams <ro...@techsolvency.com> wrote: [snip] > IMO, *operational, politics-free* discussion of items like these would > also be on topic for NANOG: > > - Some *operational* workarounds for country-wide blocking of > Facebook, Whatsapp, and Twitter [1], or Signal [2] [snip] > 2. > http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html Steering things back towards the operational, the makers of Signal announced today [1] an update to Signal with a workaround for the blocking that I noted earlier. Support in iOS is still in beta. The technique (which was new to me) is called 'domain fronting' [2]. It works by distributing TLS-based components among domains for which blocking would cause wide-sweeping collateral damage if blocked (such as Google, Amazon S3, Akamai, etc.), making blocking less attractive. Since it's TLS, the Signal connections cannot be differentiated from other services in those domains. Signal's implementation of domain fronting is currently limited to countries where the blocking has been observed, but their post says that they're ramping up to make it available more broadly, and to automatically enable the feature when non-local phone numbers travel into areas subject to blocking. The cited domain-fronting paper [2] was co-authored by David Fifield, who has worked on nmap and Tor. Royce 1. https://whispersystems.org/blog/doodles-stickers-censorship/ 2. http://www.icir.org/vern/papers/meek-PETS-2015.pdf
Re: Wanted: volunteers with bandwidth/storage to help save climate data
On Wed, Dec 21, 2016 at 3:49 PM, Ken Chasewrote: > On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said: > [..] > >>Everyone has a line at which "I don't care what's in the pipes, I just > >>work here" changes into something more actionable. > > > >Stretched far beyond any credibility. Your argument boils down to, "If it's > >a political thing that *I* like, it's on topic." I can see why you've concluded that. My final phrasing was indeed ambiguous. I would have hoped that the rest of my carefully non-partisan post would have offset that ambiguity. > "If it's a politically-generated thing I'll have to deal with at an > operational level, it's on topic." > > That work? That is indeed what I was trying to say - thanks, Ken. Royce
Re: Recent NTP pool traffic increase
On Tue, Dec 20, 2016 at 8:19 PM, Royce Williams <ro...@techsolvency.com> wrote: > On Tue, Dec 20, 2016 at 8:04 PM, Yury Shefer <she...@gmail.com> wrote: >> >> Google announced public NTP service some time ago: >> https://developers.google.com/time/ > > Leap smearing does look interesting as way to sidestep the > potentially-jarring leap-second problem ... but a note of caution. > > I've had multiple time geeks tell me that leap-smearing is pretty > different from strict-RFC NTP, and Google themselves say on that page: > > "We recommend that you don’t configure Google Public NTP together with > non-leap-smearing NTP servers." > > So it looks like we shouldn't mix and match. And since most folks > should probably want some heterogeneity in their NTP, it may be a > little premature to jump on the leap-smear bandwagon just yet. > > I'm vague on the details, so I could be wrong. This is informative: https://docs.ntpsec.org/latest/leapsmear.html > Does anyone know of any other (non Google) leap-smearing NTP implementations? Royce
Re: Recent NTP pool traffic increase
On Tue, Dec 20, 2016 at 8:04 PM, Yury Sheferwrote: > > Google announced public NTP service some time ago: > https://developers.google.com/time/ Leap smearing does look interesting as way to sidestep the potentially-jarring leap-second problem ... but a note of caution. I've had multiple time geeks tell me that leap-smearing is pretty different from strict-RFC NTP, and Google themselves say on that page: "We recommend that you don’t configure Google Public NTP together with non-leap-smearing NTP servers." So it looks like we shouldn't mix and match. And since most folks should probably want some heterogeneity in their NTP, it may be a little premature to jump on the leap-smear bandwagon just yet. I'm vague on the details, so I could be wrong. Does anyone know of any other (non Google) leap-smearing NTP implementations? Royce
Re: Wanted: volunteers with bandwidth/storage to help save climate data
n Sat, Dec 17, 2016 at 6:15 PM, Doug Bartonwrote: > On 12/16/2016 1:48 PM, Hugo Slabbert wrote: >> >> This started as a technical appeal, but: >> >> https://www.nanog.org/list >> >> 1. Discussion will focus on Internet operational and technical issues as >> described in the charter of NANOG. > > Hard to see how the OP has anything to do with either of the above. Actually, it's not that hard ... *if* we can control ourselves from making them partisan, and focus instead on the operational aspects. (Admittedly, that's pretty hard!) The OP's query was a logical combination of two concepts: - First, from the charter (emphasis mine): "NANOG provides a forum where people from the network research community, the network operator community and the network vendor community can come together *to identify and solve the problems that arise in operating and growing the Internet*." - Second, from John Gilmore: "The Net interprets censorship as damage and routes around it." The OP appears to be managing risk associated with a (perhaps low) chance of future censorship. Was the OP asking a straight question about BGP or SFPs or CDNs? Of course not. But should doctors only talk about surgical technique -- and not about, say, the need for a living will? Of course not. IMO, *operational, politics-free* discussion of items like these would also be on topic for NANOG: - Some *operational* workarounds for country-wide blocking of Facebook, Whatsapp, and Twitter [1], or Signal [2] - The *operational* challenges of replicating the Internet Archive to Canada [3] Each operator has to make such risk calculations for themselves. Some may see the "NA" in NANOG as insurance that such censorship could never happen here. Others -- especially those who came from other countries -- may feel differently. Put another way: Everyone has a line at which "I don't care what's in the pipes, I just work here" changes into something more actionable. Being *operationally* ready for that day seems like a good idea to me. Royce 1. http://www.telegraph.co.uk/technology/2016/12/20/turkey-blocks-access-facebook-twitter-whatsapp-following-ambassadors/ 2. http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html 3. https://blog.archive.org/2016/11/29/help-us-keep-the-archive-free-accessible-and-private/
Re: Recent NTP pool traffic increase
On Mon, Dec 19, 2016 at 12:49 PM, Dan Drownwrote: > Quoting David : >> >> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>> >>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: I found devices doing lookups for all of these at the same time {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org and then it proceeds to use everything returned, which explains why everyone is seeing an increase. >>> >>> >>> Thanks, David. That perfectly matches the list of servers used by >>> older versions of the ios-ntp library[1][2], which would point toward >>> some iPhone app being the source of the traffic. >>> >>> [1] >>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>> [2] >>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>> >> >> That would make sense - I see a lot of iCloud related lookups from these >> hosts as well. >> >> Also, app.snapchat.com generally seems to follow just after the NTP pool >> DNS lookups. I don't have an iPhone to test that though. > > > Confirmed - starting up the iOS Snapchat app does a lookup to the domains > you listed, and then sends NTP to every unique IP. Around 35-60 different > IPs. > > Anyone have a contact at Snapchat? Looks like folks got in touch with them. Thanks! https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18 Royce
Re: Wanted: volunteers with bandwidth/storage to help save climate data
See also: https://twitter.com/textfiles/status/808715999042117632 https://twitter.com/textfiles/status/808922272551550976 Jason Scott@textfiles When your boss gives you the goahead to mirror 200tb of NOAA data, you run with it Don't let the fact that The Internet Archive is all over this deter you, though. Coordinate here: https://docs.google.com/spreadsheets/d/12-__RqTqQxuxHNOln3H5ciVztsDMJcZ2SVs1BrfqYCc/edit#gid=0 Royce On Fri, Dec 16, 2016 at 7:02 AM, DaKnObwrote: > If you’re interested, there’s also a Slack team: climatemirror.slack.com > > You can find more info about that here: > > - https://climate.daknob.net/ > - http://climatemirror.org/ > - http://www.ppehlab.org/datarefuge > > Thank you for your help! > > >> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >> >> This is a short-term (about one month) project being thrown together >> in a hurry...and it could use some help. I know that some of >> you have lots of resources to throw at this, so if you have an >> interest in preserving a lot of scientific research data, I've set >> up a mailing list to coordinate IT efforts to help out. Signup via >> climatedata-requ...@firemountain.net or, if you prefer Mailman's web >> interface, http://www.firemountain.net/mailman/listinfo/climatedata >> should work. >> >> Thanks, >> ---rsk >> >
Re: dilemmas
On Wed, Nov 2, 2016 at 6:47 PM, William Herrinwrote: > On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush wrote: > > the sysadmins' dilemma: do you install today's critical update or wait a > > day until the next one is out before you reboot 50 servers? > > Neither. You wait for the normal patch cycle because the other six > barriers to exploiting the vulnerability will work just fine until > then. > > The vulnerability that cuts through every layer of a well engineered > defense is rare. > As is the well-engineered defense. Royce
Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey
On Mon, Sep 26, 2016 at 7:23 AM, Mark Milhollanwrote: > > On Sun, 25 Sep 2016, Stephen Satchell wrote: > > >Yeah, right. I looked at BCP38.info, and there is very little concrete > >information. > > Yeah, it's pretty naked. But how-to isn't the usual stumbling block, as > has been pointed out in this thread there needs to be the will to spend > resources setting it up and thus committing future resources to > maintenance. Actually, a clear set of how-tos is the best way to quickly convey -- to busy geeks, and to their busy managers and PMs -- how much that resource spend would probably be. Royce
Re: Chinese root CA issues rogue/fake certificates
On Tue, Aug 30, 2016 at 9:11 PM, Royce Williams <ro...@techsolvency.com> wrote: > On Tue, Aug 30, 2016 at 8:38 PM, Eric Kuhnke <eric.kuh...@gmail.com> wrote: >> >> http://www.percya.com/2016/08/chinese-ca-wosign-faces-revocation.html >> >> One of the largest Chinese root certificate authority WoSign issued many >> fake certificates due to an vulnerability. WoSign's free certificate >> service allowed its users to get a certificate for the base domain if they >> were able to prove control of a subdomain. This means that if you can >> control a subdomain of a major website, say percy.github.io, you're able to >> obtain a certificate by WoSign for github.io, taking control over the >> entire domain. > > > And there is now strong circumstantial evidence that WoSign now owns - > or at least, directly controls - StartCom: > > https://www.letsphish.org/?part=about > > There are mixed signals of incompetence and deliberate action here. Hypothetically, it would be an interesting strategy for a CA to publicly demonstrate this level of competence: https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com ... while at the same time taking over another large install base like StartSSL's (an install base fueled by offering free certs). If one got caught doing something naughty, one could buy time by A) playing the incompetence card a few times, and B) having a large enough deployment that it becomes non-trivial for the browsers/OSes to revoke you outright. I'm oversimplifying, as I do not yet actually grok the WoSign <-> StartCom cert trust relationship - but the individual components are ... interesting. Also, this is a cautionary tale about certificate diversity. Because of relative issuer stability, orgs have had the luxury of depending wholly on a single cert supplier. The risk/continuity folks might want to model some "one of our major certificate issuers just got globally revoked" scenarios - if they haven't already. (Side note: compromises in the global trust ecosystem play a fascinating part in Vinge's 2007 Hugo-winning "Rainbows End" - a great read). Royce
Re: Chinese root CA issues rogue/fake certificates
On Tue, Aug 30, 2016 at 8:38 PM, Eric Kuhnkewrote: > > http://www.percya.com/2016/08/chinese-ca-wosign-faces-revocation.html > > One of the largest Chinese root certificate authority WoSign issued many > fake certificates due to an vulnerability. WoSign's free certificate > service allowed its users to get a certificate for the base domain if they > were able to prove control of a subdomain. This means that if you can > control a subdomain of a major website, say percy.github.io, you're able to > obtain a certificate by WoSign for github.io, taking control over the > entire domain. And there is now strong circumstantial evidence that WoSign now owns - or at least, directly controls - StartCom: https://www.letsphish.org/?part=about There are mixed signals of incompetence and deliberate action here. Royce
Re: Firewall list recommendations (config conversion options)
It might also be interesting to post some redacted/simplified examples of both formats. If the conversion is "just" text manipulation and reworking of logic, it might not be hard to cobble something basic together quickly, and then crowdsource improvements quickly on Github. Royce On Mon, Apr 25, 2016 at 12:31 AM,wrote: > Hi, > > > > Looking for options on converting a large amount of Fortinet rules to > > > Checkpoint. Ultimately converting the entire configuration to > Checkpoint > > > would be nice. > > theres a post online asking the same question back in early 2010 with no > responses... > > there are also a lost of tools that do Checkpoint TO Fortinet - says > something? ;-) > > > but actually, looking for firewall conversion tools does give you a picture > of typical/common moves :) > > > > alan >
Re: finding whois servers, was .pro whois registry down?
On Thu, Mar 10, 2016 at 6:57 AM, John R. Levinewrote: >>> >>> I've set up .ws.sp.am (that's ws for Whois Server) which is >>> updated every day from a variety of sources so it's pretty accurate. >>> It's had the right server for pro.ws.sp.am all along. > > >> Hey, that's fantastic! >> >> Feature request: could you provide a human- and machine-readable one-stop >> extract at the top-level page (ws.sp.am) ? > > > I can make a web page, but not sure what you mean by one-stop extract. If > you mean a proxy that will do the whois lookups, no, because it'd get abused > and I'd get rate limited. Definitely not a proxy request - I know exactly what that would mean. The goal would be to provide a unified list of the servers for each TLD, to help people who cannot change their whois client for administrative/political/inertia reasons, but have control over their whois.conf, a la: https://superuser.com/questions/758647/how-to-whois-new-tlds So in an ideal world: - a top-level landing page that would explain briefly what it's for, and - a link from that top-level page to the whole list, in regex-aware, whois.conf-compatible format Royce
Re: finding whois servers, was .pro whois registry down?
On Thu, Mar 10, 2016 at 4:32 AM, John Levinewrote: > > _whois._tcp.pro. srv 0 100 43 whois.afilias.net. > > A swell idea, but unfortunately the idea of putting SRV records in > gTLD zones makes heads at ICANN explode. For RDAP there's a registry > at IANA but it's not populated yet and it's not obvious that registries > will be any more diligent about updating it than they are for the WHOIS > entries in the TLD database. > > >If we want machines to follow referrals we have to provide them in > >appropriate forms. > > > I've set up .ws.sp.am (that's ws for Whois Server) which is > updated every day from a variety of sources so it's pretty accurate. > It's had the right server for pro.ws.sp.am all along. > Hey, that's fantastic! Feature request: could you provide a human- and machine-readable one-stop extract at the top-level page (ws.sp.am) ? Royce
Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?
On Wed, Mar 9, 2016 at 3:54 PM, Mark Andrewswrote: > > Additionally 'whois' is free form text. Whois doesn't include a > AI to workout what this free form text means so, no, there isn't a > actual referral for a whois application to use. I'm not affiliated, but there are a couple of companies that normalize whois data. It's a whackamole game, but it sucks less than trying to do it yourself. > Additionally we should be publishing where the whois server for the > tld is in the DNS. whois applications could be looking for this > then falling back to other methods. > > e.g. > > _whois._tcp.pro. srv 0 100 43 whois.afilias.net. > > If we want machines to follow referrals we have to provide them in > appropriate forms. That's a great idea. Royce
Re: remote serial console (IP to Serial)
On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbertwrote: > On Tue 2016-Mar-08 19:10:14 +, Gavin Henry > wrote: > > Really love the Opengear IM range. We use IM4216's >> > > I'm surprised no one's mentioned freetserv[1] yet. I haven't used them so > don't consider this an endorsement, but on the surface it looks to be a > good balance of "open / DIY" and "supportable". > > [1] https://freetserv.github.io/ > This is great! A mainstream, patchable OS -- not locked into a half-baked OS or roll-your-own-TCP-stack hell I've seen in some remote serial and power devices. Thanks! Royce
Re: Congrats to SMB!
On Thu, Feb 18, 2016 at 5:40 AM, Jay R. Ashworthwrote: > Let me be, apparently, the first to extend congratulations to long time > NANOGer, Columbia CS professor, security researcher, and co-inventor of > Usenet -- does anybody remember Usenet? :-) -- Steven M. Bellovin, who, > it was announced yesterday, has become the first actual, y'know, technical > person appointed to the Privacy and Civil Liberties Oversight Board, the > White House organization formed over a decade ago to oversee the NSA in > light of its bulk data collection activities WRT US citizens. Hear, hear! [snip] > Steve's latest book is the second edition of _Firewalls And Internet Security: > Repelling the Wily Hacker_; more info including links to buy are here: > > http://www.wilyhacker.com/ > > For poor but smart people, note that there's a link there to the full text of > the > first edition; while much of it has been overrun by events, there's still a > lot of > good material there. Minor correction: Steve's latest book is _Thinking Security_ (Nov 2015). Pretty great so far. Royce
Re: Team Cymru BGP bogon status ???
No direct knowledge, but from comments on another list, it may be intermittent. Jason Fesler of test-ipv6.com reported on Jan 30 2016 at 2:08 PM PST that his Team Cymru API connections for ISP ASN and Name checks broke, and pushed a workaround to all test nodes. He then reported at 7:30 PM PST that they were back up. Royce On Sun, Jan 31, 2016 at 7:44 AM, Matthew Huffwrote: > Starting around 7:17 am EST, we lost our IPv4 & IPv6 BGP connections to > Cymru. We have two connections in both IPv4 and IPv6 on both of our two > routers. On each router one connection is stuck in active, the other > providing 0 prefixes. I can’t get to http://www.team-cymru.org from either > work or home. Anyone know what’s up?
Re: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
On Fri, Dec 18, 2015 at 8:03 AM, Steven M. Bellovinwrote: > On 18 Dec 2015, at 11:52, Steven M. Bellovin wrote: > >> On 18 Dec 2015, at 7:28, Dave Taht wrote: >> >>> I think "unauthorized code" is still plausible newspeak for "bug". >>> >>> Why blame finger foo when you can blame terrorists? >> >> It looks like two different holes, one a back door for unauthorized >> console login and one to somehow leak VPN encryption keys. There are >> hints that that latter involved tinkering with certain constants in >> the crypto (https://twitter.com/matthew_d_green/status/677871004354371584); >> that would squarely point the finger at some government's intelligence >> agency. >> >> I don't know who did it, but neither 'bug' nor 'developer debugging >> code' sounds plausible here. > > https://twitter.com/sweis/status/677896363070259200 That tweet got deleted, apparently to redraft/correct; is this the equivalent? https://twitter.com/sweis/status/677897914643976193 https://gist.github.com/hdm/107614ea292e856faa81#file-ssg500-6-3-0r12-0-diff-L16 Royce
Re: IEEE OUI regauth (search ?) site
On Wed, Dec 9, 2015 at 6:32 AM, Brandon Applegatewrote: > They’ve made some changes recently - I had a perl script that would do the > lookup and scrape live - it was great. It broke a week or so ago. > > This seems to be the page to search for OUI: > > https://regauth.standards.ieee.org/standards-ra-web/pub/view.html < > https://regauth.standards.ieee.org/standards-ra-web/pub/view.html> > > I’ve tried 4 Browsers across 2 OS’s - and that page pops up a “Loading” > sub window - flashes and reloads (loop). > > Anyone have any insight on how one can look up an OUI (yes I know about > oui.txt, but I’m asking about a live query site). > > Thanks in advance. > I know that you've asked about using it live, but IMO, you should reconsider. Given the latency between the creation of a new OUI and it showing up in a given environment, live scraping is significant overkill. Platforms like Forescout pull it about once a quarter, IIRC. Pulling the text file is also probably significantly more reliable than any given web interface, as you've already discovered. And if you cache the whole text file locally, there's no way that anyone external to your organization -- even IEEE -- can tell which OUIs you are looking up. Royce
Re: DNSSEC and ISPs faking DNS responses
On Sat, Nov 14, 2015 at 3:34 AM, Roland Dobbinswrote: >> >> More likely this is going to be iterations of what is already being more widely accepted. Downloadable pre-configured client software that works with a particular VPN service. > > > Again, downloading is a barrier to entry. Don't you remember the browser wars and the Microsoft anti-trust case? That was before the rise of the app. Downloading is now much more common than during the age of the browser wars. As of October 2014, 64% of American adults owned a smartphone [1]. Phones don't usually come with Candy Crush, but somehow, 93 *million* people played it daily at one point. They many not understand that when they installed the app, they were "downloading" it. But the end result is the same. Downloading is now a way of life -- and there are easily downloaded VPN apps. You don't have to know what a VPN is in order to use one. Anecdote != data, but during the 2014 Olympics, Googling for "how to watch the Olympics on the Internet" led many people I know to install one, without asking me for advice like they usually do. :) It sounds like we're arguing about the definition of the word "most". Your thesis appears to be that most people won't use a VPN -- and you're probably right. But what everyone else is saying is that the value of "most" is likely to shrink rapidly. And it may only take a secondary use case to reach critical mass. People I know who use WhatsApp seem to have started using it to avoid per-text charges, not to get end-to-end encrypted messaging. But now, even if Facebook's estimate [2] of 450 million WhatsApp users is 90% inflated, there are 45 million people using encrypted texting, which I would not have predicted. Most of those users probably don't know what "encryption" is. But they're using it. Royce 1. http://www.pewinternet.org/fact-sheets/mobile-technology-fact-sheet/ 2. http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/
Re: DNSSEC and ISPs faking DNS responses
On Fri, Nov 13, 2015 at 8:28 PM, Roland Dobbinswrote: > On 14 Nov 2015, at 11:32, Owen DeLong wrote: > > Go out onto the street and ask a random number of people over 30 if they >> know what a URL is and how to enter one into a browser. >> > > They don't know what URIs are, nor do they enter them into browsers. They > type words into a search engine and then click on the resulting links. > The don't know what a VPN is ... but when they can't watch the Olympics on the Internet from their own country, a buddy tells them about an "app" that "makes you look like you're coming from a different country." Now they can watch the Olympics. I saw this "one weird trick" spread like wildfire through my non-technical acquaintances. They don't have to know what a VPN is in order to to use it -- and to pass it on to their friends. Royce
Re: The spam is real
On Mon, Oct 26, 2015 at 9:10 AM, Pablo Lucenawrote: > On Sun, Oct 25, 2015 at 12:22 AM, Josh Luthman < > j...@imaginenetworksllc.com> > wrote: > > > Can we please get a filter for messages with the subject "Fw: new > message" > > ??? > > > So far I've dealt with it via Gmail's 'mute conversation' setting somewhat > effectively. > Unfortunately, the 'mute conversation' feature only works for threads that are in the inbox. I filter all lists into their own subfolders, reserving the inbox for real people. So the 'mute conversation' feature is useless for most conversations that I actually want to mute. Royce
Re: /27 the new /24
On Mon, Oct 12, 2015 at 7:23 AM, Todd Underwoodwrote: > > it's also not entirely obvious what the point of having local IXes > that serve these kinds of collections of people. > > how much inter-ASN traffic is there generally for a city of 100k > people, even if they all have 1Gb/s connections? are they all > torrenting, accessing local business web pages that are hosted > locally, streaming video from local streaming caches? if a local IX > is a good place for a llnw, akamai, ggc, netflix cache node, i can see > it, but that's about it. They are microcosms of larger areas - think gamers, B2B, local support/RDP, etc. When there's ~25ms extra latency ANC<->SEA, every little bit helps. It also lets us function locally when there are major external outages. Finally, there's a psychological benefit. It drove me nuts to have my traffic shipped to Seattle to end up literally one block away. :) It's like when I tracked my Macbook from China -- stopping briefly in its palletized/containerized form in Anchorage on its way to Kentucky (UPS distribution), and then back to Anchorage ... days later. :) Royce
Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115
On Tue, Sep 29, 2015 at 7:12 AM, Job Snijderswrote: > > Hi Bob, > > On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: > > This seems like a very good proper civil approach - maybe this or > > something like it ARIN might help promote and endorse as a benefit to > > the community ? Be nice if with the cash they did something simple > > like this and got all of us to use it? Special line forwarding ? A > > Emergency Only NOC App for our phones for just this kind of situation > > - one that registers a specific ASN and pin code we set on the > > registration page ? > > In this day and age people use IRC or Facebook to quickly get to a > friend of a friend of a friend to get to a good contact. Get on with the > times :-) This seems lossy and unscriptable to me. There are maxint different flavors of $social, so it's not suitable for escalation, IMO. Also, many people opt out of half of them when they're not on the clock. And, many of them have "I don't know you so I'll bury your message" options, which makes being tickled by a stranger for emergency purposes hard. And their "APIs", so to speak, are constantly shifting. But we already have a reliable, widespread, high-SNR channel: this list. It's the place that people go when they can't get an answer any other way. Email works when many other things are broken. What if all NOCs used their NOC email distro/alias to subscribe, filter for posts containing their own ASes/admin-domains/prefixes, plus the string "problem|issue|etc", and flag them as higher priority. A junior NOCling could check it manually every couple of hours, and maybe a public web archive of the list, in case of filter failures. I would expect most NOCs worth their salt to be monitoring nanog anyway. Why not leverage it? A sibling list could be spun off -- nanog-panic-button? ;) -- if that would be preferable. Royce
Re: Ear protection
On Wed, Sep 23, 2015 at 1:34 AM, Nick Hilliardwrote: > What are people using for ear protection for datacenters these days? For me, it depends on the use case. If I need to monitor for other sounds, or listen to music: Bose QuietComfort 15 - discontinued, but still at Costco.com for $240. Their closest current model is the 25: http://www.amazon.com/dp/B00M1NEUKK, $300). On one AAA battery (I use rechargeables), they last ~30 hours of continuous active use. The sound cancelling is excellent, and voice ranges come through well. The ear cups are almost unnoticeable - I can wear them for 8 hours, with glasses on, without discomfort. They come with a semi-rigid carrying case, and detachable cords with controls for either Samsung or iPhone. Always in my daily-carry bag. If I need pure focus, but will need to take them on and off a lot: The discontinued Howard Leight Thunder 29. (The current Howard Leight equivalent appears to be the Thunder T3, NRR30.) Full muff with headband, passive, 29dB, no frills. New old stock is still available. I have three - one at home, one at the data center, and one at the office. If you enjoy having your Cow Orkers tease you about the 747 you're about to guide in, these are great. :) The ear cups are a little more rigid -- wearing for 8 hours with glasses is noticeable, but tolerable. For reusable portability: The Etymotics mentioned elsewhere in the thread. http://www.amazon.com//dp/B0044DEESS. Long-term durable; I've had them for years, but only use them on the go. If you're actively having to talk to people in the data center, these are great, but if you're going to work alone, I recommend more NRR just to keep the average down over time. Also good for mowing the lawn, so you can hear if someone is yelling at you. I don't have any SilentEar (silentear.com, NRR32), but they look promising, and I'll be trying them. Disposable / backup / utility plugs: Flents "Quiet Please" - rolling foam, NRR29. Good for handing out to friends at concerts, and good for hotel sleeping -- good NRR, and no irritating external components. They come in packs of 25 pairs. And according to my wife, they take the edge off of my snoring. :) I'm not affiliated, but I've had good luck with earplugstore.com over the years. Their site is informative, and very NRR-aware - they list NRR in product title, and let you sort search results by NRR. Royce
Re: Synful Knock questions...
HD Moore just posted the results of a full-Internet ZMap scan. I didn't realize that it was remotely detectable. 79 hosts total in 19 countries. https://zmap.io/synful/ Royce
Re: merry xmas
On Wed, Dec 24, 2014 at 9:27 AM, Ken Chase m...@sizone.org wrote: (mtr|lft|traceroute) xmas.futile.net And be sure to crank up the max hops a little higher than 100. Royce
Re: merry xmas
On Wed, Dec 24, 2014 at 9:38 AM, Jeroen Massar jer...@massar.ch wrote: On 2014-12-24 19:27, Ken Chase wrote: (mtr|lft|traceroute) xmas.futile.net Welcome to the end of 2014. If you are going to do a silly traceroute thing that has been done thousands of times before, at least use this new fangled thing called: IPv6 Here is the Wikipedia page for you to get started on it: http://en.wikipedia.org/wiki/IPv6 Thank you for wasting IPv4 space btw, that way IPv6 has to be there earlier, and as you don't have IPv6 yet, good luck with your business ;) Maybe it's conspicuous consumption. http://en.wikipedia.org/wiki/Handicap_principle Royce
Re: Bounce action notifications - NANOG mailing list changes yahoo.com users
On Fri, Oct 10, 2014 at 7:31 AM, Steve Atkins st...@blighty.com wrote: If your domain publishes p=reject it should not have any users that participate in mailing lists. Like many, I was pretty unhappy (and busy) with the unilateral changes made by Yahoo and AOL. But this understandable stance may change. Neither of these domains is known for being heavily saturated with geeks. If Gmail started using p=reject, that might shake the tree a little more. But other than providing more warning, what would have been a better way to start eliminating forged senders? Everything I've read indicates that both Yahoo and AOL did this with eyes wide open. Assuming that eliminating forged senders is the end goal, maybe forcing the issue was the only way to move forward? What other theory about their motivation makes sense? Royce
Re: Bounce action notifications - NANOG mailing list changes yahoo.com users
On Thu, Oct 9, 2014 at 2:20 PM, Andrew Koch a...@gawul.net wrote: To correct this moving forward, selective rewriting of the from header has been recommended, but requires an upgrade to the Mailman software. If the admins have settled on a best practice, it could help other Mailman operators like myself. Two questions spring to mind: 1. With the planned method, how will reply behavior be affected? 2. Will this be an upgrade to 2.1.16, or a pre-release version of 2.1.18, or something else? From http://wiki.list.org/display/DEV/DMARC : In 2.1 16 a from_is_list feature was implemented which if enabled by a site configuration option would offer a list admin the ability to either: * Rewrite (Munge) the From: header with the posters name 'via the list' and the list's address and merge the poster's address into Reply-To: or * Wrap the message as a message/rfc822 sub-part in a MIME format outer message with From: and Reply-To: as above. Implemented now for release in 2.1.18 are the following: * The from_is_list feature from 2.1.16 is always available. * There are new settings in Privacy options - Sender filters: ** dmarc_moderaction_action is a five valued setting with values *** Accept - accept the post without rewriting From: or wrapping the message *** Munge From - rewrite the From: and Reply-To: as in from_is_list *** Wrap Message - wrap the message as in from_is_list *** Reject - reject the post *** Discard - Discard the post ** dmarc_moderaction_notice is a custom reject message to replace the default Reject message. * The above options other than Accept override the from_is_list setting for messages whose original From: domain publishes a DMARC policy of p=reject or p=quarantine. A per-list option is available to limit this to just p=reject or to apply it to either p=reject or p=quarantine. If the option is Accept, the from_is_list setting applies. * There is a site option to set the default for dmarc_moderaction_action and list admins may not set the action to a setting which is above the site default in the above list. E.g., if the site default is Reject, list admins can only set Reject or Discard; if the site default is Munge From, list admins can select anything but Accept. Royce
Re: IPv6 Default Allocation - What size allocation are you giving out
On Wed, Oct 8, 2014 at 8:07 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: Like I said, this was my understanding I am glad that it is being pointed out to be in-correct I don't have a reason for why a /64 as much as I also don't have any reason Why NOT So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). Quoting RFC6177 (successor to RFC3177): While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either. A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the total projected address consumption by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.) The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56. Royce
Re: GMail contact - misroute / security issue
On Sun, Sep 28, 2014 at 7:42 PM, Grant Taylor gtay...@tnetconsulting.net wrote: My wife is receiving someone else's emails. Specifically she is receiving emails for first namemiddle initiallast name@gmail.com (no dots) when her email address is really same first name.same middle initial.same last name@gmail.com (dots). If someone else thinks that the non-dotted email address is theirs, they are mistaken. This is a Gmail feature. Adding or removing dots makes no difference, other than changing readability. All versions of the email address are your wife's. Royce
Re: no more Send through Gmail option
On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Suárez esua...@fcaglp.fcaglp.unlp.edu.ar wrote: Hi, according to this thread: https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D Gmail isn't allowing anymore Send through Gmail option. Yep. Existing email-address setups are grandfathered, but no new ones can be added via the UI. It's probably a mix of let's support the ecosystem by only sending mail from servers authorized by the domain holder and let's sell more Google for Work email hosting. If it really was more the former, there would be a if your SPF records include:_spf.google.com, you can still do it option, IMO. Royce
Re: no more Send through Gmail option
On Fri, Sep 5, 2014 at 3:01 PM, Hugo Slabbert h...@slabnet.com wrote: If it really was more the former, there would be a if your SPF records include:_spf.google.com, you can still do it option, IMO. Manager: So, you're saying if we just check the SPF record when they set up the account, we could still let them do it. Tech: Yes, except if they also use DKIM; then it's a no-go. Manager: Okay, so if their SPF record includes Google's and they don't have DKIM, then we'd be okay? Tech: Yes...but if they don't have an SPF record when they set up the account and then add one later, we'd still be in trouble. Manager: ... Tech: I guess we could do periodic checks for SPF records on their domains and either disable sending or send them an alert if an SPF record is created that could problems? Manager: ...okay...and then it'd be okay? Tech: Well, if they don't have DKIM to start and then add it, that would also be a problem. Manager: ... Tech: ...but in addition to doing checks for new/altered SPF records, we could also do checks if they add DKIM after adding the account. Manager: ... Tech: ...or we could just turn it off. Manager: Works for me. The scenario largely rings true, except that I would think it reasonable to tell people that it if it breaks because they added DKIM, it's not Google's problem to fix. But your larger point is valid. Requiring Google for Work automatically means that Google is dealing with geeks who manage the entire domain, instead of chasing failure modes for individual end users. That being said, domain holders could signal that they're deliberately opting in domain-wide by using a different SPF include, like '_spf-fwd.google.com', and agreeing (with a checkbox?) that chasing DKIM is their baby. Royce
Re: NAT IP and Google
On Thu, May 22, 2014 at 7:26 AM, Derek Andrew derek.and...@usask.ca wrote: As others have said, Google's abuse systems are smart enough to understand NAT and proxies, and won't block on request volume alone. When we automatically apply a block, we'll generally offer a captcha to give innocent users a workaround and limit the annoyance until the abuse stops and the block can expire This failed at our site. Our entire IPv4 and IPv6 addresse blocks received captcha after captcha after captcha, forever and ever. There was a link on the page to get more information, but all that got was another captcha. Normally I am 100% behind Google in everything, but sadly, this has now fallen to 99.8%. I've triggered Google's CAPTCHA multiple times at home, just from rapidly adding and removing search terms, in a couple of different tabs, after driving down a hundred results or so. It's been a few months, but this used to happen to me pretty regularly if I had drive deep to find something. Royce
Re: AOL Mail updates DMARC policy to 'reject'
On Fri, Apr 25, 2014 at 7:43 AM, Shrdlu shr...@deaddrop.org wrote: On 4/25/2014 8:00 AM, Leo Bicknell wrote: On Apr 23, 2014, at 12:45 AM, Grant Riddershortdudey...@gmail.com wrote: Thought i would throw this out there. Curious I unleashed grep on a couple of mailing lists I operate. I turned up one AOL address. I'm not saying my data is representative of the Internet, but I remember a time when they were 50% of the addresses on my mailing lists. I doubt the largest list I manage is representative of anything beyond an insane asylum, but out of 900-950, there are SIX of those laying around. Those are all addresses receiving email (I looked at the logs, just to verify). You just never know. Keep in mind that mailing list membership is heavily dependent on demographics of their common interest. Many mailing lists that folks on this list run themselves are likely to be technical in nature, and therefore less likely to have @aol.com address. On the other hand, I belong to a club for people who collect license plates. They tend to be older. 11% (320 of them) are active AOL users. Royce
Yahoo DMARC breakage
Am I interpreting this correctly -- that Yahoo's implementation of DMARC is broken, such that anyone using a Yahoo address to participate in a mailing list is dead in the water? http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html http://www.theregister.co.uk/2014/04/08/yahoo_breaks_every_mailing_list_in_the_world_says_email_guru/ My mailman bounce action notifications are going through the roof. Royce
Re: Filter on IXP
On Sun, Mar 2, 2014 at 4:00 AM, Nick Hilliard n...@foobar.org wrote: There are many places where automated RPF makes a lot of sense. An IXP is not one of them. That make sense. Everyone is rightly resistant to automated filtering. But could we automate getting the word out instead? Can obvious BCP38 cluelessness be measured? Maybe as a ratio of advertised to unadvertised egressing ASes, etc. ? If so, then if your downstream/peer is even *partially* BCP38, give them a pass. They are at least somewhat aware of the problem. Otherwise: - Visually red-flag their BCP38 stats/percentage in RADb; - Send them an automatic email once a week; - Let upstreams *optionally* not automatically update their routes via RADb until they call to ask why; etc. Can we combat the awareness problem in bulk -- without *filtering* in bulk? Royce
Re: Filter NTP traffic by packet size?
Newb question ... other than retrofitting, what stands in the way of making BCP38 a condition of peering? Royce
Re: Filter NTP traffic by packet size?
On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams ro...@techsolvency.com wrote: Newb question ... other than retrofitting, what stands in the way of making BCP38 a condition of peering? In other words ... if it's a problem of awareness, could upstreams automate warning their downstreams? What about teaching RADb to periodically test for BCP38 compliance, send soft warnings (with links to relevant pages on www.bcp38.info), and publish stats? Continuing my naïveté ...what if upstreams required BCP38 compliance before updating BGP filters? This would require a soft rollout -- we'd have to give them a few months' warning to not interfere with revenue streams -- but it sounds like nothing's going to change until it starts hitting the pocketbooks. Royce
Re: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?)
Miles, I'm seeing it here too -- same conditions (small email list), same symptom. But interestingly, I'm not getting that message back from Yahoo's MXes; just a very high volume of of 'closed connection in response to end of data' and the usual occasional minor smattering of 'temporarily deferred due to user complaints'. Royce Williams On Sat, Jan 4, 2014 at 6:05 AM, Miles Fidelman mfidel...@meetinghouse.netwrote: Hi Folks, I run a few small email lists that have some yahoo users on them - and I just started getting complaints about receiving multiple copies of messages. In looking into it, I've found 1000s of log entries along the following lines, all from the past 5 days or so: Jan 4 09:23:51 server1 postfix/smtp[1462]: 3BA39CC094: lost connection with mta7.am0.yahoodns.net[98.136.216.26] while sending end of data -- message may be sent more than once It's not one of their standard anti-spam errors, and mail is arriving (multiple copies no less) - so it doesn't look like this is intentional blocking. So... I'm wondering if anybody else is seeing this, and if anybody has a postmaster contact at yahoo (postmas...@yahoo.com, of course, auto-replies with a pointer to a useless web form). Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: The US government has betrayed the Internet. We need to take it back
On Fri, Sep 6, 2013 at 6:27 AM, Naslund, Steve snasl...@medline.com wrote: [snip] 1. We vote in a new executive branch every four years. They control and appoint the NSA director. Vote them out if you don't like how they run things. Do you think a President wants to maintain power? Of course they do and they will change a policy that will get them tossed out (if enough people actually care). 2. The Congress passes the laws that govern telecom and intelligence gathering. They also have the power to impeach and/or prosecute the executive branch for misdeeds. They will pass any law or do whatever it takes to keep themselves in power. Again this requires a lot of public pressure. Historically speaking, I'm not convinced that a pure political solution will ever work, other than on the surface. The need for surveillance transcends both administrations and political parties. Once the newly elected are presented with the intel available at that level, even their approach to handling the flow of information and their social interaction have to change in order to function. Daniel Ellsberg's attempt to explain this to Kissinger is insightful. It's a pretty quick read, with many layers of important observations. (It's Mother Jones, but this content is apolitical): http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge I think that Schneier's got it right. The solution has to be both technical and political, and must optimize for two functions: catch the bad guys, while protecting the rights of the good guys. When the time comes for the political choices to be made, the good technical choices must be the only ones available. Security engineering must pave the way to the high road -- so that it's the only road to get there. Royce
Re: The US government has betrayed the Internet. We need to take it back
On Fri, Sep 6, 2013 at 6:55 AM, Royce Williams ro...@techsolvency.com wrote: Daniel Ellsberg's attempt to explain this to Kissinger is insightful. It's a pretty quick read, with many layers of important observations. (It's Mother Jones, but this content is apolitical): http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsberg-limitations-knowledge Er ... I forgot to include the part of the Ellsberg quote that was most relevant to the discussion, with the last sentence here being the icing on the cake: You will deal with a person who doesn't have those clearances only from the point of view of what you want him to believe and what impression you want him to go away with, since you'll have to lie carefully to him about what you know. In effect, you will have to manipulate him. You'll give up trying to assess what he has to say. The danger is, you'll become something like a moron. You'll become incapable of learning from most people in the world, no matter how much experience they may have in their particular areas that may be much greater than yours. In other words: the very politicians with the clearances necessary to strike the best balance are the ones that we cannot expect to hear us, even in our areas of expertise. Security engineering must take this fact as a constraint. Royce
Re: The US government has betrayed the Internet. We need to take it back
On Fri, Sep 6, 2013 at 8:02 AM, Naslund, Steve snasl...@medline.com wrote: I am unclear on what you mean by technical choice. Are you talking about a technical solution to keep the government from seeing your traffic? That will not work for two main reasons. [good reasons snipped] Ah, I should have been more clear. I'm definitely not proposing that the private sector could succeed in such an arms race, for exactly the two reasons that you accurately laid out: the government has vastly greater resources, and they have the law. (And I would add a third: they have a valid mission to accomplish). I intended the technical choice idea to be more broad. I'm no crypto guy, but of the work happening in this space, it seems that there are a lot of people working on the problem of how do we keep everyone else out?, and a lot of other people are working on how do we get in? And recently, a lot more folks are working on how can we quickly tell that they got in? But it doesn't seem to me that very many people are working (at a technical level) on the hard problem of how do we simultaneously enable lawful intercept, and verifiably preserve privacy? There seems to be an intractable conflict between freedom and surveillance. But if we set aside that assumption, we might discover technical approaches to support both. The politics might change if the politicians didn't have to choose one or the other. Pipe dream? Certainly. But escaping assumptions is where breakthroughs are made. Royce
Re: Yahoo is now recycling handles
On Thu, Sep 5, 2013 at 9:28 AM, Kee Hinckley naz...@marrowbones.com wrote: On Sep 4, 2013, at 9:47 PM, Leo Bicknell bickn...@ufp.org wrote: I've got to apologize publicly to Yahoo! here as part of my issue was my own stupidity. It appears in the past I've had multiple Yahoo! ID's and I was I, on the other hand, need someone from Yahoo! to contact me, because I decided to test their email wishlist feature. Repeated attempts got me nothing but a message saying that my credit card information was incorrect. But when I checked my bill this morning, I have three fifty cent charges against my account (one for each time I revalidated my email address while attempting to use their form). There's no contact page on http://wishlist.yahoo.com, despite the fact that it's an ecommerce page that takes credit cards, and there's no apparent way to contact a human from the main yahoo page. I can always ask my credit card company to refuse the charges, but if Yahoo! is charging credit cards and not providing services, I think someone there needs to know there's a problem. Never mind taking credit card numbers and providing no customer support. And it's not an isolated incident -- the exact same thing happened to me last night as well. Royce