Re: Log4j mitigation
Hi all, I guess what Jorg is suggesting is that beyond this particular incident, a preventive testing/mitigation methodology would make for a great NANOG2022 presentation/workshop. Cheers, Dora On Mon, Dec 13, 2021 at 2:33 PM Jean St-Laurent via NANOG wrote: > I agree, > > As an example that back what you're saying, I pasted the ip provided by > Jörg in my browser. > > http://45.83.64.1/ > > Here is the html page returned. > > > ... > Research Scanning Project > > This is a scanner of a research scanning project. > > If you want to exclude your IPs from scans, please send an e-mail to > excl...@alphastrike.io. > > Thank you for your appreciation! > ... > > > This ip scanner is in Germany and it looks legit, but a better > investigation is recommended. > > The second host provided looks more suspicious. > > blah.c6rip779l9hq8g7hluigcg5131oyyyt8e.interactsh.com resolve to > 104.248.51.21 which is hosted on DigitalOcean. > > Here is the html output: > > > ... > Interactsh Server > Interactsh is an open-source solution for out-of-band data extraction. It > is a tool designed to detect bugs that cause external interactions. These > bugs include, Blind SQLi, Blind CMDi, SSRF, etc. > > If you find communications or exchanges with the interactsh.com server in > your logs, it is possible that someone has been testing your applications. > > You should review the time when these interactions were initiated to > identify the person responsible for this testing. > > ... > > > First, it's important to gain visibility and filter the goods from the > bads. > > The first ip looks legit. The second could be reported to DigitalOcean for > investigation. They usually investigate very fast. > > You can check for weird network flows patterns. You can also look for that > suspicious html file that is crawling on http in clear text on your gears. > > At ISP level, visibility is a must and patterns will clearly become easy > to identify. > > I agree with Karl that perfection is enemy of good. > > Jean > > -Original Message- > From: NANOG On Behalf Of Karl > Auer > Sent: December 13, 2021 7:55 AM > To: NANOG List > Subject: Re: Log4j mitigation > > On Mon, 2021-12-13 at 06:35 -0600, Joe Greco wrote: > > Just because there are other sources of fatalities, doesn't mean you > > can't check for the quick obvious stuff. > > Indeed. > > One check, even an inadequate one, is better than no checks at all. And > over time you can add more checks or improve the ones you have. > > Don't let "perfect" be the enemy of "good". > > Regards, K. > > > -- > ~~~ > Karl Auer (ka...@biplane.com.au) > http://www.biplane.com.au/kauer > > GPG fingerprint: 61A0 99A9 8823 3A75 871E 5D90 BADB B237 260C 9C58 Old > fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 > > > > >
Re: Need for historical prefix blacklist (`rogue' prefixes) information
Hi Matthew, Quantum computing exists as POCs, IBM being one of those advertising them and announced to extend their project. There are others on the market, Amazon advertised quantum computing as a service back in 2019: https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-computing-as-a-service. The bottle neck of the current technology is scalability: we will not see QC as personal computing level just yet (to go in more detail, current technologies work at cryogenic temperatures, thus they are hyper expensive and not really scalable), but they exist and one could be imagine they are/will be used for various tasks. On the other hand, you've actually commented every word of my mail, minus the stated question. Thanks. Best Regards, Dora Crisan On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster wrote: > > > On Fri, 29 Oct 2021, 15:55 A Crisan, wrote: > >> Hi Matthew, >> I was reading the above exchange, and I do have a question linked to your >> last affirmation. To give you some context, the last 2021 ENISA report seem >> to suggest that internet traffic is "casually registered" by X actors to >> apply post Retrospective decryption (excerpt below). This would be at odds >> with your (deescalating) affirmation that hijacks are non-malicious and >> they are de-peered quickly, unless you pinpoint complete flux arrest only. >> Are there any reportings/indicators... that look into internet flux >> constant monitoring capabilities/capacities? Thanks. >> > > RPKI uses authentication not confidentiality. There is no encryption > taking place, other than the signatures on the certificates etc. > > Excerpt from the introduction: "What makes matters worse is that any >> cipher text intercepted by an attacker today can be decrypted by the >> attacker as soon as he has access to a large quantum computer >> (Retrospective decryption). >> > > Which do not exist (yet). > > Analysis of Advanced Persistent Threats (APT) and Nation State >> capabilities, >> > > Buzzwords. > > along with whistle blowers’ revelations >> > have shown that threat actors can and are casually recording all Internet >> traffic in their data centers >> > > No they're not. It's just not possible or indeed necessary to duplicate > everything at large scale. Perhaps with a large amount of filtering, > certain flows would be captured, but in the days of pervasive TLS, this > seems less and less worthwhile. > > and that they select encrypted traffic as interesting and worth >> storing.This means that any data encrypted using any of the standard >> public-key systems today will need to be considered compromised once a >> quantum computer exists and there is no way to protect it retroactively, >> because a copy of the ciphertexts in the hands of the attacker. This means >> that data that needs to remain confidential after the arrival of quantum >> computers need to be encrypted with alternative means" >> > > None of this is relevant to RPKI (ROV) at all. In fact, it reads like the > fevered dreams of a cyber security research student. What's your point > regarding your message? ROV does not use (nor needs) encryption. > > M > >
Re: Need for historical prefix blacklist (`rogue' prefixes) information
Hi Matthew, What you seem to have failed to understand is that most traffic hijacks on > the internet are not malicious in nature, they are "fat finger" incidents > where someone has accidentally announced something they did not intend to, > either because of faulty software (the infamous "BGP optimizer") or someone > leaking internal "blocks" such as the Pakistan/YouTube incident -- > certifying the origin of a prefix allows you to mitigate most of this as > the origin AS will change. Anyone seen deliberately causing hijacks is > likely to be depeered very quickly -- commercial pressure rather than > technical. > > I was reading the above exchange, and I do have a question linked to your last affirmation. To give you some context, the last 2021 ENISA report seem to suggest that internet traffic is "casually registered" by X actors to apply post Retrospective decryption (excerpt below). This would be at odds with your (deescalating) affirmation that hijacks are non-malicious and they are de-peered quickly, unless you pinpoint complete flux arrest only. Are there any reportings/indicators... that look into internet flux constant monitoring capabilities/capacities? Thanks. Excerpt from the introduction: "What makes matters worse is that any cipher text intercepted by an attacker today can be decrypted by the attacker as soon as he has access to a large quantum computer (Retrospective decryption). Analysis of Advanced Persistent Threats (APT) and Nation State capabilities, along with whistle blowers’ revelations have shown that threat actors can and are casually recording all Internet traffic in their data centers and that they select encrypted traffic as interesting and worth storing.This means that any data encrypted using any of the standard public-key systems today will need to be considered compromised once a quantum computer exists and there is no way to protect it retroactively, because a copy of the ciphertexts in the hands of the attacker. This means that data that needs to remain confidential after the arrival of quantum computers need to be encrypted with alternative means" Best to all, Dora
