время dmesg по сравнению со временем системного времени не корректно
Нет, это не сделает этого для Вас.
Динамично блокирование каждого соединения даст Вам тот же самый результат как устанавливание всеохватывающего правила для блокирования всех соединений независимо от их источника - то есть, сайт будет недоступен.
Если Вашей проблемой является просто лавинная рассылка syn, то просто включают syncookies и прекращают дело. Но если это будет истинная DDos-атака, то затем необходимо будет сделать немного больше.
Вместо этого необходимо отфильтровать трафик на основе некоторого фактора, существующего во всем трафике DDoS, но отсутствующего в правомерном трафике, таком как заголовок агента пользователя, предположив, что это - веб-трафик. Я успешно сделал это использование nginx как обратный прокси, но принимаю во внимание, что установка и управление такой вещью нетривиальны и требуют администратора, который знает его технологию. Вы не собираетесь разрешать его путем следования инструкциям на некотором блоге.
Если Вы не имеете один, то найдите тот.
Чтобы проверить вашу теорию (которая, кстати, верна), выполните следующее от имени пользователя root:
hwclock --show
Это покажет вам ваши аппаратные часы на сервере, на котором вы выполняете команду.
Чтобы синхронизировать ваши аппаратные часы с системным временем (которым управляет ntp), выполните следующую команду:
hwclock --systohc --utc
Последний аргумент (--utc) указывает hwclock хранить время в аппаратных часах в скоординированном универсальном времени. .
Кроме того, имейте в виду, что страница руководства для dmesg (1) говорит следующее, поэтому поведение, с которым вы столкнулись, документировано и допустимо:
-T, --ctime
Print human-readable timestamps.
Be aware that the timestamp could be inaccurate! The time
source used for the logs is not updated after system
SUSPEND/RESUME.
dmesg просто печатает кольцевой буфер ядра, который регистрирует сообщения с временем безотказной работы в секундах с момента запуска в качестве отметки времени.
Таким образом, если вы используете параметр -T, все эти значения времени безотказной работы просто добавляются к дате ваша система была загружена. Если у вас были времена, когда вы спали в режиме ожидания или возобновления, они теряются, поэтому в этих случаях опция -T бесполезна, так как значения даты / времени неверны для того времени и в прошлом.
Чтобы получить точное время для "недавних" записей в dmesg , вы можете преобразовать временные метки dmesg в реальное время с некоторым взломом вывода.
By "Recent ", Я имею в виду время после последней приостановки / возобновления, поскольку (как уже указали другие) время приостановки не учитывается в метке времени dmesg.
Но если вам это нужно часто, например, в записной книжке, вы можете поместить что-то вроде следующее в функции или псевдонимы:
# write current time to kernel ring buffer
echo "timecheck: $(date +%s) = $(date +%F_%T)" | sudo tee /dev/kmsg
# use our "timecheck" entry to get the difference
# between the dmesg timestamp and real time
offset=$(dmesg | grep timecheck | tail -1 \
| perl -nle '($t1,$t2)=/^.(\d+)\S+ timecheck: (\d+)/; print $t2-$t1')
# pipe dmesg output through a Perl snippet to
# convert it's timestamp to correct readable times
dmesg | tail \
| perl -pe 'BEGIN{$offset=shift} s/^\[(\d+)\S+/localtime($1+$offset)/e' $offset
# or use this instead to keep dmesg colors
dmesg --color=always | tail \
| perl -pe 'BEGIN{$offset=shift} s/^(\x1b\[.*?m)?\[(\d+)\S+/$1.localtime($2+$offset)/e' $offset
Пример вывода:
...
Sat Jun 29 11:12:28 2019 wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
Sat Jun 29 11:12:28 2019 IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
Sat Jun 29 11:34:16 2019 timecheck: 1561800856 = 2019-06-29_11:34:16
Sat Jun 29 12:10:11 2019 wlp3s0: cannot understand ECSA IE operating class, 5, ignoring
По сравнению с исходным выводом dmesg (который отключен на 3 дня):
$ dmesg | tail -4
[249424.746958] wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
[249424.749662] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[250732.318826] timecheck: 1561800856 = 2019-06-29_11:34:16
[252887.828699] wlp3s0: cannot understand ECSA IE operating class, 5, ignoring
$ dmesg -T | tail -4
[Wed Jun 26 17:59:09 2019] wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
[Wed Jun 26 17:59:09 2019] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[Wed Jun 26 18:20:57 2019] timecheck: 1561800856 = 2019-06-29_11:34:16
[Wed Jun 26 18:56:52 2019] wlp3s0: cannot understand ECSA IE operating class, 5, ignoring