Как в Midnight Commaderе использовать shell link в случае, если SSHD висит не на 22 порте?

username@hostname:port не получается :(

Связь с провайдером посредством установления ppp соединения.
Соответсвенно после дисконнекта ppp0 интерфейс пропадает (а вместе с ним внешний IP и доступ к нужным локальным серверам).
Надо, чтобы всегда был интерфейс с внешним адресом независимо от наличия реального соединения.

Нашёл, что для этого нужно поднимать dummy интерфейс.
В общем-то всё просто:
ifconfig dummy0 Мой_внешний_ip up

Вопрос:
Где ПРАВИЛЬНЕЕ это делать? Поднимать/опускать этот интерфейс в скриптах
/etc/ppp/if-up|down.local или где-то ещё?

В идеале, чтобы dummy0 интерфейс был всегда. Чтобы не было моментов, когда внешний ip недоступен.

Смотрел руководство iptables 1.1.19, книгу "оптимизация и защита линукс сервера" и ещё несколько источников.

Везде пробрасывать порты до сервера, стоящего в DMZ предлагают приблизительно следующим образом:

(1) iptables -A PREROUTING -i $EXT_I -s $EXT_NET -d $EXT_IP -p tcp --dport 80 -j DNAT --to-destination $DMZ_HTTP_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.

Например:
EXT_I=eth0
EXT_NET=10.0.0.0/8
EXT_IP=10.0.0.1

DMZ_I=eth1
DMZ_NET=192.168.0.0/24
DMZ_HTTP_IP=192.168.0.10

Атакующий IP=10.0.0.20

Тогда для нормального доступа к 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 на интерфейсе и блокировать с неправильными?

А вот и не угадали :)

ProFTPd у меня уже пропатчен и работает нормально. Клиентам под виндой в cp1251 (FAR, IE, FireFox) отдаёт нормально.

Возникла проблема с другой программой.
Программа эта: ftpls.
http://www.ohse.de/uwe/ftpcopy.html

Она почему-то не хочет выполнять CWD в каталоги с буквой "я" в имени.
Пишет, что мол сервер вернул "Not Found"
Причём содержимое этого каталога она успешно возвращает, а вот содержимое вложенных каталогов уже не возвращает. Т. е. программа реально не может выполнить CWD.

Нашёл в коде место, где она выполняет CWD. Соответственно строку с именем каталога надо наверно как-то подкорректировать.

Вопрос: как?

Пробовал ставить вместо одного 0xff два раза 0xff. (где-то в инете такой способ нашёл, но не получилось)

Или может проблема на стороне сервера в CWD ?

Нужна программа для индексации FTP серверов.
Можете посоветовать либо что-нибудь готовое, либо как лучше сделать?

Пробовал wget и lftp - в принципе работает, но как всегда проблемы с кодировками и глюки с пустыми папками.

Нужно, чтобы нормально переваривал cp1251, koi8-r, utf-8.

Навеяла новость о Fedora Legacy.

А есть дистрибутивы, у которых нет релизов как таковых? Т. е. выпускаются потихоньку обновления и выпускаются. Софт устарел, заменили на более новый, ядро новое вышло - месяца два потестировали, заменили ну и т. д. Ну и чтобы обновления, связанные с безопасностью оперативно выпускались.

Чтобы не было этих проблем с прекращением поддержки старых релизов.

Позарез надо поднять почтовый сервер для Почти персонального использования. (пока один домен - ~ 7 пользователей)

Вот мучаюсь выбором: CommuniGate Pro или postfix/exim/... .
Всем CGP устраивает, и ставится/настраивается легко, и управление приятное через веб интерфейс и был опыт работы с ним, но... он слегка проприетарный.

С другой стороны postfix/exim/qmail и т. д. Всё хорошо, но вот нету времени на изучение конфигов, тонкостей и т. д. (Можете считать что ниасилил) Надо, чтобы поставил и работает. Причём всё сразу: SMTP/POP3/IMAP, веб интерфейс, веб администрирование. И по надобности легко конфигурируется.

Что посоветуете? Забить на всё и использовать CPG.
Или может какой-нибудь готовую рабочую связку, но под лицензией GPL?
Причём можно сразу дистрибутив для поднятия почтового сервера из коробки, т. к. ставить буду на выделенный виртуальный сервер.

Нужны гигабитные сетевухи, гарантированно стабильно работающие под линуксом.

Желательно, чтобы работала с драйверами встроенными в ядро.
ОС: CentOS4 (RHEL4)

Компьютер подключается к интернету посредством 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 всех этих пользователей, но пользователи соответсвенно не должны иметь доступа к каталогам друг друга?

bash shell

Выполняем команду cd /
pwd
/

Выполняем команду cd //
pwd
//

Это как и где?
lsы вроде одинаковые
Объясните в чём разница?

Ситуация:
Есть набор программ - чёрных ящиков, крутящихся на сервере.
Раз в 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 ) ?

Программы уровня пользователя не интересуют. Их если что можно будет перезапустить.

Можно как-нибудь использовать дополнение имён файлов в утилитах ftp, sftp при работе в интерактивном режиме наподобие bashевского <Tab>?

В руководстве по 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 вроде выглядят нормально.... Вроде регулярные выражения заданы верно ( пробовал менять, толку никакого).

ОС: CentOS 4.4 (RHEL4U4) Режим SELinux: targeted

Если запускать с qemu -net user, можно как-нибудь поменять IP адрес внутренней подсети с 10.0.2.0/24 на что-нибудь другое?