Pull to refresh

Comments 83

Последние тенденции парольной аутентификации — в отказе от требования регулярной смены паролей и требований сложности. Менять пароли следует в случае подозрения в компрометации, а не на регулярной основе.
Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.

Смена порта SSH давно считается бесполезной техникой и даже вредной

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

К примеру у меня на digitalocean настроено так, и никакого спама нет.

Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.
Как-то вы делаете вывод на основании одного очень частного случая. Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест? Да еще с динамическим ip (с мобильного, например). Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения. Был 22 — стал 1723.
Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест?

В моём случае SSH, OpenVPN и Nginx повешены на 443 порт с мультиплексированием через sslh. Потому что при поездках, особенно в Китай, другой возможности достучаться до сервера просто нет.


Мусор в логах проблемой не считаю.

Воспользоватья прокси или VPN.


Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.


То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.


Также используются bastion (gateway) хосты.


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

Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.

Да никто не спорит что два забора надежнее чем один. Проблема тут в том, что мы вынуждены строить второй забор там, где он не всегда нужен, а достаточно было бы перекрасить первый забор в другой цвет.
Факт: SSH auth спам не остановится после изменения порта.

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

И всякие 0day идут мимо.
Факт: остановится.

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

согласен.


В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.


Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.


Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.

На уровне фаерволла есть волшебный connlimit — больше N соединений с одного ip-ника в минуту — шагом марш в ipset бан.

Китайские боты — распределённая система и обычно брутфорсят с разных IP. Кстати, fail2ban и подобные не умеют случаем добавлять не IP, а подсеть этого IP с заданным префиксом?

fail2ban, насколько понимаю, не умеет использовать ipset. Так что там при росте числа «запрещённых» скорость работы всей системы может ощутимо замедлиться.
Научилась, значит. Тем проще, меньше велосипедов изобретать.
может, если использовать ipset + поменять тип ipset на net и добавить префикс в настройках действия
1. При ограничении доступа по айпи/сетям вы не сможете срочно подключиться к серверу из поездки с телефона, например. Либо сложно определить весь пул подсетей у некоторых операторов, а при переподключении к интернету у вас вдруг может смениться сеть.
2. Смена порта на другой, выше нескольких тысяч, например 33333, уменьшает количество желающих подключиться к вашему серверу на порядки. Следил за этим с помощью denyhosts, он присылал письма.
3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts. У последнего вообще существует система обмена забаненными, которая у вас автоматом банит тех, кто массово подбирает пароли на других серверах, в других странах.
1. Для этого всегда должны быть «Jump host». Следить за ними намного проще, чем за тысячами vps/ec2, на которые не заходишь годами. Jump host в своюб очередь можно так же закрыть фаерволом, а доступ к нему получать исключительно через vpn.
2. Не помогает ни как, если атака нацелена специально на вас.
3. В некоторых случаях, которые появлялись уже неоднократно, достаточно одного раза. Но штука полезная, если нет других вариантов.
Вы что советуете!? Нельзя давать сервисам порты выше 32к, там начинается диапазон эфимерных портов! При удачном стечении останитесь без сервиса.
Подкрутить /proc/sys/net/ipv4/ip_local_port_range и всего делов-то.
Во-первых, комментарий не содержал даже намёка на то, что надо еще крутить, из чего совершенно очевидно, что комментатор про проблему не знает.
Во-вторых, никто не говорил, что этот диапазон нельзя менять. Но это очевидно плохая практика и совершенно бездумный совет.
3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts.

Это у которого сайт не обновлялся 5 лет, а новых релизов не выходило 10 лет?
Там что-то явно случилось с проектом:
stats.denyhosts.net/stats.html

Отвечу цитатой:


changing the SSH port from 22 to another port is basically "security by obscurity" and only carries with it minimal advantages.
The main advantage is less botnet/automated traffic will come in on port 22 looking to run SSH attacks. However, it is fairly trivial for a real attacker, or a botnet with a more astute programmer running it; to run a port scan against all the ports. Port 20,000 (or whatever number) will clearly respond with an SSH handshake, and thus they'll try attacks on that port. End of security advantages.

Если вы никому сильно не интересны то смена порта вам уменьшит кол-во мусора в логах.
В противном случае без применения остальных рекомендаций ваш порт с SSH найдут за 5 секунд.

Смена порта SSH давно считается бесполезной техникой и даже вредной
Можно поподробнее насчёт «вредности»?

Лишнее неудобство, если хостов в хозяйстве значительно больше чем 1, и все зачем-то на разных портах. Немного меньше спама в логах — вот и весь профит.

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

Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)? Администраторов больше чем один?
Настройки подключения клиент запомнит, да. Но все равно хранение дополнительной информации добавляет забот в первую очередь администратору. Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT. Можно пойти дальше, логиниться на каждый сервер с уникальным $LOGIN и уникальным $SSH_KEY. Но зачем, если есть и более удобные менее неудобные способы.

Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)?

Синхронизация? Нет, не слышал.
Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT.

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

Расскажите про синхронизацию паролей между windows-linux-android-macos ;).
Все, конечно же, решаемо. Но для ssh давно придуман доступ по ключу. Да и ваши несловарные пароли подобрать невозможно. Так какой же профит в смене порта?

Расскажите про синхронизацию паролей между windows-linux-android-macos ;).

Я юзаю KeePass, мне между windows-android хватает, но клиенты есть и под другие ОС.
Но для ssh давно придуман доступ по ключу.

Который тоже можно хранить в менеджере.
Так какой же профит в смене порта?

Отвечу вашими же словами
Немного меньше спама в логах — вот и весь профит.
«Немного меньше спама в логах — вот и весь профит»
А этого мало?

все зачем-то на разных портах

А зачем всё на разныз портах? Наша задача убрать автоматические долбилки, профита от того, что у нас все SSHки будут висеть на уникальных портах — никакого. Порт должен быть уникальным, но в рамках нашего решения, а не в прицнипе.
Наша задача убрать автоматические долбилки

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

В 2017 году iptables с -j DROP утратил актуальность?
Универсальных рецептов на все случаи жизни не существует, да.

Немного меньше спама в логах — вот и весь профит.
Нет, не весь. Сейчас я расскажу Вам про ещё один. Помните WannaCry? Он распространялся через зиродей уязвимость в протоколе SMB (TCP-порт 445). Подобная уязвимость вполне может существовать и в протоколе SSH. Через N дней/месяцев/лет какой-нибудь Джон До может обнаружить её и нацарапать новый WannaCry для SSH, который будет сканировать весь диапазон IP-адресов и ломиться во все открытые порты 22. Про результат, думаю, рассказывать не надо. Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.
Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.

Возможно. Но после первой волны (по стандартному порту) обязательно будет вторая, которая будет шарашить прицельно, и не факт, что к тому времени ваш секретный порт не будет никому неинтересен. Зато у вас будет иллюзия безопасности: "никакие боты к нам не ломятся, можно раслабиться, мы в домике". А еще могут изобрести квантовый компьютер на 100500 кубит, и все RSA ключи превратятся в тыкву…

После первой волны будет время на обновление.
если джон доу достаточно умен чтоб нацарать 0-day exploit для ssh то думаю у него хватит мозгов дописать функцию поиска ssh порта на атакуемой машине
наглое сканирование портов довольно быстро пресекается автоматикой.
Не то, что я За смену потрта ssh, но вот со сканом не все так просто.
1) Скан портов не нужен — зачем палится лишними действиям, если полно компов с стандартными портами?
2) скан можно задетектить и забанить еще до его окончания. Хотя злоумышленник и может продолжить сканирование с нового IP, но это всё равно будет медленней и сложнее. Что уменьшает вероятность.
It depends.

Вариант применения: слушать попытки соединения по стандартному порту и «тестировщиков» таких сразу отправлять на временный бан, тем же ipset.

Большую часть горе-хакеров или порт-сканнеров подобной методикой удаётся быстро и автоматически изолировать. Меньше сору, меньше вздору.
вы бегите подальше из тех мест, где так считается (и не слушайте тех, кто из тех мест)

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

я надеюсь, вы понимаете, что прямой корреляции между «уметь сменить порт» и «не уметь запретить парольную аутентификацию» нет, более того, существует обратная? если бы вы как я и многие коллеги в этом треде анализировали логи множества разных серверов на протяжении нескольких лет, то знали бы, что смена порта снижает количество неудачных попыток входа по ssh в тысячи, иногда десятки тысяч раз. ну а если бы вы вламывались в чужие системы (сам я конечно так не делал, но вот один друг рассказывал...), то знали бы как усложняет жизнь нестандартный порт (сканы nmap-ом в духе -p1-65535 о-о-о-чень затягиваются по сравнению с обычными)
Да не существует обратной. Из моей довольно немалой практики, там где изменён порт всё настроено совершенно наивно и безграмотно, практически всегда, увы…
И если вам и придётся потратить немножко времени на автоматизированный скан портов (кстати, до 65536 и, не надо, обычно, 2022, 3022 и немного дальше можно просканить, а потом, и подробнее уже если случайно там была фантазия), то потом будет куда проще в остальном. =)
Я тоже думал насчёт ограничения доступа к компиляторам. Утилита lynis, к примеру, предлагает это делать.

Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.

firewalld — это не замена iptables. Это интерфейс к iptables.

Некоторые предпочитают файрвол iptables файрволу firewalld

Это неверно. Что iptables что firewalld всего лишь надстройки над netfilter который и является фаерволом.
firewalld это надстройка над iptables, который надстройка над netfilter…
Правда, firewalld еще и надстройка над ipset…

cracklib же проверяет пароль на наличие его в словаре, который с собой носит. Это в лучшем случае вторичная мера. Лучше использовать passwdqc или pwquality. Я думал, что в rh пользуются именно pwquality.

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

Вполне актуален, когда стоит задача скрыть сам факт наличия каких-то служб на сервере. Существуют современные реализации, открывающие порт по UDP-пакету с HMAC-подписью общего ключа, времени и команды открытия порта: linuxsecurity.expert/tools/pyknock

В таком виде эту технику можно использовать как альтернативу вписывания всех доверенных хостов в список разрешённых в файрволе — пусть они прокладывают себе путь сами.
А почему не вспомнили про старый добрый TCP Wrappers?
/etc/hosts.allow
sshd: $some_trusted_IP: allow
sshd: 127.0.0.1: allow
sshd: ALL: deny
И не надо никуда порт SSH перевешывать

И еще, по мне идея использовать гуглоаутентификацию для SSH так себе затея, а вдруг Интернета не будет? Надо наверное держать одноразовые пароли на этот случай на бумажке все равно?

гугло-аутентификатору интернет не нужен — он по часам работает
Вы без интернета куда коннектится будите кстати? на соседний комп разве что.

В этой стране внезапно можно оказаться в интранете этой страны.

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

Google Authenticator'у не нужен инет, если не ошибаюсь.
Не ошибаетесь, не нужен. Нужна только точная синхронизация времени. См. TOTP
Там даже не очень точная нужна, в пределах 30 секунд. Конкретно этот аутентификатор можно настроить на ещё более грубые пределы.
опять 25: запрет входа root'ом не делает систему безопаснее, ну не делает и всё. эта рекомендация имеет очень простую основу: если злоумышленник знает имя пользователя (а root универсален для большинства систем), то ему нужно подобрать только пароль, а если не знает, то и то, и другое (что существенно увеличивает количество возможных комбинаций). вот только ключи (или билетики кербероса например) подобрать невозможно (в общем случае), а разрешение парольной аутентификации через ssh (или оставление разрешения по умолчанию) вопрос о безопасности в принципе снимает.
Если у сервера несколько администраторов, запрет входа под рутом персонализирует любые действия. Логин рута, при этом, полезно записать на бумажке, запечатать в конверт и убрать в сейф. На случай, если все эти администраторы однажды будут ехать в одном автобусе и решат, что там, куда он едет — лучше, чем на работе.
всё верно, «догнать концы» по имени пользователя проще, чем по ip, вот только это разговор об ответственности и профпригодности (если сотрудник профессионал, то все работы будут согласованы с начальством, а обо всех косяках будет сразу доложено, и поиски будут не нужны), а не о безопасности (тема статьи)
UFO landed and left these words here

Ребята, стыдно такое переводить.
Да, относительно перевода, только одно режет слух:


Firewalld — это замена для iptables, данная программа улучшает сетевую безопасность Linux.
слово "программа", лучше сказать, например, "проект".

Но, сама статья, технически слабая.
Например, мои претензии к оригиналу:


Port 5555

Ну, ок поменяли, а "ssh_port_t tcp 22" остался на месте? рестартнем sshd и… о забыли про selinux?


wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
$ rpm -ivh epel-release-7-9.noarch.rpm

wget, а почему не курл? ну то такое, НО почему не HTTPS?
А вообще есть вот что: https://lists.centos.org/pipermail/centos-announce/2014-September/020526.html
ДА, просто yum install epel-release -y !


Для начала выведите список всех бинарных файлов компиляторов из пакетов,
а затем установите для них разрешения:
rpm -q --filesbypkg gcc | grep 'bin'

Всех Бинарныйх? Или исполняемых???
Исполняемые, можно найти так:
rpm -qlv gcc | grep ^-rwx


$ groupadd compilerGroup
$ chown root:compilerGroup /usr/bin/gcc
$ chmod 0750 /usr/bin/gcc

$ — это что, от юзера? Ну да, может быть… у автора…
Ладно, а что будет после очередного обновления пакетов? Наша песня хороша, начинай с начала?
Да и вообще, зачем прод серверах компоненты для сборки?

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

По поводу ключей, спор сродни тупоконечникам и остроконечникам: в отличие от пароля, ключ, с одной стороны, нельзя подобрать. Но с другой стороны, вы должны понимать, что ваш компьютер внезапно становится универсальным средством доступа к серверу. А многие ли из вас ставят пароль на сам ключ?.. Так, что хороший пароль ненамного хуже ключа. А лучше, когда аутентификация двухфакторная: есть ключ, но на sudo будь добр пароль.

А ещё про ключи довольно часто забывают. Вот недавно нашел сервер, где администратор, чтобы упростить себе жизнь, засунул свои ключи прямо в /root/.ssh (и, соответственно, разрешил доступ руту по ssh). Давно ушел тот администратор, пользователя ему отключили, а вот проверить, не остались ли где его ключи, никто не догадался. А потом инцидент с доступом рута и вот думай — то ли есть какой нибудь 0-day на повышение привилегий, то ли ключик спёрли.

Вот мой однострочник для проверки имеющихся ключей

find / -name authorized_keys | perl -nae 'chomp; print "$_ "; $a = `cat $_`; while ($a =~ /[^ ]+ ([^\s]+)\n(.*)/){print "$1\n";$a=$2}'


Показывает пути к файлам с ключами и имена@хосты внутри.
Интересно, вот только сегодня с коллегами обсуждали =)
Ключи лучше не только, что их не подобрать, но ещё и не собрать коллекцию логинов, подменив sshd на взломанном сервере.
А пароль на ключ должен быть обязательно, это не обсуждается даже.

Кстати, 2FA через google auth при авторизации по ключу — не запрашивает код аутентификатора. Только если входить по паролю. Так что статья не корректа еще и в этом плане.
Одно «но»: имя@хост в конце ключа может не иметь к реальному происхождению и/или использованию ключа никакого отношения. А так да, удобный поиск.
Занятно! Особенно про Sudo и отправку на почту, я как то и не задумывался о таком. Хорошая мысля приходит как всегда...=)
Отлично, парни! Спасибо! Обязательно у себя сделаю.
Когда серверов штук 500, некоторые пункты меняются.
Не написано про fail2ban.
UFO landed and left these words here
Увольте копирайтера, читать глаза болят. Особенно про «терминалы». Называть tty терминалом — это круто.
WEB-хостинг. Куча клиентов + разработчикам надо ходить под разными аккаунтами (не даю я им под рутом ничего делать ибо нефиг). Соответственно отрубить авторизацию по паролю — не вариант. Просто добавить доступ по ключу — не вижу смысла. Приведённые выше несловарные пароли запоминаю довольно быстро считая необходимой проф.деформацией.
Сделал так: SSH на нестандартном порту + fail2ban. Факты: после смены порта автоматические долбилки отвалились. После установки fail2ban логи стали заметно чище. Профит в том, что теперь анализ логов стал проще. А когда тебе по нескольку раз в день нужно получать ответ на вопрос «кто откуда и зачем заходил?» профит считаю жирным лично для себя.
Астериски в других компаниях\домашний медиа-сервер — порт перенесён, fail2ban, на роутере правила ограничивающие доступ только с определённых IP. Ну глупости это — пытаться с телефона в поездке что-то там поадминить (интернет не стабильный, экран маленький, входящий звонок невовремя). На крайний случай должен быть человек в офисе\дома который ответит на звонок и всё сделает точно как сказано. А если такого человека нет, то в целом не так всё важно, чтобы не потерпеть несколько часов пока вы доберётесь до удобного рабочего места, подключитесь к офисной сети и всё сделаете как белый человек с большим монитором, клавиатурой и чашкой кофе.
И да, пароль на ключ — обязателен т.к. ваш ключ могут просто украсть.
анализ логов стал проще

Если логи читает человек — да, меньше логов — проще читать. Анализатору все равно.


по нескольку раз в день нужно получать ответ на вопрос «кто откуда и зачем заходил?»

IDS с этим вопросом справится лучше.

iig: спасибо! Некоторое время назад искал детектор атак, наткнулся на Suricata, но не осилил понять что это и как правильно использовать. Сейчас вдумчиво прочитал пару мануалов и описаний — прикольная вещь. Попробую. А то каждый раз одно и тоже:
— Алло! У нас сайт уже неделю не работает из-за вас!
— Минуту… Вчера работал — сами проверяли и с ним работали.
И в конце выясняется, что клиент зашёл, ничего не делал (а чего заходил?..) и оно само. Но все уже успели свою порцию пинков от руководства получить. Студия маленькая, пинки долетают быстро :-(
У нас сайт уже неделю не работает из-за вас!

nagios же.

Nagios пасёт весь сервер в целом и не в курсе, что где-то какой-то баннер съехал или кусок текста пропал. Так-то все страницы отдают нормальный код 200. Но для большинства заказчиков нет разницы между кодами 200 и поехал текст или 4XX\5XX. Для них всё просто: выглядит не так как ожидалось = сайт не работает. Причём время у них так-же идёт как то иначе. Например при обновлении движка надо сайт временно перевести в режим обслуживания. Ответственному со стороны заказчика сообщили о времени проведения процедуры, оно забыло сообщить своему руководству. Процедура прошла штатно и потребовала минуты 3. Но под конец этих 3 минут будет звонок и вопли, что уже несколько дней сайт не работает от слова «совсем».

Немного капитанства ;).
Административные проблемы должны решаться административными способами.
В договоре с клиентом что-то написано про порядок выполнения регламентных работ?

Конечно написано. Конечно мы их проводим в нерабочее время и обязательно предупреждаем о тои, что будем делать то и это и по времени столько. Но как уже писалось выше — взаимодействуем мы со старшим помощником младшего заместители ИО директора по развитию. А звонит нам генеральный директор. Ну есть у них такая привычка — сидеть на своём сайте и в случае чего звонить не своему сотруднику который непосредственно отвечает за развитие сайта, а нашему генеральному. А тот соответственно так-же не всегда в курсе на каком сайте что делается и разговор выглядит так как писалось выше. К сожалению в небольших городах у небольших студий работающих с не самыми крупными клиентами есть вполне себе крупные проблемы создаваемые на пустом месте именно клиентами. Поэтому к вопросам контроля за действиями клиента требования повышенные чтобы хоть на штрафы и скандалы не попадать.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
ruvds.com
Employees
11–30 employees
Registered
Representative
ruvds

Habr blog