Хабрахабр

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 19: «Анонимные сети», часть 2 (лекция от создателя сети Tor)

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3

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

Итак, вот ретранслятор. Это инопланетная технология. Вот другой ретранслятор и вот Боб. А вот и Элис. Скажем, она выбрала эти два ретранслятора, R1 и R2. Сейчас Алиса хочет поговорить с Бобом, поэтому первое, что она делает – это создаёт цепочку через эти ретрансляторы к Бобу. Затем в первую очередь Алиса выполняет одностороннюю аутентификацию, одностороннее согласование анонимных ключей. Сначала Алиса делает TLS ссылку на R1, допустим, что она уже имеет TLS ссылку на R2.

У них обоих есть доказательства безопасности. Старый протокол Tor назывался TAP — Tor Authentication Protocol, новый называется NTor. Это правильные доказательства, хотя в их описании были допущены ошибки.

Теперь Алиса и ретранслятор делятся секретным симметричным ключом S1. После аутентификации Алиса выбирает идентификатор канала circuit ID, допустим, 3, даёт команду ретранслятору создать канал «3» — create «3», и он отвечает ей, что канал создан — created. И они оба хранят его с индексом «3», что является ссылкой на этот канал.

Она говорит, что на «тройке», это идентификатор канала, о котором говорится в лекционной статье, ретранслятору отправляется расширенная ячейка с контентом. Теперь Алиса может использовать этот ключ для отправки сообщений R1.

Но на этот раз она не зашифрована открытым ключом R1, а зашифрована открытым ключом R2. Расширенная ячейка в основном содержит первую половину рукопожатия handshake. Таким образом, R1 знает, что нужно открыть новый канал к R2, и сообщает об этом ретранслятору R2 сообщением create(….), где в скобках размещена та самая половина рукопожатия, которое пришло от Алисы. Это говорит о том, что сообщение отправляется на R2. Причём Алиса не знает, какие идентификаторы каналов здесь ещё используются, потому что это «личное дело» R1 и R2. При этом R1 создаёт собственный circuit ID, поскольку идентификаторы каналов определяют другие каналы в этом втором соединении TLS.

На самом деле это маловероятно, потому что номер канала случайно выбирается из 4 байтового пространства, но я не хочу выписывать сегодня все 32-битные числа. Так что ретранслятор может выбрать, например, ID 95.

Теперь Алиса и ретранслятор R2 делятся ключом S2 и Алиса может отправлять сообщения, сначала зашифрованные с помощью S2, а затем с помощью S1. После этого R2 отвечает первому ретранслятору «created», а R1 возвращает Алисе расширенную ячейку, зашифрованную ключом S1. Она посылает такое сообщение, R1 удаляет шифрование S1 и пересылает его дальше.

Получив это сообщение, второй ретранслятор видит, что каналу 95 соответствует ключ S2, и с его помощью расшифровывает это сообщение: «о, тут сказано открыть соединение с Бобом»! Первый ретранслятор знает, что сообщения канала 3 должны отправляться второму ретранслятору по каналу 95. Прочитав это, ретранслятор R2 открывает TCP соединение с Бобом и сообщает об этом Алисе, используя такой же обратный процесс передачи сообщений.

0get /index.html», и дальше жизнь идёт своим чередом. После всего этого Алиса говорит: «замечательно, тогда скажите Бобу что-то вроде http: 1.

Хорошо, так что же мы ретранслируем на самом деле? Давайте посмотрим, что я пропустил в лекционной статье…так… это, это и это. Одна из проблем заключается в том, что мы хотим поддержать так много пользователей, насколько это возможно, а что означает, что мы должны работать на всех видах операционных систем. Некоторые решения в этой области утверждают, что необходимо передавать туда и обратно IP- пакеты, то есть эта схема должна представлять собой просто способ передачи IP-пакетов.

Если вы когда-либо использовали Nmap или какой-либо инструмент анализа сетевого трафика, вы можете запросто отличить Windows TCP от FreeBSD TCP или TCP Linux. Но TCP стеки разных операционных систем действуют по-разному. Более того, если вы можете отправить выбранному хосту необработанные IP-пакеты, вы можете спровоцировать ответы, частично основанные на том, что делает хост. Вы даже можете отличить разные версии.

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

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

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

Протоколы более высокого уровня, рассмотренные в некоторых оригинальных проектах, используют на стороне Алисы отдельные прокси для HTTP, FTP и кажутся плохой идеей. Протокол TCP представляется вполне подходящим, правильным уровнем. Это потому, что любой протокол должен иметь шифрование от начала и до конца на протяжении всего соединения Алиса-Боб, и если нам повезёт, Алисе удастся создать TLS соединение между R2 и Бобом, обладающее свойствами целостности и безопасности.

Но это невозможно осуществить, используя прокси-сервер, поэтому нам больше подходит TCP. Но если это так, то любые преобразования анонимности, которые вы хотите применить к зашифрованным данным, должны произойти в приложении, которое использует Алиса, прежде чем TLS –соединение будет полностью создано.

У нас есть доказательства безопасности для многих способов шифрования, которые мы используем, это стандартные редакции документов. Кто-то спросил меня, где же наши доказательства безопасности? Но модели, которые они должны использовать с целью доказать, что это обеспечивает анонимность, должны основываться на таких причудливых свойствах вселенной, свойствах сети или способностях атакующего, что они могут удовлетворить только комиссии по программированию, заседающие на некоторых теоретических конференциях.
Коротко говоря, эти свойства анонимности должны доказать, что злоумышленник, который может увидеть объём и тайминги данных на участке Алиса- R1, не сможет идентифицировать их, наблюдая только за выходными байтами на участке R2-Боб. В целом для протокола имеются доказательства безопасности определённых аспектов «луковой» маршрутизации. Скажем так – какие гарантии безопасности вы бы хотели от системы, которую не знаете, как построить? Но это не совсем удовлетворительный результат. Как, например, классические сети DC-Net, которые обеспечивает гарантированную анонимность, за исключением того, что любой участник может закрыть всю сеть, просто перестав в ней участвовать. Ладно, я должен быть осторожен с подобными высказываниями… Вспомним, что имеются системы с сильнейшими гарантиями анонимности, и вы знаете, как создать такие системы, но вы никогда не захотите их использовать. К тому же эта система не масштабируется.

Так что вместо того, чтобы спрашивать, гарантирует ли эта система безопасность Алисы, стоило бы спросить, сколько трафика Алиса может безопасно отправить, если хочет иметь 99% вероятности того, что эту сетевую активность не удастся связать с её деятельностью? Но для вещей, создаваемых в наше время, свойства анонимности в большей степени являются вероятностными, а не категорически гарантированными.

Мы не знали, действительно ли наша система «встанет на ноги», поэтому единственным вариантом было пробовать и смотреть, что из этого получается. Первый вопрос, который мы задали себе, приступая к созданию Tor – кто же будет управлять всеми этими штуками?

Изрядное число некоммерческих организаций захотело просто сделать пожертвования и использовать их для покупки пропускной способности и запуска узлов Tor. У нас было достаточно добровольцев. Однако пять разных человек спросили меня о легальности нашей системы. В проекте приняли участие некоторые университеты и несколько частных компаний, службы безопасности которых посчитали, что было бы весело запустить собственный сервер Tor.
При этом возникали юридические вопросы, но опять же, я не юрист и не могу дать юридическую оценку этим вещам. И как мне кажется, подобная ситуация имеет место в большинстве Европейских стран. Насколько я могу судить, по крайней мере, в США, нет юридических препятствий для запуска сервера Tor. В странах с меньшей свободой интернета использование Tor регламентируется более жестко.

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

Честно говоря, я понятия не имею, что собой сейчас представляет эта политика, потому что она сильно изменилась со времени моего студенчества. Для такого случая я бы посоветовал не запускать сервер Tor из вашей комнаты в общежитии, вернее, не использовать свой компьютер для трансляции большого объёма выходного трафика, предполагая, что это позволяет сетевая политика. Однако запуск ретранслятора без выдачи трафика в интернет будет менее проблематичным. Но в любом случае большой исходящий трафик с вашего компьютера в общежитии может привести к неприятностям. Но если ваш провайдер разрешает действовать подобным образом, то это вполне разумная вещь.

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

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

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

Тогда, когда клиент подключается к сети, он просто должен знать один узел, чтобы затем сказать: «Эй, кто тут есть в сети»? Но можно сделать так, чтобы каждый узел содержал в себе список всех других узлов, которые к нему подключены, и все они «рекламировали» бы друг друга.

Многие ранние проекты анонимности одноранговых узлов работают именно таким образом. На самом деле у многих людей есть проекты, построенные по такому принципу. Потому что, если вы подсоединяетесь к одному узлу и спрашиваете, кто в сети, и вы доверяете отвечающему, то я могу вам ответить: «я в сети, и мой друг отсюда присутствует в сети, и мой друг оттуда тоже в сети, и больше в сети никого нет!». Но это ужасная идея. Это то, что называется rаw capture attack, или атака перехвата исходного узла. То есть я могу назвать вам любое количество поддельных узлов, которыми я управляю и которые перехватывают весь ваш трафик.

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

Если я выберу эти три узла, а вы выберете три других узлах, то мы будем использовать различные наборы узлов, а это не хорошо. Это не хорошо тем, что мы снова оказывается разделёнными на идентифицируемые кластеры сети. Если я использую объединенный список, то кто-то может зафлудить меня 20-ю тысячами фейковых серверов, указав их в списке. Кроме того, если я пользуюсь переданным мне списком узлов, любая из доверенных сторон может помешать мне использовать узел, который ей не нравится, просто не указав его в списке. Я бы мог проголосовать за их исключение и смог бы каким-то образом решить две последние проблемы, но я все равно буду отделен от всех, кто использует разные доверенные стороны.

Я говорю «волшебную», потому что, хотя в этой области и есть проекты, и некоторые лучше, чем другие, ни один из них на данный момент не имеет твёрдых доказательств безопасности. Мы могли бы создать волшебную DHT, или распределённую хеш-таблицу, своего рода магическую распределенную структуру, проходящую через все узлы. Настолько твёрдых, чтобы я мог бы с уверенностью сказать, что это действительно безопасно.

Наша сеть имеет несколько доверенных органов, управляемых доверенными сторонами, которые собирают списки узлов, которые ежечасно голосуют, какие узлы могут работать в сети, и могут голосовать за то, чтобы исключить подозрительные узлы. Итак, вот к какому решению мы пришли в результате. Все они работают на том же /16, который вытворяет с трафиком такие странные вещи, и формируют консенсус, который основан на подсчёте результата голосования.
И клиенты не используют узел, если он не подписан достаточным количеством «голосов» доверенных сторон.

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

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

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

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

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

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

Другие вещи намного проще, чем веб-браузеры, но все же достаточно проблематичны. Вам нужно серьёзно «поломать» веб-браузер, чтобы он прекратил делать такие вещи, как утечка списка шрифтов, идентифицирующих вашу систему, утечка точного размера ваших окон, к которой приводят все виды кукиз, утечка того, что есть в кеше и чего там нет, и так далее.
Таким образом, у вас остаётся небольшой выбор: или изолировать все и постоянно перезапускается со свежей виртуальной машины, или перенаправить браузер, или и то, и другое. Давайте обсудим темы, за которые проголосовало большинство в аудитории. Вот и все, что я собирался сказать о проблемах приложений. Если у нас останется время, я займусь цензурой и атаками. Это злоупотребления и скрытые сервисы.

Когда мы работали над этой штукой, нас миновала одна проблема, которой все боялись – это обмен файлами, против которого может выступать ваш интернет-провайдер, и это создаст огромные юридические проблемы и разрушит ваши жизни. Итак, давайте перейдем к злоупотреблениям. Да, это было очень давно, и мы подумали о том, как бы нам этого избежать. Мы опасались, что люди попытаются использовать BitTorrent, Gnutella или нечто подобное.

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

Скажу, что преступная деятельность вообще не создает много проблем для сетевых операторов Tor. Тем не менее, есть люди, которые согласны запускать узлы с портами выхода на интернет-сайты 80 и 443, а не со всеми портами, так что это оказалось полезным, но всё равно не решило проблему злоупотреблений. Это достаточно редкое явление, и если подобное случается, то вызывает удивление. Время от времени чей-то сервер захватывают и возвращают через полгода, и им бывает нужно всё почистить.

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

Это неприемлемо для сайтов и сервисов, которые используют блокировку на основе IP-адресов, им нужно предотвратить подобное, и IP-блокировка является наиболее дешевым способом. Люди, публикующие фотографии убийств на сайте My Little Pony, люди оскорбляющие всех на IRC-каналах, люди, занимающиеся по просьбам других любовью в прямом эфире, люди, заменяющие целые страницы Википедии расовыми оскорблениями – всё это существует на самом деле и создаёт проблемы. Так что довольно часто пользователи Tor получают на некоторых сайтах вечный бан.

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

Кто-нибудь из вас пользовался «слепыми» подписями? Поэтому вам нужно рассмотреть различные способы снижения затрат ресурсов. Позже, если ваша учетная запись будет заблокирована, вам нужно будет всего лишь создать новую учетную запись с другого IP-адреса. Вы можете сделать так, что вам понадобится IP, чтобы создать аккаунт, но этот IP не будет связан с вашим реальным IP-адресом.

Над чем ещё можно поломать голову в области интеграции – это анонимные «чёрные списки». Это система, которую можно построить, и мы сотрудничаем с людьми, которые работают над созданием таких систем, хотя это требует больших усилий с точки зрения интеграции. Они немного эзотеричны, но идея состоит в том, что вы получаете нечто, позволяющее вам, к примеру, присутствовать на IRC – сервере, несмотря на бан, и вы можете использовать это столько раз, сколько захотите.

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

Дело в том, что я начал писать эти лекционные заметки ещё в 2013 году, и мне обязательно задаются вопрос о «Шелковом пути 2» и о том, как был пойман создатель Silk Road. Кто-то неизбежно задаёт мне один и тот же вопрос. «Шелковый путь 2» представлял собой скрытый сервис, работающий в сети Tor, где люди собирались, чтобы покупать и продавать незаконные вещи, в основном наркотики.

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

При этом разведывательное управление говорит правоохранительным органам: «смотрите, вот Фред, и он это совершил. С другой стороны, если вы знакомы с утечкой информации о работе АНБ, то знаете, что правоохранительные органы получает информацию от разведки, а затем пропускают её через процесс, называемый «двойная конструкция». Так что просто найдите другой способ узнать, что именно Фред сделал это, но уверяем вас — Фред действительно это сделал». Но мы раздобыли эту информацию незаконным путём, поэтому вы не сможете заявить в суде, что получили её от нас. Согласно утечкам информации от Сноудена и утечкам от другого парня, которого ещё не поймали, подобное иногда случается.

54:00

Лекция 19: «Анонимные сети», часть 3 (лекция от создателя сети Tor) Курс MIT «Безопасность компьютерных систем».

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

Вам нравятся наши статьи? Спасибо, что остаётесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до января бесплатно при оплате на срок от полугода, заказать можно тут.

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»