Dear fellow SwiNOGers,
in the last few months we had several security audits and all of them proposed to disable tcp timestamps. (i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
What do you guys think about this?
Regards André
On 2016-03-10 17:12, Andre Keller wrote:
Dear fellow SwiNOGers,
in the last few months we had several security audits and all of them proposed to disable tcp timestamps.
Did they also state why? :)
(i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
You might want to read up on: http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf
What do you guys think about this?
It all depends on what you are "protecting" yourself from.
Think about it: if it was a huge security issue, it would be disabled per default ;)
It is primarily a obfuscation technique that primarily hides if you did upgrade your kernel recently...
Greets, Jeroen
❦ 10 mars 2016 17:12 +0100, Andre Keller ak@list.ak.cx :
in the last few months we had several security audits and all of them proposed to disable tcp timestamps. (i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
What do you guys think about this?
By disabling it, the effective bandwidth of the TCP connections may decrease quite a bit (much of RFC7323 relies on timestamps) and you deprive yourself of some interesting workarounds when handling many connections (RFC 1337 and the likes).
Dear André
Ignore this crap. Really.
We do 1-2 external security audits per year and I’ve seen incredible crap in those reports. My favorites are things like “Hostname mail.domain.com suggests this is a mail server. Consider changing it to something not so obvious.” and a few lines further down: “Detected open port 25 on server mail.domain.com. Attackers could abuse this knowledge. Consider changing the port to something else”, etc.. The worst I ever encountered was that in the report they were complaining, that there’s a firewall in place that blocks ports and/or certain ICMP types... :-O
During the last few years I’ve learned, that these things are more or less unchanged output copy/pastes from automated hacking tools. If an audit company does not filter out such crap, you might as well consider changing your provider.
One more: “Server with IP x.x.x.x with DNS name www.domain.com http://www.domain.com responds to Port 80” (not mentioning, that the only answer from Port 80 is a redirect to the respective https website).
If you need some recommendations, contact me off-list.
Kind regards,
Viktor
Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Andre Keller Gesendet: Donnerstag, 10. März 2016 17:12 An: swinog@lists.swinog.ch Betreff: [swinog] TCP timestamps
Dear fellow SwiNOGers,
in the last few months we had several security audits and all of them proposed to disable tcp timestamps. (i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
What do you guys think about this?
Regards André
Hi Swinogers well maybe the same experts where asked for an expertise from AVM for the new Firmware upgrade on the router products this days. They proudly announced to have a Stealthmode implemented, which of corse is just a drop of ICMP Requests, which user find Evil because someone told once in a newspaper several years agow :D But they maybe never did have the idea there are ICMP types which could be used for real evil things than just getting an answer back ;) i would read this crap several times, then think about what made sense, maybe that will be unsuccessful and then i will be shure there is a dustbin unterneath your desk.
Roger
On 10/03/2016 12:12, Andre Keller wrote:
Dear fellow SwiNOGers,
in the last few months we had several security audits and all of them proposed to disable tcp timestamps. (i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
What do you guys think about this?
Regards André
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
On 11 Mar 2016, at 01:33, Roger roger@mgz.ch wrote:
Hi Swinogers well maybe the same experts where asked for an expertise from AVM for the new Firmware upgrade on the router products this days. They proudly announced to have a Stealthmode implemented, which of corse is just a drop of ICMP Requests, which user find Evil because someone told once in a newspaper several years agow :D But they maybe never did have the idea there are ICMP types which could be used for real evil things than just getting an answer back ;) i would read this crap several times, then think about what made sense, maybe that will be unsuccessful and then i will be shure there is a dustbin unterneath your desk.
Roger
Furthermore ICMP is _mandatory_ for MTU path discovery to work. So be ready for all kind of non functioning stuff if you transfer larger packets than the MTU somewhere in the middle (such as trying to squeeze a 1500 byte ethernet packet into a IPSec tunnel with a MTU around 1426). TCP/IP is built in the way that it reacts on these ICMP MTU mismatch messages when packets get dropped on the way due to too big size. TCP can adapt but if ICMP is filtered away, then TCP will not notice and a endless retransmission dance begins. The odd thing there is that it "kinda works". Sometimes its just slow and sometimes nothing works. We use IPSec in our network heavily and we have seen that happening with large corporations such as Networksolutions.com (which is one of the oldest companies in the internet, they should know this stuff!). T1his can be a big issue. So if I ever find a consultant telling me I should filter away ICMP just because, I will kick him out of the door immediately. The only reason where this could be valid is if you still have Windows95 machines in your network due to the "ping-of-death" bug. But if you have that, then you're hopelessly lost anyway.
Let's face it. Firewalls and NAT have been built to break the internet in the way it has been intended with all kinds of strange side effects. Thinking they are the only defence to protect you is so wrong. Social engineering brings hackers behind firewalls and they attack from with inside. A well secured localhost is way more important. I'm using machines on public IP's without firewall or NAT in between over 20 years and the issues I've seen have all been controllable (but I'm not an interesting target to hack like a Bank). On the other hand NAT & Firewalls (and their admins) have turned out to be a way bigger problem.
Andreas Fink DataCell ehf, Backbone ehf, Cajutel Inc, Alisanus GmbH ------------------------------------------------------------------ c/o Alisanus GmbH Clarastreasse 3, 4058 Basel, Switzerland E-Mail: andreas@fink.org mailto:andreas@fink.org https:// https://www.fink.org/www.fink.org https://www.fink.org/ Mobile: +41-78-6677333 Office: +41 61 6666330 Skype: andreasfink Jabber/XMPP: andreas@fink.org mailto:andreas@fink.org ICQ: 8239353 ------------------------------------------------------------------
On 10/03/2016 12:12, Andre Keller wrote:
Dear fellow SwiNOGers,
in the last few months we had several security audits and all of them proposed to disable tcp timestamps. (i.e. on Linux net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies on this and there might be implications for PAWS (tcp sequence number wrapping).
What do you guys think about this?
Regards André
swinog mailing list swinog@lists.swinog.ch mailto:swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi,
Furthermore ICMP is _mandatory_ for MTU path discovery to work. So be ready for all kind of non functioning stuff if you transfer larger packets than the MTU somewhere in the middle (such as trying to squeeze a 1500 byte ethernet packet into a IPSec tunnel with a MTU around 1426). TCP/IP is built in the way that it reacts on these ICMP MTU mismatch messages when packets get dropped on the way due to too big size. TCP can adapt but if ICMP is filtered away, then TCP will not notice and a endless retransmission dance begins. The odd thing there is that it "kinda works". Sometimes its just slow and sometimes nothing works. We use IPSec in our network heavily and we have seen that happening with large corporations such as Networksolutions.com (which is one of the oldest companies in the internet, they should know this stuff!). T1his can be a big issue. So if I ever find a consultant telling me I should filter away ICMP just because, I will kick him out of the door immediately. The only reason where this could be valid is if you still have Windows95 machines in your network due to the "ping-of-death" bug. But if you have that, then you're hopelessly lost anyway.
This is basically only true for ipv6. In ipv4 network devices can fragment. This does not mean, that I would consider filtering icmp a reasonable idea.
Let's face it. Firewalls and NAT have been built to break the internet in the way it has been intended with all kinds of strange side effects. Thinking they are the only defence to protect you is so wrong. Social engineering brings hackers behind firewalls and they attack from with inside. A well secured localhost is way more important. I'm using machines on public IP's without firewall or NAT in between over 20 years and the issues I've seen have all been controllable (but I'm not an interesting target to hack like a Bank). On the other hand NAT & Firewalls (and their admins) have turned out to be a way bigger problem.
NAT and Firewalls are not the biggest problem, but there is just too many people around configuring these devices with a limitted understanding, of how the internet works.
regrards Robert
On 11 Mar 2016, at 11:40, Robert Meyer r.meyer@net-wizard.org wrote:
Hi,
Furthermore ICMP is _mandatory_ for MTU path discovery to work. So be ready for all kind of non functioning stuff if you transfer larger packets than the MTU somewhere in the middle (such as trying to squeeze a 1500 byte ethernet packet into a IPSec tunnel with a MTU around 1426). TCP/IP is built in the way that it reacts on these ICMP MTU mismatch messages when packets get dropped on the way due to too big size. TCP can adapt but if ICMP is filtered away, then TCP will not notice and a endless retransmission dance begins. The odd thing there is that it "kinda works". Sometimes its just slow and sometimes nothing works. We use IPSec in our network heavily and we have seen that happening with large corporations such as Networksolutions.com (which is one of the oldest companies in the internet, they should know this stuff!). T1his can be a big issue. So if I ever find a consultant telling me I should filter away ICMP just because, I will kick him out of the door immediately. The on
ly reason where this could be valid is if you still have Windows95 machines in your network due to the "ping-of-death" bug. But if you have that, then you're hopelessly lost anyway.
This is basically only true for ipv6. In ipv4 network devices can fragment. This does not mean, that I would consider filtering icmp a reasonable idea.
they COULD fragment but 99% of the routers do drop and send back a ICMP back
Let's face it. Firewalls and NAT have been built to break the internet in the way it has been intended with all kinds of strange side effects. Thinking they are the only defence to protect you is so wrong. Social engineering brings hackers behind firewalls and they attack from with inside. A well secured localhost is way more important. I'm using machines on public IP's without firewall or NAT in between over 20 years and the issues I've seen have all been controllable (but I'm not an interesting target to hack like a Bank). On the other hand NAT & Firewalls (and their admins) have turned out to be a way bigger problem.
NAT and Firewalls are not the biggest problem, but there is just too many people around configuring these devices with a limitted understanding, of how the internet works.
I can only confirm that..
-
Andre Keller -
Andreas Fink -
Jeroen Massar -
Robert Meyer -
Roger -
Viktor Steinmann -
Vincent Bernat