Приветствую господа!
Я, наверное, не совсем беженец, т.к. не очень плотно сидел на ганзе. Кроме того я рассчитываю извлечь/принести пользу своим пребыванием здесь. Для начала хочу изложить свои мысли касательно взлома ганзы.
Сам я являюсь веб-разработчиком, и хотя к ганзе отношения не имею
, обдумывал создание достаточно разных и сложных вещей. Кроме того, как веб-разраб, я интересуюсь путями взлома ресурсов, дабы по возможности защитить от них свои продукты.
Начну по поводу лички.
(рассуждаем на логическом уровне архитектуры ANSI-SPARC)
Когда мы разрабатываем систему обмена сообщениями, напрашивается естественное решение: одно письмо – одна единица хранения (запись, строка в БД). При этом надо помнить, что доступ к ней должен быть предоставлен 2 людям. Получателю, и отправителю (у одного во входящих, у другого в исходящих). Удалять сообщение когда
один человек его удалил – нельзя. Сочинять проверку на удаление сообщения обоими людьми – ресурсоемко (дольше програмить, медленнее работает, менее изящное решение). Еще одно напрашивающееся решение, не удалять запись в БД, а только
отмечать ее, как удаленную.
Теоретически, можно время от времени выполнять операцию "сборки мусора", т.е. запускать удаление сообщений (записей в бд), для котолрых имеется отметка об их удалении отправителем и получателем. Но, во-первых такие вещи надо отдельно делать (настраивать крон, или еще как извращаться) а это лениво. Да и так все работает. А во-вторых… У программистов есть присказка "это не баг, это - фича".
И действительно. Предположим теоретическую ситуацию: злой-злой маньяк-педофил в личных сообщениях напросился в гости к невинной крохе… кроху, как положено по сюжету, убил, изнасиловал и сожрал… а напоследок удалил ее переписку, зайдя в ее аккаунт, с ее компа, а потом и из своего компа. А если сообщения все равно хранятся в БД, то доблестная милиция прихватит негодяя за негодяйскую задницу.
Конечно, встает вопрос, почему не удалять слишком старую переписку. Скажем трехлетней удаленности, но смотри "во-первых"
И кстати. Взглянем на физический уровень архитектуры ANSI-SPARC. Как именно выполняется операция удаления в БД? Наиболее
быстрый метод удаления – это маркировка записи, без ее физического удаления из файла. (кстати файлы на компе удаляются тоже не насмерть, а только маркируются как удаленные, но это скорее относится к другой области)
И еще. По поводу устаревания слитой лички. По моим оценкам объем информации на ганзе порядка 100гигов. Скорость моего интернет соединения 20 мегабит. Таким образом выкачивать всю ганзу мне придется 11часов. Если другие посетители не будут локтями отталкивать меня от кормушки. Если ширина промежуточных каналов тоже будет не меньше 20 мегабит. В реальности скорее потребуется больше времени.
Исходя из этого хронология видится мне так.
1 проникновение на сайт.
2 получение бэкапа БД
3 выкачивание бекапа БД, и возможно бэкапа сайта (картинки, например, могли жить и не в базе). Имеено в этот момент наблюдалось внеплановое зависание ганзы.
4 Замена админского пароля доступа к сайту и ДНС (Доступа в личный кабинет провайдера)
5 Подмена сайта путем внесения изменений в ДНС записи (вроде говорят какое то время IP сайта был левый)
6 Удаление инфы на сервере, пока владелец бегает, пытается восстановить админский доступ в ЛК провайдера. (Помните, в пятницу, 29 марта, прошел слушок, что к понедельнику-вторнику все образуется?)
Собственно пункт 3 – требует определенного времени, и поэтому, скачана была не абсолютно актуальная версия бэкапа. Пункт 6 тоже требует времени, особенно если нужно надежно уничтожить данные (многократная перезапись поверх).
Кстати, если среди присутствующих люди, имевшие опыт модераторства на ганзе? Вопрос видна ли модераторам информация об е-мейлах пользователей форума?
О механике взлома попытаюсь порассуждать в следующий раз.
Кстати, нету ли попгановцев, может поделятся инфой… а то у меня одни предположения…
И каторжанская переписка их рук дело.С ганзы регулярно народ на нары выдёргивали по 222,223
