mtn db regenerate_caches (снэпшот сначала захотел mtn db migrate, а потом и mtn db regenerate_caches).Итак, оно работает, работает и ещё раз работает. Todo: посмотреть, сколько оно отъедает памяти на соединение; насколько вырос трафик, т.к. теперь коннекты вирусов на honeypot не отваливаются, а остаются висящими, пусть и в очень ленивом режиме. Кстати, забавно, что сетевой стэк ядра 2.6 на клиенте остаётся подвисать на тарпите даже после явного close() на сокет. А оффтопик сразу после close() присылает FIN. Ещё одно отличие -- в ответ на zero window линух шлёт keep-alive пакеты, а оффтопик -- zero window probes; последнее вроде бы также вернее.
...
Create connexion slot ec87 for 71.174.117.108:57911 -> 81.9.35.6:22
Create connexion slot ec45 for 71.174.117.108:57913 -> 81.9.35.70:22
Create connexion slot ec41 for 71.174.117.108:57914 -> 81.9.35.73:22
Create connexion slot ec3e for 71.174.117.108:57919 -> 81.9.35.71:22
Send keep-alive for slot f7ec
Send keep-alive for slot 8cae
Send keep-alive for slot be4
Send keep-alive for slot d61b
Ignore FIN = 1, RST = 0 from 81.9.74.225:3553 (disconnected)
Send keep-alive for slot b63e
Send keep-alive for slot 7e6e
*** Holding 2607 connexions
Send keep-alive for slot 982f
Send keep-alive for slot 7beb
...
Не отрицая тотальной пользы tarpit'а (хотя бы для самолюбия), должен отметить, что есть один надводный камень. Типичная сессия вируса, обращающегося к моему серверу (в норме), выглядит так:
syn ->
<- rst (port unreachable)
Ну нет у меня MSSQL, AD и прочей атрибутики всем известной ОС. Типичная же сессия вируса к tarpit-enabled машине выглядит так:
syn ->
<- syn,ack (win 0)
ack ->
(дальше идут разные механизмы тестирования окна, или keep-alive, как делает Linux, или zero window probes, как делают окна)
fin -> (игнорируется) ...
То есть, если имеем один экземпляр вируса в сети, и ловим его на тарпите, это, безусловно, сэкономит трафик. Если же всё не так... Вот цифры. Тарпит у меня спустя неделю держал до 50 тысяч соединений единовременно, и за ночь набегало до 180 мегабайт входящего (вирусного) трафика. Тарпит выключил, входящий трафик (только вирусный) за ночь -- 3 мегабайта. Повод призадуматься. Мой сервер за две недели испытаний кому-то сэкономил немало трафика. Увы, не мне.
А ещё так говорил Таненбаум: на современных сетях не стоит производительность приносить в жертву надёжности. И я с ним согласен, потому как типичная причина потерь пакетов на wired-сетях сейчас — это обрыв линии. Времена огромных сегментов коллизий и выпадания пакетов в проводных сетях давно прошли.
И так он говорил: протокол должен быть ориентирован на нормальную работу; ошибка должна рассматриваться как ситуация исключительная, и должна обрабатываться отдельно. Это вполне понятно, т.к. вынесение анализа ошибок в исключительные ситуации даёт прирост производительности.
Но вот чего я не понимаю, так это в каком веке застыли комитеты IETF. К примеру, возмём рабочую группу RMT (Reliable Multicast Transport). Ребята работают уже не первый год, и результатом явился целый стэк протоколов (один другого страшнее), и вершиной всего этого — использование FEC! Поясню в двух словах: FEC (Forward Error Correction), это такой способ (избыточного) кодирования информации, когда получатель может восстановить всю информацию при условии утери части пакетов или части битов одного пакета; FEC широко и оправданно используется в беспроводных сетях, будь то GSM или WiFi. И вот, эти черти (RMT working group) рассуждают на тему применения кодирования Рида-Соломона на транспортном уровне!
Удивительный пример заботы в условиях применения RMT, например, в кластерах :) Ни Reed, ни Solomon не спасут при обрыве линии связи. А "выпадения" пакетов на оптике — это уже из ряда вон. В беспроводных сетях же тем не менее: это не задача транспорта высокого уровня. Не царское это дело, пьяных урок шомполами в уши тыкать.