Связь с провайдером посредством установления ppp соединения.
Соответсвенно после дисконнекта ppp0 интерфейс пропадает (а вместе с ним внешний IP и доступ к нужным локальным серверам).
Надо, чтобы всегда был интерфейс с внешним адресом независимо от наличия реального соединения.
Нашёл, что для этого нужно поднимать dummy интерфейс.
В общем-то всё просто:
ifconfig dummy0 Мой_внешний_ip up
Вопрос:
Где ПРАВИЛЬНЕЕ это делать? Поднимать/опускать этот интерфейс в скриптах
/etc/ppp/if-up|down.local или где-то ещё?
В идеале, чтобы dummy0 интерфейс был всегда. Чтобы не было моментов, когда внешний ip недоступен.
(2) iptables -A FORWARD -i $EXT_I -s $EXT_NET -o $DMZ_I -d $DMZ_HTTP_IP -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -i $EXT_I -s $EXT_NET -o $DMZ_I -d $DMZ_HTTP_IP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $DMZ_I -s $DMZ_HTTP_IP -o $EXT_I -d $EXT_NET -m state --state ESTABLISHED,RELATED -j ACCEPT
где:
EXT_I -внешний интерфейс
EXT_NET - адреса внешней сети (если интернет, то этот параметр можно опустить)
EXT_IP - IP маршрутизатора на внешнем интерфейсе
DMZ_I - интерфейс, смотрящий в DMZ.
DMZ_HTTP_IP - адрес сервера в DMZ зоне
Всё это работает прекрасно (если я конечно нигде не ошибся).
Но с такой схемой проброса возможна (или невозможна?) примерно такая "атака", позволяющая выявить наличие DMZ.
Тогда для нормального доступа к DMZ_HTTP_IP должен прийти пакет с:
-s=10.0.0.20 -d=10.0.0.1 -p tcp --dport=80
пакет пройдёт через правило (1) и потом через правило (2).
Но ведь доступ получить можно и так:
На хосте 10.0.0.20 прописываем:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.1 dev eth0(к примеру)
Тогда придёт такой пакет (-d адрес в принципе можно угадать перебором):
-s=10.0.0.20 -d 192.168.0.10 -p tcp --dport=80
Пакет не пройдёт через правило (1) т. к. -d не совпадает с EXT_IP но благополучно пройдёт через правило (2) и тем самым выдаст информацию о наличии DMZ.
Я пробовал проводить такой эксперимент на простенькой одноранговой сети (на интерфейсе EXT_I), всё замечательно получается.
В некоторых источниках вместо правила (2) предлагают использовать совсем простое правило без проверки --dport и state.
Для исправления ситуации как я понимаю можно использовать например такое доп. правило, но только до принятия решения о маршрутизации и до раскрытия NAT пакета:
iptables -t mangle -A PREROUTING -i $EXT_I -s $EXT_NET -d $EXT_IP -p tcp --dport 80 -j MARK --set-mark 1
А правило (2) изменить примерно на такое:
iptables -A FORWARD -m mark --mark 1 -j ACCEPT
Что вы об этом всём думаете?
Может можно как-нибудь более изящно решить эту проблему?
Столкнулся с такой вещью.
Удалённо захожу на сервер (AltLinux 2.4) с правами обычного пользователя. Набираю ps -A, вижу только свои процессы (пробовал другие ключи -e, aux).
На своей машине (CentOS 4.4) набираю ps -A и вижу все процессы всех пользователей.
Более того, на удалённой машине не могу зайти в /proc/* где * - PIDы чужих процессов (sshd не в chrootе, по фс ходить разрешено)
На своей - спокойно захожу в /proc/*. И даже частично открываются файлы. (stat, cmdline и т. д.)
Вопрос: как сделать так, чтобы было видно только свои процессы (как на AltLinuxе) ну и /proc/* чтобы нельзя было особо шастать?
Есть маршрутизатор под управлением Linux.
На нём есть следующие интерфейсы: eth0, eth11, eth2, ppp0, tap0.
За интерфейсами сети:
eth0: 192.168.0.0/24
eth1: 192.168.1.0/24
eth2: 192.168.2.0/24
ppp0: 1.2.3.4 и весь интернет
tap0: 10.0.0.0/8
Также прилагается большая таблица статических маршрутов (фактически на всех интерфейсах)
Ну например такого вида:
route add -net 172.16.0.0/12 gw 192.168.1.254 dev eth1
Для всех интерфейсов выставлены в "1" rp_filter.
Всё работает.
Вопрос:
Нужно ли для усиления безопасности (борьба со спуфингом) в iptables прописывать правила такого вида:
iptables -A INPUT -i eth1 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j ACCEPT
iptables -A INPUT -i eth1 -j DROP
т. е. отфильтровывать пакеты с "правильными" исходящими IP на интерфейсе и блокировать с неправильными?
Она почему-то не хочет выполнять CWD в каталоги с буквой "я" в имени.
Пишет, что мол сервер вернул "Not Found"
Причём содержимое этого каталога она успешно возвращает, а вот содержимое вложенных каталогов уже не возвращает. Т. е. программа реально не может выполнить CWD.
Нашёл в коде место, где она выполняет CWD. Соответственно строку с именем каталога надо наверно как-то подкорректировать.
Вопрос: как?
Пробовал ставить вместо одного 0xff два раза 0xff. (где-то в инете такой способ нашёл, но не получилось)
А есть дистрибутивы, у которых нет релизов как таковых? Т. е. выпускаются потихоньку обновления и выпускаются. Софт устарел, заменили на более новый, ядро новое вышло - месяца два потестировали, заменили ну и т. д. Ну и чтобы обновления, связанные с безопасностью оперативно выпускались.
Чтобы не было этих проблем с прекращением поддержки старых релизов.
Позарез надо поднять почтовый сервер для Почти персонального использования. (пока один домен - ~ 7 пользователей)
Вот мучаюсь выбором: CommuniGate Pro или postfix/exim/... .
Всем CGP устраивает, и ставится/настраивается легко, и управление приятное через веб интерфейс и был опыт работы с ним, но... он слегка проприетарный.
С другой стороны postfix/exim/qmail и т. д. Всё хорошо, но вот нету времени на изучение конфигов, тонкостей и т. д. (Можете считать что ниасилил) Надо, чтобы поставил и работает. Причём всё сразу: SMTP/POP3/IMAP, веб интерфейс, веб администрирование. И по надобности легко конфигурируется.
Что посоветуете? Забить на всё и использовать CPG.
Или может какой-нибудь готовую рабочую связку, но под лицензией GPL?
Причём можно сразу дистрибутив для поднятия почтового сервера из коробки, т. к. ставить буду на выделенный виртуальный сервер.
Компьютер подключается к интернету посредством ppp (pptp) соединения.
Соответственно когда есть подключение - есть и интерфейс ppp0 с внешним IP адресом (статическим).
Когда сессия рвётся - интерфейс пропадает.
Вопрос:
Возможно ли на период пропадания ppp соединения сохранять ppp0 интерфейс? А ещё лучше, чтобы ppp0 интерфейс поднимался в процессе загрузки компьютера (независимо от успешности подсоединения к провайдеру)
Т. е. можно сделать как с обычным Ethernetом? Есть кабель - есть интерфейс, есть связь. Нет кабкля - нет связи, но интерфейс есть.
Вопрос простой, но чего-то как-то не получается :)
Есть: Apache. Запускается от имени apache и группы apache.
Есть каталоги пользователей:
/home/user1/public_html
/home/user2/public_html
/home/user3/public_html
...
Какие права должны быть установлены на /home/userX; /home/userX/public_html ?
В каких группах должны состоять user1, user2, ... , apache
чтобы apache мог и писать и читать в каталоги public_html всех этих пользователей, но пользователи соответсвенно не должны иметь доступа к каталогам друг друга?
Ситуация:
Есть набор программ - чёрных ящиков, крутящихся на сервере.
Раз в N месяцев ( N ~ 3-6 ) сервер виснет намертво.
Есть предположение, что вешает сервер одна из этих программ.
По косвенным признакам похоже, что у системы кончаются PIDы.
Чтобы доказать, что это именно так ( или опровергнуть ) хочется видеть динамику выдачи PIDов данным программам ( т. е. динамику вызовов forkов )
Как можно фиксировать в режиме реального времени ( т. е. не скриптом ps -aux под cronом :) ) факт выдачи PID конкретной программе ( факт вызова fork ) ?
Единственное что пока пришло в голову, это вот так:
xlib.c:
...
extern pid_t fork(void)
{
pid_t x;
x = syscall(SYS_fork);
printf("++++++ %d ++++++\n", (int) x);
....
здесь скорее всего dPID/dt анализироваться будет :)
....
return x;
}
ну и потом LD_PRELOAD=./xlib.so ./black_box
Какие ещё есть варианты или как этот усовершенствовать ( или исправить :) )?
Работать контрукция должна несколько месяцев и не требовать вмешательства человека.
На сервере стоит зона Europe/Moscow
UTC=false
Нужно ( захотелось всвязи с одной задачей ) перевести и железные и обыяные часы в зону UTC без перезагрузки.
Для этого соответственно надо поменять файл /etc/localtime на /usr/share/zoneinfo/UTC
и дать команду
hwclock --systohc --utc.
Вопрос вот в чём:
Может такой грубый "перевод" часов налету как-то отразиться на системе?
В частности на поведении ядра и файловой системе ( Softraid/LVM ) ?
Программы уровня пользователя не интересуют. Их если что можно будет перезапустить.
В руководстве по iptables написано, что в mangle не рекомендуется фильтровать трафик. В частности интересует DROP по критерию mark и DROP по критериям -i , -s.
Есть какая-нибудь техническая причина такого ограничения или так пишут просто из-за первоначального предназначения таблицы mangle ?
Надо отфильтровать все пакеты на интерфейсах с заведомо ложными источниками. Можно конечно некоторые пакеты метить в mangle ( PREROUTING ) и потом их резать в filter ( INPUT/FORWARD), но куда красивее выглядит вынос Всех действий с плохими пакетами в mangle ( PREROUTING )...
Технически команды вида
iptables -t mangle -A PREROUTING -p all -i eth0 -s 192.168.0.0/16 -j DROP проходят.
Зачем по-умолчанию задаётся доступ к каталогу '/' в httpd.conf ?
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
Ведь DocumentRoot по-умолчанию указывает на /var/www/html (во многих дистрибутивах)
А конф. файлы находятся в /etc/httpd/
Так зачем apachу иметь доступ к корневому каталогу?
Без этой директивы вроде нормально работает...
Никак не могу понять...
Есть каталог /var/www
У него контекст: ...:httpd_sys_content_t
Я Удаляю! каталог /var/www, потом снова создаю его командой:
mkdir /var/www
У него опять контекст ...:httpd_sys_content_t
Мне надо, чтобы у каталогов вида /home/username/www/*
был контекст ...:httpd_user_content_t
Я создаю каталог:
mkdir /home/username/www
У него почему-то контекст ...:user_home_t !!!
Делаю fixfiles relabel. У каталога /home/username/www котнекст становится правильным ...:httpd_user_content_t.
Вопрос:
Как сделать так, чтобы задавался правильный контекст при создании объекта, а не только операцией relabel ?
Файл file_contexts и types.fs вроде выглядят нормально.... Вроде регулярные выражения заданы верно ( пробовал менять, толку никакого).