Да нет, отчего же... Работа системного администратора по настройке безопасности сервера, сети, любой инфруструктурной единицы это и есть установка подобных ловушек и затем кропотливое ползание по логам, а также автоматизация этого нудного процесса. Так что никакая это не фантастика, хотя понятное дело все упирается во время и другие ресурсы.
Верьте в свои силы и будьте упорнее. И все получится.
Flint, я много о чем слышал. Может вы еще расскажете о способе получения большого числа прокси, которые не выкладываются на открытых ресурсах типа proxy4all? Все прокси, публикующиеся на открытых ресурсах можно закидывать в черный список автоматом, таких систем масса. AOL могли бы давно это уже сделать.
А владельцы зомби сетей на эту ерунду тратить свои дорогостоящие ресурсы не станут - не стоит оно того.
Перебор по словарю называется "словарная атака". Брут-форс к перебору из словаря никакого отношения не имеет, это метод подбора перебором символов, то есть метод "грубой силы". Поэтому прежде чем дерзить выучите для начала матчасть.
"Тронуты" это как? Скачайте к себе все что есть на хостинге, сравните файлы с исходной копией обычным fc. А то просто угадайка какая-то... Если файлы поменялись по содержанию - разбирайтесь. Если только по дате - спросите у хостера "а че это вдруг они у меня не той даты-времени вдруг встали?". Хостер признается только если вы будете корректны и сочтет изменение не особо критичным для вас. Иначе скорее всего будет все отрицать и концов не найдешь.
Собственно, идея "как поймать": зарегистрировать "красивый" номер аськи - приманку, сделать на нем внушительный контакт-лист. Внушающий доверие. Одним из контактов поставить другую, контрольную аську все время включенную и работающую через программу, логирующую аськин трафик. При угоне аськи №1 есть вероятность что на аську №2 поступит предложение "помочь материально". Аська работает напрямую - IP-IP, задача логгера вычислить с какого IP поступило предложение.
Правда вероятность события невелика. Можно очень долго ждать такого безобразия. Есть вероятность и работы хакера с прокси, но во-первых трафик аськи через прокси пустить сложнее, а во-вторых, как показывает практика, хакеров-паранойиков мало. Может и проколоться, полениться. Все равно, дескать, не найдут.
Имея IP адрес можно уже и в управление "К" идти. Суды Линча у нас чреваты.
Еще можно найти контору, которая угоняет аську. Скорее всего будут работать анонимно. Дать им заказ на угон, для ускорения процесса. Отследить процесс работы. Далее все так же - сдать логи в органы.
Мужики, я может чего-то не понимаю, но если в асе пароль ограничен 8мью символами (попробовал сейчас - у меня - так), то какая разница из каких символов вы будете составлять пароль? При брут-форсе все равно будет перебираться один и тот же набор символов, который доступен для задания пароля. Если, конечно, не считать хакеров тупыми людьми, которые будут использовать для подбора только буквы нижнего регистра. Нынешние мощности машин и канал позволяют перебрать и все 255 символов, думаю, просто 8 символов для пароля это очень мало.
А вообще, мне непонятно, что, неужели AOL (или кто там владеет этой ботвой сейчас) не поставила защиты от потокового перебора паролей? Скорее всего поставила, иначе асем давно пользоваться перестали из-за массового угона.
Посему более реальными считаю варианты подбора паролей-слов по словарю и угон через захват локальной БД аськи или какой-то ее частью. Точно не уверен, ковыряться некогда, но у меня есть подозрение, что аська при логине сверяет введенный пароль и с локальной базой тоже ДАЖЕ ЕСЛИ НЕ УСТАНОВЛЕНО "СОХРАНЯТЬ ПАРОЛЬ", то есть где он должен локально лежать ВСЕГДА, пусть и шифрованный. А значит его можно украть через троянца и банально отдать автомату на очень мощной машине на декрипт.
Да в том то и дело что вроде бы не в Content-type, его перелопатили давно. Проблема не в отстутствии ключа в реестре, с этим все понятно, поведение действительно как =1. Проблема в том, что при этом ключе HTTP/1.1 выдаваемое вручную будет переписано поверх! А об этом нигде не сказано.
Собственно сама ситуация не важна, как заголовки формируются. Важно, что робот не кушает страницы если ему отвечают HTTP/1.0 в ответ за запрос.
PS: То что яндексу можно 406 выдать это занятно, но вопрос только в том как он это интерпретирует. Сомневаюсь, что он будет делать перезапрос с другими параметрами. Негибкий он какой-то. Без Date тоже может страницы не есть. С неправильным Content-length ничего не ест. И так далее. При этом все другие боты менее жестки в требованиях - интернет бывает разный, чего не встретится только на его просторах.
вывод очень странный. судя по сообщению он должен быть таким "не пользуйтесь maxton, потому что всякие кривые надстройки над ИЕ вносят дополнительный бажный слой в разработки микрософта".
и вообще, отладку нужно делать только под чистыми браузерами, при отключенных баннерорезках и прочих антиспаях которые лезут в HTML код. это мне практика подсказала.
robust, не путайте людей. Во-первых, уберите мой ник из цитаты, а во-вторых кроме авторизации через htpasswd есть масса других способов, которые поддерживаются и Apaсhe и IIS. Есть доменная авторизация, есть Керберос... Много чего есть.
А про какую-такую панель управления вы тут пишете вообще непонятно. ТС на эту тему ничего не говорил вроде бы. Написать же интерфейс по управлению htpasswd записями - пара пустяков.
Последнее же предложение:
показывает слабое знакомство с предметом. Любая авторизация делается на стороне сервера, поскольку там хранится база с авторизационными данными. И надежность зависит только от способа передачи данных по большому счету. И делать это через встроенный в веб-сервер механизм или писать что-то свое - без разницы. Можно и там и там накосячить или наоборот сделать хорошо и надежно.
Mad Cat, почитайте что такое basic и другие возможные способы встроенной в веб-сервер авторизации.
Веб-форму можно передать, например, по SSL каналу. Или, встроить свой алгоритм шифрования в ActiveX, например, и передать данные ему и далее на сервер. На серверной стороне можно также хранить базу пользователей в нужном формате - с хранением паролей, без него, в общем как угодно.
Во встроенной авторизации всем в плане передачи данных заправляет браузер, а в плане самой авторизации - или веб-сервер, или авторизационная система (тот же Керберос).
К слову, если используется Кербер, то вряд ли самопальными веб формами удастся добиться такой же степени защиты. Хотя надо смотреть уже предметно почему там так все наворочено.
Аналогично, все там нормально работает в ИЕ.
Я бы при отладке выводил (например в windows.status) значение, которое вы присваиваете в стиль объекта. Хотя сильно сомневаюсь, но наверное есть ненулевая вероятность, что при каком то значении в стиле объект умрет. Но я с таким никогда не сталкивался и потому больше склонен думать что это локальная или временная проблема. Я бы подергал скрипт на других машинах, попробовал прибить ИЕ и запустить его заново, перегрузить. Иногда, такое шаманство приводит ИЕ в чувство. Правда такие ошибки чтобы внутри ИЕ что-то "залипло" бывают редко очень и в основном когда работаешь с внешними объектами ActiveX.
