Оплата услуг VDSina зарубежной картой



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

Мы подключили оплату зарубежными картами(Европа и Азия) через Яндекс.кассу. Для оплаты услуг с зарубежной карты используйте способ оплаты «Банковская карта» в личном кабинете.

Исключительным методом борьбы со сложившемся мировым экономическим кризисом является тариф Вечный. Обезопась себя и своих друзей от всех непредвиденных ситуаций — плати один раз и пользуйся ВЕЧНО vdsina.ru/eternal-server

С уважением, VDSina.ru

Читайте нас в социальных сетях twitter.com/vdsina и vk.com/vdsina

Обещали и сделали миграцию серверов между дата-центрами

1. Создаём резервную копию сервера в текущем дата-центре
2. Копируем резервную копию в другой дата-центр
3. Создаём сервер в другом дата-центре из скопированной копии
4. КАЙФ



https://vdsina.ru/

СЕНСАЦИЯ!!! Хостинг вселенского масштаба VDSina.ru шагнул в новое измерение!



Мы с нескрываемым энтузиазмом и практически в оргазме представляем самый значимый в мире тариф ВЕЧНЫЙ!!!

11 340 руб / 2 ГБ RAM / 2 core / 40 ГБ NVMe
vdsina.ru/pricing/eternal-server
vdsina.ru/?partner=1374

Итоги: 9 главных технологических прорывов 2019 года

На связи Александр Чистяков, я евангелист vdsina.ru и расскажу про 9 лучших технологических событий 2019 года.

В оценке я больше полагался на свой вкус, чем на мнение экспертов. Поэтому в этот список, например, не вошли беспилотные автомобили, потому что ничего принципиально нового и удивительного в этой технологии нет.

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

1. Переносимые серверные приложения на языке программирования Rust под WebAssembly
Я начну обзор с двух докладов:
1. Доклад Брайана Кантрилла “Время переписать ОС на Rust?”, прочитанный им ещё в 2018-м.
На момент прочтения доклада, Брайан Кантрилл работал в компании Joyent на позиции CTO и еще не догадывался, чем закончится для него и Joyent 2019-й.

2. Доклад Стива Клабника, члена core team языка Rust и автора книги “The Rust Programming Language”, работающего в Cloudflare, где он рассказывает об особенностях языка Rust и технологии WebAssembly, позволяющей использовать веб-браузеры как платформы для запуска приложений.

В 2019-ом WebAssembly со своим интерфейсом WASI, предоставляющим доступ к объектам операционной системы, такими, как файлы и сокеты, шагнула за рамки браузеров и нацеливается на рынок серверного программного обеспечения.

Суть прорыва очевидна — у человечества появляется еще один рантайм, способный запускать переносимые приложения для Web (кто-нибудь помнит принцип WORA, придуманный еще авторами языка Java?).

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

WebAssembly настолько переворачивает игру, что Соломон Хайкс, один из создателей Docker, писал о том, что, если бы WebAssembly и WASI существовали в 2008-м, Docker бы просто не родился.


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

Это слайд из доклада Стива, который наглядно показывает соотношение числа ошибок безопасности, которых целиком можно избежать при использовании Rust к общему числу ошибок в MS Windows, найденных за последние полтора десятилетия.


Компания Microsoft должна была как-то ответить на такой вызов, и она ответила.

2. Project Verona от Microsoft, который спасет Windows и откроет новую страницу истории для любой ОС

Количество ошибок в ядре Microsoft Windows и большинстве пользовательских программ почти линейно увеличивалось в течение последних 12 лет.


В 2019 Мэтью Паркинсон из Microsoft представил публике Project Verona, который может положить этому конец.

Это инициатива Microsoft по созданию безопасного языка программирования, основанного на идеях языка Rust: коллеги из Microsoft Research выяснили, что большинство проблем с безопасностью связано с тяжелым наследием языка C, на котором написана большая часть Windows. Rust-подобный язык Verona управляет памятью и конкурентным доступом к ресурсам, используя принцип абстракций с нулевой стоимостью. Если вы хотите подробно разобраться, как он работает, просмотрите доклад самого Паркинсона.

Интересно, что компанию Microsoft традиционно воспринимают как империю зла и противника всего нового, несмотря на то, что Саймон Пейтон-Джонс, основной разработчик Glasgow Haskell Compiler, работает именно в Microsoft.


Вопрос Брайана Кантрилла из первого пункта: “не пора ли переписать ядро операционной системы на Rust?” получил неожиданный ответ — очевидно, что ядро операционной системы переписать пока невозможно, но программы, работающие в userspace, уже переписываются. Начался неостановимый процесс, и это откроет новую страницу будущего для всех операционных систем.

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

Я использую свой метод оценки популярности языков программирования при помощи анализа репозиториев на Github, раз в месяц обновляя данные в таблице. Если в начале года популярных репозиториев на Dart было всего 100, то сегодня их уже 313.

Dart обогнал по популярности Erlang, PowerShell, R, Perl, Elixir, Haskell, Lua и CoffeeScript. Быстрее, кажется, в этом году не рос ни один другой язык программирования. Почему так произошло?

Один из знаковых докладов этого года по версии аудитории HackerNews был прочитан Ричардом Фельдманом и назывался “Почему функциональное программирование не является нормой?” Значительная часть доклада посвящена анализу того, каким образом языки программирования становятся популярными. Одна из основных причин, по версии Ричарда — наличие популярного приложения или фреймворка, иначе говоря the killer app.

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


Мы ничего не знаем про Dart, так как не занимаемся мобильной разработкой, но горячо приветствуем еще один язык программирования со статической типизацией.

4. Шанс на выживание ядра Linux и его коммьюнити благодаря вирутальной машине eBPF

Мы в VDSina любим конференции: в этом году я ездил на конференции DevOops в Санкт-Петербурге и участвовал в круглом столе, посвященном трендам и горячим штучкам в индустрии. В 2019-м в таких разговорах лидировали мнения:
  • Docker мертв, потому что слишком скучен
  • Kubernetes жив и протянет где-то год — о нём ещё будут говорить на конференциях в 2020 году
  • тем временем, в ядро Linux никто из живых людей не заглядывает уже давно

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




Благодаря eBPF, ядро теперь сообщает о наступлении событий, которые можно частично обрабатывать вне ядра — интерфейс дает возможность безопасно и эффективно взаимодействовать с ядром из userspace и расширять и дополнять функциональность ядра Linux, минуя всевидящее око Линуса Торвальдса.

До eBPF разработка программ, деятельность которых тесно связана с взаимодействием с ядром Linux была непростой историей — для создания вещей вроде драйверов не очень быстрых устройств и интерфейсов для файловых систем в userspace требовалось проходить формальную процедуру review опытными разработчиками ядра Linux.

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

Я не одинок в своем энтузиазме: разработчик ядра с многолетним стажем Дэвид Миллер декларирует важность eBPF для выживания (!) экосистемы разработки ядра. Другой, не менее известный разработчик Брендан Грегг (я его большой фанат) называет eBPF прорывом, равного которому не было 50 лет.

Тем временем Линус Торвальдс за подобное обычно публично не хвалит и я могу его понять — кому хочется публично выставлять себя идиотом? :)


5. Linux забил почти последний гвоздь в гроб FreeBSD благодаря асинхронному интерфейсу io_uring в ядре Linux

Раз уж речь зашла о ядре Linux, необходимо отметить и другое значительное улучшение, происшедшее в этом году: включение в ядро нового высокопроизводительного асинхронного API ввода/вывода io_uring за авторством Дженса Эксбоу из Facebook.

Много лет системные администраторы и разработчики под FreeBSD обосновывали свой выбор фактом, что во FreeBSD асинхронный ввод-вывод был сделан лучше, чем в Linux. Например, этот аргумент использовал в своем докладе в 2014-ом году Глеб Смирнов из Nginx.

Теперь игра перевернулась. На использование io_uring уже перешла распределённая файловая система Ceph и результаты тестов производительности впечатляют — рост количества операций ввода/вывода в секунду составляет от 14% до 102% в зависимости от размера блока. Существует прототип, использующий асинхронный ввод-вывод в PostgreSQL (по крайней мере, для background writer), запланированы дальнейшие работы по переводу PostgreSQL на асинхронный ввод-вывод. Но учитывая консервативность сообщества разработчиков, в 2020-м эти изменения мы еще не увидим.


6. Триумфальное возвращение компании AMD с линейкой процессоров Ryzen
Ничего необычного, просто компания AMD, долгое время бывшая в индустрии на вторых ролях, бьёт рекорд за рекордом.

Новая линейка процессоров Ryzen показала невероятное соотношение цена/производительность: они доминируют в списке самых продаваемых процессоров на Amazon, а в некоторых регионах продажи процессоров AMD превысили продажи Intel. В конкурентной борьбе Intel вынуждена идти на крайне непопулярные меры: заставляет программы, созданные при помощи их собственного компилятора, работать менее эффективно на процессорах конкурента. Несмотря на грязные способы борьбы Intel, рыночная оценка AMD вплотную приблизилась к рекордным значениям 2000-го года.

7. Вслед за AMD, Apple целится откусить кусок пирога Intel с помощью iPadOS и старых уловок Гейтса

В битвах гигантов обычно пытаются участвовать все, кто может держать в руках оружие, и на кормовую базу Intel претендует не только компания AMD. Компания Apple повела себя как старый бык из анекдота.

Выпустив новый iPadOS, Apple использовала против Intel тактику, которая называется “disruptive innovation” — подрывные инновации.

Определение Википедии

«Подрывные инновации» (англ. Disruptive innovation) — инновации, которые изменяют соотношение ценностей на рынке. При этом старые продукты становятся неконкурентоспособными просто потому, что параметры, на основе которых раньше проходила конкуренция, теряют свое значение.

Примерами «подрывных инноваций» являются телефон (заменил телеграф), пароходы (заменили парусные суда), полупроводники (заменили электровакуумные приборы), цифровые камеры (заменили пленочные), электронная почта («подорвала» традиционную почту).

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

Apple успевает урвать часть рынка, превращая iPad из терминала для развлечений в полноценный рабочий инструмент — сначала для тех, кто создает контент, а теперь и для разработчиков. Конечно, в ближайшее время мы не увидим MacBook на базе ARM, но маленькие неприятности с дизайном клавиатур MacBook Pro способствуют поиску альтернативных решений и одним из них обещает стать iPad Pro с iPadOS.

Причем тут Гейтс и Microsoft?

В свое время Гейтс провернул точно такой же трюк с IBM.

В 1970-х IBM доминировал на рынке серверов, с уверенностью гиганта не обращая внимания на персональные компьютеры для обывателей. В 1980-х Гейтс создает на деньги IBM и лицензирует для него MS-DOS, оставляя права на операционную систему на себя. Получив деньги, Microsoft создает под MS-DOS графический интерфейс, и рождается Windows — сначала просто графическая надстройка над DOS, а потом и первая операционная система под PC, удобная для использования широкими массами. IBM, будучи большой неповоротливой компанией проигрывает рынок персональных компьютеров молодой и быстрой Microsoft. Я очень кратко пересказал эту замечательную историю, поэтому если вам интересно, как в 2020-ом Apple будет играть против Intel с помощью iPadOS, очень рекомендую прочитать её целиком.

8. Укрепление позиций ZFSonLinux — старый конь борозды не портит
Компания Canonical представила возможность установки Ubuntu с использованием файловой системы ZFS в качестве root file system прямо из инсталлятора. Иногда мне кажется, что инженеры, работавшие в Sun Microsystems, представляют собой отдельный биологический вид человека разумного (уже упоминавшиеся выше Брайан Кантрилл и Брендан Грегг работали в Sun). Посудите сами, несмотря на многолетние попытки всего человечества сделать что-то, хотя бы, отдаленно похожее на файловую систему ZFS, несмотря на неразрешимые лицензионные ограничения, препятствующие включению исходного кода ZFS в основную ветку разработки ядра Linux, мы все еще используем ZFS, и в ближайшее время ситуация не изменится.

9. Oxide Computer Company — мы будем пристально следить за командой, которая явно способна на многое — как минимум, создать крутое шоу
Я завершаю свой список новым упоминанием Брайана Кантрилла, с которого я и начал.

Брайан Кантрилл с другими инженерами (некоторые из которых тоже раньше работали в Sun) основал предприятие под названием Oxide Computer Company, основная цель которого — создание серверной платформы, пригодной для использования в больших масштабах. Известно, что очень большие корпорации, такие как Google, Facebook и Amazon, не используют в своей деятельности обычное серверное железо. Компания Брайана призвана устранить это неравенство, разработав программно-аппаратную платформу, пригодную для использования любым облачным сервисом (не обойдется и без языка программирования Rust).

Их задумка — обещание новой революции, и я буду, как минимум, с удовольствием наблюдать за движением их мысли и их разработкой в грядущем 2020 году.

Что мы успели сделать в 2019 в VDSina
Технологических прорывов в 2019 с VDSina мы не делали, но нам все равно есть, чем гордиться.

В феврале мы добавили возможность использовать локальную сеть между серверами и запустили услугу регистрации доменов. Цену сделали одной из самых низких на рынке — 179 руб за ru/рф, в том числе и за продление.

В марте выступили на IT Global Meetup #14.

В апреле увеличили ширину канала для каждого сервера с 100 до 200 Мегабит, значительно увеличили лимит трафика для всех тарифов (кроме самого дешёвого) — до 32 ТБ в месяц.

В июле у клиентов появилась возможность автоматически устанавливать Windows Server 2019. В пределах московской локации начали предоставлять бесплатную защиту от DDoS.
Также в июле наша компания появилась на Хабре, дебютировав статьей, как мы написали собственную панель управления хостингом и как это помогло нам сделать качественный скачок в поддержке клиентов.

В августе добавили возможность создавать снимки — резервные копии серверов.
Выкатили публичный API.
Увеличили ширину канала для каждого сервера с 200 до 500 Мегабит.
Участвовали в конференции Chaos Constructions 2019, раздав в качестве мерча плётки с логотипом компании (слоган кампании был “Когда разработчик сверху”) и взорвали телеграм-чаты.

В сентябре мы запустили самый милый и дружелюбный инстаграм IT-компании — о новостях и буднях VDSina начал рассказывать пёсик-разработчик.
www.instagram.com/developer.dog/


В ноябре мы съездили на Highload++, поучаствовали в круглом столе “базы данных в Kubernetes” и одели участников в шапки-акулы.

В декабре выступили на DevOps-митапе в офисе ГазПромНефти с докладом про базы данных в Kubernetes и на конференции DevOpsDays в Москве с докладом про выгорание, который, определенно, стал моим лучшим выступлением за год.
www.youtube.com/watch?v=JqShWWtCL04

Заключение
Как говорил Нассим Талеб, гораздо проще предсказать то, чего мы точно не увидим. Хочу отметить, что всё то новое, что мы увидим в 2020-м берет начало еще в 2019-м, 2018-м и раньше. Я не берусь предсказывать будущее точно, но 2020-й точно не станет годом Linux на десктопе (когда вы в последний раз видели десктоп?) а год Linux на мобильных устройствах мы наблюдаем уже лет десять.

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


https://vdsina.ru

DDoS-атака через социальную инженерию



TL;DR Атакующий подменяет source ip на адрес вашего сервера и триггерит автоматические абузы. В результате клиента банят на хостинге за вредоносную активность, которой не было.
Эта статья написана нашим клиентом, который перешёл к нам от крупного хостера после DDoS-атаки и любезно согласился поделиться этой историей.

Расскажу про удивительно коварный способ DDoS-атак, с которым я раньше не сталкивался. Коварство заключается в том, что на сам сервер жертвы не выполняется никакой атаки. Вместо этого, злоумышленник провоцирует срабатывание сторонних систем обнаружения атак, заставляя генерировать совершенно настоящие жалобы (в простонародье «абузы») на ваш сервер.

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

В статье подробно разбирается этот вид атаки в реальном кейсе.

Хронология событий
Я держал несколько личных проектов на VPS-серверах у одного известного хостера. Однажды мне пришло от него такое письмо:
#9042382: ToS Violation — Malicious Activity
Hello,
We have received a report of malicious activity originating from your server XXXX. We ask that you investigate this matter as soon as you are able. Once you have completed your investigation, kindly reply to this ticket with the answers to the following questions:
Reported-From: abuse-out@checkdomain.de
Category: info
Report-Type: info
Service: different services
Version: 0.1
User-Agent: Checkdomain Express 0.19
Date: Fri, 26 May 2018 19:25:19 +0200
Source-Type: ipv4
Source: my-server-ip-xx-xxx
Port: dif.
Report-ID: dih3cefnp@checkdomain.de
Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json
Attachment: text/plain

DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS
(letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits)
 portflood: syn | | standby.checkdomain.de |
VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER
my-server-ip-xxx-xxx-xxx: this ip-number was never banned before

AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - 
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -

Где my-server-ip-xx-xxx это IP-адрес сервера.

В нем хостер пересылает мне жалобу, поступившую на его ящик abuse@, и настойчиво просит прекратить вредоносную активность, иначе я буду заблокирован. В приложенном логе виден список TCP-подключений к 80 (HTTP) порту в состоянии SYN RECEIVED. То есть с моего сервера идёт SYN-флуд на чей-то веб-сервер.

Первая мысль — меня взломали и с моего сервера идёт SYN-флуд. В Linux есть ограничения на управление сокетами с правами обычного пользователя и посылать только SYN-пакеты (без установки полноценного TCP-соединения) можно только имея привилегии root. А это значит, что взломали полностью.

В панике бегу на сервер искать вредоносный процесс. Проверяю top, ss, lsof и ничего подозрительного не вижу. Первичный вывод: «ужас, наверное залили настолько крутой руткит, который прячет вирус на уровне ядра от всех системных утилит!». В процессе исследований выясняется, что нагрузка на сервер никак не изменилась, по графикам в панели хостера трафик на интерфейсе остается прежним.

До этого я запускал tcpdump c фильтрами, показывающими исходящий трафик и ничего подозрительного не видел. Отчаявшись, решаю посмотреть весь трафик на сервер. В потоке легитимного трафика нахожу редкие RST-пакеты от странных серверов.

Выглядит это примерно так, где my-server-ip-xx-xxx адрес моего сервера:
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]


Было очевидно, что это аномалия, так как больше никакого обмена с этими серверами не было и почему они шлют пакет закрытия соединения, мне было неясно.
На этом моменте опытные админы сразу бы всё поняли, но мы разберём всё на пальцах

Как это работает
Входящие RST-пакеты это ответы на попытки установить TCP-соединение на закрытый порт. При этом от моего сервера никакого исходящего трафика в сторону серверов, посылающих RST, нет. Это значит, что атакующий подменяет исходящий адрес на мой и генерирует трафик, похожий на DDoS-атаку. Но так как единственное, что может атакующий, это послать исходящий пакет, все ответы от серверов приходят на мой сервер.

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

В моем случае атакующий не ставил целью исчерпать канал сервера-жертвы. Его активность была совершенно незаметна на графиках потребления канала. Главной его целью было спровоцировать системы автоматического уведомления о сетевых атаках, которые пошлют письмо с жалобой на abuse-адрес, указанный в whois подсети моего провайдера. Это умеют делать системы обнаружения и предотвращения вторжений (Intrusive Prevent/Detect System), такие как Snort и Suricata.

В результате хостер получает абсолютно настоящее письмо от легитимных компаний, в котором содержится жалоба на мою вредоносную активность и даже логи в них настоящие. При этом атакующему не нужен большой канал, так как он заранее знает адреса серверов, на которых установлены IDS/IPS-системы и минимально необходимое число пакетов, чтобы сработала автоматическая жалоба.

Единственной трудностью для атакующего является поиск сервера, разрешающего подмену исходящих IP-адресов в пакетах. Все нормальные хостеры блокируют такие пакеты. Существует только два типа хостинга, позволяющего клиентам подменять исходящий IP: либо очень безграмотно настроенный, либо специально созданный для кибер-криминала.

Проверяем возможность подмены IP-адреса
Советую вам проверить своего хостера на возможность подмены исходящего IP. Для этого потребуется два сервера, один для приёма трафика, другой для отправки.

На стороне принимающего сервера запустим логирование входящего трафика. В качестве фильтра укажем редкий порт, на котором в обычное время не должно быть трафика:
tcpdump -i any port 9912

На проверяемом сервере сгенерируем пакет с подменой исходящего IP-адреса на 1.1.1.1, направленный на порт 9912. Для этого используем крутую утилиту nping от разработчиков nmap. Она позволяет генерировать любые нестандартные пакеты на уровне L2 и L3.
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com

receiver-server.com — адрес слушающего сервера, на котором запущен tcpdump
1.1.1.1 — подменяемый исходящий адрес
9912 — удалённый порт

Если на стороне receiver-server.com вы увидите пакет, пришедший от имени 1.1.1.1, значит ваш провайдер позволяет подменять исходящий IP-адрес. Это повод сообщить ему о проблемах в настройке сетевого оборудования. Зачастую такой проблемой страдают домашние интернет-провайдеры.

Глупая техподдержка
Разобравшись в причинах жалоб, я подробно все изложил хостеру:
Hello,
I finally understand what happened.

They spoof my IP address and DDoS random hosts using my address as source address. So victims generate automatic abuse reports to my hosting providers.

You can see on abuse log that connections are only in SYN_RECV state (no full TCP-connection established) because they can send only one packet using spoofed IP and can't finish TCP-handshake.
I can prove this. There are many TCP RST incoming packets coming right now to my server from hosts whom I never sent any packets.

You can check it right now by running:

tcpdump -i eth0 «tcp[tcpflags] & (tcp-rst) != 0»

You will see that many RST packets came from hosts to which I've never sent any data.
This proves that attacker is spoofing my IP-address to compromise me and generate abuses.
Тогда мне казалось, что любой квалифицированный инженер техподдержки разберётся в ситуации и вопрос будет закрыт. Но вместо этого они требовали от меня проверить сервер антивирусом или полностью переустановить ОС. Пока мы переписывались с техподдержкой, абузы продолжали поступать и через сутки меня забанили.

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

https://vdsina.ru

Настоящее суммирование интернет-каналов — OpenMPTCPRouter



Можно ли объединить несколько интернет-каналов в один? Вокруг этой темы куча заблуждений и мифов, даже сетевые инженеры с опытом часто не знают о том, что это возможно. В большинстве случаев, объединением каналов ошибочно называют балансировку на уровне NAT или failover. Но настоящее суммирование позволяет пустить одно единственное TCP-подключение одновременно по всем интернет-каналам, например видеотрансляцию так, чтобы при обрыве любого из интернет-каналов вещание не прерывалось.

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

Мифы про суммирование каналов

Есть много бытовых роутеров, поддерживающих функцию Multi-WAN. Иногда производители называют это суммированием каналов, что не совсем верно. Многие сетевики верят, что кроме LACP и суммирования на L2 уровне, никакого другого объединения каналов не существует. Мне часто доводилось слышать, что это вообще невозможно от людей, которые работают в телекомах. Поэтому попробуем разобраться в популярных мифах.

Балансировка на уровне IP-подключений

Это самый доступный и популярный способ утилизировать несколько интернет-каналов одновременно. Для простоты представим, что у вас есть три интернет провайдера, каждый выдаёт вам реальный IP-адрес из своей сети. Все эти провайдеры подключены в роутер с поддержкой функции Multi-WAN. Это может быть OpenWRT с пакетом mwan3, mikrotik, ubiquiti или любой другой бытовой роутер, благо сейчас такая опция уже не редкость.

Для моделирования ситуации представим, что провайдеры выдали нам такие адреса:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33

То есть, подключаясь к удалённому серверу example.com через каждого из провайдеров, удаленный сервер будет видеть три независимых source ip клиента. Балансировка позволяет разделить нагрузку по каналам и использовать их все три одновременно. Для простоты представим, что мы делим нагрузку между всеми каналами поровну. В итоге, когда клиент открывает сайт, на котором условно три картинки, он загружает каждую картинку через отдельного провайдера. На стороне сайта это выглядит как подключения с трёх разных IP.



Такой режим балансировки часто несёт проблемы для пользователей. Например, многие сайты жёстко привязывают cookie и токены к IP-адресу клиента, и если он внезапно изменился, то запрос отбрасывается или клиента разлогинивает на сайте. Это часто воспроизводится в системах клиент-банка и на других сайтах со строгими правилами пользовательских сессий. Вот простой наглядный пример: музыкальные файлы в VK.com доступны только при действительном ключе сессии, который привязан к IP, и у клиентов, использующих такую балансировку, часто не проигрываются аудио, потому что запрос ушёл не через того провайдера, к которому привязана сессия.


Такая балансировка позволяет получить суммирование скорости интернет-канала, при использовании множества подключений. Например, если у каждого из трёх провайдеров скорость 100 Мегабит, то при загрузке торрентов мы получим 300 Мегабит. Потому что торрент открывает множество подключений, которые распределяются между всеми провайдерами и в итоге утилизируют весь канал.

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


Это справедливо и для видео-трансляций. Если вы вещаете потоковое видео на какой-то условный Twitch, то балансировка на уровне IP-подключений не даст никакой особенной пользы, так как видео-поток будет транслироваться внутри одного IP-подключения. В данном случае, если у провайдера WAN 3 начнутся проблемы со связью, например потери пакетов или снижение скорости, то вы не сможете моментально переключиться на другого провайдера. Трансляцию придётся останавливать и переподключаться заново.

Настоящее суммирование каналов
Реальное суммирование каналов даёт возможность пустить одно подключение к условному Twitch сразу через всех провайдеров таким образом, что, если любой из провайдеров сломается, подключение не оборвется. Это на удивление сложная задача, которая до сих пор не имеет оптимального решения. Многие даже не знают, что такое возможно!

По предыдущим иллюстрациям мы помним, что условный сервер Twitch может принять от нас видеопоток только от одного source IP адреса, значит он должен быть у нас всегда постоянным, вне зависимости от того, какие провайдеры у нас отвалились, а какие работают. Чтобы этого добиться, нам потребуется суммирующий сервер, который будет терминировать все наши подключения и объединять их в одно.


В такой схеме используются все провайдеры, и отключение любого из них не вызовет обрыв связи с сервером Twitch. По сути, это особый VPN-тоннель, под капотом у которого сразу несколько интернет-каналов. Главная задача такой схемы — получить максимально качественный канал связи. Если на одном из провайдеров начались проблемы, потеря пакетов, увеличение задержек, то это не должно никак отразиться на качестве связи, так как нагрузка автоматически будет распределяться по другим, более качественным каналам, которые есть в распоряжении.

Коммерческие решения
Эта проблема давно беспокоит тех, кто ведёт прямые трансляции мероприятий и не имеет доступа к качественному интернету. Для таких задач существуют несколько коммерческих решений, например компания Teradek делает такие монструозные роутеры, в которые вставляются пачки USB модемов:


В таких устройствах, обычно, встроена возможность захвата видеосигнала по HDMI или SDI. Вместе с роутером продаётся подписка на сервис суммирования каналов, а также обработки видеопотока, перекодирования его и ретрансляции дальше. Цена таких устройств начинается от 2к$ с комплектом модемов, плюс отдельно подписка на сервис.

Иногда это выглядит достаточно устрашающе:


Настраиваем OpenMPTCPRouter
Протокол MP-TCP (MultiPath TCP) придуман для возможности подключения сразу по нескольким каналам. Например, его поддерживает iOS и может одновременно подключать к удалённому серверу по WiFi и через сотовую сеть. Важно понимать, что это не два отдельных TCP-подключения, а именно одно подключение, установленное сразу по двум каналам. Чтобы это работало, удалённый сервер должен поддерживать MPTCP тоже.

OpenMPTCPRouter — это открытый проект программного роутера, позволяющего по-настоящему суммировать каналы. Авторы заявляют, что проект находится в статусе альфа-версии, но им уже можно пользоваться. Он состоит из двух частей — суммирующего сервера, который размещается в интернете и роутера, к которому подключаются несколько интернет-провайдеров и сами клиентские устройства: компьютеры, телефоны. В качестве пользовательского роутера может выступать Raspberry Pi, некоторые WiFi-роутеры или обычный компьютер. Есть готовые сборки под различные платформы, что очень удобно.


Настройка суммирующего сервера
Суммирующий сервер располагается в интернете и терминирует подключения со всех каналов клиентского роутера в одно. IP-адрес этого сервера будет внешним адресом при выходе в интернет через OpenMPTCPRouter.

Для этой задачи будем использовать VPS-сервер на Debian 10.

Требования к суммирующему серверу:
  • MPTCP не работает на виртуализации OpenVZ
  • Должна быть возможность установки собственного ядра Linux

Сервер разворачивается выполнением одной команды. Скрипт установит ядро с поддержкой mptcp и все необходимые пакеты. Доступны установочные скрипты для Ubuntu и Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh


Результат успешной установки сервера.


Сохраняем пароли, они потребуются нам для настройки клиентского роутера, и перезагружаемся. Важно иметь в виду, что после установки SSH будет доступен на порту 65222. После перезагрузки нужно убедиться, что мы загрузились с новым ядром
uname -a 
Linux test-server.local 4.19.67-mptcp

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

Настройка клиентского роутера
На сайте проекта доступны готовые сборки для некоторых платформ, например Raspberry Pi, Banana Pi, роутеры Lynksys и виртуальные машины.
Эта часть openmptcprouter основана на OpenWRT, в качестве интерфейса используется LuCI, знакомый всем, кто когда-либо сталкивался с OpenWRT. Дистрибутив весит около 50Мб!


В качестве тестового стенда я буду использовать Raspberry Pi и несколько USB-модемов с разными операторами: МТС и Мегафон. Как записать образ на SD-карту, полагаю, не нужно рассказывать.

Изначально Ethernet-порт в Raspberry Pi настроен как lan со статическим IP-адресом 192.168.100.1. Чтобы не возиться с проводами на столе, я подключил Raspberry Pi к WiFi точке доступа и задал на WiFi-адаптере компьютера статический адрес 192.168.100.2. DHCP-сервер по умолчанию не включен, поэтому нужно использовать статические адреса.

Теперь можно зайти в веб-интерфейс 192.168.100.1

При первом входе система попросит задать пароль root, с этим же паролем будет доступен SSH.


В настройках LAN можно задать нужную подсеть и включить DHCP-сервер.

Я использую модемы, которые определяются как USB Ethernet интерфейсы с отдельным DHCP-сервером, поэтому это потребовало установки дополнительных пакетов. Процедура идентична настройке модемов в обычном OpenWRT, поэтому я не буду рассматривать её здесь.

Далее нужно настроить WAN-интерфейсы. Изначально в системе создано два виртуальных интерфейса WAN1 и WAN2. Им нужно назначить физическое устройство, в моем случае это имена интерфейсов USB-модемов.

Чтобы не запутаться в именах интерфейсов, я советую смотреть сообщения dmesg, подключившись по SSH.

Так как мои модемы сами выступают роутерами, и сами имеют DHCP-сервер, мне пришлось изменить настройки их внутренних диапазонов сетей и отключить DHCP-сервер, потому что изначально оба модема выдают адреса из одной сети, а это вызывает конфликт.

OpenMPTCPRouter требует, чтобы адреса WAN-интерфейсов были статическими, поэтому придумываем модемам подсети и настраиваем в меню system → openmptcprouter → interface settings. Здесь же нужно указать IP-адрес и ключ сервера, полученный на этапе установки суммирующего сервера.


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


По умолчанию используется режим shadowsocks + mptcp. Это такой прокси, который заворачивает в себя все подключения. Изначально он настроен обрабатывать только TCP, но можно включить и UDP.


Если на странице статуса нет ошибок, на этом настройку можно считать законченной.
С некоторыми провайдерами может возникнуть ситуация, когда на пути следования трафика флаг mptcp обрезается, тогда будет такая ошибка:

В этом случае можно использовать другой режим работы, без использования MPTCP, подробнее об этом здесь

Заключение
Проект OpenMPTCPRouter очень интересный и важный, так как это, пожалуй, единственное открытое комплексное решение проблемы суммирования каналов. Всё остальное либо наглухо закрытое и проприетарное, либо просто отдельные модули, разобраться с которыми обычному человеку не под силу. На текущем этапе развития проект ещё достаточно сырой, крайне бедная документация, многие вещи просто не описаны. Но при этом он всё-таки работает. Надеюсь, что он будет и дальше развиваться, и мы получим бытовые роутеры, которые будут уметь нормально объединять каналы из коробки.


https://vdsina.ru

Устанавливаем Kali Linux с графическим интерфейсом на виртуальный сервер



TL;DR в статье описывается установка Kali Linux с графической средой на виртуальный сервер с ISO-образа по VNC. Такой системой можно пользоваться как полноценным десктопом.

Большинство хостеров предоставляют только консольный доступ к виртуальным серверам и ограниченный выбор образов операционных систем. Но что, если вы хотите установить собственную ОС со своего диска, например что-то экзотическое вроде Kali Linux? У нас вы можете подключить собственный ISO-образ и установить с него любую операционную систему, которая поддерживается гипервизором.

С момента установки- управление сервером происходит по VNC в графическом окружении, точно так же, как на десктопной виртуальной машине вроде VirtualBox или Vmwarе. Пользоваться таким сервером можно прямо в браузере без установки дополнительных программ.

Создание сервера
Первым делом нужно создать виртуальный сервер. Установка операционной системы из ISO-образа происходит уже на созданный сервер, а создать пустой сервер нельзя. Поэтому при создании сервера выбираем любой образ ОС, например CentOS. Этот выбор не имеет значения, так как мы все равно будем форматировать жесткий диск.


Графическая среда требует существенно больше системных ресурсов, поэтому выбираем конфигурацию с 4ГБ оперативной памяти для комфортной работы. Могу сказать, что и с 2ГБ тоже работает сносно, но тяжелые программы вроде Burp Suite на Java съедают всю память. Чтобы ресурсов точно хватило, мы подготовили для вас бонус — 1000 рублей при пополнении баланса от 3000 рублей. Чтобы его активировать, перейдите по этой ссылке для регистрации и пополнения.


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

Дожидаемся завершения установки сервера, обычно это занимает не более минуты. Если в момент создания сервера оставить вкладку открытой, вы услышите звуковое уведомление о том, что сервер создан. Так же вы получите письмо на электронную почту с реквизитами для SSH-доступа к серверу. Эти реквизиты нам не потребуются, так как мы установим пароль на этапе установки новой системы.


Подключение ISO-образа
Теперь, когда сервер создан, мы можем подключить ISO-образ с Kali Linux. Для этого его сперва нужно смонтировать в панели управления, так подключенный ISO-образ будет доступен для подключения ко всем созданным серверам. Услуга подключения ISO-образа стоит 1 рубль в день. Нам он потребуется только на время установки, после чего его можно будет удалить.


Здесь можно загрузить ISO с компьютера, выбрать из нашей библиотеки или указать ссылку на файл с образом, который будет автоматически скачан. Нам не потребуется ничего скачивать, так как в библиотеке уже есть образ с Kali Linux. Не обращаем внимания на версию, так как Kali Linux выпускается по модели «Rolling release», он не имеет определенных мажорных версий, и всегда может быть обновлен до актуального состояния простым запуском apt ugprade.


Монтирование образа займет не более минуты, после чего его статус изменится на «активно». Теперь его можно подключать к существующим серверам. Для этого заходим в свойства сервера и нажимаем кнопку «Подключить ISO». После подключения ISO система будет перезагружена и загрузка системы начнется с образа.

Доступ по VNC
На этом этапе система загружена с ISO-образа и не имеет доступа в интернет. Единственный способ управления сервером, это подключиться к виртуальному экрану по VNC. В нашей панели управления встроен браузерный VNC-клиент, который запускается по нажатию одной кнопки. Никакие пароли при этом вводить не требуется.


При желании, вы можете использовать свой VNC-клиент, например Realvnc. Реквизиты для подключения можно посмотреть нажав на пиктограмму раскрытия пароля. Важно помнить, что адрес VNC-сервера отличается от IP-адреса вашего сервера.


Описывать все этапы установки Kali Linux мы не будем, так как они сводятся к простому нажатию Next -> Next -> Next -> Finish. Остановимся только на неочевидных моментах.

Настройка сети вручную
Виртуальный сервер не получит IP-адрес автоматически, так как в сети нет DHCP-сервера, поэтому его потребуется ввести вручную. На этапе обнаружения DHCP можно нажать Cancel, чтобы не тратить время.


Выбираем ручную конфигурацию и вводим IP-адрес, шлюз и маску сети. Все нужные настройки для конкретного сервера сразу указаны внизу страницы VNC-клиента.


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

Аналогичным образом поступаем с вопросом о загрузчике GRUB — выбираем пункт по умолчанию.

Завершение установки
После завершения установки система автоматически перезагрузится и мы снова попадем в загрузочное меню ISO-образа. Чтобы загрузить установленную систему с жесткого диска, нужно извлечь ISO из сервера. После чего сервер автоматически перезагрузится и мы попадем уже в установленный Kali Linux.

Чтобы не платить за смонтированный ISO-образ, его можно удалить из панели управления. Он нам больше не нужен.


Заключение
Готово! Теперь у нас есть дистрибутив Kali Linux, который всегда включен и доступен. Не нужно нагружать основной компьютер виртуальным машинами и страдать, если нужно перезагрузиться.
Это особенно удобно когда нужно запустить какую-то ресурсоемкую программу вроде сканера, и оставить ее выполняться на несколько дней.


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



https://vdsina.ru

Как мы хостили скандальный имиджборд 8chan



8chan (новое название 8kun) — популярный анонимный форум с возможностью пользователей создавать собственные тематические разделы сайта и самостоятельно их администрировать. Известен своей политикой минимального вмешательства администрации в модерирование контента, из-за чего стал популярен у разной сомнительной публики.

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

С правовой точки зрения ситуация с 8chan достаточно спорная, так как администрация декларирует, что следует законам США и удаляет запрещённый контент с сайта, а также выполняет запросы правоохранительных органов. Претензии к 8chan носят скорее морально-этический характер: место имеет дурную репутацию.

2 ноября 2019 к нам на хостинг vdsina.ru пришёл 8chan. Это вызвало оживлённые споры внутри нашего коллектива из-за чего мы решили опубликовать этот пост. В статье рассказывается история гонений на 8chan и почему мы в итоге решили предоставить хостинг проекту 8chan (который всё равно закрылся).

Хронология событий
Мы не будем описывать конкретные эпизоды трагедий, участники которых как-либо упоминаются в контексте 8chan. Отношение к этим событиям однозначно для любого здорового человека и не является для нас предметом споров. Главный вопрос, который мы хотим поднять — это может ли поставщик услуг выступать в роли цензора и решать кому отказывать в предоставлении сервиса, основываясь не на букве закона, а на своём представлении о морали.

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

Исключение из поисковой выдачи Google
В августе 2015 сайт 8ch.net перестал показываться в поисковой выдаче Google. В качестве причины для удаления было указано «Жалобы на контент, содержащий насилие над детьми». При этом правила сайта явно запрещали публикацию такого контента и с самого сайта 8ch.net подобный медиа-контент оперативно удалялся.

Спустя несколько дней, после публикации на ArsTechnica, сайт 8ch.net частично вернулся в поисковую выдачу Google.

Отключение от CloudFlare

Сайт 8chan использовал сервис CloudFlare для защиты от DDoS-атак и в качестве CDN. 5 августа 2019 года в блоге Cloudflare был опубликован большой пост о том почему они решили прекратить обслуживание 8chan.

Вот краткие выдержки из этого поста:
… стало известно, что подозреваемый в расстрелах террорист был вдохновлён интернет-форумом 8chan. Основываясь на предоставленных доказательствах, можно утверждать, что он выложил целую речь прямо перед тем, как убить 20 человек.

...8chan не раз подтверждал звание выгребной ямы для ненависти.

— Cloudflare о прекращении обслуживания 8chan


В своём посте CloudFlare сравнивает сайт 8chan с другим скандальным сайтом, антисемитским новостным изданием The Daily Stormer, которому так же ранее было отказано в обслуживании. Однако главное отличие The Daily Stormer от 8chan в том, что первый сайт прямо позиционируется как антисемитский и контент публикуется самими авторами сайта, в то время как на 8chan весь контент является пользовательским, точно так же, как в условном facebook или twitter. При этом позиция администрации 8chan состоит в том, чтобы не вмешиваться в контент пользователей «сверх того, что требует закон США». То есть администрация сайта блокирует, к примеру, сцены насилия над несовершеннолетними, но не запрещает дискуссии.

CloudFlare явно осознают неоднозначность своего решения, когда пишут, что им оно не слишком нравится, но при этом полностью законно.
Нам по-прежнему крайне неудобно находиться в роли судей контента и мы не планируем часто делать это. Многие ошибочно предполагают, что причина тому — первая поправка США. Это не так. Во-первых, мы частная компания и мы не ограничены первой поправкой. Во-вторых, подавляющее большинство наших покупателей, и более 50% нашего дохода приходит из-за границ США, где, ни первая поправка, ни аналогичная ей либертарианская защита свободы слова не применимы. Единственное сходство с первой поправкой здесь в том, что мы имеем право выбирать с кем вести бизнес, а с кем нет. Нас не обязывают вести бизнес со всеми.

— Cloudflare о прекращении обслуживания 8chan


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

Вольный перевод:
Чо? Почему вы называете 8chan сайтом ненависти и обвиняете его в «беззаконии»? Это просто движок, на котором любой может создать свою борду и самостоятельно её администрировать. Как можно сравнивать это с The Daily Stormer, новостным сайтом со своим администратором?

И вообще почему вы обвиняете сайт в убийствах? Это люди убивают людей, а не форум в интернете. Если они будут использовать смски и мобильную связь, чтобы общаться с другими людьми, то надо отключить мобильную связь?


Отключение хостинга
После отключения от CloudFlare обнаружился реальный IP хостинг-площадки 8chan. Это были адреса дата-центра Voxility. Официальный аккаунт Voxility в твиттере написал, что адреса принадлежали реселлеру под названиями Epik/Bitmitigate, которого сразу отключили.


Переезд в Россию
Спустя три месяца после отключения хостинга, сайт возобновил работу под новым именем 8kun.net. Согласно расследованию CBS News, сперва сайт развернулся на площадке Selectel, но в тот же день был заблокирован. После чего переехал к нам.

Почти сразу один из наших бизнес-партнёров потребовал заблокировать ресурс, потому что 8kun нарушает их AUP. Мы начали искать возможность предоставить хостинг для 8kun, не нарушая партнёрских договорённостей и как только нашли такой, разблокировали серверы 8kun. К тому моменту ресурс успел переехать на Medialand.

Мы приняли решение не блокировать сайт, пока он не нарушает законы стран, в которых мы работаем.

Подпольный хостинг Medialand
Вскоре домен 8kun.net стал указывать на IP-адрес 185.254.121.200, который формально не должен принадлежать никому, так как находится в нераспределённом пуле адресов и официально не выделен ещё ни одному провайдеру. Однако этот адрес анонсируется из автономной системы AS206728, которая по данным Whois принадлежит провайдеру MEDIALAND. Это русский подпольный хостинг, получивший известность после расследование Брайна Кребса — Крупнейший пуленепробиваемый хостинг.

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

Доклад на конференции BlackHat USA 2017 о сетевой инфраструктуре преступников, в которой фигурирует хостер «Медиа Лэнд».

Разделегирование доменов
За время существования сайта, у него сменился владелец. Из-за разногласий с прошлым владельцем, доменное имя 8ch.net сохранить не удалось. В октябре 2019 сайт был переименован в 8kun.net и анонсирован перезапуск проекта.

Пока домен 8kun.net был активен, посторонние люди зарегистрировали у регистратора name.com несколько доменов:
  • 8kun.app
  • 8kun.dev
  • 8kun.live
  • 8kun.org

И установили переадресацию на домен 8kun.net. Все эти домены были разделегированы Name.com якобы за нарушение правил, при этом заблокировав возможность переноса доменов к другому регистратору. Об этом сообщил владелец доменов.

Вскоре домен 8kun.net был разделегирован по заявлению бывшего владельца.

Некоторые время сайт был доступен по адресу 8kun.us, но и этот домен был разделегирован.
Забавный момент — нам писал регистратор этого домена с просьбой заблокировать хостинг, хотя сами они могли выключить домен в один клик.


На текущий момент сайт 8chan полностью недоступен в клирнете (обычном интернете) и зайти на него можно только через сеть TOR используя onion-адрес.

Заключение
Мы никоим образом не поддерживаем насилие и нетерпимость в любой форме. Целью данного поста является обсуждение технической и правовой стороны проблемы. А именно: могут ли поставщики услуг самостоятельно, не дожидаясь судебных решений, определять какой ресурс является незаконным.

Совершенно очевидно, что любые публичные сервисы, которые разрешают публикацию пользовательского контента, обязательно будут регулярно использованы во зло. На площадках Facebook, Instagram, Twitter публикуются сотни обращений террористов и даже их прямые трансляции. При этом не ставится вопрос о том, что существование этих площадок влияет на количество преступлений.

Случай с 8chan показывает, что несколько частных компаний могут объединиться и попросту уничтожить другой ресурс, методично отключая услуги связи и разделегируя домены. По такой же схеме могут быть уничтожены и любые другие ресурсы. Вряд ли полное цензурирование интернета приведёт к снижению насилия в мире, но совершенно точно породит множество аналогичных площадок в даркнете, где отследить авторов уже будет намного сложнее.

Вопрос сложный и легко можно найти аргументы как за, так и против блокировки 8chan. А как вы считаете?



https://vdsina.ru

Почему мы решили не блокировать 8chan и предоставить им хостинг

В эту субботу мы начали предоставлять хостинг для имиджборда 8kun.net.

Мы хотим выразить свою позицию относительно 8kun, свободы слова, свободного интернета и конкретно о статье об экстремизме УК РФ.

С 2015 года до сегодня в России сотни человек были осуждены на реальные сроки лишения свободы за высказывания в интернете. Статья «экстремизм» стала инструментом подавления политической оппозиции и способом лишения одного из главных прав, гарантируемых нам конституцией РФ — свободы слова.

В июне 2016 года был принят «антитеррористический пакет» Яровой, который дал ФСБ законное право расшифровывать нашу переписку и ужесточил наказание за экстремизм в интернете. В Уголовном Кодексе нет четкого правового определения слова «экстремизм», часто под этим понимается просто критика властей и существующих порядков.

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

В условиях цензуры и давления на СМИ, свободный интернет остается единственной надеждой на реальное представление о том, что происходит в мире.

Мы теряем наши конституционные права и свободы одно за другим.

После теракта в редакции газеты Charlie Hebdo 7 января 2015 года, два гражданских активиста Владимир Ионов и Марк Гальперин вышли с плакатами Je suis Charlie на Манежную площадь в Москве.

Власти быстро отреагировали — суд рассмотрел два административных материала и назначил Марку Гальперину арест на 38 суток. Дадина суд приговорил к аресту на 15 суток и к штрафу в размере 20 тысяч рублей.

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

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

Мы — 8chan.



https://vdsina.ru

Терминальный сервер для админа; Ни единого SSH-разрыва



Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

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

Настройка сервера
Идея проста и наглядно проиллюстрирована на картинке в заголовке поста: все SSH-подключения мы будем держать на специальном терминальном сервере. Этот сервер будет нашей точкой входа для управления другими серверами. При этом на конечных серверах не потребуется настройки или установки дополнительного ПО.
Для терминального сервера подойдет почти любая конфигурация, но лучше иметь побольше оперативной памяти, чтобы хранить лог консоли внутри каждой сессии и иметь возможность в любой момент проскроллить историю вверх и посмотреть, что вы делали на сервере сессии месяц назад. Обычно 1-2ГБ памяти достаточно.

Выбор дистрибутива
В терминальном сервере самое главное — это uptime, ведь чем реже мы перезагружаемся, тем больше живут наши SSH-сессии. Поэтому выбираем максимально консервативный LTS (Long Term Support) дистрибутив, например стабильную ветку debian или ubuntu. Настраиваем автоматические обновления (unattended-upgrades) таким образом, чтобы внезапный перезапуск программ не стал неожиданностью.

Настройка SSH-сервера
Так как терминальный сервер будет открывать доступ ко всем нашим серверам разом, будет правильно его обезопасить. Для этого запретим аутентификацию с помощью паролей, оставив только доступ с помощью ключей, а так же запретим логиниться пользователем root.
Предварительно нужно создать нового пользователя в системе.
/etc/ssh/sshd_config
.....
# Запрет логиниться пользователем root
PermitRootLogin no
# Запрет использования паролей, только ключи
ChallengeResponseAuthentication no
# Если паролей нет, то и PAM не нужен
UsePAM no
....


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

Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.
  • Это не позволит защититься от перебора паролей, так как автоматические сканеры всё равно найдут SSH на любом порту и начнут долбиться.
  • Это вносит бардак, если систему администрирует несколько человек и каждый выдумывает свои порты. Когда таких систем десятки, приходится искать сканером на каком порту спрятан SSH на этот раз.
  • Это ломает встроенные ограничения безопасности в программах. Например, веб-браузеры не подключатся на порт 22, если явно указать его в HTTP, но при этом подключатся на другой нестандартный порт. Это можно использовать для срабатывания IDS/IPS систем DDoS.

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

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

Устанавливаем tmux, если он еще не установлен:
apt install tmux


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

Создаем новую сессию:
tmux new


В этот момент мы создали новую сессию с одним окном и сразу подключились к ней. Можно видеть появившуюся внизу зелёную панель состояния. Это что-то вроде панели с вкладками в браузере. На ней будут отображаться текущая вкладка и соседние, а также служебные сообщения.

В этот момент, даже если мы закроем SSH-подключение и заново подключимся к серверу, наша запущенная сессия tmux останется в прежнем состоянии, вместе со всеми запущенными программами так, будто мы ее свернули. Попробуем запустить программу top внутри сессии tmux и отключимся от неё. Для наглядности закроем полностью окно терминала и заново подключимся к серверу.

После переподключения к серверу подключимся к нашей запущенной ранее сессии:
tmux attach

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

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

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


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

Вот основные команды:
  • Ctrl+b + c — (create) Создать новое окно (вкладку)
  • Ctrl+b + <цифра> — Переместиться на вкладку номер N, где цифра это клавиша от 0 до 9. Нумерация окон начинается с нуля.
  • Ctrl+b + x — закрыть текущее окно. Если будет закрыто последнее окно, сессия tmux завершится.
  • Ctrl+b + w — отобразить список всех окон, по которому можно перемещаться кнопками курсора вверх-вниз и выбрать нужное, нажав enter.
  • Ctrl+b + " — разделить окно пополам по горизонтали и создать новое
  • Ctrl+b + % — разделить окно по вертикали и создать новое
  • Ctrl+b +, — переименовать текущее окно
  • Ctrl+b + вниз/вверх/влево/вправо — перемещаться по pane'ам внутри окна
  • Ctrl+b + page up/page down — прокрутить скролл вверх
  • Ctrl+b + / — искать по истории, как в vim или less

Это все хоткеи, которые мне потребовались за 10 лет использования tmux. На самом деле их намного больше, но для начала лучше остановиться на этих.

Конфиг Tmux
Я считаю хоткей Ctrl+b неудобным, так как прожимать три клавиши для любого действия выходит слишком много. Тема конфигов tmux это отдельная область вкусовщины, и у каждого бывалого пользователя есть свое видение как правильно и удобно. Есть даже целые авторские подборки конфигов и тем для tmux.

Для отправной точки я приведу пример своего конфига, который, как мне кажется, исправляет все сложности, мешающие быстрому освоению tmux. Конфиг располагается в домашней папке с именем ~/.tmux.conf
# Вместо ctrl+b будет использовать одну кнопку. Нам моем macbook это самая правая клавиша в цифровом ряду
set-option -g prefix `

# Когда нужно послать символ <`> нажимаем `+a
bind-key a send-prefix

# Нумерация окон с единицы вместо ноля
set -g base-index 1
set-option -g base-index 1
setw -g pane-base-index 1

# Lowers the delay time between the prefix key and other keys - fixes pausing in vim
set-option -sg escape-time 1

# Лимит истории консоли в 1000 строк. Столько строк можно отскроллить вверх
set -g history-limit 1000

# Цвета статус бара

# default statusbar colors
set-option -g status-fg white
set-option -g status-bg default

# default window title colors
set-window-option -g window-status-fg default
set-window-option -g window-status-bg default




# Автозапуск окон с командами при первом запуске
#------------------

# Respawn windows when PANE IS DEAD
bind-key R respawn-window

# Создать сессию default с окном local
new -d -s default -n local

# Создать окно с именем irc и командой irssi
neww -d -n irc irssi

# Создать окно с именем superserver и командой ssh root@superserver.com
neww -d -n superserver ssh root@superserver.com

# Создать окно с именем anotherserver и командой ssh root@123.123.123.123
neww -d -n superserver anotherserver root@123.123.123.123


Данная конфигурация позволяет автоматически создавать несколько окон при запуске, в которых сразу запускаются SSH-сессии. При этом не требуется вручную создавать новую сессию командой tmux new, достаточно всегда вводить tmux attach. Если сессия до этого не существовала, она будет создана.

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

Для этого добавим в конец файла ~/.bashrc запуск tmux. Важно помнить, что такая конструкция будет работать только с конфигом выше.
if [ ! "$TMUX" ]; then
 tmux attach
fi

if [ "$TMUX" ]; then
 export TERM=screen
fi

Это простое условие означает, что если мы не в tmux, то подключаемся к нему.
На этом конфигурация tmux на терминальном сервере закончена. Отныне для каждого нового SSH-подключения мы будем создавать отдельное окно в tmux. И даже если соединения с терминальным сервером будет потеряно, все SSH-подключения останутся активными.

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

Mosh — надстройка над обычным OpenSSH сервером, которая позволяет забыть о разрывах соединения. Mosh авторизуется по обычному SSH, после чего поднимается отдельный UDP-канал, который мгновенно восстанавливается после разрыва, даже если у вас сменился внешний IP-адрес.
Так как нам нужно держать постоянное подключение к терминальному серверу, мы установим mosh только на сервер и на наш рабочий компьютер. При этом на удалённые серверы ничего устанавливать не потребуется, так как подключения к ним и так уже живут вечно в tmux.

Устанавливаем mosh на сервер:
apt install mosh


Устанавливаем mosh на наш рабочий компьютер. Он доступен для всех основных операционных систем, но нативный клиент есть только для Unix-подобных операционных систем. Версия для Windows реализована с помощью Cygwin либо приложения Chrome.

Я использую macOS, и устанавливаю mosh через пакетный менеджер brew:
brew install mosh


В большинстве случаев mosh не требует дополнительной настройки и работает прямо из коробки. Достаточно вместо команды ssh написать mosh:
mosh user@my-server.com


Для нестандартных конфигураций команда выглядит чуть сложнее. Например, если нужно указать порт и путь к ключу:
mosh --ssh="ssh -p 2222 -i /path/to/ssh.key" user@my-server.com


Первичную аутентификацию mosh выполняет как обычный SSH-клиент, авторизуясь на стандартный порт 22. При этом mosh-сервер изначально не слушает никаких портов, и кроме оригинального демона OpenSSH наружу никаких портов на сервере не открыто. После подключения по TCP, mosh запускается на сервере в юзерспейсе и открывает дополнительный тоннель по UDP.


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

Чтобы каждый раз не вводить длинную команду подключения к терминальному серверу, я сделал алиас команды подключения из одной буквы:
alias t='mosh --ssh="ssh -p 443 -i /path/to/ssh.key" user@my-server.com'


Заключение
Эта простая схема позволяет значительно сэкономить время и нервы, не терять результат работы при обрыве SSH. Мне постоянно приходится видеть, как начинающие админы начинают каждый раз заново логиниться на свои сервера и убивать залипшие SSH-сессии.
Возможно, на первый взгляд это покажется слишком запутанным, но я уверяю вас, стоит себя один раз пересилить и привыкнуть, как вы начнете смотреть со снисходительным сожалением на тех, у кого до сих пор ломаются SSH-подключения.

https://vdsina.ru