Что касается SELinux.
man getsebool
getsebool |grep http/ftp и т.п.
setsebool value=on/off
man chcon
Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
Уже обсуждалост в комментах к одному из топиков. Какая разница — пароль юзера 8 символов и 8 символов пароль рута или пароль только на рута, но 16 символов? Это при использовании паролей. При использовании ключей все равно админы любят sudo без паролей делать — толку в таком случае рута закрывать?
Порты полезно менять, если наш провайдер по дефолту блочит 22 порт. Это отголоски того самого бага в SSHv1. Плюс у нескольких хостеров встречал, что ssh открывается только для определенных адресов. Я предпочитаю делать это сам, поэтому перевешиваю ssh.
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
Смысл в том, что на российском рынке, продавая честно юзерам софт, много не заработаешь. И по причине менталитета юзеров и из-за особенностей ведения бизнеса.
Я знаю что такое ребиллы и как они работают.
>Дураков эффективнее лечить именно рублём
Собственно дураков в штатах уже несколько раз так лечили. Была в свое время шумная история с адалтовым платником, который якобы давал доступ к сайту на халяву при введении данных карты. Только вот мелким шрифтом было указано, что в нагрузку идет подписка на два платных сайта за $50 в месяц. Сайт как минимум год или два отработал прежде чем его закрыли. И это в штатах. В наших реалиях подобные конторы при популяризации карт начнут плодиться как грибы после дождя.
Ну и с нашим менталитетом, законами и правоохранительными органами, при популяризации карт сразу появятся конторы, которые начнут продавать софт/сервисы с оплатой кредиткой и мелким пунктом в пользовательском соглашении, который им формально позволит биллить карту юзера каждый месяц пока юзер сам не дойдет до банка и не сделает чачу, а таких будет меньшинство.
То есть, то что русскому хорошо — то немцу смерть. Т.е. работающие в штатах технологии не факт, что будут работать у нас.
Плюс контент-провайдеры у многих юзеров на корню убили своими платными смс эту тягу к покупке простым способом. После диких списаний с мобильного счета, юзер теперь пять раз подумает прежде чем светить карту при покупке софта.
Чтобы собака укусила кормящую руку?
Если аналитики скажут что платформа провальная, то к выходу платформы на массовый рынок не будет достаточного количества приложений, т.к. разработчики эти прогнозы тоже читают. Не будет приложений — не будет продаж. И платформа действительно будет провальной. Так что тут работает обратная связь и подкармливает ее сами-знаете-кто :)
Спасибо за пример.
В принципе я в курсе, что такое поведение программы не должно приводить к падению ядра, но в случае с тем софтом — у меня нет исходников и я не знаю как именно программа пытается память запросить и как/на каком языке она написана. То есть могу только говорить о том, что такое есть и видел/вижу такую проблему своими глазами, при том софт запускается под обычным юзером. Проблема решается увеличением свопа или наращиванием оперативки.
Честно говоря за 13 лет ни разу такого не было. Если система стоит не на массиве, то при деградации диска без разницы как смонтирована ФС. На системах с аппаратными raid-контроллерами или нативным софт-raid линуксов тоже такое не видел. А вот в полусофтовых контроллерах каких только барабашек не встречал.
Софт раид был родной линуксовый?
И как интересно вы спасете /sbin? Корневую ФС в RO монтировать — не проканает. /sbin вынести на отдельный раздел — тоже.
Ну это собственно не удивительно — родная ось в родном гипервизоре шустрее будет бегать. Если количество виртуалок под виндой приближается к 10ку, то стоит задуматься о родном для винды решении.
Просто удивился — Xen вроде как пилится Цитриксом, если бы у них винда криво работала, то вмварь давно бы их в прессе камнями закидала.
Странно. У меня опыта с виндой не очень много — в основном все виртуалки с центом или RHELом. На работе 7 виртуалок под XenServer бегают, дрова стоят цитриксовые. Не уверен конечно на 100%, что они полностью паравирт (не ковырял), но машинки бегают очень шустро.
Пару машин еще запускал на Xen под RHEL в режиме полной виртуализации, они да — не так шустро как хотелось бы работали. Недавно перевел их под KVM с паравирт дровами, вроде шустрее бегают.
В обоих случаях ни разу не видел BSOD.
>Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
Ээээ… А в чем проблема с Xen? Под винду паравирт дрова есть и работают нормально. Под фряху — не знаю, но если и нет, то можно в полной виртуализации запустить.
Опять же Citrix XenServer в базовом варианте очень неплох и халявен.
Я не знаю почему именно оно стопорится, но на самом последнем RHEL4. При запуске этой задачи если своп+память меньше запрошенного объема, то получаем полный стоп системы с паникой и дампом. Местные программеры ковырялись, сказали что стоп идет в момент когда задача пытается отожрать память. В детали я особо не вдавался — и без этого дел хватает.
Нет, пытаюсь на пальцах объяснить, что заполнение свопа на несколько процентов это не страшно во многих случаях. Почему на пальцах — я вас не знаю и не знаю вашего уровня подготовки.
Надо смотреть, что происходит при этом с оперативкой. Если очень хорошая ее часть отдана под кеш, то ничего страшного нет. А вот если кеш практически не занимает оперативку и у нас юзается своп, то память надо наращивать. Самое по себе использование свопа — не показатель.
Пример — оперативки 16 гиг, 10 под кешем, в свопе живет гиг. Надо наращивать память? Нет. Просто какие-то процессы так долго ни фига не делали, что система решила их выкинуть в своп, и правильно сделала.
Опять же еще рабочий пример. Старая десктопная машина на работе. Установлено было 2 гига оперативки. Постоянно была запущена куча задач, большая часть из которых висела в фоне и открывалась пару раз за день. Почему и т.п. в данном случае не вопрос — так надо и мне так удобно. При таком количестве задач система лагала временами. Подключил своп — все летает. Подождать пару секунд пока система вытащит из свопа редко используемую задачу меня не напрягает. Держать эти задачи постоянно в памяти — смысла нет. Покупать ради них дополнительную память — тоже не имеет смысла. Повышенная нагрузка на винт? Да и фиг бы с ним, они нынче все равно обычные расходники. Да и остановка/запуск этих задач каждый раз вызовет большую нагрузку на винт, чем выдергивание их из свопа.
man getsebool
getsebool |grep http/ftp и т.п.
setsebool value=on/off
man chcon
Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
>Дураков эффективнее лечить именно рублём
Собственно дураков в штатах уже несколько раз так лечили. Была в свое время шумная история с адалтовым платником, который якобы давал доступ к сайту на халяву при введении данных карты. Только вот мелким шрифтом было указано, что в нагрузку идет подписка на два платных сайта за $50 в месяц. Сайт как минимум год или два отработал прежде чем его закрыли. И это в штатах. В наших реалиях подобные конторы при популяризации карт начнут плодиться как грибы после дождя.
То есть, то что русскому хорошо — то немцу смерть. Т.е. работающие в штатах технологии не факт, что будут работать у нас.
Если аналитики скажут что платформа провальная, то к выходу платформы на массовый рынок не будет достаточного количества приложений, т.к. разработчики эти прогнозы тоже читают. Не будет приложений — не будет продаж. И платформа действительно будет провальной. Так что тут работает обратная связь и подкармливает ее сами-знаете-кто :)
В принципе я в курсе, что такое поведение программы не должно приводить к падению ядра, но в случае с тем софтом — у меня нет исходников и я не знаю как именно программа пытается память запросить и как/на каком языке она написана. То есть могу только говорить о том, что такое есть и видел/вижу такую проблему своими глазами, при том софт запускается под обычным юзером. Проблема решается увеличением свопа или наращиванием оперативки.
Софт раид был родной линуксовый?
И как интересно вы спасете /sbin? Корневую ФС в RO монтировать — не проканает. /sbin вынести на отдельный раздел — тоже.
Просто удивился — Xen вроде как пилится Цитриксом, если бы у них винда криво работала, то вмварь давно бы их в прессе камнями закидала.
Пару машин еще запускал на Xen под RHEL в режиме полной виртуализации, они да — не так шустро как хотелось бы работали. Недавно перевел их под KVM с паравирт дровами, вроде шустрее бегают.
В обоих случаях ни разу не видел BSOD.
Ээээ… А в чем проблема с Xen? Под винду паравирт дрова есть и работают нормально. Под фряху — не знаю, но если и нет, то можно в полной виртуализации запустить.
Опять же Citrix XenServer в базовом варианте очень неплох и халявен.
Пример — оперативки 16 гиг, 10 под кешем, в свопе живет гиг. Надо наращивать память? Нет. Просто какие-то процессы так долго ни фига не делали, что система решила их выкинуть в своп, и правильно сделала.