starred/hardening

Fork 0

mirror of https://github.com/konstruktoid/hardening.git synced 2026-04-26 01:05:56 +03:00

[GH-ISSUE #129] Is net.ipv4.tcp_timestamps=0 still relevant? #59

New issue

Closed

opened 2026-03-03 13:58:48 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 13:58:48 +03:00

Owner

Originally created by @bob-rove on GitHub (May 24, 2022).
Original GitHub issue: https://github.com/konstruktoid/hardening/issues/129

Originally assigned to: @konstruktoid on GitHub.

I was going through all sysctl settings set by this tool and found an odd thing (in my personal opinion).

In the past this setting was relevant to protect from server uptime guessing. But since original sec issue was fixed in kernel 4.x, is it still relevant to turn off timestamps?

To not duplicate words, I'd like to refer to a similar report of a similar tool:

https://github.com/dev-sec/ansible-collection-hardening/issues/360

Originally created by @bob-rove on GitHub (May 24, 2022). Original GitHub issue: https://github.com/konstruktoid/hardening/issues/129 Originally assigned to: @konstruktoid on GitHub. I was going through all `sysctl` settings set by this tool and found an odd thing (in my personal opinion). In the past this setting was relevant to protect from server uptime guessing. But since original sec issue was fixed in kernel 4.x, is it still relevant to turn off timestamps? To not duplicate words, I'd like to refer to a similar report of a similar tool: https://github.com/dev-sec/ansible-collection-hardening/issues/360

kerem closed this issue

2026-03-03 13:58:48 +03:00

kerem commented

2026-03-03 13:58:49 +03:00

Author

Owner

@konstruktoid commented on GitHub (May 24, 2022):

Hi @bob-rove and thanks for going through the settings, and you are absolutely correct. Will remove it so the upstream default is used.

In my defense, github.com/konstruktoid/hardening@bc42f45b68 was commited some six months before the kernel update ;)

@konstruktoid commented on GitHub (May 24, 2022): Hi @bob-rove and thanks for going through the settings, and you are absolutely correct. Will remove it so the upstream default is used. In my defense, https://github.com/konstruktoid/hardening/commit/bc42f45b68cc1978a5c0424e35655512a30aaeb1 was commited some six months before the kernel update ;)

kerem commented

2026-03-03 13:58:49 +03:00

Author

Owner

@bob-rove commented on GitHub (May 25, 2022):

@konstruktoid Wow, so awesome to see such a quick reaction! And thanks a mil for confirming the case 🙇

Indeed, the issue behind TCP timestamps has a long history of not being fixed as far as I can see through the publications all over the Internet. And it's actually pretty hard to determine whether timestamps should still be disabled despite being fixed in kernel. For example, it might still be useful to keep timestamps disabled to make sure clients behind NAT are served without issues, but only in case of net.ipv4.tcp_tw_reuse = 1. And that seems to be not a usual case anymore as at least on recent Ubuntu LTS version net.ipv4.tcp_tw_reuse = 2 by default (ie: enabled only on loopback). Unless I'm getting things wrong 😇

Anyway, was glad to contribute! 😄 I'm really excited about this project as it helps a lot to make things more secure by default, well done folks! 🚀

I assume the can be closed (leaving up to the maintainers).

@bob-rove commented on GitHub (May 25, 2022): @konstruktoid Wow, so awesome to see such a quick reaction! And thanks a mil for confirming the case 🙇 Indeed, the issue behind TCP timestamps has a long history of not being fixed as far as I can see through the publications all over the Internet. And it's actually pretty hard to determine whether timestamps should still be disabled despite being fixed in kernel. For example, it might still be useful to keep timestamps disabled to make sure clients behind NAT are served without issues, but only in case of `net.ipv4.tcp_tw_reuse = 1`. And that seems to be not a usual case anymore as at least on recent Ubuntu LTS version `net.ipv4.tcp_tw_reuse = 2` by default (ie: enabled only on loopback). Unless I'm getting things wrong 😇 Anyway, was glad to contribute! 😄 I'm really excited about this project as it helps a lot to make things more secure by default, well done folks! 🚀 I assume the can be closed (leaving up to the maintainers).

kerem commented

2026-03-03 13:58:49 +03:00

Author

Owner

@konstruktoid commented on GitHub (May 25, 2022):

Reading https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt, setting 2 will result on the old ("bad") way and I should probably add net.ipv4.tcp_timestamps=1 in the future to ensure the recommended default it set.

tcp_timestamps - INTEGER
Enable timestamps as defined in RFC1323.
	0: Disabled.
	1: Enable timestamps as defined in RFC1323 and use random offset for
	each connection rather than only using the current time.
	2: Like 1, but without random offsets.
	Default: 1

Regarding tcp_tw_reuse: "it should not be changed without advice/request of technical experts", and since tcp_tw_reuse and ip_autobind_reuse is the only ones with that notice, I'm just going to leave it alone.

I'm going to close the issue, and thank you yet again for bringing this it.
Please continue to bring up and question anything you find odd, it helps alot.

@konstruktoid commented on GitHub (May 25, 2022): Reading https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt, setting `2` will result on the old ("bad") way and I should probably add `net.ipv4.tcp_timestamps=1` in the future to ensure the recommended default it set. ``` tcp_timestamps - INTEGER Enable timestamps as defined in RFC1323. 0: Disabled. 1: Enable timestamps as defined in RFC1323 and use random offset for each connection rather than only using the current time. 2: Like 1, but without random offsets. Default: 1 ``` Regarding `tcp_tw_reuse`: "it should not be changed without advice/request of technical experts", and since `tcp_tw_reuse` and `ip_autobind_reuse` is the only ones with that notice, I'm just going to leave it alone. I'm going to close the issue, and thank you yet again for bringing this it. Please continue to bring up and question anything you find odd, it helps alot.

No labels

Stale

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/hardening#59

No description provided.

Rows
Columns