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



Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

Добрый день, уважаемые читатели.

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

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

Начну с причины возникновения LLTR (Link Layer Topology Reveal).

У меня был один “велосипед” - синхронизатор больших файлов “на полной скорости сети”, способный за 3 часа целиком залить 120 GiB файл по Fast Ethernet (100 Мбит/с; 100BASE‑TX; дуплекс) на 1, 10, 30, или > 200 ПК. Это был очень полезный “велосипед”, т.к. скорость синхронизации файла почти не зависела от количества ПК, на которые нужно залить файл. Все бы хорошо, но он требует знания топологии сети для своей работы.

Можно продолжить цепочку дальше, но на этом я прервусь.

Существующие протоколы обнаружения топологии канального уровня (LLDP, LLTD, CDP, …) для своей работы требуют соответствующей поддержки их со стороны всех промежуточных узлов сети. То есть они требуют как минимум управляемых свитчей, которые бы поддерживали соответствующий протокол. На Хабре уже была статья, как используя эти протоколы, “определить топологию сети на уровнях 2/3 модели OSI”.

Но что же делать, если промежуточные узлы – простые неуправляемые свитчи?

Если интересно как это можно сделать, то добро пожаловать под кат. Обещаю наличие множества иллюстраций и примеров.

{ объем изображений: 924 KiB; текста: 69 KiB; смайликов: 9 шт. }

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

Короткий ответ: никак, им пофиг.

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

UPD

Статья на английском hub.zhovner.com/geek/how-skype-fixes-security-vulnerabilities/

Пост на HackerNews news.ycombinator.com/item?id=13227480

TL;DR:

• Любой может заблокировать ваш аккаунт навсегда так, что вы больше не сможете им пользоваться. Для этого достаточно знать только имя аккаунта. В большинстве случаев Skype откажет вам в восстановлении доступа. Microsoft знает об этой проблеме несколько лет.
  
  
• Механизм генерации восьмизначных одноразовых кодов аутентификации (Microsoft Security Code), которые используются для восстановления пароля к аккаунту Microsoft, уязвим. Атакующий может угадать код.
  
  
• Техподдержка Skype уязвима для атак социальной инженерии. Microsoft считает это нормальным.
  
  
• Техподдержка Skype не знает, что на самом деле происходит с вашим аккаунтом, и почему он заблокирован. В любом случае вы получите стандартный ответ, что ваш аккаунт заблокирован за нарушение правил, даже если аккаунт был удален по вашему запросу.
  
  
• Skype по-прежнему раскрывает ваш IP-адрес, в том числе и локальный (тот, что на сетевом интерфейсе). В некоторых случаях возможно раскрытие контактов, подключенных с того же внешнего IP-адреса, что и вы. Например, членов семьи, подключенных к домашнему роутеру.
  
  
• Атакующий может скрыть активную сессию из списка авторизованных клиентов (команда /showplaces) используя старые версии SDK. Таким образом, зная пароль, можно незаметно просматривать переписку жертвы.

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