Безопасность Capistrano
Благодаря всем комментаторам. Я думаю, что нашел ответ. По крайней мере, в сервере версии 2.6.32 30 ядра Ubuntu, кажется, существует ошибка хронометрирования. Ошибка иногда(?) уничтожает машины, когда они достигают времени работы приблизительно 200.. 210 дней. На самом деле останова сразу не происходит после того, как предел достигнут, но инициирован некоторой операцией (в моем случае: apt-get install ...).
NB: 200 дней о 2^32, времена 1/250 второй, и 250 являются значением по умолчанию для CONFIG_HZ.
На данный момент, я не нашел данные по тому, была ли проблема решена в более свежих ядрах. Я знаю, что это, кажется, не влияет на более старое ядро (2.6.32 26 серверов). От всей этой информации я предполагаю, что, если она еще не фиксируется, ею можно избежать:
- загружают машины каждые 190 дней (хорошая идея для обновлений ядра так или иначе)
- корректируют CONFIG_HZ к 100 и таким образом делают его каждые 497 дней. Однако это могло бы иметь довольно неожиданные побочные эффекты, особенно в виртуальных средах. И это не делает , решают проблема.
Вот отчет об ошибках для Ubuntu.
Одной вещи i 'll нравится добавлять, то, что было бы лучше исключить парня нечто из способности войти от ssh, Что я имею в виду, должен соединиться с сервером как пользователь "супермен" и впоследствии использование su foo чтобы стать пользователем нечто и выполнить любую команду, Вы хотите
Используя этот путь, взломщику нужны оба пароля / закрытый ключ, чтобы смочь использовать capistrano. Если он был закрытым ключом, он может соединиться с сервером, но не может выполнить capistrano., если у него есть пароль, он не может даже соединиться с сервером, потому что пользовательскому нечто не позволяют войти в систему.
это не действительно проблема capistrano, больше ssh один. Если Вам разрешают войти в систему машина через ssh (с ключом или паролем), если взломщик находит те учетные данные, он может также сделать то, что Вам разрешают сделать на тех машину. Ваш системный администратор имеет к границам множества к тому, что Ваш развертывать учетную запись может сделать (разрешение файла, полномочия команды...). Существует хороший walktrough того, как защитить ssh для тех, определяют задачу здесь для http://www.linuxjournal.com/article/8257
Если Вы используете ключи SSH для аутентификации, и кто-то крадет их, это - та же самая ситуация, как будто кто-то украл пароль той учетной записи пользователя; в обоих случаях он получил бы полномочия, связанные с той учетной записью.
Поэтому доступ SSH к общедоступному серверу не должен быть предоставлен снаружи Вашей сети компании: этот путь, даже если кто-то знал пароль root, он просто, не мог бы использовать его для соединения с веб-сервером.
Я надеюсь, что Вы защищаете тот сервер с брандмауэром, или, приводя это к сбою, Вы, по крайней мере, используете веб-сервер, встроенный один (IPTABLES на Linux, я предположил бы) только позволить трафик HTTP/S с внешней стороны. Если Вы не... хорошо, сделайте это. Теперь.
Вы уверены, что это - проблема?
если кто-то крадет нашу общественность ssh
Это было бы закрытым ключом, не общедоступным. Ваши административные пользователи, вероятно, аутентифицируются таким же образом, и это - разумная установка.
Действительно необходимо защитить те ключи, одинаково. Имейте хост управления с закрытым ключом хорошо firewalled и плотно управляемый доступом.
Существуют некоторые опции для улучшения:
Вы могли пойти полностью с двухфакторной аутентификацией, но это бесполезно, не делая того же к Вашему административному доступу.
Другая опция состояла бы в том, чтобы иметь аутентификацию ssh-агента использования capistrano.
Если Вы не используете capistrano ни для чего кроме начального развертывания, Вы можете сделать, чтобы тот пользователь самоликвидировался, IE удаляют pubkey из .ssh каталога.
если кто-то крадет наш частный ssh ключ и доступ к нашим машинам как пользователь нечто, может удалить веб-сайт
Зашифруйте свои закрытые ключи SSH с безопасным паролем и не копируйте их в удаленные серверы.
Если кто-то овладеет Вашим закрытым ключом, то он будет бесполезен им без пароля.