...

суббота, 28 июля 2018 г.

[Перевод] Как SSH появился на 22 порту

SSH по умолчанию работает на порту 22. Это не совпадение. Вот история, как ему достался этот порт.

Когда я (Тату Илонен) впервые опубликовал эту историю в апреле 2017 года, она стала вирусной: её прочитали около 120 000 читателей за три дня.


Я написал первую версию SSH (Secure Shell) весной 1995 года. В то время широко использовались Telnet и FTP.

Но я всё равно разработал SSH для замены и telnet (порт 23) и ftp (порт 21). Порт 22 был свободен и удобно располагался между портами для telnet и ftp. Я подумал, что такой номер порта может стать одной из тех маленьких деталей, которые придадут некоторую ауру доверия SSH. Но как его получить? Я никогда не распределял порты, но я знал тех, кто этим занимается.

В то время процесс выделения портов был довольно простым. Интернет был меньше, и мы находились на самых ранних стадиях интернет-бума. Номера портов выделяла организация IANA (Internet Assigned Numbers Authority). В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойса К. Рейнольдса. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.
Меня откровенно пугал Джон как автор всех основных RFC для Интернета!

Так или иначе, но перед анонсом ssh-1.0 в июле 1995 года я отправил в IANA такое электронное письмо:

From ylo Mon Jul 10 11:45:48 +0300 1995
From: Tatu Ylonen <ylo@cs.hut.fi>
To: Internet Assigned Numbers Authority <iana@isi.edu>
Subject: request for port number
Organization: Helsinki University of Technology, Finland

Уважаемый сэр,

Я написал программу для безопасного входа с одной машины на другую по небезопасной сети. Это значительное улучшение безопасности по сравнению с существующими протоколами telnet и rlogin и их реализациями. В частности, она предотвращает спуфинг IP, DNS и маршрутизации. Мой план состоит в том, чтобы свободно распространять программу в интернете и обеспечить как можно более широкое её использование.

Я хотел бы получить зарегистрированный привилегированный номер порта для программы. Желательно в диапазоне 1-255, чтобы его можно было использовать в поле WKS на нейм-серверах.

Ниже прикладываю проект RFC для протокола. Программное обеспечение локально используется несколько месяцев и готово для публикации, за исключением номера порта. Если можно оперативно присвоить номер порта, я хотел бы выложить программу уже на этой неделе. В настоящее время в бета-тестировании я использую порт 22. Было бы отлично использовать этот номер (в настоящее время в списках он обозначен как «неприсвоенный»).

Название сервиса для программного обеспечения — "ssh" (Secure Shell).

С уважением,

Тату Илонен <ylo@cs.hut.fi>

… затем следуют спецификации протокола ssh-1.0


На следующий день в почтовом ящике лежало письмо от Джойса:
Date: Mon, 10 Jul 1995 15:35:33 -0700
From: jkrey@ISI.EDU
To: ylo@cs.hut.fi
Subject: Re: request for port number
Cc: iana@ISI.EDU

Тату,

Мы присвоили порт 22 для SSH, указав вас контактным лицом.

Джойс


У нас получилось! Теперь у SSH порт 22!!!

12 июля 1995 года в 2:32 утра я анонсировал окончательную бета-версию для своих бета-тестеров в Хельсинкском технологическом университете. В 17:23 выслал тестерам пакеты ssh-1.0.0, а в 17:51 отправил объявление о SSH (Secure Shell) в список рассылки cypherpunks@toad.com. Я также продублировал анонс в несколько новостных групп, списков рассылки и непосредственно отдельным людям, которые обсуждали смежные темы в интернете.


По умолчанию сервер SSH по-прежнему работает на порту 22. Однако бывает иначе. Одна из причин — тестирование. Другая — запуск нескольких конфигураций на одном хосте. Редко бывает, что сервер работает без рутовых привилегий, в этом случае он должен размещаться на непривилегированном порту (т. е. с номером 1024 или больше).

Номер порта можно настроить, изменив директиву Port 22 в /etc/ssh/sshd_config. Он также указывается параметром -p <port> в sshd. Клиент SSH и программы sftp тоже поддерживают параметр -p <port>.


Параметр -p <port> можно использовать для указания номера порта при подключении с помощью команды ssh в Linux. В SFTP и scp используется параметр -P <port> (примечание: заглавная P). Указание из командной строки переопределяет любое значение в файлах конфигурации.
SSH является одним из немногих протоколов, которому часто разрешено работать через файрволы на исходящий доступ, особенно в небольших и технических компаниях. Входящий SSH обычно разрешён к одному или нескольким серверам.

Исходящий SSH


Настройка исходящего SSH в файрволе очень проста. Если есть ограничения на исходящий трафик вообще, просто создайте правило, разрешающее исходящие соединения по порту TCP 22. Вот и всё. Если требуется ограничить адреса назначения, можно создать соответствующее правило, разрешив доступ только к серверам вашей организации в облаке или к jump-серверу, который защищает доступ к облаку.

Обратное туннелирование — это риск


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

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

Но обычно туннелирование нарушает политику безопасности и отнимает контроль у администраторов файрвола и команды ИБ. Например, оно может нарушать правила PCI, HIPAA или NIST SP 800-53. Его могут использовать хакеры и спецслужбы, чтобы оставить бэкдоры в локальной сети.

Программа CryptoAuditor контролирует туннелирование в файрволе или в точке входа в группу облачных серверов. Она работает в связке с Universal SSH Key Manager для получения доступа к ключам хоста, используя их для расшифровки сеансов SSH в брандмауэре и блокировки несанкционированного форвардинга.

Входящий SSH


Для входящего доступа есть несколько вариантов:
  • Настройте файрвол для пересылки всех подключений к порту 22 на определённый IP-адрес во внутренней сети или DMZ. Запустите по этому IP-адресу CryptoAuditor или jump-сервер, чтобы контролировать и проверять дальнейший доступ в организацию.
  • Используйте разные порты на файрволе для доступа к разным серверам.
  • Разрешайте доступ по SSH только после входа в систему с помощью VPN, обычно по протоколу IPsec.

Iptables — это файрвол хоста, встроенный в ядро Linux. Обычно он настроен для защиты сервера, предотвращая доступ ко всем портам, которые не были явно открыты.

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

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Если хотите сохранить правила навсегда, то в некоторых системах это можно сделать командой:

service iptables save

Let's block ads! (Why?)

[Перевод] Раскрыты подробности недавнего запуска на Аляске


Здания Тихоокеанского пускового комплекса на острове Кадьяк, Аляска. Источник: Alaska Aerospace Corp.

WASHINGTON — 20 июля некая неизвестная компания выполнила суборбитальный пуск с космодрома на Аляске; и вот, спустя неделю, появилась хоть какая-то информация: ракета-носитель от Astra Space несмотря на плотную облачность успешно стартовала с Тихоокеанского пускового комплекса на острове Кадьяк, Аляска, в шесть часов вечера по EST.
В марте текущего года Astra Space получила лицензию на проведение суборбитальных тестовых полётов от Управления коммерческих космических перевозок (Office of Commercial Space Transportation, AST) Федерального агентства гражданской авиации (Federal Aviation Administration, FAA). Согласно выданному разрешению, РН стартовала в южном направлении и несла массо-габаритный макет второй ступени; в связи с этим FAA выпустило предупреждение о закрытии района для полётов авиации с 14 по 21 июля включительно.

Удивительно, но при этом мероприятие не появилось в списке лицензированных запусков на сайте агентства, хотя перечень уже содержит более поздние пуски, как орбитальные, так и суборбитальные. В заявлении, опубликованном FAA 24 июля в ответ на запрос SpaceNews, говорится, что запуск состоялся, однако произошли некоторые «накладки».

«Запуск Astra Space, Inc. с Тихоокеанского пускового комплекса на острове Кадьяк в прошлую пятницу, 20 июля, окончился неудачей», — сообщает агентство — «Он был полностью законным и мы наблюдали за этим событием».

Тихоокеанский космодром — в основном известный как Комплекс Кадьяк — находится под управлением корпорации Alaska Aerospace. Крэйг Кэмпбелл, президент и исполнительный директор Alaska Aerospace, 27 июля дал интервью SpaceNews, но предупредил, что его возможность обсуждать подробности ограничена соглашением о неразглашении.

«Наш клиент предпочитает, чтобы мы не обсуждали его дела с прессой», — поясняет он — «Я могу подтвердить, что запуск состоялся, и они в целом остались довольны».

При этом Кэмпбелл не упоминал ни о каких «накладках» или других сопутствовавших инцидентах. «Пока идёт обработка данных, могу лишь сказать, что мы не понесли никакого материального ущерба», — сказал Крэйг — «И мы ожидаем, что Astra Space и дальше будет пользоваться нашим космодромом».

Astra Space одна из множества появившихся за последние год контор, разрабатывающих лёгкие носители для вывода малых спутников; однако она выделяется редкой скрытностью — нет даже публичного веб-ресурса. По крайней мере, точно известно, что базируется компания в Аламеде, Калифорния, арендуя у города территорию бывшей военно-воздушной базы. В документах аренды обозначена деятельность по «предоставлению услуг запуска нового поколения» при помощи ракеты Astra, способной доставить на низкую опорную орбиту до ста килограммов груза.

Комплексом Кадьяк интересуются и другие операторы. Незадолго до Rocket 1 космодром посетили представители Vector, чтобы провести ряд предварительных испытаний для своей РН Vector-R, тестовый полёт которой запланирован в конце этого года. Вероятно, позже здесь обоснуется и Rocket Lab — по их заявлению, Аляска стала одним из четырёх финалистов в отборочном конкурсе на вторую площадку для компании, и в августе отсюда уже стартует первый Electron.

Let's block ads! (Why?)

Кунсткамера: умелец из Массачусетса добивается права на самостоятельный ремонт Tesla

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

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

На самом деле существует далеко ненулевая вероятность (скажем, 148% 99,999%) того, что все эти компании просто стараются побольше заработать. Ремонт во многих случаях — дело недешевое. В качестве примера можно взять замену экрана телефона iPhone в официальном сервисном центре и своими руками (в том случае, если они ровные). В сервисном центре вполне могут взять 100-150 евро за замену экрана обычного iPhone 6, не говоря уже о старших моделях. Если же менять дисплей самому, заказав его из Китая, это обойдется раз в 10 дешевле (цена китайского качественного дисплея для iPhone 6 — около 15 евро). Но те самые крупные компании в прямом смысле слова вставляют палки в колеса умельцам, которые способны ремонтировать все сами.
Так, в 2016 году журналисты смогли раздобыть документальные доказательства того, что Apple выплачивает денежные вознаграждения чиновникам, которые выступают против законопроектов о «праве на ремонт». Эти законопроекты пытались провести сразу в четырех штатах США — Миннесоте, Небраске, Нью-Йорке и Массачусетсе. В них предлагалось обязать производителей электроники, транспортных средств и т.п. предоставлять независимым ремонтным мастерским и индивидуальным лицам программные и аппаратные инструменты, требуемые для выполнения ремонта, которые использует сам производитель.

Сказанное касается не только Apple. Многие другие компании поступают еще хуже. Если корпорация из Купертино хотя бы не препятствует неофициальному ремонту своих устройств (пускай и при помощи деталей вторичного рынка), то такая компания, как John Deere напрямую запрещает самостоятельно обслуживать свои тракторы. И если трактор этой компании ломается, то фермеру из удаленного региона приходится ждать сервис-мэна из ближайшего центра техобслуживания, бросив все. Работа стоит, а специалист может приехать, порой, лишь через пару дней. И хуже всего то, что поломка может быть очень незначительной — например, что-то случилось с ПО трактора.

Tesla тоже против


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

Но даже в том случае, если детали в наличии, то специалисту по ремонту (неофициальному) все равно запрещают что-то делать. В качестве примера можно привести пользователя YouTube с ником Rich Rebuilds. Сам себя он называет «Доктором Франкенштейном Tesla». Дело в том, что он изучает внутренности вышедших из строя электромобилей (утопленников, жертв пожаров и ДТП) и пытается собрать из нескольких «трупов» один живой электромобиль.

Он собирает запчасти от Tesla, которые не поддаются ремонту для того, чтобы использовать их для восстановления электромобилей, которые не безнадежны. «Доктора Франкенштейна» на самом деле зовут Рич Бенуа.

Началось все с того, что он сам хотел приобрести Tesla. Но цена в $80 000 показалась Ричу завышенной. И он начал искать возможность сэкономить, занимаясь изысканиями в сети. Один раз ему попался на глаза привлекательный ценник, но за Tesla, которая побывала в воде. «Утопленники» даже среди обычных автомобилей считаются почти непригодными для использования, а здесь речь шла о высокотехнологичном устройстве с огромным количеством электронных компонентов. «Я подумал, насколько сложно может быть восстановить этот электромобиль? Может быть, бросить его в мешок с рисом?», — шутит Рич.

Наконец, он приобрел несколько вышедших из строя электромобилей, и начал собирать из двух «трупов» живую машину. Все свои действия Рич выкладывал на YouTube, для того, чтобы и другие пользователи сети могли увидеть, что можно, а чего нельзя делать с Tesla.


Сам он — не автомобильных дел мастер, а ИТ-специалист, который имеет неплохую работу в Бостоне. Когда он узнал о Tesla, то электромобили сразу ему понравились. Но через время он понял, что компания вовсе не приветствует попытки заняться DIY-сервисом. К примеру, Tesla не разрешила своему экс-сотруднику открыть магазин запчастей и заниматься ремонтом электромобилей в Дании. Правда, на данный момент у него уже есть официальный договор с компанией.

На данный момент Рич уже восстановил свою первую Tesla (без всяких сервисных центров) и занимается приведением в порядок второго электромобиля. Его работа привлекла внимание сообщества Tesla. Он также открыл группу в Facebook для тех, кто желает купить или продать запчасть от электромобиля Tesla. Сформировалось целое сообщество любителей Tesla-мобилей, которые требуют предоставления права на ремонт. Энтузиасты вступают в группу отовсюду — от Норвегии до Южной Африки.

По словам Рича, он теперь мечтает об открытии неофициального сервисного центра электромобилей Tesla, но боится юридических последствий. «Я бы хотел сделать это, но я знаю, чем все закончилось для тех, кто попытался открыть подобные центры. Они закрывались через несколько месяцев после открытия. И Tesla не давала им необходимые инструменты для работы», — говорит Рич.

Представители компании на данный момент не дают комментарии относительно сложившейся ситуации. Но неофициальные отклики все же есть. И они поразительно похожи на те, что по поводу сторонних сервисных центров говорили в Apple. Речь идет о «необходимости профессионального ремонта, специалистами, которые знают, что делать, чтобы не допустить дальнейших проблем с эксплуатацией транспортного средства, которое выходит на дороги общего пользования». В принципе, доля правды в этом есть — автомобиль это не телефон, если он поломается прямо на дороге, это может повлечь за собой не просто аварию с порчей имущества, но и стать причиной смерти участников ДТП.

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

Надежда все же есть


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

Постановление было анонсировано 25 июля. В штате будет создан специальный комитет, который займется изучением всех нюансов права на ремонт, с рассмотрением точки зрения как тех, кто желает ремонтировать что-либо самостоятельно, так и тех, кто не хочет допустить подобных «вольностей».

В случае подтверждения правоты сторонников права на ремонт в Массачусетсе (а потом, надо думать, и в других штатах) официальных производителей чего бы то ни было обяжут предоставлять неофициальным сервисным центрам инструменты и ПО для выполнения необходимых работ. Речь идет не только об Apple или John Deere, но и о других компаниях, включая Tesla. Компаниями придется предоставлять диагностическое программное обеспечение, доступы к сервисам, обновлениям и заплаткам, необходимым сторонним ремонтникам.

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

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

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

В 2015 году представители лагеря сторонников права на ремонт одержали победу при помощи специалистов по авторскому праву, которые работали абсолютно бесплатно. В этом процессе участвовали Electronic Frontier Foundation, Public Knowledge, Институт интеллектуальной собственности Южной Калифорнии и многие другие. Усилия увенчались успехом — Бюро авторского права США в 2015 году утвердило больше исключений, чем когда-либо. Одно из исключений касалось ремонта тракторов.

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

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

Хотелось бы надеяться, что в Массачусетсе смогут добиться своего — а за этим штатом последуют и другие регионы и страны.

Let's block ads! (Why?)

Opera вышла на биржу

27 июля 2018 года компания Opera Ltd., разработчик одноимённого браузера, провела публичное размещение акций на бирже Nasdaq. Размещение прошло удачно. В первые часы торгов стоимость акций выросла на 30% от цены предложения $12, достигнув максимума в $15,62.

Всего в первый день торгов продано акций на сумму $115 млн. Это немалые деньги, которые компания потратит на совершенствование браузера и других своих продуктов. Согласно сопроводительным документам для инвесторов, Opera планирует использовать деньги «в исследования и разработку программного обеспечения искусственного интеллекта с целью его использования со службами обнаружения контента, а также для маркетинга, партнёрских отношений и приобретений». Сейчас около 25% сотрудников Opera работает над Opera News и платформой ИИ.

В общем, от недостатка финансов Opera точно не будет страдать. Капитализация корпорации исходя из текущей стоимости акций составляет $1,2 млрд.
У компании Opera богатая история. Её основали в 1995 году два норвежца: Йон Стефенсон фон Течнер и Гейр Иварсёй.

Гейр Иварсёй был ведущим разработчиком в компании Opera Software и умер в 2006 году после продолжительной борьбы с раком. На странице «О программе» браузера Opera (начиная с 9-й версии) размещено посвящение «Памяти Гейра Иварсёй (Geir Ivarsøy)».

Второй сооснователь Йон Стефенсон фон Течнер покинул Opera Software в 2011 году, а позже основал компанию Vivaldi Technologies, половина сотрудников которой раньше работали в Opera. В 2016 году вышла первая стабильная версия Vivaldi — браузера «для опытных пользователей, которые хотят больше пользоваться возможностями браузера по умолчанию, а не ставить расширения».


Браузер Vivaldi

Для своего времени Opera стал по-настоящему революционным браузером. Первая общедоступная версия вышла в 1996 году как условно-бесплатная программа. Браузер привлекал невероятной скоростью работы по сравнению с конкурентами Netscape Navigator и Internet Explorer. Собственно, программа и распространялась под девизом «самый быстрый браузер на Земле» («the fastest browser on Earth»). Например, вот исторические результаты тестов на скорость всех браузеров на компьютере Intel Pentium 3 800 МГц с 256 МБ RAM.

Как видим, Opera побеждает абсолютно во всех тестах под Windows. В некоторых тестах её преимущество подавляющее. Обычным пользователям не нужны были тесты — разница в скорости работы была очевидна и без них. Поэтому Opera стала одним из самых любимых браузеров на постсоветском пространстве, где фактор платности программного обеспечения не имел особого значения.

В мире Opera стала третьим по популярности браузером в то время — и у неё сложился круг преданных фанатов. Во время бума доткомов, когда основатели Netscape стали мультимиллионерами, Йон Стефенсон фон Течнер отказался выводить компанию на биржу. Возможно, тем самым он спас компанию, когда пузырь лопнул.

Тем не менее, в 2004 году фирма всё-таки провела IPO на норвежской бирже и привлекла около $20 млн. А в 2016 году случилась известная сделка, когда консорциум китайских инвесторов купил браузерное направление Opera Software за $575 млн. Эта компания теперь называется Opera Ltd. Именно она сейчас выпустила акции на бирже Nasdaq.


Китайские владельцы Opera Ltd. радуются успешному IPO 27 июля 2018 года

Сегодня Opera получает больше половины дохода по партнёрским поисковым соглашениям с Google и «Яндексом». В проспекте для размещения акций это указано как фактор риска — доходы слишком зависят от небольшого количества партнёров. За первые три месяца 2018 года Opera получила прибыль $6,6 млн при доходе $39,4 млн. Это примерно на 55% больше, чем за тот же период прошлого года.

Финансовый директор компании Фроде Якобсен (Frode Jacobsen) говорит, что партнёрство с Google взаимовыгодное: Opera сотрудничает с Google более десяти лет и периодически продлевает контракт. Последнее трёхлетнее соглашение подписано в конце 2017 года.

В 2018 году по статистике StatCounter у десктопного и мобильного браузеров Opera около 3,5% мирового рынка.

Let's block ads! (Why?)

[Перевод] Против пораженческих настроений в приватности. Почему браузеры всё-таки могут остановить фингерпринтинг

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

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

Вопрос в следующем: насколько эффективен фингерпринтинг? То есть насколько уникален отпечаток устройства типичного пользователя? Ответ имеет большое значение для приватности в интернете. Но изучать этот вопрос с научной точки зрения трудно: хотя у многих компаний есть огромные базы отпечатков, они не делятся ими с исследователями.
Первый масштабный эксперимент по снятию отпечатков под названием Panopticlick запустил Фонд электронных рубежей в 2009 году. Сотни тысяч добровольцев посетили сайт panopticlick.eff.org и согласились на снятие отпечатка своего браузера для исследования. Эксперимент показал удивительный результат: у 83% пользователей во всей выборке обнаружились уникальные отпечатки. У пользователей с включенными Flash или Java отпечатки ещё более уникальные: 94%. Эксперимент исследователей из INRIA во Франции с ещё большей выборкой показал в целом аналогичный результат. Между тем, разные исследователи, в том числе и мы, говорили о том, что в браузерах увеличивается количество функций, которые можно использовать для фингерпринтинга: Canvas, Battery, Audio и WebRTC.

Вывод был ясен: фингерпринтинг крайне эффективен. Браузер не может справиться с этой угрозой, выдавая скриптам меньше информации: слишком много утечек информации, слишком много векторов атаки. Последствия серьёзные. Разработчики браузеров пришли к выводу, что не могут справиться со сторонней слежкой, и поэтому защиту приватности отдела на откуп расширениям. [1] Но эти расширения тоже не стремились ограничить фингерпринтинг. Большинство из них работали по сложной схеме: они блокировали тысячи скрипты-трекеры по вручную составленным спискам, постоянно играя в догонялки, когда появлялись новые игроки.

Но вот случился поворот: команде INRIA (включая некоторых авторов предыдущих исследований) удалось договориться с крупным французским веб-сайтом и протестировать его посетителей на отпечатки. Результаты опубликованы несколько месяцев назад, и на этот раз результаты совершенно иные: только у трети пользователей оказались уникальные отпечатки (по сравнению с 83% и 94% ранее), несмотря на использование исследователями полного набора из 17 признаков. Для мобильных пользователей число ещё ниже: менее 20%. Эти различия объясняются двумя причинами: увеличением выборки в новом исследовании и тем, что самоотбор участников, как представляется, привнёс в предыдущие исследования определённую предвзятость. Есть и другие факторы: интернет постепенно избавляется от плагинов, таких как Flash и Java, так что возможность фингерпринтинга должна и дальше снижаться. Внимательное изучение результатов показывает, что самое простое вмешательство браузеров для ограничения атрибутов с максимальной энтропией значительно улучшит способность пользователей скрываться в толпе.

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

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

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

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

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

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

[2] В эксперимент взяли пользователей, которые раньше подтвердили согласие на приём куков, но специально их не информировали об исследовании. [вернуться]

Let's block ads! (Why?)

Система распознавания лиц Amazon Rekognition приняла 28 конгрессменов США за преступников

Американский союз гражданских свобод (American Civil Liberties Union, ACLU) продолжает кампанию против использования систем распознавания лиц федеральными агентствами и полицией. ACLU настаивает, что качество этих систем слишком низкое для реального использования. В результате будет много ложных срабатываний, из-за чего пострадают невинные люди. Пытаясь убедить Конгресс США запретить использование этих систем, правозащитники предприняли дерзкую, но эффективную акцию: они прогнали через систему распознавания лиц Amazon Rekognition всех американских конгрессменов. Результат оказался немного предсказуем: система распознала 28 конгрессменов как преступников. Фотографии «героев» на скриншоте вверху.
Amazon агрессивно продвигает свою систему распознавания лиц. Недавно стало известно, что корпорация заключила контракты с полицейскими подразделениями округа Вашингтон, штатов Орегон и Флорида. Руководитель компании Джефф Безос позиционирует Rekognition как эффективный инструмент распознавания лиц в реальном времени, в том числе по видеопотоку, который поступает с носимых видеокамер на униформе полицейских.

Это напоминает систему, которую в этом году начали тестировать в некоторых городах Китая, в том числе в городе Чжэнчжоу (провинция Хэнань на востоке центральной части Китая). Там полицейским выдали специальные очки с видеокамерами, которые тоже подключены к программному обеспечению для распознавания лиц.

Гаджеты выдали в первую очередь сотрудникам транспортной полиции, которые работают на оживлённой железнодорожной станции Восточный Чжэнчжоу, потому что перед их глазами проходит больше всего людей. Очки специально разработаны для полиции и подключены к наладонному компьютеру. После сканирования лица прохожего компьютер подключается к центральной базе данных, где осуществляется поиск совпадений. Эксперимент доказал свою эффективность: к 6 февраля полиции удалось идентифицировать семь беглецов, которые обвиняются в скрытии с места ДТП и торговле людьми.

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

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

Результаты тестов ACLU показали, что Rekognition ошибочно приняла изображения 28 невинных конгрессменов за преступников. Интересно, что неправильные срабатывания искажены в сторону людей с чёрным цветом кожи. Среди «пострадавших» конгрессменов таких 39%, хотя в реальности темнокожие конгрессмены составляют лишь 20% нижней палаты парламента. Такие результаты подтверждают опасения представителей чернокожих групп, которые изложены в письме Congressional Black Caucus в адрес Amazon, что использование системы распознавания лиц может иметь «глубокие негативные непреднамеренные последствия» для чернокожего населения, незаконных мигрантов и участников акций протеста. В самом деле, есть признаки того, что система чаще ошибается при сравнении чернокожих лиц, особенно женщин.

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

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

Сканирование произведено на общедоступном сервисе Amazon Rekognition, стоимость услуги составила $12,33. Для сравнения с фотографиями 535 конгрессменов и сенаторов выбрали 25 000 публично доступных фотографий людей в наручниках. Тест проводился с настройками по умолчанию. 28 ошибок означают примерно 5% ложноположительных срабатываний. Теоретически это может и неплохой результат, но если применить её на тысячах лиц, то это означает множество невинных людей, которых подвергнут обыскам из-за ошибки программы.

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

ACLU призвал Конгресс «ввести мораторий» на использование данной технологии, пока она не начнёт выдавать приемлемую точность.

Let's block ads! (Why?)

Жертвы GDPR: кто уже прекратил работу из-за нового регулирования персональных данных

Европейский общий регламент по защите данных вступил в силу два месяца назад. Пока IT-сектор размышляет о будущем крупных информационных гигантов, перемены уже происходят и на более низком уровне: многие компании закрылись, другие — пытаются адаптироваться.


/ фото SounderBruce CC

Цена слишком высока


Цель GDPR — ужесточить контроль за обработкой персональных данных пользователей. Потому новое законодательство накладывает на компании большое количество требований. И хотя это должно принести выгоду IT-сектору в долгосрочной перспективе (так как вопросы, связанные с регулированием этой сферы, станут прозрачнее), сейчас нововведения дорого обходятся некоторым компаниям. И не все смогли решить этот вопрос.

Так, перед введением GDPR, о прекращении работы объявил ряд онлайн-игр. Например, Super Monday Night Combat и Loadout.

Активный период разработки Loadout, запустившейся в 2012 году, давно закончился. Однако чтобы соответствовать новым требованиям GDPR, команде проекта нужно было бы вложить значительные ресурсы в разработку: перебрать клиент, обновить базы данных и серверы. По словам СЕО Loadout Роба Коэна (Rob Cohen), это того не стоило. Большинство игроков Loadout — из ЕС, поэтому рассчитывать на выживание проекта без них тоже не приходилось.

По той же причине закрылась Super Monday Night Combat, также выпущенная в 2012 году. По словам её создателей, бюджет, необходимый для переделки проекта в соответствии с требованиями GDPR, превышает бюджет, выделяемый шестилетней игре.

Помимо компьютерных игр, «под ударом» оказались сервисы, которые предполагают хранение персональных данных в распределенных реестрах. Например, закрылся сервис проверки биографических данных PICOPS. По сути, он «связывал» личность человека с адресом в Ethereum-блокчейне. Согласно заявлению создателей, сервис пользовался огромным успехом, но сохранить все его функции, которые делали его полезным, и одновременно выполнить все требования GDPR, оказалось невозможным.

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

Временные (?) меры


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

И хотя для ряда проектов это не было выходом (тот же Loadout), были и те, кто пошел на такой шаг. Например, геймеры из Европы потеряли возможность играть в Ragnarok Online: компания закрыла европейские серверы и ограничила доступ по IP.


/ фото Tony Webster CC

К блокировкам по IP прибегли и некоторые американские СМИ, получающие трафик из Европы. Заблокировали доступ к своим сайтам с европейских IP Los Angeles Times и Chicago Tribune. Однако такие методы подвергаются критике сообщества.

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

Падение рекламных объемов


Но есть и менее очевидные последствия. Так, от введения GDPR пострадали европейские рекламные биржи, размещающие онлайн-рекламу по технологии программатик. 25 мая (дата вступления GDPR в силу) рекламные объемы обвалились: падение составило от 25 до 40% между разными компаниями.

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

USA Today сохранили доступ для европейских пользователей на сайт, но убрали оттуда всю рекламу. The New York Times временно не отображала объявления через программатик в Европе.

Спустя месяц, объемы рекламы начали постепенно восстанавливаться, однако по разным отраслевым оценкам многие рекламодатели всё еще тратят на 30% меньше денег, чем до 25 мая.

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

На сайте, где ведут учёт «жертв» GDPR, сейчас около 20 наименований. Какие-то сервисы закрылись полностью, какие-то — заблокировали доступ с европейских IP.

Интересно, что даже крупнейшие IT-компании были вынуждены пойти на сокращения: так, Twitter закрыл свои приложения для Roku, Android TV и Xbox.

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



P.S. Несколько материалов из Первого блога о корпоративном IaaS:
P.P.S. Посты по теме из нашего блога на Хабре:

Let's block ads! (Why?)

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 5: «Откуда берутся ошибки систем безопасности», часть 1

Массачусетский Технологический институт. Курс лекций #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

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

Пол Ян: добрый день, меня зовут Пол Ян, я закончил MIT в 2004 году, получил степень магистра в сфере инженерии и компьютерных наук и до 2010 года работал в компании Oracle. Cейчас я работаю техническим директором в компании iSec Partners. Раньше я даже не знал, что такие компании существуют. Наша компания занимается консалтингом в области компьютерной безопасности, тестированием на проникновения (пентестинг), сетевой безопасностью, мы занимаемся изучением хакерских программ, находим различные уязвимости и ликвидируем их.

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

  • что такое «ошибки безопасности»?
  • доверительные отношения;
  • примеры ошибок, встречающихся в реальной жизни;
  • операция «Аврора»;
  • Stuxnet;
  • мне нравится заниматься проблемами безопасности, что я должен делать?

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

Итак, давайте начнём с рассмотрения того, что такое ошибки безопасности. Но прежде чем начать говорить об этом, сначала определим, что означает само понятие безопасности.

Айвен Арч сказал: «Система безопасна, если она ведёт себя точно так, как задумано, и больше ничего не делает". Системы становятся всё более и более сложными. Если мы говорим об операционных системах, кто может сказать, для чего точно они предназначены и что конкретно позволяют делать?

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

В качестве примера рассмотрим, как Администрация транспортной безопасности TSA определяет модель угрозы. Цель обеспечения безопасности Международного аэропорта Логан состоит в том, чтобы предотвратить проникновение запрещённых предметов, таких, как например, пена для бритья, на борт воздушного судна. Модель угрозы представляет собой два пункта:

  • каковы возможные пути проникновения запрещённых вещей в аэропорт?
  • где находятся «точки входа» этих вещей на территорию аэропорта?

Как вы можете пронести запрещённые предметы мимо охраны? Как вы попытаетесь атаковать их систему безопасности? Вы можете пронести их там, где нет проверки, воспользовавшись привилегиями VIP-пасажира, спрятать их среди других вещей либо воспользоваться услугой других авиалиний для доставки в аэропорт запрещённых вещей.

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

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

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

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

Обычно разработчиков программного обеспечения заботит функциональность и возможности своего продукта, а не его безопасность. Все покупают ПО из-за его возможностей, а не из-за его безопасности. Поэтому безопасность всегда остаётся на втором месте и разработчики начинают заботиться о ней только после того, как продукт пострадает от злоумышленников. Обычно инженеры видят только малую часть «мозаики», они не обращают внимания на технические детали. Сможете ли вы ответить на вопрос, сколько строк кода содержит Linux 2.6.32, Windows NT4 и Adobe Acrobat?

Правильные ответы в порядке перечисления программ – от 8 до 12,6 миллионов строк, 11-12 миллионов и 15 миллионов. Действительно, всех обычно удивляет, что «Акробат» содержит больше строк программного кода, чем «Linux» и «Windows». Таким образом, даже то ПО, которое мы считаем простым, в действительность чрезвычайно сложное.

Проблемами безопасности интересуются следующие категории людей:

  • инженеры;
  • преступники;
  • исследователи безопасности;
  • тестеры на проникновение (пентестеры);
  • правительства;
  • хактивисты;
  • представители научных кругов.

Я выделил всего 6 категорий, но вероятно, их больше. Рассмотрим, что интересует первую категорию людей – преступников.

Их цель – ресурсы, с помощью которых можно завладеть чужими деньгами (ботнет, CC#s, спамерская рассылка «писем счастья») и при этом не попасть за решётку. Для достижения цели они используют самые новейшие хакерские эксплойты, использующие уязвимости ПО. Они не нуждаются в привилегиях доступа к данным, а просто крадут их, используя уязвимости, оставленные разработчиками. Чаще всего объектами атаки являются кредитные карты и всё, что с ними связано. Поэтому доступ к чужим деньгам преступники получают с помощью денег, покупая данные у хакеров, или используя метод тестирования Чёрного Ящика. Это метод тестирования «софта» по функциональной спецификации и требованиям, не используя при этом внутреннюю структуру кода или доступ к базе данных. При этом исходный код разбирается на составляющие, что позволяет обнаружить бреши в защите программы.

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

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

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

Третья категория наиболее полезная в деле обеспечения безопасности – это тестировщики на проникновение (пентестеры).

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

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

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

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

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

Их цель – сделать «что-то хорошее», в их понимании этого слова, и не попасть за это в тюрьму. Иногда я соглашаюсь с тем, что они делают, иногда – нет.

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

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

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

Все эти группы людей используют похожую технику и ищут одно и то же: уязвимые системы. Если у них есть доступ, они производят обзор исходного кода, используют интервью с инженерами или выполняют тестирование в контролируемой среде. Если доступа нет, они выполняют тестирование Чёрного Ящика, занимаются технологией fuzzing (например, вводят случайные данные и смотрят, как на это отреагирует система), делают техническое копирование Reverse Engineering (использование двоичных файлов программного кода) и занимаются социальной инженерией.

«Фаззингу» подвержены многие сложные программные системы, например, тот же Acrobat Reader – здесь проверяется возможность переполнения буфера с помощью специально созданных объёмных документов в .pdf формате. Такой документ «загоняется» в «Акробат» чтобы проверить, способен ли он вызвать сбой системы.

Социальная инженерия является самым простым и быстрым способом нахождения проблем безопасности путём взлома аккаунтов в социальных сетях.

Итак, давайте погрузимся в предмет лекции и рассмотрим уязвимости, которые мы ищем.

Инженеры часто допускают ошибки относительно того того, как должны работать системы и как они будут работать после создания. Примером катастрофической ошибки в программном обеспечении, приведшей к смерти людей, является программа для аппарата лучевой терапии Therac-25. Неверная работа системы безопасности аппарата привела к тому, что как минимум 6 человек получили огромные дозы радиации, два человека – смертельные. Я расскажу вам об этом в общем, без упоминания деталей и принципов работы этого облучателя.

Программное обеспечение этого медицинского аппарата предусматривало два режима использования облучателя. Первый, X-Ray image, режим рассеивания электронов, при котором радиационное облучение было минимальным, не предусматривал использования защитного фокусирующего экрана. Второй режим Radiation Treatment обеспечивал мощный режим облучения, при котором больное место подвергалось направленному пучку радиоактивного излучения мощностью 25 МэВ. Для этого между пациентом и излучателем помещался защитный фокусирующий экран.

На следующем слайде показано, как выглядел программный код, управляющий работой защитного экрана. Вы видите, что в одной строке располагались однобайтовые данные, сообщающие, нужна или нет установка защитного экрана на место. Если эта величина равнялась 1, экран устанавливался, если она равнялась 0, экран убирался. Проблема состояла в том, что внутри программы при вводе параметра, равного 0, например, если врач вручную корректировал мощность облучения до 0, происходило деление величины излучения на 0. Так как деление на 0 является недопустимой операцией, происходило переполнение буфера, программа давала сбой и мощность излучения автоматически принимала максимально возможное значение при отсутствии защитного экрана.

Здесь разработчики использовали ошибочное предположение, что в режиме Radiation Treatment параметр использования защитного экрана всегда будет принимать не нулевое значение, переполнения буфера никогда не произойдёт и программа никогда не даст сбой. В результате этого неверного предположения погибли люди, потому что при сеансе без экрана в режиме Radiation Treatment они получили смертельный радиационный ожог.

Узнав об этом случае, мой однокурсник сказал: «Я сделал для себя вывод, что никогда не буду писать медицинское программное обеспечение».

Большой вред могут принести неверные предпосылки при разработке программного обеспечения, примером чего является система аккаунтов amazon.com.

Этот интернет магазин позволяет следующее:

  • вы можете добавить в свой аккаунт кредитную карту или электронный почтовый ящик с именем и физическим адресом;
  • Amazon даёт вам возможность сменить пароль к аккаунту через зарегистрированный почтовый ящик;
  • Amazon позволяет вам видеть 4 последних цифры номера кредитной карты;
  • Apple предоставляет вам возможность войти в свой аккаунт, используя 4 последних цифры номера кредитной карты;
  • Gmail позволяет изменить аккаунт Apple через аккаунт в Twitter.

Какие неверные предпосылки позволили создать эту порочную цепочку? Неправильные политики безопасности, выраженные в первом и четвёртом пунктах. Отсюда следует вывод: компоненты, влияющие на вашу систему, часто находятся за пределами вашего внимания (Facebook, Amazon, Apple). Поэтому злоумышленник может завладеть данными вашей кредитной карты через аккаунт на amazon.com, используя возможности этих трёх независимых систем. Это можно считать полной моделью угрозы.

Поэтому ответьте на вопрос: является ваш пароль к персональному почтовому ящику надёжней или слабее пароля, который вы используете для онлайн-банкинга?

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

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

Если вы хотите стать инженером, который разрабатывает компьютерные системы, вам нужно думать так, как думает исследователь проблем безопасности:

  • какие предпосылки нужно использовать для обеспечения безопасности при разработке дизайна системы?
  • какие предпосылки являются неверными?
  • что вы можете нарушить, если предпосылка оказалась неправильной?

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

Управлять памятью – трудное дело.

В качестве примера я приведу вам упрощённую схему протокола установления безопасной связи:

  • избегать пересмотра, или переустановления контакта;
  • Алиса: «Боб, если ты здесь, скажи «бу»!
  • Боб: «Бу!»
  • в результате Алиса и Боб считают, что очень хорошо знают друг друга.

Технически этот протокол выглядит так:
  • Алиса посылает пакет, содержащий пинг;
  • пакет имеет определённую длину данных;
  • Боб возвращает назад пакет той же длины.

При этом Боб производит разбор присланных Алисой данных:

Просматривает длину данных и их расположение в буфере. Затем он готовит Алисе ответ, добавляя 2 байта к длине запроса Алисы, копирует в ответ новую длину запроса Алисы и высылает его ей обратно:

Видите ли вы здесь какую-нибудь проблему? Где здесь уязвимость?

Она заключена во второй и четвёртой строках ответа Боба. Размер данных, передаваемых пользователем, может не совпадать с фактическим размером данных. Протокол установления связи TSL использует открытый протокол шифрования SSL. Так работает примерно 60% серверов, имеющихся в Интернете. Боб, то есть сервер, никогда не проверяет фактическую длину полученных данных. Из-за того, что сервер добавляет 2 байта, пользователь может прочитать около 64 КB данных памяти сервера, включая частные ключи.

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

Иногда к нам обращаются компании и говорят, что обнаружили такую уязвимость и как её можно исправить. Мы отвечаем им: «никак, вам просто необходимо немедленно поменять ключи шифрования». Поэтому обязательно нужно проводить мониторинг отличий, возникающих в Open SSL при обмене данными.

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

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

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

В 2014 году злоумышленникам удалось создать дополнения браузера Yahoo, которые с помощью ботнет заражали компьютеры пользователей вредоносными программами. Они использовали конкретные ошибки Java-скриптов, позволяющие установить на компьютеры 6 типов вредоносного кода.

Одна из уязвимостей заключалась в том, что неправильно изолированные входные данные пользователей выполнялись браузером как java-скрипты, которые перенаправляли пользователей к набору вредоносных программ под названием Magnitude через уязвимость XSS. Этот Magnitude использовал новейшие уязвимости «нулевого дня» в Yahoo, из-за чего с 30 декабря 2013 по 3 января 2014 года заражение в вирусом происходило с интенсивностью 27000 компьютеров в час. В этом случае использование ботнет было очень эффективным.

Решением проблемы стал механизм отключения выполнения java-скриптов на странице браузера и внедрение функции «click-to-play» в браузере Chrome.

Ещё один тип атак использует принцип Confused Deputy – это подозрительное доверие приложений к принимаемым данным. Под это определение попадает довольно широкий круг проблем безопасности. Такой тип уязвимости получил название Cross-Site Request Forgery (сокращенно CSRF или XSRF), что означает «подделка межсайтовых запросов». Подделка запроса авторизации заставляет вас делать то, что вы не собирались сделать.

Исследователи проблем безопасности из Microsoft и люди науки рассмотрели возможность совершать в Интернете бесплатные покупки. Эта возможность появляется при использовании третьей стороны, выступающей в качестве платёжной системы с кассовой услугой Cashier as a Service. Вы знаете много сайтов, которые предлагают провести платёж через «foo…», вы кликаете по такой ссылке, и вас перенаправляют на сайт платёжной системы.

В процессе покупки участвуют трое: продавец, провайдер платёжной системы CaaS и читер-покупатель. Отношения между тремя сторонами проходят через пользователя. На следующем слайде показана схема такой покупки.

Вы, обращаетесь к владельцу онлайн-магазина и говорите, что хотите купить книгу. Он отвечает вам, что для этого вам нужно заплатить $10 его платёжному сервису CaaS за операцию 123. Вы обращаетесь к «кассиру» и говорите: «вот $10 для TxID:123». CaaS сообщает магазину: «оплата произведена». Магазин говорит: «ОК». Транзакция завершена.

Кто-нибудь видит, как можно атаковать эту систему расчетов? Какая тут имеется уязвимость? Правильно, здесь нет подтверждения того, что сумма проведённой оплаты совпадает со стоимостью товара! Если вы обратите внимание на операции 3 и 4, то увидите, что здесь нет никакой информации о том, какая сумма фактически была переведена. На следующем слайде показано, как можно совершить практически бесплатную покупку, используя уязвимость системы – вместо $10 покупатель переводит всего $1, и транзакция всё равно считается подтвержденной.

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

Ещё больше случаев непредвиденного взаимодействия возникает при управлении паролями.
Количество успешных атак паролей пользователей постоянно растёт благодаря увеличению вычислительных способностей компьютеров, росту скорости вычислений и использованию большого количества реальных паролей для пользовательских словарей хакеров. Это не означает, что пользователи используют пароли типа «аааааа» или «аааааб», но часто разные пользователи используют одни и те же пароли. Возникает ситуация, когда большое число взломанных паролей позволяет хакерам создавать более объёмные словари для хакерского ПО, что, в свою очередь, способствует взлому ещё большего числа паролей. Здесь возникает обратная связь, и техника взлома паролей постоянно совершенствуется.

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

Расширения браузеров сами по себе являются интересными вещами.

Некоторые плагины позволяют безопасно взаимодействовать с разными доменами, и если вы переходите с одного домена на другой, они автоматически очищают кукиз и останавливают работу по обмену данными с незнакомым доменом. Примером может служить плагин Cloud To Butt Plus для браузера Chrome. Он располагается на панели браузера и позволяет безопасно взаимодействовать с любым доменом.

Создание безопасного браузера является сложной задачей, потому что все компоненты, обеспечивающие его работу, такие как java-скрипт или Flash-player, должны реализовывать одну и ту же оригинальную политику безопасности. Компоненты браузера должны исключать возможность неконтролируемого взаимодействия и воздействия одного домена на другой. Примером служит сайт нашей компании www.isecpartners.com, который не позволяет нам прочитать ваш адрес электронной почты, когда вы авторизовались на сайте, и не навязывает вам наши кукиз.

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

Браузеры создаются ведущими инженерами крупных компаний, например, Google, поэтому стоят очень дорого. А расширения для браузеров создают сторонние разработчики. Расширения становятся всё более популярными, и злоумышленники пользуются этим. Они связываются с разработчиками и говорят: «эй, продай мне это расширение за $10000»! После чего злоумышленник превращает дополнение во вредоносное ПО, изменяя скрипты веб-страницы, а затем бесплатно распространяет или продаёт это модифицированное расширение пользователям. После того, как пользователь установит такое расширение, он подвергнется атаке. Примером может служить то, что тысячи пользователей Chrome пострадали в январе 2014 года после того, как спамеры купили расширение и превратили его в эксплойт.

Вернёмся к обсуждению расширений браузеров, которые управляют паролями. Они обеспечивают безопасность, преследуя такие цели:

  • безопасная отправка паролей третьей стороне;
  • общая безопасность приложений пользователя;
  • простота использования;
  • генерирование надёжных паролей;
  • безопасное хранение паролей.

Наша компания занимается исследованием первых трёх целей. Ответьте, кто из вас использует менеджеры паролей? Всего пару человек. А кто из вас использует программы для хранения паролей 1password или LastPass и сервис для сокрытия адреса своего электронного почтового ящика Mask Me? Давайте рассмотрим эти программы.

Программа 1password в действительности не обеспечивает безопасность приложений, потому что предлагает функцию «тихого» обновления через HTTP с использованием неподписанных пакетов. Кроме того, она запускается с правами привилегированного пользователя компьютера.

При этом функцию автозаполнения и автопосылки заполненных форм предоставляет только LastPass, программа Mask Me имеет только функцию автозаполнения формы, а 1password вообще не имеет этих функций. Функции автоматизации существенно облегчают удобство использования программы, так как пользователю не нужно каждый раз вводить множество данных, но также увеличивают возможность использования вредоносных эксплойтов, если в системе имеется уязвимость.

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

  • различия между HTTP и HTTPS;
  • заполнение учётных данных в iframes;
  • кросс-доменные запросы;
  • различия между поддоменами (субдоменами);
  • идентификация страниц входа.

Разница между незащищённым соединением HTTP и безопасным HTTPS играет большую роль в обеспечении безопасности. Если не обращать внимание на появляющийся в строке браузера адрес, можно легко попасть вместо безопасного сайта на фишинговый сайт. При этом атаки SSL stripping могут легко «вскрыть» ваш пароль.

Здесь также могут использоваться атаки перенаправления, когда с безопасного сайта https:// example.com вас перенаправляют на опасный http:// example.com. Если менеджер пароля использует автозаполнение форм, то вы можете зарегистрироваться на фальшивой странице. Программа Mask Me имеет уязвимость, потому что использует не только автозаполнение, но и посылку заполненной формы, что поможет злоумышленнику украсть ваш пароль.

33:35 мин

Продолжение:

Курс MIT «Безопасность компьютерных систем». Лекция 5: «Откуда берутся ошибки систем безопасности», часть 2


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

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

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

Let's block ads! (Why?)

[Перевод] Браузерный сетевой шутер на Node.js

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

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


Поиграть в готовую игру можно здесь! При нажатии клавиш W или «вверх» корабль приближается к курсору, при щелчке мыши — стреляет. (Если никого нет онлайн, то чтобы проверить, как работает мультиплеер, откройте два окна браузера на одном компьютере, или одно из них на телефоне, ). Если вы хотите запустить игру локально, то полный исходный код выложен на GitHub.
При создании игры я использовал графические ресурсы из Kenney's Pirate Pack и игровой фреймворк Phaser. В этом туториале вам отведена роль сетевого программиста. Начальной точкой будет полностью функциональная однопользовательская версия игры, а нашей задачей будет написание сервера на Node.js с использованием Socket.io для сетевой части. Чтобы не перегружать туториал, я сосредоточусь на частях, относящихся к мультиплееру, и пропущу концепции, относящиеся к Phaser и Node.js.

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

Давайте приступим.

1. Подготовка


Я выложил заготовку проекта на Glitch.com.

Подсказки по интерфейсу: превью приложения можно запустить, нажав на кнопку Show (вверху слева).


В вертикальной боковой панели слева содержатся все файлы приложения. Для редактирования этого приложения необходимо создать его «ремикс». Так мы создадим её копию в своей учётной записи (или «форк» в жаргоне git). Нажмите на кнопку Remix this.

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

Сейчас, прежде чем двигаться дальше, вам важно познакомиться с игрой, в которую мы будем добавлять многопользовательский режим. Посмотрите на index.html. В нём есть три важные функции, о которых нужно знать: preload (строка 99), create (строка 115) и GameLoop (строка 142), а также объект игрока (строка 35).

Если вы предпочитаете обучаться практикуясь, то убедитесь, что разобрались в работе игры, выполнив следующие задания:

  • Увеличьте размер мира (строка 29)заметьте, что есть отдельный размер мира для внутриигрового мира и размер окна для самого холста страницы.
  • Сделайте так, чтобы двигаться вперёд можно было и при помощи «пробела»(строка 53).
  • Измените тип корабля игрока (строка 129).
  • Замедлите движение снарядов (строка 155).

Установка Socket.io


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

Первое, что нам нужно сделать — установить модуль Socket.io. В Glitch это можно сделать, перейдя в файл package.json, а затем или введя необходимый модуль в зависимостях, или нажав Add package и введя «socket.io».


Теперь как раз подходящее время, чтобы разобраться с логами сервера. Нажмите на кнопку Logs слева, чтобы открыть лог сервера. Вы должны увидеть, что он устанавливает Socket.io со всеми её зависимостями. Именно здесь нужно искать все ошибки и выводимые данные серверного кода.

Теперь перейдём в server.js. Именно здесь находится наш серверный код. Пока здесь есть только некий базовый boilerplate-код для обслуживания нашего HTML. Добавим в верхнюю часть файла строку, чтобы включить Socket.io:
var io = require('socket.io')(http); // вставьте это после определения http

Теперь нам также нужно включить Socket.io в клиенте, так что давайте вернёмся к index.html и добавим внутрь тега <head> такие строки:
<!-- Загрузка сетевой библиотеки Socket.io -->
<script src="/socket.io/socket.io.js"></script>

Примечание: Socket.io автоматически обрабатывает подгрузку клиентской библиотеки по этому пути, поэтому эта строка работает, даже если в ваших папках нет каталога /socket.io/.

Теперь Socket.io включена в проект и готова к работе!

2. Распознавание и спаунинг игроков


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

Принятие соединений на сервере


Добавьте этот код в нижнюю часть server.js:
// Приказываем Socket.io начать принимать соединения
io.on('connection', function(socket){
    console.log("New client has connected with id:",socket.id);
})

Так мы просим Socket.io слушать все события connection, которые автоматически происходят при подключении клиента. Библиотека создаёт новый объект socket для каждого клиента, где socket.id — это уникальный идентификатор этого клиента.

Чтобы проверить, что это работает, вернитесь в клиент (index.html) и добавьте куда-нибудь в функцию create эту строку:

var socket = io(); // Это запустит событие 'connection' на сервере

Если запустить игру и посмотреть на лог сервера (нажмите на кнопку Logs), то вы увидите, что сервер зарегистрировал это событие соединения!

Теперь при подключении нового игрока мы ожидаем, что он передаст нам информацию о своём состоянии. В нашем случае нам необходимо знать по крайней мере x, y и angle, чтобы правильно создать его в нужной точке.

Событие connection было встроенным событием, запускаемым Socket.io. Мы можем слушать любые самостоятельно задаваемые события. Я назову своё событие new-player, и буду ожидать, что клиент отправит его, как только он подключится с информацией о своём положении. Это будет выглядеть так:

// Приказываем Socket.io начать принимать соединения
io.on('connection', function(socket){
    console.log("New client has connected with id:",socket.id);
    socket.on('new-player',function(state_data){ // Слушаем событие new-player в этом клиенте 
      console.log("New player has state:",state_data);
    })
})

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

Мы можем отправить сообщение всем остальным подключённым игрокам, чтобы они знали, что появился новый игрок. В Socket.io есть для этого удобная функция:

socket.broadcast.emit('create-player',state_data);

При вызове socket.emit сообщение просто передаётся этому одному клиенту. При вызове socket.broadcast.emit оно отправляется каждому клиенту, подключенному к серверу, за исключением того, на чьём сокете была вызвана эта функция.

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

Серверный код теперь должен выглядеть вот так:

// Приказываем Socket.io начать принимать соединения
io.on('connection', function(socket){
    console.log("New client has connected with id:",socket.id);
    socket.on('new-player',function(state_data){ // Слушаем событие new-player в этом клиенте
      console.log("New player has state:",state_data);
      socket.broadcast.emit('create-player',state_data);
    })
})

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

Спаунинг в клиенте


Теперь, чтобы завершить этот цикл, нам нужно выполнять в клиенте два действия:
  1. Сгенерировать сообщение с данными нашего местоположения после соединения.
  2. Слушать события create-player и создавать игрока в этой точке.

Для выполнения первого действия после создания игрока в функции create (примерно в строке 135), мы можем сгенерировать сообщение, содержащее данные о местоположении, которые нам нужно отправить:
socket.emit('new-player',{x:player.sprite.x,y:player.sprite.y,angle:player.sprite.rotation})

Нам не нужно беспокоиться о сериализации отправляемых данных. Можно передавать их в любом типе объекта, а Socket.io сама обработает его за нас.

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

New player has state: { x: 728.8180247836519, y: 261.9979387913289, angle: 0 }

Теперь мы знаем, что наш сервер получает оповещение о подключении нового игрока и правильно считывает данные о его местоположении!

Далее мы хотим слушать запросы на создание нового игрока. Мы можем разместить этот код сразу после генерирования сообщения, он должен выглядеть так:

socket.on('create-player',function(state){
  // CreateShip - это функция создания и возврата спрайта, которую я определил ранее 
  CreateShip(1,state.x,state.y,state.angle)
})

Теперь протестируйте код. Откройте два окна с игрой и убедитесь, что он работает.

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

Задача: сможете разобраться, почему так получилось? Или как вы можете это исправить? Пошагово пройдите по написанной нами логике клиента/сервера и попробуйте отладить её.

Надеюсь, вы попробовали разобраться самостоятельно! Происходит следующее: когда первый игрок подключается, сервер отправляет событие create-player всем остальным игрокам, но пока ещё нет игроков, которые могут его получить. После подключения второго игрока сервер снова отправляет свои сообщения, и первый игрок получает его и корректно создаёт спрайт, в то время как второй игрок пропустил сообщение первого игрока.

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

Предупреждение о синхронизации состояния игры


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

Второй подход заключается в передаче всего состояния игры. В этом случае мы просто при каждом подключении или отключении отправляем всем полный список всех игроков.

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

В нашем случае, вместо того, чтобы пытаться отправлять сообщения при подключении игрока для его создания и при отключении для его удаления, а также при перемещении для обновления его позиции, мы можем объединить всё это в одно общее событие update. Это событие обновления всегда будет отправлять позиции каждого игрока всем клиентам. Именно этим и должен заниматься сервер. Задача клиента — поддерживать соответствие мира получаемому состоянию.

Для реализации такой схемы я сделаю следующее:

  1. Буду хранить словарь игроков, ключом которого будет их ID, а значением — данные об их местоположении.
  2. Добавлять игрока в этот словарь при его подключении и отправлять событие update.
  3. Удалять игрока из этого словаря при его отключении и отправлять событие update.

Можете попробовать реализовать эту систему самостоятельно, потому что эти действия довольно просты (здесь может пригодиться моя подсказка по функциям). Вот, как может выглядеть полная реализация:
// Приказываем Socket.io начать принимать соединения
// 1 - Сохраняем словарь всех игроков как ключ/значение 
var players = {};
io.on('connection', function(socket){
    console.log("New client has connected with id:",socket.id);
    socket.on('new-player',function(state_data){ // Слушаем событие new-player в этом клиенте 
      console.log("New player has state:",state_data);
      // 2 - Добавляем в словарь нового игрока
      players[socket.id] = state_data;
      // Отправляем событие обновления
      io.emit('update-players',players);
    })
    socket.on('disconnect',function(){
      // 3- Удаляем игрока из словаря при отключении
      delete players[socket.id];
      // Отправляем событие обновления
    })
})

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

Вот как я обрабатываю это событие в клиенте:

// Слушаем подключение других игроков
// ПРИМЕЧАНИЕ: где-то в другом месте у вас должно быть определено other_players = {}
socket.on('update-players',function(players_data){
    var players_found = {};
    // Обходим в цикле все полученные данные игроков
    for(var id in players_data){
        // Если игрок ещё не создан
        if(other_players[id] == undefined && id != socket.id){ // Проверяем, чтобы не создать самого себя
            var data = players_data[id];
            var p = CreateShip(1,data.x,data.y,data.angle);
            other_players[id] = p;
            console.log("Created new player at (" + data.x + ", " + data.y + ")");
        }
        players_found[id] = true;
        
        // Обновляем позиции других игроков
        if(id != socket.id){
          other_players[id].x  = players_data[id].x; // Обновляем целевую, а не текущую позицию, чтобы можно было её интерполировать
          other_players[id].y  = players_data[id].y;
          other_players[id].rotation  = players_data[id].angle;
        }
        
        
    }
    // Проверяем отсутствие игрока и удаляем его
    for(var id in other_players){
        if(!players_found[id]){
            other_players[id].destroy();
            delete other_players[id];
        }
    }
   
})

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

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

3. Синхронизация позиций кораблей


Здесь начинается очень интересная часть. Мы хотим синхронизировать позиции кораблей на всех клиентах. В этом проявится простота той структуры, которую мы создали на текущий момент. У нас уже есть событие обновления, которое может синхронизировать местоположения всех кораблей. Нам достаточно сделать следующее:
  1. Заставить клиент генерировать сообщение каждый раз, когда он перемещается в новую позицию.
  2. Научить сервер слушать это сообщение о перемещении и обновлять элемент с данными игрока в словаре players.
  3. Генерировать событие обновления для всех клиентов.

И этого должно быть достаточно! Теперь ваша очередь попробовать реализовать это самостоятельно.

Если вы совершенно запутаетесь и вам нужна будет подсказка, то посмотрите на готовый проект.

Примечание о минимизации передаваемых по сети данных


Наиболее прямолинейный способ реализации — обновлять позиции всех игроков каждый раз при получении события перемещения от любого игрока. Замечательно, если игроки всегда получают последнюю информацию сразу же после её появления, но количество передаваемых по сети сообщений легко может вырасти до сотен на кадр. Представьте, что у вас есть 10 игроков, каждый из которых отправлять в каждом кадре сообщение о перемещении. Сервер должен передавать их обратно всем 10 игрокам. Это уже 100 сообщений на кадр!

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

Ещё один способ решения заключается в отправке сервером обновлений с постоянной частотой, вне зависимости от количества полученных от игрока сообщений. Распространённым стандартом является обновление сервера примерно 30 раз в секунду.

Однако при выборе структуры своего сервера вам следует оценивать количество передаваемых в каждом кадре сообщений ещё на ранних этапах разработки игры.

4. Синхронизация снарядов


Мы почти закончили! Последняя серьёзная часть заключается в синхронизации по сети снарядов. Мы можем реализовать её так же, как синхронизировали игроков:
  • Каждый клиент отправляет позиции всех своих снарядов в каждом кадре.
  • Сервер перенаправляет их каждому игроку.

Но тут есть проблема.

Защита от читерства


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

Чтобы частично справиться с этой проблемой, мы попробуем использовать другую схему:

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

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

Для реализации такой схемы мы добавим генерирование сообщения при выстреле. Я больше не буду создавать сам спрайт, потому что его существование и местоположение целиком будут определяться сервером. Теперь наш новый выстрел снарядом в index.html будет выглядеть так:

// Выстрел снарядом
if(game.input.activePointer.leftButton.isDown && !this.shot){
    var speed_x = Math.cos(this.sprite.rotation + Math.PI/2) * 20;
    var speed_y = Math.sin(this.sprite.rotation + Math.PI/2) * 20;
    /* Сервер теперь симулирует снаряды, а клиенты всего лишь рендерят позиции снарядов, поэтому это нам больше не нужно
    var bullet = {};
    bullet.speed_x = speed_x;
    bullet.speed_y = speed_y;
    bullet.sprite = game.add.sprite(this.sprite.x + bullet.speed_x,this.sprite.y + bullet.speed_y,'bullet');
    bullet_array.push(bullet); 
    */
    this.shot = true;
    // Сообщаем серверу, что мы выстрелили снарядом
    socket.emit('shoot-bullet',{x:this.sprite.x,y:this.sprite.y,angle:this.sprite.rotation,speed_x:speed_x,speed_y:speed_y})
}

Также теперь мы можем закомментировать весь фрагмент кода, обновляющий снаряды в клиенте:
/* Мы обновляем снаряды на сервере, поэтому в клиенте нам это больше не нужно
// Обновление снарядов
for(var i=0;i<bullet_array.length;i++){
    var bullet = bullet_array[i];
    bullet.sprite.x += bullet.speed_x; 
    bullet.sprite.y += bullet.speed_y; 
    // Удаляем снаряд, если он слишком далеко от экрана
    if(bullet.sprite.x < -10 || bullet.sprite.x > WORLD_SIZE.w || bullet.sprite.y < -10 || bullet.sprite.y > WORLD_SIZE.h){
        bullet.sprite.destroy();
        bullet_array.splice(i,1);
        i--;
    }
} 
*/

Наконец, нам нужно заставить клиент слушать обновления снарядов. Я решил реализовать это так же, как и с игроками, то есть сервер просто отправляет массив всех позиций снарядов в событии под названием bullets-update, а клиент для поддержания синхронизации создаёт или уничтожает снаряды. Вот, как это выглядит:
// Слушаем события обновления снарядов
socket.on('bullets-update',function(server_bullet_array){
  // Если в клиенте недостаточно снарядов, создаём их
 for(var i=0;i<server_bullet_array.length;i++){
      if(bullet_array[i] == undefined){
          bullet_array[i] = game.add.sprite(server_bullet_array[i].x,server_bullet_array[i].y,'bullet');
      } else {
          // В противном случае просто их обновляем! 
          bullet_array[i].x = server_bullet_array[i].x; 
          bullet_array[i].y = server_bullet_array[i].y;
      }
  }
  // Если их слишком много, удаляем лишние
  for(var i=server_bullet_array.length;i<bullet_array.length;i++){
       bullet_array[i].destroy();
       bullet_array.splice(i,1);
       i--;
   }
                  
                })

И это всё, что должно быть в клиенте. Я буду предполагать, что вы уже знаете, куда вставлять эти фрагменты кода и как всё это соединить, но если у вас возникли проблемы, то можете всегда вглянуть на готовый результат.

Теперь в server.js нам нужно отслеживать и симулировать снаряды. Сначала мы создадим массив для отслеживания снарядов, аналогично массиву для игроков:

var bullet_array = []; // Отслеживает все снаряды для обновления их на сервере

Далее мы слушаем событие выстрела снаряда:
// Слушаем события shoot-bullet и добавляем их в наш массив снарядов
  socket.on('shoot-bullet',function(data){
    if(players[socket.id] == undefined) return;
    var new_bullet = data;
    data.owner_id = socket.id; // Добавляем к снаряду id игрока
    bullet_array.push(new_bullet);
  });

Теперь мы симулируем снаряды 60 раз в секунду:
// Обновляем снаряды 60 раз в секунду и отправляем обновления
function ServerGameLoop(){
  for(var i=0;i<bullet_array.length;i++){
    var bullet = bullet_array[i];
    bullet.x += bullet.speed_x; 
    bullet.y += bullet.speed_y; 
    
    // Удаляем, если снаряд слишком далеко от экрана
    if(bullet.x < -10 || bullet.x > 1000 || bullet.y < -10 || bullet.y > 1000){
        bullet_array.splice(i,1);
        i--;
    }
        
  }
  
}

setInterval(ServerGameLoop, 16);

И последний шаг — это отправка события обновления где-нибудь внутри этой функции (но совершенно точно вне цикла for):
// Сообщаем всем, где находятся все снаряды, передавая целый массив
  io.emit("bullets-update",bullet_array);

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

5. Столкновение со снарядами


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

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

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

Можете попробовать реализовать эту часть самостоятельно. Чтобы заставить корабль игрока мерцать при попадании, просто задайте его альфа-каналу значение 0:
player.sprite.alpha = 0;

И он будет плавно возвращаться к полной непрозрачности (это выполняется в обновлении игрока). Для других игроков действие будет похожим, но вам придётся возвращать его альфа-канал к единице в функции обновления чем-то подобным:
for(var id in other_players){
 if(other_players[id].alpha < 1){
        other_players[id].alpha += (1 - other_players[id].alpha) * 0.16;
    } else {
        other_players[id].alpha = 1;
    }
}

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

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

6. Сглаживание движения


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

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

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

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

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

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

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

// Обновляем позиции у игроков
if(id != socket.id){
  other_players[id].target_x  = players_data[id].x; // Присваиваем целевую, а не настоящую позицию, чтобы можно было интерполировать
  other_players[id].target_y  = players_data[id].y;
  other_players[id].target_rotation  = players_data[id].angle;
}

Затем в функции update (тоже на стороне клиента) мы обходим в цикле всех остальных игроков и толкаем их по направлению к их цели:
// Интерполируем всех игроков к позиции, в которой они должны быть
for(var id in other_players){
    var p = other_players[id];
    if(p.target_x != undefined){
        p.x += (p.target_x - p.x) * 0.16;
        p.y += (p.target_y - p.y) * 0.16;
        // Интерполируем угол, избегая проблему с положительными/отрицательными значениями
        var angle = p.target_rotation;
        var dir = (angle - p.rotation) / (Math.PI * 2);
        dir -= Math.round(dir);
        dir = dir * Math.PI * 2;
        p.rotation += dir * 0.16;
    }
}

Таким образом, сервер отправляет нам обновления по 30 раз в секунду, но мы всё равно можем играть с частотой 60 fps и игра по-прежнему выглядит плавной!

Заключение


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

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

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

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

Вы можете воспользоваться ещё одной полезной функцией Glitch, которая заключается в возможности скачивания или экспорта собственного проекта через расширенные параметры (Advanced Options) в левом верхнем углу:

Let's block ads! (Why?)