Что нужно проделать на Debian 8.8, чтобы избавиться от Petya.A/Petya.C (Wanna Cry)?

И да, наличие VPN сервера выпускающего своих клиентов в интернет это деталь о которой стоило упомянуть гораздо раньше.

в самом верху написано же

После установки поднял VPN сервер, подключил несколько клиентов.

вот!

И эти клиенты ходят через этот VPN в интернет. Я пытался сформулировать эту мысль по саркастичней, но не получается: инфицирован один из компов использующих этот VPN, он участвует в атаке, с точки зрения остального мира это выглядит так как-будто атака идёт с твоего сервера.

как этого избежать?

Какие ещё пети в дебиане, что за бред.

Такие:

https://securelist.ru/sambacry-is-coming/30889/

сначала утверждал что проблема появляется на чистом сервере

Он же сразу написал что есть VPN

После установки поднял VPN сервер, подключил несколько клиентов

Вчера вечером я снова заказал у провайдера новую установку «Debian-88-jessie-64-LAMP». Абсолютно ничего на него не ставил. Сегодня утром с помощью команд tcpdump src port 445 и tcpdump dst port 445 увидел, что снова активно идет траффик по 445 порту.

Тогда я это неправильно понял.

ТС, сначала утверждал что проблема появляется на чистом сервере. пусть подтвердит или опровергнет.

Сегодня утром с помощью команд tcpdump src port 445 и tcpdump dst port 445 увидел, что снова активно идет траффик по 445 порту.

Еще раз вкратце повторюсь!

первым был debian minimal + VPN + smb

потом я подцепил вирус, получил жалобу

потом я установил debian minimal + VPN сервер + закрыл порты (21, 111, 135, 137, 138, 139, 445, 6851, 36082, 65448) с помощью iptables + подключил VPN клиентов к своему VPN серверу

потом я снова подцепил вирус, получил жалобу

потом я установил debian LAMP

теперь пытаюсь разобраться в ситуации на этом форуме

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

может! как этого избежать?

как этого избежать?

не пускать виндовых клиентов.

не пускать виндовых клиентов.

нельзя не пускать виндовых клиентов.

нужно придумать как «закрыть дырки» в сервере, чтобы виндовые Пети не пролазили через VPN. только вот как это сделать?

Такие

доступен ли сетевой диск на запись для неавторизованного пользователя

загруженный файл может быть исполнен в контексте процесса samba-сервера

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

Т.е. нужно быть дважды криворуким, и всё равно при перезагрузке сервера вирус перестанет работать.

чтобы виндовые Пети не пролазили через VPN. только вот как это сделать?

Много у тебя клиентов? Найди кто гадит и забань его.

Я не очень в курсе Петиных нюансов... А они не перебьются какое-то время без 445 порта по vpn, или к чему он там критичен

Вот-вот закрыть на выход 135, 445 и что-то там ещё. Но если клиенты начнут массово сканировать 80 и 443 порты, то придётся банить клиентов.

... Найди кто гадит ...

как?

я же сюда пришел за тем, чтобы узнать что делать и как делать

Вряд ли там массовое. Сначала закрыть, потом наиболее упорных ловить tcpдампом

Т.е. нужно быть дважды криворуким, и всё равно при перезагрузке сервера вирус перестанет работать.

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

Ну вот как-то так... число дважды криворуких явно больше 0.

Вот-вот закрыть на выход 135, 445

как?

и что-то там ещё.

что еще?

Сегодня утром с помощью команд tcpdump src port 445 и tcpdump dst port 445 увидел, что снова активно идет траффик по 445 порту.

я же правильно понял, что картина ниже говорит о подозрительном траффике на 445 порту?

root@Debian-88-jessie-64-LAMP ~ # tcpdump src port 445
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:26:57.638885 IP Debian-88-jessie-64-LAMP.microsoft-ds > 178.205.47.90.54926: Flags [R.], seq 0, ack 3283346194, win 0, length 0
15:26:58.197424 IP Debian-88-jessie-64-LAMP.microsoft-ds > 178.205.47.90.54926: Flags [R.], seq 0, ack 1, win 0, length 0
15:26:58.641686 IP Debian-88-jessie-64-LAMP.microsoft-ds > 45.77.79.59.vultr.com.58954: Flags [R.], seq 0, ack 311297874, win 0, length 0
15:26:59.281122 IP Debian-88-jessie-64-LAMP.microsoft-ds > 45.77.79.59.vultr.com.58954: Flags [R.], seq 0, ack 1, win 0, length 0
15:27:07.033766 IP Debian-88-jessie-64-LAMP.microsoft-ds > 211.102.90.199.50414: Flags [R.], seq 0, ack 56187656, win 0, length 0
й^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

root@Debian-88-jessie-64-LAMP ~ # tcpdump dst port 445
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:27:36.818730 IP redayhost.com.62754 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 463707649, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:27:37.471249 IP redayhost.com.62754 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 463707649, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:27:52.483958 IP 128-72-45-107.broadband.corbina.ru.52451 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 2027415972, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:27:53.030930 IP 128-72-45-107.broadband.corbina.ru.52451 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 2027415972, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:27:56.825111 IP 46-119-131-106.broadband.kyivstar.net.53308 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 517964763, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
15:27:57.354393 IP 46-119-131-106.broadband.kyivstar.net.53308 > Debian-88-jessie-64-LAMP.microsoft-ds: Flags [S], seq 517964763, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

так? или нет?

В гугель : ipyables block output ports
По второму вопросу - tcpdump
Когда юзеров много, то лучше настроить suricata + ELK, например, чтоб удобно было смотреть пакостников.

Чтоб было более удобно банить, советую openvpn с личными клиентскими сертефикатми и ведением ipp.txt.

Вот-вот закрыть на выход 135, 445 и что-то там ещё. Но если клиенты начнут массово сканировать 80 и 443 порты, то придётся банить клиентов.

Мне не очень понятен один вопрос. Как впс провайдер узнаЁт, что от ТС идет атака? по активности на 445 порту? Как он тогда узнает что атака продолжается, если она продолжится например по 80?

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

Как впс провайдер узнаЁт, что от ТС идет атака? по активности на 445 порту?

когда провайдер видит, что мой комп стучится на кучу компов в Китае, Индонезии и т. д. на 445 порт, это как минимум подозрительно...

Как он тогда узнает что атака продолжается, если она продолжится например по 80?

в данной ситуации вирус пользуется уязвимостью smb протокола, который по умолчанию на 445 порту, а не на 80

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

Годная толстота поменяй пароль root и запрети root доступ по ssh

в данной ситуации вирус пользуется уязвимостью smb протокола, который по умолчанию на 445 порту, а не на 80

Я так понял что по smb протоколу он распространяется, а заражается по любому из. Тогда 445-го вам хватит чтобы просто успокоить для начала своего хостера, а потом разбираться не торопясь

Wed Jun 28 16:19:59 2017 TCP [ip_moego_servera] 55347 => >3.18.50.252 445

так заблокируйте 445 порт для vpn
проверяйте, что там у вас в правилах файрвола (iptables -L) нагорожено

советую openvpn с личными клиентскими сертефикатми и ведением ipp.txt.

openvpn это хорошо, но требует установки ПО для него клиентам. использую его в других целях на других системах

так заблокируйте 445 порт для vpn

Делал так:

iptables -A INPUT -p tcp --dport 445 -j DROP
iptables -A INPUT -p udp --dport 445 -j DROP

не прокатило, значит вот так:

iptables -A INPUT -p tcp --dport 445 -j DROP
iptables -A INPUT -p udp --dport 445 -j DROP

iptables -A OUTPUT -p tcp --dport 445 -j DROP
iptables -A OUTPUT -p udp --dport 445 -j DROP

я Вас правильно понял?

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

как я понял ответ где-то здесь

блокируй порты в цепочке FORWARDблокируй порты в цепочке FORWARD

iptables -A FORWARD -p tcp --dport 445 -j DROP
iptables -A FORWARD -p udp --dport 445 -j DROP

так?

да, почитать не помешает
однако будет полезнее почитать man iptables и man iptables-extensions
а сейчас стоит сделать

iptables -A FORWARD -p tcp --dport 445 -j DROP
iptables -A FORWARD -p udp --dport 445 -j DROP

вряд ли vpn поднимался ради самбы

это точно!

да и вообще наверно имеет смысл выпускать только 80 и 443.

накатывал такую (см. выше) но посте установки VPN сервера и подключения к нему клиентов - снова пришла жалоба...

А если виндос-клиенты не подключать, жалобы есть?

Знаю такого товарища, у которого пароли рута сперли.

Ребят, а можно ли заразиться, если samba установлен и запущен, но все вх. порты относящиеся к самбе закрыты?

Что нужно проделать на Debian 8.8, чтобы избавиться от Petya.A/Petya.C (Wanna Cry)?

Патч Бармина.

Вот была таже фигня, прешлось все перепиливать с одной штукой. Поставь Обновление для Samba вручную

Можно

Можно

... а можно ли заразиться, если samba НЕ устанавливался после установки ОС + все порты относящиеся к самбе закрыты?

Патч Бармина.

Сделал - не помогло :)

После установки поднял VPN сервер, подключил несколько клиентов.

Действительно, откуда?

Это шутка? Каким образом?

Здравствуйте!

Интересно, а что пишут антивирусы rkhunter и ClamAV? :-)

Скорее всего нет

iptables -A FORWARD уж тогда, VPN ведь.

Здравствуйте!

Топикстартера или посадили в тюрьму или выгнали с работы. Одно из двух... :-)

Для цепочек FORWARD, INPUT и OUTPUT закрыл TCP-порты и UDP-порты 1024-1035, 135, 139 и 445.

ждемс...

Ты не в курсе, через какую уязвимость ломают? Предыдущая была датирована мартом 2017 года. А то у меня системы обновлены в мае, вдруг уязвимы?