Linux 64 -номера портов SSH?

Is it possible to configure Linux to use 64 bit ports?

Нельзя изменить параметр для использования 64-битных портов в TCP/UDP.

Вы могли бы создавать аналогичные протоколы, но вы могли бы общаться только с вашими модифицированными хостами и это был бы не TCP/UDP, а новый набор протоколов, скажем, TCP64/UDP64.

Вот лишь некоторые вещи, которые вам нужно будет добавить, чтобы эти протоколы работали, просто для начала, прежде чем даже учитывать влияние памяти и массу других проблем:

• определение TCP64(модификация текущего сегмента TCP)
• новое семейство AF _INET, способный поддерживать расширенные порты вместе с кодом ядра для их обработки (если вы думаете о копировании/вставке, обратите внимание, что вам нужно изменить, по крайней мере, список определений структур, определений типов и вызовов htons()или ntohs(), например
• код для всех программ пользовательского пространства, предназначенных для использования новых стеков, в том числе на границах сети, таких как брандмауэры, если вы планируете фильтровать трафик.

Так как это будет другой набор протоколов, с собственными IP-номерами , они не будут мешать узлам маршрутизации, хотя они могут быть отброшены ими по маршруту, потому что номер IP-протокола будет не быть известным.

Что касается смягчения последствий :, программное обеспечение, такое как fail2banи пользовательские сервисные порты (в 16 -битном диапазоне )являются обычными методами, хотя не единственными .

Как уже упоминалось, это невозможно, поскольку и TCP, и UDP используют 16 бит для обозначения порта. Таким образом, вам нужно, чтобы все хосты в Интернете изменили протокол TCP на что-то другое, что маловероятно.

К счастью, у нас есть IPv6 , развернутые в настоящее время во многих местах, поэтому вместо того, чтобы злоумышленник угадывал, какой у вас порт, вы можете использовать разные службы на хосте для прослушивания разных IPv6-адресов, тем самым заставляя злоумышленника необходимость угадывать IP-адрес -, выполняя то же самое, заставляя их искать большее пространство. Адрес IPv6 имеет 128 бит, и даже один компьютер всегда может использовать как минимум 64 бита для себя (или больше, если это разрешено ), поэтому злоумышленнику даже сложнее угадать, чем ваша идея с 64-битным портом -.

Конечно, как и в случае со скрытым портом, вы должны быть осторожны, чтобы ваш скрытый IPv6-адрес не был легко доступен злоумышленнику.

(Разумеется, исходный и конечный компьютеры должны иметь возможность подключения по протоколу IPv6. Если они этого не сделают, попросите своего интернет-провайдера предоставить его изначально и используйте какой-нибудь туннель IPv6, например тоннельброкер.нет , пока они не сделают)

Думая, что большее количество возможных номеров портов улучшит безопасность, вы, по сути, полагаетесь на безопасность через неизвестность . Сохранить в секрете номер пользовательского порта будет гораздо сложнее, чем, скажем, пароль. Например, вашему маршрутизатору не нужно знать ваш пароль SSH, но вам нужно сообщить ему номер порта, если вы используете переадресацию портов. Гораздо лучшей мерой с точки зрения безопасности было бы отключение аутентификации на основе пароля -и использование вместо этого сертификатов.

Наличие большего количества возможных номеров портов также не предотвратит DoS-атаки. :Существуют атаки, которым не нужно знать номер порта, и если бы все каким-то образом переключились на случайные номера портов, такие атаки стали бы преобладающими..

Вы не можете использовать 64-битные -порты без изменения протоколов TCP/UDP, и если вы это сделаете, вы не сможете общаться с остальным миром.

Но вы можете сделать что-то еще. :Использовать скрытый сервис Tor.

Если вы настроите скрытый сервис Tor, вы получите имя хоста, например:

p53lf57qovyuvwsc6xnrppyply3vtqm7l6pcobkm​yqsiofyeznfu5uqd.onion

И это не легко догадаться.

Еще одним преимуществом является то, что вы можете получить к нему доступ только через Tor -, а не через обычный Интернет; но сервер может быть за NAT, не надо возиться с пробросом порта -и т.д.

Задержка выше (около 500 мс ), но вы можете легко получить пропускную способность 10 Мбит/с, поэтому это нормально для SSH и потокового видео, но не подходит для видеоконференций.

Я не думаю, что изменение стека TCP целесообразно, потому что даже если вы сделаете это на стороне сервера, вам придется также исправлять клиент и программное обеспечение, работающее на нем.

В качестве меры я бы предложил использовать CrowdSec. Это что-то вроде современного fail2ban (, так что найдите поведение в журналах и заблокируйте их ), но совместимое с IPV6, более быстрое и несвязанное. Кроме того, вы получаете выгоду от черного списка IP-адресов всех других пользователей, защищающих свой SSH-порт, который идентифицировал агрессивные IP-адреса, нацеленные на них.

Отказ от ответственности :Я являюсь частью команды CrowdSec.