- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
p.s. быть может важность инфы несколько преувеличена.
очень важная инфа.
p.p.s. а еще можно арендовать второй сервер и синхронизировать их каждую ночь, или еще третий сервер.. и все в разных странах..
так и задумано.
спасибо.
noseomen добавил 09-11-2011 в 14:38
По насоветовали-то вам ТС сколько - аж три страницы
четвертая пошла:D
По насоветовали-то вам ТС сколько - аж три страницы :).
На мой взгляд все несколько усложнено - vpn, суперспециалист, без которого "не обойтись"...
Выскажу свое мнение - все описанное можно сделать самостоятельно, не прибегая к "специалистам":
как уже сказали, необходимости в VPN нет, т.к. данные будут архивироваться/шифроваться на локальном компьютере, а уже потом пересылаться на удаленный бекап-сервер.
Для безопасности что можно сделать -
1. не вешать на сервер сайт, чтобы лишний раз боты и сканеры уязвимостей не лезли. То есть сервер будет отвечать только по IP.
2. Перевесить ssh порт (и ftp), к примеру, на 10963 порт и 8523 порт соответственно. Ограничить доступ по ip для ssh (и ftp), для совсем уж параноиков отключить вход для root, и каждый раз мучить себя командами "sudo..."
3. Включить автоматическое обновление пакетов на сервере.
4. Заливать файлы через sftp или ssh.
5. Хороший пароль на сервер и антивирус с фаерволлом на локальном компе.
Кажись все.
p.s. быть может важность инфы несколько преувеличена.
p.p.s. а еще можно арендовать второй сервер и синхронизировать их каждую ночь, или еще третий сервер.. и все в разных странах..🤣
А потом эти люди плачат о том что их сайт слили вместе с базой
А потом эти люди плачат о том что их сайт слили вместе с базой
а что не так? расскажите?
а что не так? расскажите?
Да много чего не так:
1. не вешать на сервер сайт, чтобы лишний раз боты и сканеры уязвимостей не лезли. То есть сервер будет отвечать только по IP.
2. Перевесить ssh порт (и ftp), к примеру, на 10963 порт и 8523 порт соответственно. Ограничить доступ по ip для ssh (и ftp), для совсем уж параноиков отключить вход для root, и каждый раз мучить себя командами "sudo..."
3. Включить автоматическое обновление пакетов на сервере.
4. Заливать файлы через sftp или ssh.
5. Хороший пароль на сервер и антивирус с фаерволлом на локальном компе.
1. зачем? имена как раз и придуманы для удобства. Тем более, что вы предлаете пункт 2.
2. Если фильтровать по ip то зачем менять порты? сами себя ломать будете?
И отключить рутовый доступ - это в первую очередь, а не для параноиков.
3. надо обновлять руками, думая при этом головой, а не автоматически.
Не буду вступать в полемику с izbushka - у каждого свои методы. Сколько людей - столько и мнений, я описал свое видение решения проблемы ТС.
Можно холиварить и хаять чужие предложения до бесконечности, предлагать заплатить "спецам" за то, что настраивается за 1,5-2 часа вручную, а так же ежедневно подключаться к N серверам и пыхтя вбивать ручками что-то типа
и при этом усиленно думать головой, как предлагает izbushka
Мне известно, что порой автообновление может привести к падению софта, все бывает в жизни, я описал путь наименьшего сопротивления, конечный выбор в любом случае за ТС.
От темы отписываюсь, ничего интересного не предвидится.
а что не так? расскажите?
Отсутствует комплексный подход
как уже сказали, необходимости в VPN нет, т.к. данные будут архивироваться/шифроваться на локальном компьютере, а уже потом пересылаться на удаленный бекап-сервер.
С этой точки зрения - вообще бекап-сервера своего не надо. Покупаете место на бекап-хостинге - и все.
1. не вешать на сервер сайт, чтобы лишний раз боты и сканеры уязвимостей не лезли. То есть сервер будет отвечать только по IP.
Вешать какие-то публичные сервисы на бекап-сервер - конечно, глупо. Только к доступности сервера по IP или доменному имени это не имеет никакого отношения.
2. Перевесить ssh порт (и ftp), к примеру, на 10963 порт и 8523 порт соответственно. Ограничить доступ по ip для ssh (и ftp), для совсем уж параноиков отключить вход для root, и каждый раз мучить себя командами "sudo..."
Параноя непричем. Доступ к сервисам, которые не являются публичными - и не должен быть таковым. Ну и отключают вход для root - вовсе не для того, чтобы себя "мучить":
И отключить рутовый доступ - это в первую очередь, а не для параноиков.
Это _азы_. Самая простая причина: наиболее вероятный источник поломки - Вы. Работа под обычным пользователем не позволит Вам просто из-за опечатки снести полсервера.
3. Включить автоматическое обновление пакетов на сервере.
И молиться?
Кажись все.
Даже когда Вы школу закончите - "все" Вы вряд-ли сумеете перечислить.
А все потому, что ТС покуда и задачу толком не сформулировал. Он перечислил ровно _одну_ угрозу, от которой хотел бы защититься. Критично ему, например, - если зашифрованный файл просто удалят с сервера? А все Ваши "защиты" это позволяют - причем влегкую.
Бессмысленно защищаться от всего на свете ("максимальная защита" - маркетоидный бред): секс в водолазном костюме, наверно, более чем безопасный... Но кому оно надо, ы?
p.s. быть может важность инфы несколько преувеличена.
Вот это единственный пункт, с которым можно согласиться.
noseomen, хреновый из Вас постановщик задач. Видел несколько Ваших тем по защите той или иной информации - везде тёмный лес, никакой конкретики.
При этом Вам уже не один раз указывали на то, что нужно определиться с ценностью информации и потенциальными угрозами, а уж потом строить защиту (сорри за оверквотинг):
...
Надо анализировать методы, которыми вы будете обеспечивать доступ к данным авторизованным лицам и оценивать их слабые места. Если данные на сервере вообще не будут расшифровываться, а только храниться, то задача сильно упрощается.
Без постановки конкретной задачи сложно что-то подсказать. Вобще это вопрос компромиса ценности данных и затрат на их безопасное хранение.
Необходимо оценить для себя эти данные, и выделить бюджет на их защиту.
Дальше необходимо понять от чего или от кого нужно защитить данные.
...
...
А все потому, что ТС покуда и задачу толком не сформулировал. Он перечислил ровно _одну_ угрозу, от которой хотел бы защититься. Критично ему, например, - если зашифрованный файл просто удалят с сервера? А все Ваши "защиты" это позволяют - причем влегкую.
...
Для начала - учите "матчасть". Почитайте какую-нибудь книжку по защите информации, а лучше несколько. Не забывайте, что "три кита" информационной безопасности это: конфиденциальность, целостность и доступность информации. А у Вас, пардон, из трёх только один остался, да и тот шибко урезанный )))
Порядок действий такой: строите модель защищаемой информации, потом модель угроз безопасности и только после этого - строите модель защиты информации. В текущем варианте всё наоборот: Вы ищете средство защиты, а потом придумываете как и что будете защищать. ИМХО, напоминает удаление гланд через самизнаетекакоеместо. И если в корне не поменяете подход - результат может оказаться весьма плачевным...