LINUX.ORG.RU

Сообщения gapsf2

 

(Еще одно) HOWTO по конфигурированию фаервола своими руками

 

Здравствуйте.
Предлагаю вашему вниманию еще одно руководство по самостоятельной настройке
фаервола/маршрутизатора на базе GNU/Linux (iptables+tc) для небольшого офиса.
Здесь http://handmade-linux-firewall.narod.ru/
Зеркало http://hlf.netii.net/

В отличие от других текстов подобного рода:
- вопросы фильтрации, маршрутизации, управления трафиком 
  рассматриваются в совокупности и взаимосвязи на функционально
  законченном примере сети; 
- предлагается унифицированная схема организации правил и цепочек iptables - это основное  ради чего этот «велосипед» изобретался;
- предлагается схема управления трафиком (опять же в некотором роде универсальная);
- рассматривается реально эксплуатируемый набор правил (полный листинг);
- включает исходники фаервола с(о всё еще неполным) описанием функционирования;
- есть картинки :)
- на русском.
Данной текст используется мною как сборник моих текущих знаний в данной области
и как рабочая шпаргалка.
gapsf2
()

apache2+кириллица в URL, как?

Есть web-сервер под Debian etch+Apache2. Подскажите, пжлста чего надо сделать(и/или установить), чтобы поддерживалась кириллица в пути+имени файла URL'ов (без всяких %D3%81%87%A4%95), вот так:

http://domain.ru/картинко.jpg

Сейчас сообщает что файл не найден. Спсб.

>>> Подробности (Invalid URL, no host part!)

gapsf2
()

M$ мимикрирует под FOSS

Последнее время наблюдается опасная тенденция: M$ "косит" под FOSS, выказывая свое "рвение" быть "открытими" и взаимодействовать с OpenSource-сообществом. Казалось бы - пусть резвятся. Однако есть реальная опасность подмены понятий.

M$ активно пытается внедриться в OpenSource-сообщество, примазаться к его достижениям, распространить репутацию, достигнутую OS-сообществом за долгие годы развития, на себя. И это после стольких лет говна, которого они выливали в сторону FOSS. И это на фоне активной скупки и "продажности" некоторых FOSS-проектов (MySQL, Xen, SUSE...) и коммерциализации основных Linux-дистрибутивов.

M$ начала засылать своих эмиссаров на разные конференции по отрытому ПО. Высокопоставленные лбы из M$ и их эмиссары на конференциях, начали делать заявления типа: "M$ всегда была за стандарты и всегда взаимодействовала с OS-сообществом". Появились откровенно провокационные заявления: "OS-сообщество прилагает недостаточные усилия по взимодействию с закрытм ПО (т.е. с M$)", выгораживающие M$ в глазах людей. Начались "дешевые" акции по использованию слова "Open" в стандартах, продуктах и иницативах M$, по сути не являющихся открытими и бесплатными: Office Open XML (прямое созвучие с OpenOffice), "Открытый исходный код от Microsoft" и т.д.

После такой обработки очень скоро появится масса людей, считающих что "так всегда и было", что "M$ и есть образец самой открытой, дружелюбной и следующей стандартам конторы". Будет скуплено еще некоторое кол-во (может быть ключевых) FOSS-проектов. Туда будут внедрены "свои" люди и в конце концов многие "обыватели" начнут ассоциировать FOSS c M$ и другими подобными конторами. Таким образом, одев шкуру FOSS, M$ может подменить в сознании многих ценности FOSS.

На мой взгляд, надо игнорировать все "инициативы" примазаться к OS-сообществу, препятствовать попыткам перевернуть с ног на голову ценности FOSS: пусть варятся сами в мире своих стандартов, систем и инициатив, как они это делали до сих пор.

>>> Подробности (Invalid URL, no host part!)

gapsf2
()

Концептуальные пути взлома и защиты сервера интересуют

Есть много руководств и howto по безопасности, в которых разъясняется, ЧТО надо делать:
закройте то, не ставьте это, уберите лишнее, это настройте вот так и т.д.
Но вот я пока не встречал howto, в котором разъяснялись бы концепты, подобные нижеследующим.
Далее предполагается ОС Linux и что в настройке компонентов нет ошибок (администратора).
Локального физического доступа у нападающего нет, системных аккаунтов - тоже, DOS-атаки не рассматриваются.
Итак меня, как админа, интересуют три следующих ситуации и пути (теоретические и практические)
УДАЛЕННОГО (через сеть) взлома.
Кто владеет знаниями или ссылками на соответствующие источники - прошу прокомментировать, правильны ли эти рассуждения.

1. "Компьютер полностью изолированный firewall'ом"
  Компьютер, подключен к сети, на нем могут присутсвовать некие работающие сервисы и
  при помощи firewall полностью запрещен входящий и исходящий трафик
  (например iptables -P DENY/DROP для всех цепочек или явными правилами DENY/DROP в PREROUTING/POSTROUTING).
  Конечно его можно физически отключить от сети, но интересует именно когда он подключен.
  Я считаю что удаленный взлом системы невозможен (нет путей проникновения, не на что воздействовать).
  Теоретическая возможность появляется, только если есть грубая ошибка в сетевом коде ядра,
  позволяющая обойти firewall, т.е. некий пакет будет проходить дальше на обработку, несмотря на запрет.
  Только так появляется хотя-бы какая-то возможность воздействовать на что-то.
  Такое маловероятно. Т.е. я считаю такую машину невзламываемой удаленно.

2. "Маршрутизатор"
  Компьютер, подключен к сети, он выполняет роль МАРШРУТИЗАТОРА, на нем могут присутсвовать некие
  работающие сервисы и при помощи firewall полностью запрещен INPUT и OUTPUT трафик и разрешен только FORWARD.
  Ситуация примерно как в первом варианте, но чуть хуже. Непосредственно воздействовать на
  процессы (сервисы), работающие на машине невозможно, а можно только попытаться сконструировать
  некие пакеты использующие уязвимости в сетевом коде ядра и только.
  Если их там нет то и путей удаленного взлома маршрутизатора не существует.

3. "Компьютер, предоставляющий сервис"
  Компьютер, подключен к сети, на нем, для примера, работает SMTP-сервер tcp/25 и POP3-сервер tcp/110.
  При помощи firewall закрыто все (и все протоколы и все порты) кроме вот этих двух TCP-портов.
  Т.е. есть соответствующие ALLOW и ESTABLISHED.
  В данной ситуации, кроме как на сетевой код ядра, можно воздествовать ТОЛЬКО на эти два сервера.
  Т.е. если, теоретически, в этих сервисах нет уязвимостей, такую машину по прежнему нельзя взломать.
  Практическая возможность взлома, повляется только при наличии уязвимостей в одном из сервисов.
  Опять же, для собственной уверенности, в такой конфигурации, достаточно "контролировать" только эти пути взлома,
  так как они единственные.
Правильны ли эти рассуждения.
Спсб.

>>> Подробности (Invalid URL, no host part!)

gapsf2
()

отправка почты и бакапы. из DMZ для LAN

В данный момент в DMZ установлен только web-сервер. Остальное, в частности mail-сервер находится на самом файерволе. В связи с этим "вскрылись" следующие вопросы:

- Всяческие сообщения от cron и других служб естесственно не могут быть переданы по SMTP на почтовый сервер. Самым правильным конечно будет размещение самого mail-сервера в DMZ, но это вопрос будущего.

- Бэкапы с web-сервера тоже невозможно отослать например по FTP на сервер стоящий в LAN. Тут я вижу только решение такое: не web-сервера должен подключаться в LAN к бэкап-серверу для передачи бакапов, а наоборот - бэкап-сервер подключается к web-серверу и забирает у него уже подготовленные к тому времени бэкапы. Или ставить бэкап-сервер в DMZ?

В целом: как стандартно решаются подобные вопросы для серверов, находящихся в DMZ? Можно ссылки на русс/англ. Спсб.

>>> Подробности (Invalid URL, no host part!)

gapsf2
()

IMQ/IFB inress+egress полудуплекс

Всем привет. Подключены мы через полудуплексный канал к интернету, а это значит что если исходящий трафик полностью исчерпает нашу пропускную способность, то на взодящий трафик уже ничего не остается и наоборот. Ясно, что надо ограничивать. Подключил я web-сервер в DMZ. И теперь хочу сделать так, чтобы входящий+исходящий трафик этого web-сервера суммарно не превышал определенной велечины (пусть 256кбит), чтобы нам оставалось чего-то для работы.

Можно так: ограничить входящий к серверу до 128кбит и исходящий от сервера до 128кбит (на самом web-сервере или на файерволе). Однако в этом случае пик будет достигнут только при полной загрузке в обе стороны, а если, например в данный момент, входящий трафик мизерный, а исходящий уже уперся в свои 128кбит ограничения то, исходящий не сможет использовать тот резерв, который отпущен под неиспользумый в данный момент входящий. Для этого надо ограничивать ingress+egress в совокупности, чтобы в любой момент времени совокупный трафмк web-сервера не првышал 256, а уж сколько там входящего, сколько исходящего не суть важно - дело второе. А как это сделать? Я знаю что есть IMQ или недавно IFB. Но позволяют ли они "склеить" ingress и egress например одного интерфейса? И если можно как, будут выглядеть команды tc для "склеивания" ingress и egress. Спасибо.

>>> Подробности (Invalid URL, no host part!)

gapsf2
()

Unable to handle kernel NULL pointer...

Здрасьте. Помогите соорентироваться по этой ситуации (ниже часть лога).
Это debian etch (еще пока он был testing) c собственноручно скомпилированным vanilla kernel 2.6.15.1 (gcc 4.1.2 20061115). Происходит такое примерно раз в месяц.
Эксперименты проводить не могу (отладка, воспроизведение ошибки),
так как это - рабочая система, на которой офис висит.

1. Для меня непонятна причина:
- это баг ядра? если да, то какой подсистемы? сменить ядро?
- может просто gcc криво скомпилил? (соответсвенно надо просто перекомпилить, может даже лучше версией 2.95.3)
- глючное железо?
Как решить, в чем причина?

2. Куда лучше ломануться с этой проблемой?
В баги debian? Так вроде это к debain прямого отношения не имеет - сам компилил.
Спасибо!

2007-08-21T05:26:34+07:00 saturn XFS mounting filesystem sda1
2007-08-21T05:28:41+07:00 saturn Unable to handle kernel NULL pointer dereference at virtual address 00000032
2007-08-21T05:28:41+07:00 saturn printing eip:
2007-08-21T05:28:41+07:00 saturn c012d04f
2007-08-21T05:28:41+07:00 saturn *pde = 00000000
2007-08-21T05:28:41+07:00 saturn Oops: 0000 [#1]
2007-08-21T05:28:41+07:00 saturn CPU:    0
2007-08-21T05:28:41+07:00 saturn EIP:    0060:[<c012d04f>]    Not tainted VLI
2007-08-21T05:28:41+07:00 saturn EFLAGS: 00210002   (2.6.15.1) 
2007-08-21T05:28:41+07:00 saturn EIP is at find_get_pages+0x39/0x5b
2007-08-21T05:28:41+07:00 saturn eax: 8001002c   ebx: 00000001   ecx: c37a9e98   edx: 00000032
2007-08-21T05:28:41+07:00 saturn esi: 00000003   edi: c37a9f08   ebp: c37a9e8c   esp: c37a9e44
2007-08-21T05:28:41+07:00 saturn ds: 007b   es: 007b   ss: 0068
2007-08-21T05:28:41+07:00 saturn Process umount (pid: 22621, threadinfo=c37a8000 task=c1f9a540)
2007-08-21T05:28:41+07:00 saturn Stack: c463dc94 c37a9e94 00000000 0000000e c37a9e8c 00000000 c013668d c463dc90 
2007-08-21T05:28:41+07:00 saturn 00000000 0000000e c37a9e94 00000001 c01367f8 c37a9e8c c463dc90 00000000 
2007-08-21T05:28:41+07:00 saturn 0000000e 00000000 00000000 00000000 c1079180 00000032 000000bb c7972b48 
2007-08-21T05:28:41+07:00 saturn Call Trace:
2007-08-21T05:28:41+07:00 saturn [<c013668d>] pagevec_lookup+0x2b/0x32
2007-08-21T05:28:41+07:00 saturn [<c01367f8>] truncate_inode_pages+0x60/0x237
2007-08-21T05:28:41+07:00 saturn [<c02192ed>] linvfs_clear_inode+0x52/0x67
2007-08-21T05:28:41+07:00 saturn [<c015ec9b>] dispose_list+0xb2/0xc5
2007-08-21T05:28:41+07:00 saturn [<c015ed7e>] invalidate_inodes+0x3a/0x4e
2007-08-21T05:28:41+07:00 saturn [<c014e07b>] generic_shutdown_super+0x70/0x11a
2007-08-21T05:28:41+07:00 saturn [<c014ea87>] kill_block_super+0x27/0x3d
2007-08-21T05:28:41+07:00 saturn [<c014df93>] deactivate_super+0x67/0x80
2007-08-21T05:28:41+07:00 saturn [<c016188b>] sys_umount+0x39/0x82
2007-08-21T05:28:41+07:00 saturn [<c010e48a>] do_page_fault+0x3b2/0x618
2007-08-21T05:28:41+07:00 saturn [<c01618eb>] sys_oldumount+0x17/0x1b
2007-08-21T05:28:41+07:00 saturn [<c0102945>] syscall_call+0x7/0xb
2007-08-21T05:28:41+07:00 saturn Code: 83 c0 04 8b 54 24 24 89 54 24 0c 8b 54 24 20 89 54 24 08 89 5c 24 04 89 04 24 e8 1e 84 10 00 89 c6 85 c0 74 1a 89 d9 31 db 8b 11 <8b> 02 f6 c4 40 75 16 ff 42 04 83 c3 01 83 c1 04 39 de 75 ea fb 
2007-08-21T05:28:41+07:00 saturn Badness in do_exit at kernel/exit.c:807
2007-08-21T05:28:41+07:00 saturn [<c0117bfb>] do_exit+0x31f/0x324
2007-08-21T05:28:41+07:00 saturn [<c0103270>] do_trap+0x0/0xd0
2007-08-21T05:28:41+07:00 saturn [<c010e36f>] do_page_fault+0x297/0x618
2007-08-21T05:28:41+07:00 saturn [<c010e0d8>] do_page_fault+0x0/0x618
2007-08-21T05:28:41+07:00 saturn [<c0102b6f>] error_code+0x4f/0x54
2007-08-21T05:28:41+07:00 saturn [<c012d04f>] find_get_pages+0x39/0x5b
2007-08-21T05:28:41+07:00 saturn [<c013668d>] pagevec_lookup+0x2b/0x32
2007-08-21T05:28:41+07:00 saturn [<c01367f8>] truncate_inode_pages+0x60/0x237
2007-08-21T05:28:41+07:00 saturn [<c02192ed>] linvfs_clear_inode+0x52/0x67
2007-08-21T05:28:41+07:00 saturn [<c015ec9b>] dispose_list+0xb2/0xc5
2007-08-21T05:28:41+07:00 saturn [<c015ed7e>] invalidate_inodes+0x3a/0x4e
2007-08-21T05:28:41+07:00 saturn [<c014e07b>] generic_shutdown_super+0x70/0x11a
2007-08-21T05:28:41+07:00 saturn [<c014ea87>] kill_block_super+0x27/0x3d
2007-08-21T05:28:41+07:00 saturn [<c014df93>] deactivate_super+0x67/0x80
2007-08-21T05:28:41+07:00 saturn [<c016188b>] sys_umount+0x39/0x82
2007-08-21T05:28:41+07:00 saturn [<c010e48a>] do_page_fault+0x3b2/0x618
2007-08-21T05:28:41+07:00 saturn [<c01618eb>] sys_oldumount+0x17/0x1b
2007-08-21T05:28:41+07:00 saturn [<c0102945>] syscall_call+0x7/0xb 
gapsf2
()

аутентификация трафика от машин из LAN на шлюзе с помощью PPP

Подскажите, пожалуйста по теме.
Сделал Linux-шлюз (LAN IP 192.168.0.129) c PPP+PPTP.
Остались непонятки с адресами.
1. Адрес получаемый клиентом задаю в chap-secrets (192.168.0.1)
а вот где задать адрес сеерверной части соединения
(оно автоматически устанавливается в 192.168.0.1, 192.168.0.2 и т.д.).
Как задать пары адресов клиент-сервер для каждого пользователя?

2. В виндах раньше было: шлюз - 192.168.0.129 все пакеты, предназначеные не для сети 192.168.0.0/24 шли на этот адрес (т.е. на шлюз) и там уже роут "переправлял" их на интерфейс подключённый к инету.
А в случае подключения клиента к шлюзу через PPTP что у него должно стоять в качестве шлюза?

3. Как на виндовом клиенте трафик предназначеный для инета будет "запихиваться" в установленое со шлюзом PPTP-соединение?
Там все автоматически, чтоль происходит или надо таблицу роутинга явно подправлять?
Спасибо!
gapsf2
()

смена паролей сервисов самими пользователями

Подскажите пожалуйста какое-нибуть средство для следуещей ситуации.
На Linux есть например POP3-сервер, pppd.
Соответсвенно в определенных файлах хранятся учетные записи пользоваетелей с паролями.

Сами они эти пароли у меня поменять не могут - приходится им ко мне обращаться и я им ставлю новый пароль.

Вопрос: есть ли некая тулза позволяющая самому пользователю изменять свой пароль на определенный сервис.

На базе web-интерфейса или работающая еще как-то удаленно.
Гланое, чтобы она не была привязана к набору файлов с паролями, а можно было гибко добавить в нее смену пароля для (любого) сервиса.
Ну допустим захочу я еще SMTP-аутентификацию или еще что-то.

Сейчас мне видится такое самопальное решение: скрипт на bash или perl, который запускается в качестсве shell у пользователя.
Пользователь подключается через ssh и видит что-то типа:

На какой сервис вы хотите сменить пароль?
1. Почта
2. Подключение к интернет

Пользователь жмет единичку и ему:
Введите
старый пароль:
новый пароль:
подтвердите новый пароль:
Но это как-то туповато, к тому же не хочется никого
в /etc/passwd заводить.

Подскажите, кто знает тулзу, которая "цетрализованно" позволяет менять пользователям свои пароли на различные сервисы в Linux.
Спасибо!
gapsf2
()

SATA 2.6.15.1 и ограничение на количество partitions

Intel ICH5 SATA.
Решил сменить ядро с 2.6.7 на 2.6.15.1.
Скомпилил - гружу - не хочет монтировать /root ни в какую.
На 2.6.7 SATA диск имел имя /dev/hde.
А в 2.6.15.1 в Device Drivers появились:
1. ATA/ATAPI/MFM/RLL support
[*] Support for SATA (deprecated)
2. SCSI device support->SCSI low-level drivers
[*] Serial ATA (SATA) support
[*] Intel PIIX/ICH SATA support
/root у меня на 16 разделе (/dev/hde16) (у меня там промежуточная Linux система для построеняи финальной)

Если я компилю с первым вариантом то
получает имя /dev/hde (как и раньше) и все грузится.
Но вот я смотрю эта фича скоро исчезнет из ядра,
а главное с ней какие-то проблемы с прерываниями
(irq 10: nobody cared!)

А вот при выборе второго (SCSI)
это устройство получает имя /dev/sda.
И самое главное SCSI диск поддерживает максимум 15
разделов, а у меня система на 16ом!

Вопрос на будущее: какой в ядре останется драйвер?

Потому как если не использовать первый вариант
(из-за того что его просто уберут и потдерживать не будут),
то тогда сразу надо диск перебивать из расчета
максимум в 15 разделов.
Т.е. в будущем, хоть SATA и не SCSI, но из-за
того что в Linux это сделано через SCSI-подсистему,
будем иметь ограничение на 15 разделов.
А на IDE потдерживается до 63 разделов.
http://www.tldp.org/HOWTO/Partition/partition-types.html
3.4. Logical Partitions

Кто что знает по этому вопросу?
Спасибо!
gapsf2
()

аутентификация трафика от машин из LAN на шлюзе с помощью IPSEC

На протяжении длительного времени пытаюсь решить проблему
аутентификации и авторизации траффика LAN<->INET
от максимиум 50 машин Win98/2000/XP/2003 через Linux 2.6.x-шлюз.
Общая мысль - сделать так, чтобы на шлюзе можно было
определить от кого/кому (а не от какой машины (IP,MAC-адреса))
проходит данный IP-пакет и принять решение что с ним делать
основываясь на этой информации, а не по IP/MAC-адресам.
А так же интересует подсчет траффика так же по пользователям.

Проблема стара, на форуме читал пару дискуссий на эту тему,
но "окончательного" решения пока не смог реализовать.
В кратце проблема и "способ" (VPN) описаны здесь
http://www.flowix.com/.
Однако это за деньги - неинтересно, а главное хочется
понять как это сделать самому.

Варианты типа:
1. По IP адресу
Проблемы: подмена адреса, угоны сессий,
невозможно определить пользователя
если одним компьютером пользуется несколько человек.
2. По МАС адресу - подмена адреса
Проблемы: подмена адреса, угоны сессий,
невозможно определить пользователя
если одним компьютером пользуется несколько человек.
3. Пользователь открывает свой IP
подключившись к шлюзу через SSH2
(добавление правила в NETFILTER через iptables).
Проблемы: явное открытие/закрытие
(особенно закрытие - забыл закрыть и
ушел - кто-то себе открытый адрес поставит и усё),
угоны сессий,
невозможно определить пользователя
если одним компьютером пользуется несколько человек.
4. Всякие прокси отпадают так как на все
протоколы их просто не существует,
а контролировать надо весь трафик.
5. http://www.nufw.org/
Это уже почти то что надо.
На шлюзе ставится сервер отвечающий за аутентификацию
пакетов, а на пользовательской машине клиент, который
отсылает запрос на сервер на каждое новое соединение
(типа от кого это соединение).
http://www.nufw.org/Principles.html
Естественно, сначала надо залогиниться этим клиентом на
nufw сервере.
Контролируются только пакеты SYN (инициализация подключения),
остальное отслеживается CONNTRACK ядра Linux.
И все вроде зашибись. Но вся проблема в клиенте под винды.
Эти сволочи его только продают, а свободнораспространяемого нет.
Так что...
6. VPN. А именно хотелось бы:
- как в SSH2 на каждого, кто может подключиться через шлюз,
можно было бы сгенерить ключи для ipsec-соединения,
или просто задать пароли
- лучше без всяких IKE-демонов, руками куда-нибудь сложил на шлюзе
публичные ключи пользователей, пользователям дал ключ сервера
- траффик между клиентскими машинами и шлюзом аутентифицировался
(AH протокол) по сгенеренным ключам (ключ=пользователю),
шифрование как таковое не нужно.
- на шлюзе (т.е. в Linux iptables) можно было определить от
кого (кем подписан) данный пакет.
Предположительно это SPI (Security Parameter Index).
- чтобы "это" работало с win98 (PGPNet), Win2000/XP/2003
иначе смысла нет заводлить эту бодягу.
Пробую уже, но остается много неясностей:
- будет транспорт или туннель?
- PGPNet и Linux IPSEC совместимы вообще?
- с ключами и IKE не ясно, можно ли без IKE-демона?
как с SSH2 - сгенерить и рассовать по клиентам и в шлюз,
и никаких автоматических обменов ключами и смены через промежутки времени.
- как же в iptables определить кто подписывал данный пакет
(думаю, что по SPI, но так ли это)?
- а если без IKE-демона нельзя
(т.е. ключи будут автоматически генериться) как же
определить кто подписывал данный пакет, ведь SPI для
каждого я уже не смогу задать?

Главный вопрос: возможно ли в принципе, то что описано в 6 пункте.
Т.е. аутентификация трафика от машин из LAN на шлюзе с помощью IPSEC.
Если кто может, ппроясните сей вопрос.
Может есть более простые и не менее надежные способы?

gapsf2
()