Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
вопрос о том в какой степени необходимо защищать SLES который стоит за маршрутизаторм
 
В общем ситуация такая планирую поставить SLES за маршрутизаторм и думаю надо ли будет приобретать подписку на обновления или можно обойтись.

вопрос 1й: сервак будет хостингом для vmware server, никаких входящих пакетов на его IP из внешней сети маршрутизатор пропускать не будет,  внутри, на  виртуалке ,на нем будут крутится сервера на которые будет сделан проброс входящих пакетов для некоторых портов. Вроде на  его (хоста) IP никаких пакетов не приходит и даже если какя то уязвимость будет присутствовать, то вроде воспользоваться ей будет нелегко. Хотя конечно через его сетевой интерфейс пакеты все таки будут проходить дабы дойти до виртуализованых серверов. Но я думая что взломать транзитными пакетами нелегко и с практической точки зрения можно считать что обновления на него ставить не требуется. А как вы думаете? кстати SLES на этом сервер не константа, можно похостится и на другой версии, просто я точно знаю что vmware server работает хорошо на SLES, а на других не пробовал.

Вопрос 2: за маршрутизатором будет стоять SLES (тут без вариантов, поскольку поставщик того ПО которое будет на него установлено соглашается только на SLES, на другие версии не разрешает ставить). На него будут переадресовываться входящие HTTP запросы. прикладное ПО будет отвечать посредством апача(как конкретно они будут взаимодействовать поставщик не ответил, сказал только что будет чрез апач). Ни какие другие входящие пакеты не планируются. Я вот задумался, на этот сервер стоит  ли приобретать подписку, или просто периодически апач обновлять? другие сервисы то все равно не будут доступны через входящие пакеты. Или если уязвимость будет в ядре, то можно внедриться будет?  Как вы думаете?

При рассмотрения этих вопросов давайте условимся считать что из лакалки серьезно проникать на сервера не будут а  требования к уровню безопасности от проникновения из внешней сети умерены, т.е. можно считать допустимым риск проникновения, при условие что на практике это сделать весьма затруднительно.

Пажайлуста подскажите что вы думаете по этим вопросам.
 
Цитата
Но я думая что взломать транзитными пакетами нелегко
Взломают хост в vmware, и уже изнутри - сам сервер. :) У нас vmware-server крутится на платформе CentOs 5.2 - 5.3.

Цитата
На него будут переадресовываться входящие HTTP запросы. прикладное ПО будет отвечать посредством апача(как конкретно они будут взаимодействовать поставщик не ответил, сказал только что будет чрез апач).
Прежде всего - никакого NAT-а для этой машины. Поставьте фронтендом - nginx и на нем обрезайте все, что не должно проходить на апач - там можно даже содержимое http запросов ограничивать, если разработчику надо ходить снаружи - туннелируйте по ssh с ключами через внешний шлюз. Тогда, если не принимать во внимание возможные дырки в прикладном ПО, можно спать спокойно.
 
Цитата
Взломают хост в vmware, и уже изнутри - сам сервер
Ну я планирую гостевые ос более менее защищеные располагать, хотя конечно могут и взломать.
Цитата
У нас vmware-server крутится на платформе CentOs 5.2 - 5.3
Спасибо за подсказку, сегодня поставил CentOS, правда vmware-server еще не успел
Код
если разработчику надо ходить снаружи 
Да он будет ходить снаружи по SSH и VNC причем с правами root'а. Хотя, честно говоря мне это  не нравиться, мне кажется это неправильно что кто то будет лазать по серваку с админским правами. Но выбора нет.
Цитата
Поставьте фронтендом - nginx
Да наврено так и сделаю. Собственно в выделенной гостевой ос на тот хост про который писал выше и поставлю. Обещают перевезти asa5510, в ней вроде  будет  функции предотвращения передачи подозрительных пакетов в внутреннею сеть. кстати интересно а фильтрации входящих http запросов в ней нет? может ей тоже можно ограничить? Не сталкивался еще с asa, буду разбираться как привезут.
 
Цитата
lw+ пишет:
Да он будет ходить снаружи по SSH и VNC причем с правами root'а.

Зачем веб-разработчикам права рута? :) Заведите через sudo те команды, которые ему нужно будет выполнять, или загоните разработчиков в виртуальную машину. Хотя, тут вопрос - кто отвечает за хост систему: если разработчик - то и флаг ему в ..., а вот если Вы - то никаких административных прав третьим лицам давать нельзя.
 
[QUOTE]а вот если Вы - то никаких административных прав третьим лицам давать нельзя.[QUOTE] Заставили дать права.. Да и не разработчик-то он а просто тех подержка, политика у них такая что не разрешают программу самому ставить, только силами тех суппорта. они еще учетную запись в системе создали, хорошо хоть я не поленился аудит пароля провести, оказалось трех-буквенный пароль совпадающий с логином(он трех-буквенный) стоял...
 
Ну так дали бы права на время установки софта - потом, после установки и настройки, отобрали (сменили пароль) да и всего делов. :) На кухне двух хозяек быть не должно! У нас на работе несколько администраторов, но основную политику: что и как ставится на конкретный сервер, проводит один человек.
Страницы: 1
Читают тему