Linux Debian

[oldbay]

Софтом старше экскрементов мамонта тоже вредно пользоваться. Из-за уязвимостей и старых модулей ядра, например.

Если вопрос касается замороженных веток дебиана и редхата - то тут древние только версии программ - (в centos 5 стоит ядро версии 2.6.18) = но они на протяжении поддержки версии дистрибутива постоянно патчатся заплатками безопасности + явные ошибки правятся. Откуда и появляются версии ядра, в том же centos, 2.6.18-224! и т.д.

Конечно данные минорные патчи нового функционала не приносят - но стабилизацию и безопасность обеспечивают.

Ядро и софт можно и самому прикрутить, не? )

Так кто же говорит что нельзя. Только делать из монолитного инструмента,коим редхат является, сборную солянку совсем как то не хочется.

Когда жизнь заставляла,требовалось некоторые устройства к centos 5 серверу цеплять, то и ядро из fedora 8 src.rpm собиралось руками и для софта дополнительного писались spec файлы(для того же SAMS) потом с "радостным визгом" устанавливались.

В конце концов есть и дополнительные репозитории от таких же самопалов-умельцев и даже сайт для поиска этих , в том числе самопальных, репозиториев. И уж к совсем вещей радости приверженцев redhat only и навсегда - серьёзный проект Scientific Linux от, обожаемых героями ТБВ, специалистов ЦЕРН - хороший, годный, дистрибутив основанный на redhat с приятным спектром дополнительного софта и относительно свежими ядрами - и вся эта радость относительно легко устанавливается на centos 5.

Таки все словоблудие развел только с одной целью - показать что и из редхата можно слепить, в том числе , годную десктопную убунту - вопрос только зачем? Зачем использовать микроскоп для разлядывания грязи по ногтями или болгарку для нарезания колбасы? - они для другого предназначены

Потому и написал что для десктопа он не удобен(но применим как и любой другой линукс) - а лучше использовать чтото другое с репозиторием побольше и с софтом посвежее

Вот как бы к рукам прибрать эквивалент Redhat network, да так чтоб без гемора и нахаляву ))

RHN-? Были разговоры что RedHat-оиды собираются открыть исходники сей радости. Правда давно их продолжения не слышал.

[oldbay]

Ну конечно. А еще принцип "да кому нахер надо нас ломать!"

Иногда лучше предупредить беду, чем разбираться с последствиями...

Воистинну дурацкий принцип. Просто были прецеденты когда: после мониторинга инфраструктуры указываешь на явные дыры в безопасности (типа промапленных наружу из локали портов, неправильно настроенного ssh, iptables, использования уязвимых версий софта для создания смотрящих наружу сокетов и т.д.) а в ответ получаешь пресловутое: "да кому мы нужны чтобы нас ломать!". А когда уже ломают - то орут на тебя что якобы не предупредил или вообще знал и сам сломал - потому что раньше никто не знал, якобы, и не ломал, соответственно.

Сладу нет с этим дурацким мнением .... в последнее время стал сразу оговаривать: что ни буду ничего делать на внешней стороне инфраструктуры, если рекомендации по безопасности будут проигнорированы.

[S10]

Если вопрос касается замороженных веток дебиана и редхата - то тут древние только версии программ - (в centos 5 стоит ядро версии 2.6.18) = но они на протяжении поддержки версии дистрибутива постоянно патчатся заплатками безопасности + явные ошибки правятся. Откуда и появляются версии ядра, в том же centos, 2.6.18-224! и т.д.

Конечно данные минорные патчи нового функционала не приносят - но стабилизацию и безопасность обеспечивают

Я как раз про новый функционал. Например, чтобы добавить в Debian 6 модули ядра Hyper-V Integration Tools, надо качать и компилить свеженькое ядро. В Ubuntu 10.04 часть этих модулей уже запилена, а с 10.10 имеется все необходимое.

Немного некорректный пример, но тем не менее.

[oldbay]

Я как раз про новый функционал. Например, чтобы добавить в Debian 6 модули ядра Hyper-V Integration Tools, надо качать и компилить свеженькое ядро.

Ну так похожих примеров масса: и драйвер aufs приходилось в центосовское(федорино) ядро имплантировать и собирать как для центоса, так и однажды для того же сверсвежего арча ядро с патчами для OpenVZ.

Правда как в моих , так же как ваших примерах идет разговор не а новом функционале , а о дополнительном.

Для меня новые ядра хороши наборами новых драйверов к устройствам - когда все начинает без бубна подключатся - серьёзный качественный перелом в этом плане произошел с версии ядра 2.6.30, а на 5-м центосе ядроо 2.6.18 патченое по безопасности , но ,естественно, без обновленной драйверной базы.... оттого и страдания.

 

В Ubuntu 10.04 часть этих модулей уже запилена, а с 10.10 имеется все необходимое.

Тут вопрос скорее в том как патчит ядро мантейнер конечного дистрибутива. В убунту скажем может сие и запатчено, а в той же слакваре, которая ставит чистые непатченныя ядра, такого может не оказаться.

Вернусь к соему любимому aufs = раньше ядро арча было пропатчено для его поддержки, а сечас убрали нафиг = и у меня осталось 3 гребучих варианта для работы с кроссмонтированием: aufs-fuse(но такого г..на в сервере бездисковой загрузки и нак не нужно), собирать ядро с поддержкой aufs из AUR, ну и самый адекватный = собирать ядро в gentoo - то которое нужно(с тем же aufs).

[Set7]

Согласен насчёт дремучего и непопулярного софта Дебиан,но он почти без глюков.Да и я просто привык к второгному.А так,чисто интуитивно,нравиться Минт.

[pork]

Э хе хе, хрю хрю....

 

А теперь, внимание - вопрос !

 

Представьте, что у вас есть комп на Дебиане или там на Убунте и вы выполняете на нём

команду:

iptables -A INPUT -j DROP

которая тупо дропает все входящие пакеты.

 

Вопрос: будет ли работать интернет (хотя бы просмотр сайтов) после такой команды ?

[oldbay]

Представьте, что у вас есть комп на Дебиане или там на Убунте и вы выполняете на нём

команду:

iptables -A INPUT -j DROP

которая тупо дропает все входящие пакеты.

 

Вопрос: будет ли работать интернет (хотя бы просмотр сайтов) после такой команды ?

 

Свин ... троллить iptables-ом - это сильно ))

 

А какие правила были объявлены в INPUT перед тем как ты вводишь свою супер команду?

Видимо, всё таки, сначала ты формируешь что то вроде:

# разрешить весь INPUT с lo интерфейса
iptables -A INPUT -i lo -j ACCEPT
# разрешить все входящие инициированные вашим OUTPUT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

ну и наконец вводишь страшное:

#задропать все остальные входящие пакеты
iptables -A INPUT -j DROP

В таком виде, да - будут все интернеты работать.... если ты еще и с OUTPUT ничего не химичил

[pork]

Да нет, изначально ничего, то есть во всех цепочках политика ACCEPT.

 

Ты поставь голенький Дибиан и убедись, что ничего такого нету:

 

# разрешить весь INPUT с lo интерфейса

iptables -A INPUT -i lo -j ACCEPT

# разрешить все входящие инициированные вашим OUTPUT

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

 

а есть только:

 

# iptables -L -t filter

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

# iptables -L -t nat

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

# iptables -L -t mangle

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

 

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

[oldbay]

Да нет, изначально ничего, то есть во всех цепочках политика ACCEPT.

 

Ты поставь голенький Дибиан и убедись, что ничего такого нету:

 

# разрешить весь INPUT с lo интерфейса

iptables -A INPUT -i lo -j ACCEPT

# разрешить все входящие инициированные вашим OUTPUT

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

так ясно дело на свежеустановленной системе такого ничего нет

 

а есть только:

 

# iptables -L -t filter

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

# iptables -L -t nat

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

# iptables -L -t mangle

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

 

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

то есть нихрена нет

 

ты хочешь сказать что на таком девственно-розовом iptables добавление правила

 

-A INPUT -j DROP

 

у тебя весь входящий траффик не рубится?

там по сути должен рубится весь трафик в том числе и с lo интерфейса - ломая в том числе функционал некоторого софта (тот что хочет локалхост видеть)

 

а что говорит iptables -L -v -t filter ?

 

пакеты вообще через iptables идут? хотя бы в принципе через INPUT?

 

Если не идут, скорее всего нужно ковырять настройки ядра в /proc/sys/net/ipv4 - те же настройки после испытаний можно добавить в /etc/sysctl.conf

Честно не знаю как в дебианах, но в редхатах, арчах и гентах там вырубат по умочанию только форвардинг(пакеты по форварду вообще не идут) net.ipv4.ip_forward = 0.

[pork]

Я вопрос задал.

И жду ответа - да или нет. (желательно, аргументированного ответа).

 

ps: и да, ваще не понимаю, как связано пользование инетом (запросы к внешним адресам и ответы он них)

с интерфейсом lo.

 

считай для определённости, что lo с его 127.0.0.1 тут ваще нипричём.

есть eth0, с параметрами: адрес=192.168.0.100, маска=255.255.255.0, шлюз=192.168.0.1, dns=8.8.8.8.

в роутер он смотрит, короче, и пользуется днсом гугла, но это не суть.

 

И вот вопрос - что будет после iptables -A INPUT -i eth0 -j DROP

?

 

После того, как будут запрещены входящие пакеты с eth0.

 

pps: форвардинг по дефолту вырублен везде, он не связан с пользованием инетом

конкретно с данного компа. он свзязан с транзитом пакетов с одной сетевой карты на другую,

когда пришёл пакет не для нас, а для других и его надо переправить в другую сетевую карту,

вот тогда надо включать форвардинг.

[oldbay]

Я вопрос задал.

И жду ответа - да или нет. (желательно, аргументированного ответа).

Свин не наглей, иначе я с тобой играть не буду

ps: и да, ваще не понимаю, как связано пользование инетом (запросы к внешним адресам и ответы он них)

с интерфейсом lo.

считай для определённости, что lo с его 127.0.0.1 тут ваще нипричём.

а lo мой хрюкатый друг, тоже интерфейс и тоже сетевой , и когда ты рубишь весь input ты дропиш пакеты в том числе и с него, и так же с прочей виртуальщиной tun ppp br и т. д.

 

есть eth0, с параметрами: адрес=192.168.0.100, маска=255.255.255.0, шлюз=192.168.0.1, dns=8.8.8.8.

в роутер он смотрит, короче, и пользуется днсом гугла, но это не суть.

 

 

И вот вопрос - что будет после iptables -A INPUT -i eth0 -j DROP

?

 

После того, как будут запрещены входящие пакеты с eth0.

ничего не будет, если не созданы другие правила перед глобальным дропом входящих пакетов.

 

Тут теория простая: правила выполняются по очереди с верху в низ - если пакет соответствует правилу к нему это правило и будет применяется.

У тебя глобальная политика к INPUT выставлена в ACCEPT(она никого не блокирует - по типу все разрешить а потом отдельными правилами запрещать), после чего ты создаешь единственное правило iptables -A INPUT -i eth0 -j DROP(тоесть убить все что валится с eth0) и должен в результате получить 0 входящих пакетов на любой посылающий запросы локальный софт(браузеры, wget-ы и т.д.), так как ответные пакеты на твои запросы погибли в неравном бою с DROP-ом.

 

pps: форвардинг по дефолту вырублен везде, он не связан с пользованием инетом

конкретно с данного компа. он свзязан с транзитом пакетов с одной сетевой карты на другую,

когда пришёл пакет не для нас, а для других и его надо переправить в другую сетевую карту,

вот тогда надо включать форвардинг.

форвардинг тоже таблица fiter его отключение в sysctl я тебе как пример привел - что многое можно переменными ядра рулить.

[pork]

Садись, два.

 

Инет будет прекрасно работать.

 

Почему же это так, объяснить тебе ?

[oldbay]

Почему же это так, объяснить тебе ?

обьясни, будь так добр

[alexastor]

Вопрос: будет ли работать интернет (хотя бы просмотр сайтов) после такой команды ?

Инет будет прекрасно работать.

К чему все это?

[scorcer]

свин

осилив ман, не стоит думать что ты круче всех.

а обьяснения твои я тоже почитаю, так что не откладывай.

 

а по теме вот держи картинку.

[kenika]

да уж какой там ман, такое знание рождается из экспериментов.

[pork]

да пошутил я, ничё я не знаю, будет ли там инет или нет.

и ваще линукс говно, рулит винда.

 

но.... если сильно хочется, можно взять VirtualBox, поставить минималистический Debian

и проверить на практике.

результат поразителен и необъясним !

[oldbay]

но.... если сильно хочется, можно взять VirtualBox, поставить минималистический Debian

и проверить на практике.

результат поразителен и необъясним !

хорошо тролохрюша, так и быть, посмотрю(хотя дебияном и не пользуюсь)... но вот в магию я не верю, всему есть причины.

[scorcer]

Свин

А какого тогда было" я задал вопрос", " садись, два"..?

 

Если тебе есть что написать - напиши. Ненадо тут "результат поразителен" и прочая хня, не трать мое время.

[oldbay]

Если тебе есть что написать - напиши. Ненадо тут "результат поразителен" и прочая хня, не трать мое время.

Тратить наше время, это его лучшая развлекуха ... он же трололо

Мне вот тоже лень дебиан ставить ради хрюшкиного развода. Возможно когда нибудь подвернется работа на debian по умолчанию, вот тогда и посмотрю .... наверное

[kenika]

Есть такой модуль ядра nf_conntrack, в чём несложно убедиться

с поомщью

 

lsmod

modinfo nf_conntrack

 

Он занимается отслеживанием IP-соединений, и всегда можно

посмотреть детальный отчёт о них, просто сказав

 

cat /proc/net/ip_conntrack

 

C одной стороны, отслеживание соединений и построение детатьного отчёта по ним

вроде бы не должно влиять на работу правил IPTABLES, но вот с другой стороны...........

 

http://www.frozentux.net/iptables-tutorial...ONNTRACKENTRIES

[oldbay]

Есть такой модуль ядра nf_conntrack, в чём несложно убедиться

с поомщью

 

lsmod

modinfo nf_conntrack

 

Он занимается отслеживанием IP-соединений, и всегда можно

посмотреть детальный отчёт о них, просто сказав

 

cat /proc/net/ip_conntrack

 

C одной стороны, отслеживание соединений и построение детатьного отчёта по ним

вроде бы не должно влиять на работу правил IPTABLES, но вот с другой стороны...........

 

http://www.frozentux.net/iptables-tutorial...ONNTRACKENTRIES

 

Вот, совсем другое дело - это уже интересно.

Спасибо мегасвин, покурим твои доки.

[kenika]

Э, нет, в том мегамане ничего не сказано, как влияет nf_conntrack

на работу правил iptables, а он сцуко влияет.

 

Влияет так - если какой-то пакет проходит по разрешённому правилу,

то и ответные пакеты по этому соединению тоже пропускаются,

вот почему

 

iptables -A INPUT -j DROP

 

не будет препятствовать получению ответных пакетов по поднимаемым куда-то соединениям,

но первым к тебе снаружи обратиться конечно же никто не сможет.

 

Чтобы это безобразие отключить надо выкинуть модуль ядра nf_conntrack

или просто запретить трекинг пакетов, это делается так:

 

iptables -t raw -A OUTPUT -j NOTRACK

 

вот тогда

iptables -A INPUT -j DROP

действительно булет рубить всё входящее.

 

 

http://www.frozentux.net/iptables-tutorial...es_traverse.jpg

[oldbay]

Э, нет, в том мегамане ничего не сказано, как влияет nf_conntrack

на работу правил iptables, а он сцуко влияет.

 

Влияет так - если какой-то пакет проходит по разрешённому правилу,

то и ответные пакеты по этому соединению тоже пропускаются,

вот почему

 

iptables -A INPUT -j DROP

 

не будет препятствовать получению ответных пакетов по поднимаемым куда-то соединениям,

но первым к тебе снаружи обратиться конечно же никто не сможет.

 

Чтобы это безобразие отключить надо выкинуть модуль ядра nf_conntrack

или просто запретить трекинг пакетов, это делается так:

 

iptables -t raw -A OUTPUT -j NOTRACK

 

вот тогда

iptables -A INPUT -j DROP

действительно булет рубить всё входящее.

 

 

http://www.frozentux.net/iptables-tutorial...es_traverse.jpg

интересный механизм, обязательно протестирую.

вообщето всегда считал: чтобы запустить обратно через input ответные пакеты от разрешенных через output запросов, требуется добавить в input правило:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

перед

iptables -A INPUT -j DROP

либо просто обьявить при этом глобальные правила input-а в DROP

п.с:

Видимо из за глобального дропа input-а(то что и советовалось в старинных доках по iptables) у меня такого казуса с прохождением conntrack пакетов никогда не было - так как по умолчанию всё убивалось,если специальным правилом не разрешить, - даже они.

Еще раз спасибо, свин, за инфу - буду подозрительнее относиться к conntrack ..... вот блин засада то

[kenika]

А чё плохого ?

Пишешь разрешающее правило и при этом автоматом подразумевается,

что и ответные пакеты к этому правилу тоже пройдут по нему - этож просто, понятно и удобно !