Здравствуйте.
Предлагаю вашему вниманию еще одно руководство по самостоятельной настройке
фаервола/маршрутизатора на базе GNU/Linux (iptables+tc) для небольшого офиса.
Здесь http://handmade-linux-firewall.narod.ru/
Зеркало http://hlf.netii.net/
В отличие от других текстов подобного рода:
- вопросы фильтрации, маршрутизации, управления трафиком
рассматриваются в совокупности и взаимосвязи на функционально
законченном примере сети;
- предлагается унифицированная схема организации правил и цепочек iptables - это основное ради чего этот «велосипед» изобретался;
- предлагается схема управления трафиком (опять же в некотором роде универсальная);
- рассматривается реально эксплуатируемый набор правил (полный листинг);
- включает исходники фаервола с(о всё еще неполным) описанием функционирования;
- есть картинки :)
- на русском.
Данной текст используется мною как сборник моих текущих знаний в данной области
и как рабочая шпаргалка.
Есть web-сервер под Debian etch+Apache2.
Подскажите, пжлста чего надо сделать(и/или установить), чтобы поддерживалась кириллица в пути+имени файла URL'ов (без всяких %D3%81%87%A4%95), вот так:
Последнее время наблюдается опасная тенденция: 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: пусть варятся сами в мире своих стандартов, систем и инициатив, как они это делали до сих пор.
Есть много руководств и 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.
В данной ситуации, кроме как на сетевой код ядра, можно воздествовать ТОЛЬКО на эти два сервера.
Т.е. если, теоретически, в этих сервисах нет уязвимостей, такую машину по прежнему нельзя взломать.
Практическая возможность взлома, повляется только при наличии уязвимостей в одном из сервисов.
Опять же, для собственной уверенности, в такой конфигурации, достаточно "контролировать" только эти пути взлома,
так как они единственные.
Правильны ли эти рассуждения.
Спсб.
В данный момент в DMZ установлен только web-сервер. Остальное, в частности mail-сервер находится на самом файерволе.
В связи с этим "вскрылись" следующие вопросы:
- Всяческие сообщения от cron и других служб естесственно не могут быть переданы по SMTP на почтовый сервер. Самым правильным конечно будет размещение самого mail-сервера в DMZ, но это вопрос будущего.
- Бэкапы с web-сервера тоже невозможно отослать например по FTP на сервер стоящий в LAN. Тут я вижу только решение такое: не web-сервера должен подключаться в LAN к бэкап-серверу для передачи бакапов, а наоборот - бэкап-сервер подключается к web-серверу и забирает у него уже подготовленные к тому времени бэкапы. Или ставить бэкап-сервер в DMZ?
В целом: как стандартно решаются подобные вопросы для серверов, находящихся в DMZ? Можно ссылки на русс/англ.
Спсб.
Всем привет.
Подключены мы через полудуплексный канал к интернету, а это значит что если исходящий трафик полностью исчерпает нашу пропускную способность, то на взодящий трафик уже ничего не остается и наоборот.
Ясно, что надо ограничивать.
Подключил я web-сервер в DMZ.
И теперь хочу сделать так, чтобы входящий+исходящий трафик этого web-сервера суммарно не превышал определенной велечины (пусть 256кбит), чтобы нам оставалось чего-то для работы.
Можно так: ограничить входящий к серверу до 128кбит и исходящий от сервера до 128кбит (на самом web-сервере или на файерволе).
Однако в этом случае пик будет достигнут только при полной загрузке в обе стороны, а если, например в данный момент, входящий трафик мизерный, а исходящий уже уперся в свои 128кбит ограничения то, исходящий не сможет использовать тот резерв, который отпущен под неиспользумый в данный момент входящий.
Для этого надо ограничивать ingress+egress в совокупности, чтобы в любой момент времени совокупный трафмк web-сервера не првышал 256, а уж сколько там входящего, сколько исходящего не суть важно - дело второе.
А как это сделать?
Я знаю что есть IMQ или недавно IFB.
Но позволяют ли они "склеить" ingress и egress например одного интерфейса?
И если можно как, будут выглядеть команды tc для "склеивания" ingress и egress.
Спасибо.
Подскажите, пожалуйста по теме.
Сделал 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-соединение?
Там все автоматически, чтоль происходит или надо таблицу роутинга явно подправлять?
Спасибо!
Подскажите пожалуйста какое-нибуть средство для следуещей ситуации.
На Linux есть например POP3-сервер, pppd.
Соответсвенно в определенных файлах хранятся учетные записи пользоваетелей с паролями.
Сами они эти пароли у меня поменять не могут - приходится им ко мне обращаться и я им ставлю новый пароль.
Вопрос: есть ли некая тулза позволяющая самому пользователю изменять свой пароль на определенный сервис.
На базе web-интерфейса или работающая еще как-то удаленно.
Гланое, чтобы она не была привязана к набору файлов с паролями, а можно было гибко добавить в нее смену пароля для (любого) сервиса.
Ну допустим захочу я еще SMTP-аутентификацию или еще что-то.
Сейчас мне видится такое самопальное решение: скрипт на bash или perl, который запускается в качестсве shell у пользователя.
Пользователь подключается через ssh и видит что-то типа:
На какой сервис вы хотите сменить пароль?
1. Почта
2. Подключение к интернет
Пользователь жмет единичку и ему:
Введите
старый пароль:
новый пароль:
подтвердите новый пароль:
Но это как-то туповато, к тому же не хочется никого
в /etc/passwd заводить.
Подскажите, кто знает тулзу, которая "цетрализованно" позволяет менять пользователям свои пароли на различные сервисы в Linux.
Спасибо!
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
На протяжении длительного времени пытаюсь решить проблему
аутентификации и авторизации траффика 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.
Если кто может, ппроясните сей вопрос.
Может есть более простые и не менее надежные способы?
