LINUX.ORG.RU
ФорумAdmin

suricata блокировка telegram

 ,


0

4

Вот, ношёл сингтуры для telegram'а в исходниках ndpi:

  if (packet->payload_packet_len == 0)
    return;
  if (packet->tcp != NULL) {
    if (packet->payload_packet_len > 56) {
      dport = ntohs(packet->tcp->dest);
      /* sport = ntohs(packet->tcp->source); */

      if (packet->payload[0] == 0xef && (
          dport == 443 || dport == 80 || dport == 25
        )) {
        if (packet->payload[1] == 0x7f) {
          ndpi_int_telegram_add_connection(ndpi_struct, flow);
        }
        else if (packet->payload[1]*4 <= packet->payload_packet_len - 1) {
          ndpi_int_telegram_add_connection(ndpi_struct, flow);
}
Попытался создать правило на основе этой сингтуры:
rejectboth tcp any any <> any any (dsize:>56;content: "|ef|";content: "|7f|"; sid:2462;)
Но, почему-то когда под это правило попадает телеграм, то https сайты перестают открываться. Что не так?

★★★★★

tg вроде tls сессию устанавливает с сервером, видимо она и попадает под эти сигнатуры..вместе со всем https трафиком

Deleted ()
Последнее исправление: log4tmp (всего исправлений: 1)
Ответ на: удаленный комментарий

радуйся, забанят сигнатуру, перестанут банить адреса

anonymous ()
Ответ на: комментарий от ne-vlezay

Ну а что ты там поймаешь? tg по ip ломится.
До всех этих историй с tg, я в компании просто блокировал все подсети из AS'ки telegram ltd и этого було достаточно, думаю сейчас уже нет, но вроде пользователи отучились его на рабочих пк использовать.

Deleted ()
Ответ на: комментарий от Deleted

Вот как работает TLS:

https://ru.wikipedia.org/wiki/TLS

Основные шаги процедуры создания защищённого сеанса связи:
клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера;
клиент, до начала передачи данных, проверяет валидность (аутентичность) полученного серверного сертификата, относительно имеющихся у клиента корневых сертификатов удостоверяющих центров (центров сертификации). Клиент также может проверить не отозван ли серверный сертификат, связавшись с сервисом доверенного удостоверяющего центра;
для шифрования сессии используется сеансовый ключ. Получение общего секретного сеансового ключа клиентом и сервером проводится по протоколу Диффи-Хеллмана. Существует исторический метод передачи сгенерированного клиентом секрета на сервер, при помощи шифрования асимметричной криптосистемой RSA (используется ключ из сертификата сервера). Данный метод не рекомендован, но иногда продолжает встречаться на практике.

ne-vlezay ★★★★★ ()
Последнее исправление: ne-vlezay (всего исправлений: 1)

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

anonymous ()
Ответ на: комментарий от Deleted

И каждый раз ничего не может и просит помощи у людей которым пытается заблокировать. Вот такие кадры и работают на государство, воистину нормальные люди туда не идут.

entefeed ☆☆☆ ()
Ответ на: комментарий от Deleted

Я только за сеть отвечаю, политики для ad-шки другой человек пишет. И не вахтер, пришло распоряжение сверху заблокировать.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.