Yes, including 80 and 443.
He was purely a GRC monkey that had absolutely zero technical knowledge, he just knew how to check boxes. It took way too long for me to explain to him that closing those ports would take our SaaS down entirely, and I was absolutely appalled that I had to have that discussion and started questioning how the hell this guy became a CISO.
I've heard some people argue that CISOs don't need to be technical, but I wholeheartedly disagree and can't fathom how anybody could think that someone who manages something should be able to get away with not having any knowledge in the field they manage. Like, I get that the IC track and the management track are completely different skillsets, but once you get to that level, you should have both sets of skills. I wouldn't want a CTO that doesn't know how to code, and I'd be terrified of a CFO that doesn't know accounting.
The thing is, I wouldn't actually have the authority to make the change. I'd have to convince someone from DevOps/SRE to do it, and they were certainly not gonna do it.
Btw, compliance auditors are required to be CPAs.
SAAS Engineer: Leave it on so I can tell when your shit goes down without having to consult your service status page.
Sysadmin: I really dont care what you do, just enable it when you raise a complaint with your ISP so they can tell you what you broke.
Residential: Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet. YMMV.
Dropping ICMP breaks path MTU discovery (PMTU). It's the biggest reason why sites break when accessed (or served) over VPNs. This is often mitigated on the server, or in NAT-ing routers, by clamping TCP MSS, but that doesn't really resolve the problem. It doesn't fix it for UDP, nor likely for double VPN scenarios, etc, plus you're just losing bandwidth that way.
Some people make fatalistic arguments that even if they allow ICMP, something downstream may not have, so it's futile. But the networks in the middle rarely if ever block ICMP; those engineers know better. The real issue is on the ends. If you're a sysadmin dropping ICMP, you're half the problem. Fix ICMP on your end, and half the problem goes away. The other half of the problem are those NAT-ing routers, firewalls, and VPNs that don't handle ICMP properly. You can't fix those, but plenty of residential and commercial equipment on the other end, as well as VPN setups, actually do the right thing. Don't make perfect the enemy of better.
The issue is that sysadmins make this the ISP's issue anyway. They wont do any kind of investigation but simply yell at the telco. Telcos are ready willing and able to clamp. Its as natural as breathing at this point.
The only thing that gets me is when the some small business refuses to enable ICMP for troubleshooting when they raise a complaint. You have to come to the table at least that far.
Depending on your definition of small business, asking someone "hey can you enable ICMP real quick" is like asking them "hey can you build a rocket ship while skydiving?"
Small as in <100 employees. The IT guy doesnt want to change anything, hes been there 20 years and never changed that setting. Or he needs to go through change management which he is also adverse to.
its very easy and cheap to saturate a link with flood traffic, but fixing this issue requires large investments in big expensive firewalls that can block these stupid attacks
IP stacks haven't responded to broadcast pings for ≥20 years now. If you find one that does, please report it so it can get fixed.
> because src.ip can be easily spoofed
Operators have been pushing to get BCP38 everywhere for ≥ 20 years now. If you find one that doesn't do it, please report it so I can depeer and shame them on public mailing lists.
> ICMP flood
So you'll just get flooded with UDP instead (cf. sibling comment).
If it does, it generally won't pass telco CPE certification, i.e. Comcast and the likes won't be selling it to you in any bundle. Blocking ICMP Fragmentation Needed / ICMPv6 Packet Too Big is a hard fail on all of those, other message types can vary.
(Source: I work in this area.)
[Ed.: to be clear, there is no single "telco CPE certification"; each telco decides this on their own. A bunch of them form groups/"alliances" though, and a lot of the certification requirements are the same everywhere.]
I supported a mid size WISP for 2 years and something like 60% of the issues they sent my way were ultimately resolved with MSS Adjust or MTU clamping.
The more spiky black angular antennas you put sticking up on a router that makes it resemble a science fiction movie arachnid-form robot, the faster it goes. This seems to be the universal design language now.
For routers that consumers purchase themselves, the design language seems to have been optimized to look amazing and cool and grab the attention of someone browsing the aisles at the local Best Buy.
I wouldn't be surprised if the damn antennas are just empty. They don't seem to serve any purpose.
It also compensates for interference dead spots when you hold your phone into such a spot.
The long sticks typically radiate in the plane normal to the stick, i.e., if you make them all perfectly vertical, they are focused to the same floor. Individual ones can be rotated readily to cover special spots, especially if you have more than 4 antenna.
I generally recommend just maximizing angles between them, i.e. 90° between 2 or 3 antennas. Wall attenuation & reflections will equalize it out, and you have a lower chance of dead zones. The ≥4th one —on the same radio— is YOLO. Annoyingly enough, for some devices they don't tell you which antenna is on which radio.
However, they also have more than 1 radio these days, and sharing the antennas on them not exactly beneficial; if you have one 2.4GHz, 5GHz and 6GHz radio each, you might as well optimize the antennas for each radio. And even if it's the same band, separate antennas allow you to have distinct radios cover distinct space with different RF propagation characteristics.
(They're not empty, or at least I haven't found any fake ones yet.)
Maybe there are edge cases associated with this?
I consider the integrity of messages to-and-from the web to be very important.
Many of us lived through days when ISPs or some other greedy middleman injected ads into unsecured web pages. They played DNS tricks too.
Imagine if you had an app download that could be maliciously modified in-flight.
Furthermore, a certificate can guarantee you’re not connected to an imposter. What if the TFA link was redirected to “abevigoda.com”? Catastrophe!
Sure, your website may have unimportant stuff on it that nobody relies on, but do you want visitors to see ads in your content that you didn't put there?
Still worth creating a bit of a shield between you and the site to make it just hat much harder for anybody in the middle to inject anything / change anything.
Back before Lets Encrypt made it inexcusable to not have https, it was a common-ish prank to MITM all the HTTP traffic you could see and do something harmless like rotate images 180 degrees.
While it's highly unlikely that threat actors would be lurking in trusted networks and devices on such a network path, they definitely don't need to use shared WiFi or ARP spoofing if they have control of a core router or transmission line. That's the very essence of MITM attacks.
Knowledge of facts and history.
What leads people such as yourself to start a response this way? "I'll respond to you but first I'm going to feign ignorance of how you could even say that in a way that adds absolutely nothing to the discussion." I perceive this as exceptionally rude. Am I alone in that?
> does inherently allow undetected tampering by any middleman.
Yes. And did I describe methods by which you can hijack connections to /become/ the middleman? Perhaps you missed the subtle detail.
> That's the very essence of MITM attacks.
The popularized attacks you're describing became popular because they were done with the techniques I described in places like Starbucks and other businesses with open Wifi networks. Here it is, literally:
So, I am still unsure that you are clued in here, because the article you have linked to has nothing at all to do with tampering in-flight TCP streams, only sniffing them. Perhaps you do not understand how these principles differ. This shared WiFi scenario certainly permits eavesdropping on unencrypted channels, and that’s a danger that’s distinct from actual MITM.
You claim we’re describing the same thing but we are not.
> did I describe methods
No, actually you didn’t — you named one vector and one mostly unrelated LAN attack. ARP spoofing may be a stepping stone, but not really central.
The attack you describe happens at the application layer, in fact. It doesn’t even need to use TCP. You’re simply stealing someone’s credentials and reusing them in a new browser session. There’s really no way to legitimately describe this as “MITM” — or “tampering” at all. [Your Wikipedia article does not use these terms.]
And in a typical Starbucks installation, nobody would realistically attempt to tamper with in-flight TCP streams. Because that attack would involve some elaborate setup, presenting a higher challenge than the Firesheep attack. I am sure you could explain and describe the former, if you understand the underlying principles.
No, the classic MITM attacks on http do involve neither WiFi nor ARP, but simply interposing malicious code somewhere else on-path. [Actually it is not necessarily malicious, because NAT gateways work by modifying TCP streams too!] That’s why a newer name is called “on-path attack”. And you seem to have omitted that scenario from your comments.
You don't need ARP spoofing or anything like that to intercept a plaintext communication when you control the ISP
Yes, the IETF and Mozilla really put NSA in their place with SSL, but the publicized, primary reason for adoption was eCommerce.
As the NSF handed control of the backbone to Sprint and commerce was finally permitted, the vendors campaigned to secure http lest the consumer’s personal data and credit card details were snooped and scooped while in-flight.
The Internet was incubated in a high-trust environment and every collegiate sysadmin was secretly employed by the NSA (except for Chris Siebenmann who is a North Korean sleeper agent). Once they were able to receive paychecks from Jeff Bezos instead, they began installing malware on routers to replace porn with videos of dancing babies and kittens being totes adorbs.
SSL kept our credit cards safe from the NSA and our porn is no longer sponsored by the ASPCA. Whew.
There are now alternatives, like zerossl for instance
But most importantly: it pushed ACME and all the automation blocks, DNS-based DCV and stuff
So now, lots (all ?) providers also let's you generate certificate (cloud provider and cdn and whatever)
In the end, no, let's encrypt hardly controls "most of the domains on the internet"
Not to mention injected ads which used to be very common in the late 2000s.
Plenty. There are a lot of information-only websites where you might want to keep your visit to yourself.
To give an obvious example: some parts of the United States are trying very hard to make abortion impossible. The state government could mandate that ISPs MitM your traffic, and alert the police when you visit a website giving you information about the legal abortion clinics in a neighboring state. Guess you'll be getting a home visit...
The same is going to apply with looking up info on LGBT subjects, civil rights, Tiananmen Square, a religion not explicitly allowed by the state, whether Eurasia has always been at war with Oceania, and so on. Heck, even a seemingly innocent website visit could theoretically come back to haunt you years later. Just some bored scrolling on Wikipedia? Nope, you were planning a crime - why else were you reading pages about chemical warfare during WW I? That neighbor who died due to mixing bleach and ammonia was obviously murdered by you.
If it's unencrypted, you should assume it's being logged by someone nefarious. Are you still okay with it?
It's honestly surprising that anyone gets away with any significant crimes, given just how much potential evidence is recorded.
TLS is more important on sites that are just serving information. It's easy to reconstruct your train of thought as you click around.
Librarians have fought (and lost) to defend our privacy to read.
https://www.ala.org/advocacy/intfreedom/privacyconfidentiali...
It's a little bit like using Tor for some of your ordinary browsing (which I do) so that spy agencies can't infer everyone using Tor is doing something wrong.
If they're going to "Ask HN", they should ask something like "what are most others doing in regards to X" because that's the only information that can be accurately gleaned in this kind of environment; otherwise, consider asking Reddit/Gemini. https://youtu.be/V-SJQdREDKM
$ ping shouldiblockicmp.com PING shouldiblockicmp.com (52.92.225.139) 56(84) bytes of data.
64 bytes from s3-website-us-west-2.amazonaws.com (52.92.225.139): icmp_seq=1 ttl=241 time=75.3 ms
$ ping -6 shouldiblockicmp.com
ping: shouldiblockicmp.com: Address family for hostname not supportedEvery time a server is hammering our corporate firewall, I know that if I put it into Shodan, it's going to be running out of date versions of those two. It's rare they come from the same IP block, so at best I can block a /32 if they're a persistent offender.
Nothing worth keeping has broken as a result.
I also block outgoing to those sources (as destinations).
Person A makes a statement against X, Person B challenges the statement saying "if you're against X, why aren't you against Y?" when X is a subset of Y, then person A says "I'm against Y too"
It just seems odd to me because the original statement against X is very specific, so it implies that they only dislike A.
To give a simple example, imagine someone saying "I hate red Mazda Miatas" when the truth is that they hate red cars in general. It's just so odd and misleading to be so specific when the truth is far more general.
I think the point I'm trying to make is...if you're blocking ALL traffic, including ICMP, from sources you consider trash, then why would you start the conversation with "I block ICMP"? Why go out of your way to create such a miscommunication? More importantly, how is your general viewpoint even relevant to a topic that's specifically about ICMP?
Some people just do it to troll, though. It's rather silly, considering they're kneecapping their own communications, but… as with all trolls, non-engagement tends to be the best option.
(So I'm non-engaging for 2 distinct reasons.)
I didn't want to stray too far off topic, so I left it at that. I had / have a little project running that detects "uninvited activity" on my systems, and blocks traffic (including ICMP) to and from those sources based on a few rules.
https://github.com/UninvitedActivity/UninvitedActivity
It needs some maintenance, so I sometimes avoid mentioning it.
ICMP can be a special case because of the reasons mentioned in the article and other replies, such is why I addressed it separately from other types of blocking (eg. ports). The main point I wanted to make in my original comment was that my blocking of ICMP from 'trash' sources causes my internet experience no problems; that whilst blanket blocking ICMP may not be a good idea, selective blocking doesn't seem to be a problem.
Also, implement ssl because it’s trivial and prevents garbage isps from injecting ads.
Third, how about no ads to begin with?
It's best left on at least inside a private/protected network.
Nobody wants to have their servers reassemble fragments, it's too much work; many servers just drop any fragments they do get. I ran servers pushing 20 gbps of downloads, and would receive on the order of two fragments per second. It looked legitimate, so I preferred not to disable fragment assembly, but I'd set the reassembly buffer as small as possible; there's no need to keep more than say 16 fragments... if you're getting more than a handful of fragments, it's ddos and that one guy with a weird network will just have to deal. They probably can't use any other sites anyway.
These days with cheap bandwidth about, the only way to really prevent DDoS is to catch them at the source(s). Hell, I have 25Gbit at home (Init7), I can blow entire small telcos off the internet. Once. Then Init7 terminates my service. And that's really the only thing that can prevent this…
If you really care about the cpu usage, you should drop raw traffic instead (when dos from certain ip is detected)
Not asking "Why should I leave it on", I'm specifically asking for legitimate valid use cases for disabling it.
I really can only think of one, abd that's if your server just gets a relentless amount of pings that it takes up a significant portion of your bandwidth. (There was a news article about a news site in Australia, I think, that had that happen)
appleaday1•8mo ago
Retr0id•8mo ago
gavinsyancey•8mo ago
cj•8mo ago
The only reason I can think of is to sync user session cookies across domains?
jcelerier•8mo ago
UltraSane•8mo ago
kaoD•8mo ago
odo1242•8mo ago
I do believe it works if you block just the youtube.com domain and not *.youtube.com
j16sdiz•8mo ago
In additional to youtube.com, in many cases, they redirect to many countries specific domain as well (e.g google.co.jp)
Youtube is common enough that they want to login on the same flow
kccqzy•8mo ago
timewizard•8mo ago
prirai•8mo ago