- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
недавно как раз проходила эпидемия которая тырит пароли из Total Comander
так что причина скорее всего в этом, тем более что Вы говорите что они были там сохранены
Насколько вижу - ни у каких хостеров не ломают чаще - их ломают довольно редко - а чаще трояны уводят пароли от фтп на локальном компьютере
А если все-таки выбиравть из хостеров по этому параметру - то, видимо, отчасти зависит от архитектуры хостинга - см, например http://caravan.ru/reference/faq/hosting/why/
Да Караван вообще рулит, в чем убедился не раз :)
Есть бооольшое подозрение что никакие способы хранения паролей вообще не помогут. Поскольку пароль можно перехватывать в момент передачи его по сети, это универсально и независимо от способа хранения.
Видимо единственная панацея в этом случае - криптованный доступ SFTP и т.п.
Видимо единственная панацея в этом случае - криптованный доступ SFTP и т.п.
Могу продолжить... если CMS с Web админкой, то доступ в админку только по https... а еще лучше совсем без Web админки :)
Далее, есть такая хорошая штука, как цифровая подпись. Т.е. некотороая сигнатура, которая кладется до и после защищаемого текста в момент его сохранения в CMS. CMS, при выдаче страницы, убирает эту сигнатуру, при этом убеждаясь, что подписанное содержимое не изменилось. Если изменилось - то выдается просто ошибка с сообщением админу, или в идеальном случае, берется предыдущая версия документа, если она есть.
Могу продолжить... если CMS с Web админкой, то доступ в админку только по https... а еще лучше совсем без Web админки :)
Далее, есть такая хорошая штука, как цифровая подпись. Т.е. некотороая сигнатура, которая кладется до и после защищаемого текста в момент его сохранения в CMS. CMS, при выдаче страницы, убирает эту сигнатуру, при этом убеждаясь, что подписанное содержимое не изменилось. Если изменилось - то выдается просто ошибка с сообщением админу, или в идеальном случае, берется предыдущая версия документа, если она есть.
Ну работа в веб-панели по https - это муторно, думаю достаточно авторизацию делать по https, а далее уже по обычному каналу. Формально можно и тут напакостить, но вероятность этого уже чисто гипотетическая :)
думаю достаточно авторизацию делать по https, а далее уже по обычному каналу
Ну, вольному - воля :)
Правда мне не совсем понятен механизм изменения секюрной сесии на несекюрную. Тут, в зависимости от реализации может быть дырочка или просто шоссейная дорога.
Есть бооольшое подозрение что никакие способы хранения паролей вообще не помогут. Поскольку пароль можно перехватывать в момент передачи его по сети, это универсально и независимо от способа хранения.
Видимо единственная панацея в этом случае - криптованный доступ SFTP и т.п.
Прослушка и анализ трафика - слишком трудоёмкая процедура, для того чтобы проводить ее массово и повально, так что рядовому вебмастеру это не грозит.
Еще немногие хостеры додумались до таких вещей, как блокировка панели и фтп по ip адресу. А полезная фича.
На днях обнаружил на сайте вирь. Пол - часа пытался его потереть, этот гад сидел не как все, в конце index.php, он залез в файл который инклюдится в index.php !
Меня вот что удивляет, если у аккаунта стащили пароль от FTP, для чего им вставлять этот iframe код в конец страницы, получив пароли от FTP, взломщик получает полный доступ к аккаунту на сервере, на котором можно заливать свои скрипты и запускать их , после спокойно все удалять, чего взломщик же не делает, а довольствуется лишь iframe кодом который подгружает трояна или эксплоит совсем с другого сервера.