Jump to content
Local
USD

как бороться с DoS на сеть провайдера?

Recommended Posts

активно досят мои ір 

тсп/удп

заяву в  кибер уже написал

кто как наблюдает/борется?

у меня софт бджп на никсе

Share this post


Link to post
Share on other sites

blackhole? 

Магистралы не хотят помогать? 

Share this post


Link to post
Share on other sites

В нульроут отправляйте у провадера черз комьюнити.

Share this post


Link to post
Share on other sites

магистрали просят ір конкретние, или ето не хотят помогать?

 

как диагностировать конкретние іп ?

Share this post


Link to post
Share on other sites

flowspec в идеале, netflow, jflow или sampling на крайний случай

Edited by LV10

Share this post


Link to post
Share on other sites
3 часа назад, USD сказал:

магистрали просят ір конкретние, или ето не хотят помогать?

 

как диагностировать конкретние іп ?

Так будет просто охренительно большой список ИПшек, и он тебе ничем не поможет. 

 

Кстати ты уверен, что это тебя ддосят, а не ты кого-то? :)

Share this post


Link to post
Share on other sites
31 минуту назад, tkapluk сказал:

Так будет просто охренительно большой список ИПшек, и он тебе ничем не поможет. 

 

Кстати ты уверен, что это тебя ддосят, а не ты кого-то? :)

1. В блекхол кидают свои іп а не чужие

2. Абсолютно, походу конкуренти развлекаются.

И спасибо по существу мне ответили више.

Share this post


Link to post
Share on other sites

При синк-флуде рандомными ойпи помогает нулроут на адрес атакуемого.  Но не на долго :))))

 

Вот примеры для атак (нейротерорризма):

 

1. DoS Land

hping3 -V -c 13666 -d 120 -S -w 32 -p 0 -s 80 --flood --rand-source VICTIM_IP_ADDRESS

 

Вот это, пожалуй, самая жестяковая атака для пионернета. Если запустить в несколько потоков ( в конце команды & и так несколько копий команд), ляжет все где бутылочные горшлыки. Все, что софвтово обрабатывает пакеты умрет на широком канале вверх по трассе :). Источник атаки можно отследить по графикам "вниз". IP атакующего не виден.  А если с разных мест, и в договорняке... уууу... жесть. 

Как бороться с этой нечестью ? :) Пфф.. только сообща :)

 

2. Smurf DoS

 

hping3 -1 --flood -a VICTIM_IP BROADCAST_ADDRESS

Тут все просто. Сканим сетку жертвы (например Angry IP Scanner), вычисляем бродкасты и лупим по ним. К примеру сеть 192.168.1.0/24, бродкаст 192.168.1.255. Лупим по нему, а он, в свою очередь отвечает арп-ами. Если комбинировать эти атаки настойчиво, то атакуемый последние волосы на жопе вырвет от злости.

 

Есть еще куча всяких рецептов по взлому, ловли на живца и тд.

Что не ясно - спрашивайте. И давайте делится опытом.

Всем удачи :)

 

 

 

Edited by loki
  • Like 2

Share this post


Link to post
Share on other sites
10 часов назад, loki сказал:

1. DoS Land

hping3 -V -c 13666 -d 120 -S -w 32 -p 0 -s 80 --flood --rand-source VICTIM_IP_ADDRESS

 

Вот это, пожалуй, самая жестяковая атака для пионернета. Если запустить в несколько потоков ( в конце команды & и так несколько копий команд), ляжет все где бутылочные горшлыки. Все, что софвтово обрабатывает пакеты умрет на широком канале вверх по трассе :). Источник атаки можно отследить по графикам "вниз". IP атакующего не виден.  А если с разных мест, и в договорняке... уууу... жесть. 

Как бороться с этой нечестью ? :) Пфф.. только сообща

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

Share this post


Link to post
Share on other sites

Обколются своей марихуаной, а потом я*** друг друга в с****!

ОБСТАВЯЦА СВАИМИ СУФТРУТЕРАМИ А ПАТОМ ПЫШУТЬ ДРУХ ДРУХУ ПАМАХИТЕ НА ФОРУМИ

НУЖНА СТАВИТЬ ЦИСКА АСР И БИГИПИ ФЛОУСПЕК С АПЛИНКАМИ БУДУВАТЬ!

 

:)

  • Haha 1

Share this post


Link to post
Share on other sites

Это если в двух слова, на самом деле защиты строятся посерьезней

Типы DDoS-атак
https://ddos-guard.net/ru/terminology
 
Защита от хакерских атак с помощью ipfw
https://www.opennet.ru/base/sec/ipfw_antihack.txt.html

На бордеры

# Запрет X-сканирования:
add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования:
add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Запрет FIN-сканирования:
add 1003 reject log tcp from any to any not established tcpflags fin
# Защита от спуфинга
add 1004 deny log ip from any to any not verrevpath in

На сервисы

# Ограничение числа одновременных соединений:
add 1005 allow ip  from any to any  setup limit src-addr 10

  • Like 3

Share this post


Link to post
Share on other sites

подскажите, а кто какое ставить ограничение на  число одновременных соединений: ?

Share this post


Link to post
Share on other sites

Если свой почтовик и конектятся клиентом, то нужно учитывать что клиент удерживает открытую сесию на каждый ящик, тут может и 20 быть и 100.

Для чужих 10 с головой.

Share this post


Link to post
Share on other sites
7 часов назад, masters сказал:

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

И много таких провайдеров по Украине? Кто у себя настроил uRPF?

Share this post


Link to post
Share on other sites

маленький пример

Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:16202 from 108.61.182.21:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 8 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:2163 from 122.129.105.169:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53

Share this post


Link to post
Share on other sites

Ну похоже на dns amplification attack.

А что такое XxXxX? Это один IP или разные или что?

Share this post


Link to post
Share on other sites
28 минут назад, USD сказал:

маленький пример

Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:16202 from 108.61.182.21:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 8 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:2163 from 122.129.105.169:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53

http://whiteglasses.livejournal.com/109620.html

Share this post


Link to post
Share on other sites
1 час назад, ttttt сказал:

А что такое XxXxX? Это один IP или разные или что?

Название хоста и его айпи. 

Share this post


Link to post
Share on other sites
6 часов назад, pavlabor сказал:

Это если в двух слова, на самом деле защиты строятся посерьезней

Типы DDoS-атак
https://ddos-guard.net/ru/terminology
 
Защита от хакерских атак с помощью ipfw
https://www.opennet.ru/base/sec/ipfw_antihack.txt.html

На бордеры

# Запрет X-сканирования:
add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования:
add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Запрет FIN-сканирования:
add 1003 reject log tcp from any to any not established tcpflags fin
# Защита от спуфинга
add 1004 deny log ip from any to any not verrevpath in

На сервисы

# Ограничение числа одновременных соединений:
add 1005 allow ip  from any to any  setup limit src-addr 10

 

 

До 3.14зды твоя теория ))).   Когда к тебе летит 1лям пакетов на 300 Мбитной ширине, то твой фаер сходит с ума  Спорим ? :)))) Твой копипастный пример с реальностью ничего общего не имеет. А на 10G полоске, нагенерить вообще такую кучу можно...

Edited by loki

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
2 часа назад, foreverok сказал:

И много таких провайдеров по Украине? Кто у себя настроил uRPF?

Те у кого руки и мозги с правильного места, и которые думают напред готовы отразить. Остальные 90% ляжут от любой детской шалости.

Share this post


Link to post
Share on other sites
31 минуту назад, ttttt сказал:

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

Чем меньше размер пакета и больше их ряд, тем хуже софтроутеру . Все ж можно руками задать. То просто пример.

Главное, найти открытый сокет от которого можно "просить" ответ :).  Поверь, больше 90% провайдеров уязвимы к примитивным и детским атакам. Все благодаря широким каналам и  теоретикам-админам.

Ааа магистралам вообще пох. Они не готовы раскошелиться на дорогие Л7 железки.

Назовите магистралов которые могут защитить ? :) И сколько это будет стоить.

 

 

Edited by loki

Share this post


Link to post
Share on other sites
10 часов назад, masters сказал:

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

Ой не смешите меня. Как эту режут ? Контролируют каждый открытый сокет на адресах  своих клиентов ? )))

Атаку произвести можно из кучи мест. В общем это. Пионервойны наступили, или не ))))?

Share this post


Link to post
Share on other sites
41 минуту назад, loki сказал:

Ой не смешите меня. Как эту режут ? Контролируют каждый открытый сокет на адресах  своих клиентов ? )))

Атаку произвести можно из кучи мест. В общем это. Пионервойны наступили, или не ))))?

Большинство нормальных магистралов не пропускают трафик от ип не анонсированные в райпе.

Этот простой прием режет 90% спуфинга.

Поэтому твое дебильное предположение "Контролируют каждый открытый сокет на адресах  своих клиентов ?", говорит о довольно глубоких познаниях которые в конце концов сводится к "перегрызть лом зубами" - "Путин введи войска", или "дяденька нужно покупать помощнее железо".

Если ты внимательно прочитаешь то что я написал, то ты увидишь что это не мои рекомендации, приложены урлы где можно прочитать статьи полностью.

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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By antiddos
      Уважаемые господа!
       
       
       
      Предлагаем Вашему вниманию сервис по защите от DDoS атак для ваших сайтов, серверов, сетей.
       
      Наша компания на рынке более 10 лет. 
      Мы представляем собой распределенную CDN с центрами фильтрации в Украине, Польше и Нидерландах.
      Наши решения построено на оборудовании Radware, Brocade, Juniper и позволяют фильтровать большие обьемы трафика. Мы работаем с любыми атаками включая L2-L7.
       
      Приглашаем к участию в партнерскую программу интеграторов и администраторов сетей, в которой вы будете получать гарантированное вознаграждение за привличенных клиентов. (условия вас приятно удивят!)
       
      Для всех желающих можем предоставить тестовую защиту на сутки. 
       
      Кроме того, для всех наших клиентов мы предоставляем услугу High Load consulting абсолютно бесплатно, как и администрирование выделенного сервера.
       
      Стоимость услуг для украинских пользователей:
      - Удаленная защита сайта без переноса контента на нашу площадку от 1000грн
      - Хостинг с защитой от DDoS от 1350грн
      - Виртуальный выделенный сервер с защитой от DDoS от 3000грн
      - Выделенный сервер с защитой от DDoS от 4000грн.
       
      Будем рады видеть Вас в числе наших клиентов. 
       
       
      Hi-Load Systems LLC
       Украина, 49000
       Днепр, ул. Казакова, 2Д
       БЦ «Континент»
       +380 68 420 0111; +380 95 420 0111
       
       
       
       
    • By pavlabor
      В 2019 году продолжаются DDoS-атаки с использованием протокола LDAP: в этот раз на сайт Qiwi
      В четверг, 24 января, мы наблюдали атаку 212,5 Gbps (гигабит в секунду) / ~10 Mpps (миллионов пакетов в секунду) в пике, комбинировавшую векторы старого доброго SYN-флуда и достаточно редкой LDAP-амплификации с фрагментами.

    • By СИОН
      Доброго времени суток коллеги.
      Такая проблема случилось...
      Взломали сеть - положили биллинг и микротик основной. 
      Также сдохло железо (программно) все что касается оборудования микротик и юбикюти. 
      Восстанавливаем уже третьи сутки.
       
      Вопрос:
      Как дальше обезопасить сеть? Какое железо и ПО преобрести чтобы упредить данные неприятные инсинуации.
      Офтоп... просьба не поддергивать и не писать нелепые сообщения, попросту помочь советом.
      Заранее спасибо.
    • By MazaXaka
      Добрий вечір форумчанам, є питання яке час від часу мучить сервер і не дає клієнтам бути щасливими.
       
      Сервер на freebsd + ubilling на борту, NAS тут же, інколи (раз в пів року або декілька разів на тиждень) "вішається" ну в сенсі не з кінцями, а до того моменту поки з нього не відключити інтернет.
      Відповідно коли таке стається фаєрволом блокуємо діапазон портів, який звужуємо методом виключення, або при можливості ідентифікуємо порт через trafshow
      наприклад в цьому випадку заблокували 61855 сервер ожив, життя прекрасне.
       
      Так от питання хто і як з цим бореться? Настройка BSD чи вище стоячого маршрутизатора/комутатора ?
×