Войти

Показать полную графическую версию : Как защитить сайт от взлома?


eldorado60
06-04-2006, 18:57
Я открываю сайт но не знаю как зашитить его"
знаете ли вы какие не-будь скрипты или проги чтоб зашитить от взлома!
Заранее Спасибо!

vadimiron
06-04-2006, 20:25
а какие технологии ваш сайт использует?? на чём написан??

Vlad Drakula
07-04-2006, 10:20
eldorado60
чтобы следать защищенный сайт нужно думать головой в момент его разработки...

eldorado60
07-04-2006, 20:30
на html
я делал его с Word!
PS
Он на сервере narod.ru

vadimiron
08-04-2006, 00:19
eldorado60
тогда боятся нечего, в html особенного ничего не взломаешь
Если только сервер взломают, но на это уже мы повлиять не можем

Coutty
12-05-2006, 21:06
Вообще-то мало кто ломает сайты на народе. Во всяком случае в течение первого года работы бояться особо нечего. Это как с вирусами - они есть, но вероятность заражения невысока (относительно того, как эту проблему ставят журналисты).

DrAibolit-2000
29-08-2006, 05:35
А что значит защитить?

Demiurg
05-09-2006, 12:18
...к вопросу о защите (в моем случае web-приложения)...
...необходимо передать (_бесплатно_) одной фирме разработанное нами web-приложение (так сказать, в "юзанье", до тех пор пока они наши клиенты), но так чтобы оно (web-application) никуда из ихних пенатов не ушло...
Доступ root к их серванту с приложением только у меня. ACL, secure level вещи конечно хорошие, но что сделаешь если они винт банально подцепят к другой машине...
Первое, что пришло в голову: поместить data (PostgreSQL'я) и DocumentRoot (Apache) в раздел /www и закриптовать его GELI... это поможет (от того, если винт подцепят на другой комп)? И что произойдет с /www если комп уйдет в ребут по питанию (упс есть, но все же)? Или нужно что-то другое?

Необходимый приоритет защиты по убыванию:
1. C'шные хранимые процедуры (работают со специфическим железом), вызываются из триггеров.
2. Структура базы.
3. php-скрипты...

mar
05-09-2006, 21:05
Demiurg
закриптовать его GELI... это поможет (от того, если винт подцепят на другой комп)?
да, эта штука как раз должна помочь в таком случае. NB при работе с шифрованным диском производительность неизбежно падает, что может быть критично для работы с postgresql (хотя зависит от объема данных). Что будет при падении питания - вопрос интересный, но, как ни странно, мне с ходу ничего по этому поводу не попалось.
Доступ root к их серванту с приложением только у меня. А просто доступ? Это я к тому, что апач доступен только Вам, или еще кому? И еще, интересно, что будет при перехвате рутового доступа с конcоли? Или доступ с консоли запрещен совсем? (Тогда сервер должен стоять в Вашей фирме, чтоб вам его подымать в случае чего :)

Demiurg
06-09-2006, 16:51
Это я к тому, что апач доступен только Вам, или еще кому?
...под апачем крутится только web-приложение (корпоративное, работают только сотрудники фирмы)... в планах еще запустить web-сайт (скорее всего будет крутиться тоже на этом компе (будет переадресация со шлюза) или отдельный комп в DMZ, а вот под апачем или под nginx пока вопрос... этот вопрос пока отложен на неопределенное время)...
И еще, интересно, что будет при перехвате рутового доступа с конcоли?
Насколько я помню, ssh/pf/tcp-wrappers еще не отменяли :) да и с IPSec повозиться можно...
Или доступ с консоли запрещен совсем?
Только к нулевой, а что до остальных (insecure) - локально пускай брутфорсят хоть до посинения, истирают пальцы о клавиатуру... :) удаленно брутфорс пресекается pf...
Тогда сервер должен стоять в Вашей фирме, чтоб вам его подымать в случае чего
Если чего... то подъедем, поднимем... :)




© OSzone.net 2001-2012