Anton Karpov описал (http://www.opennet.me/base/sec/authpf_auth.txt.html) один из путей решения проблемы подключения за чужой счет в домашней сети, через использование пакетного фильтра OpenBSD/PF и авторизационного шелла authpf (http://www.openbsd.org/faq/pf/authpf.html).
Т.е. при входе пользователя на сервер по ssh, автоматически поднимается NAT на тот адрес, который присвоен этому пользователю, после завершения сессии - правила трансляции удаляются.URL: http://www.opennet.me/base/sec/authpf_auth.txt.html
Новость: http://www.opennet.me/opennews/art.shtml?num=6123
полезная статья
я так и сделаю
щас стоит: obsd3.8+pf/nat+squid+netams
подскажите только как authpf со squid'ом связать?
А зачем их связывать?
В squid использовать external_acl - небольшой скрипт бутдет выбирать из
/var/authpf/<ip-adress> имя пользователя и, тогда в логах squid`а
будет прописыватся login:---- squid.conf ---
acl authuser external authpf
http_access allow authuser
external_acl_type authpf ttl=60 children=1 %SRC /usr/local/libexec/squid/seapf
---------------------seapf - тот самй скрипт.
Тогда очень просто через squid`овые логи показываются трафик пользователя при заходе с разных ip. Думаю можно и к netams можно также припинать.
Только netams авторизацию порезать, а netams заставить для закрытия юзверя создавать файл /etc/authpf/banned/<user name>.Зачем это надо? Некоторые юзвери видя статистику по ip dst ip src -
кричат и пищат, а sarg или netams очень доходчиво все показывает.PS. логи по ip src ip dst очень лего выгребаются при такой авторизации через ng_ipacct.
Что-то никак не получается запустить authpf согласно man-ов.
Может кто напишнт пример конфигурационных файлов pf.conf,
authpf.conf и authpf.rules для доступа в сеть для примера одного юзера.
Что только люди ни придумывают, лишь бы не делать по-нормальному.
>Что только люди ни придумывают, лишь бы не делать по-нормальному.по-нормальному это как?
pppoe
"FreeBSD+mpd+WindowsXP" прекрасно работает
IMHO, "громоздкие решения" во многом упростят жизнь админа в будущем
mclone@Droid:~> ll -s `where authpf`
20 -r-sr-sr-x 1 root authpf 18436 16 вер 02:18 /usr/sbin/authpf*IMHO, 20Kb != "громоздкие решения". А если судить по количеству занимаемой памяти и скорости работы - ни PPPoE, ни *VPN не выдерживают критики (подразумевается пара сотен одновременных пользователей в сегменте с роутером ~1 gHz на fxp(4)-like NICs под FreeBSD 5/6 or OpenBSD)
Ну еще 2mb/юзверь на sshd накинь, как минимум.
>Ну еще 2mb/юзверь на sshd накинь, как минимум.Трафик через ssh не идет. Юзер по ssh заходит для того чтобы на него поднялся NAT,никакого тунеля при этом не нужно. Все просто и элегантно....для админа.
Для того чтобы это было просто и элегантно для пользователя, можно обойтись без ssh, а поставить apache+mod_ssl, написать простой CGI скрипт, который при правильном вводе пароля будет открывать NAT, и раз в минуту проверять не закрыл ли клиент окно в браузере. Если закрыл - NAT на его IP убирается.
>>Ну еще 2mb/юзверь на sshd накинь, как минимум.
>
>Трафик через ssh не идет. Юзер по ssh заходит для того чтобы
>на него поднялся NAT,никакого тунеля при этом не нужно. Все просто
>и элегантно....для админа.
Так никто и не против и в этом вся прелесть
>
>Для того чтобы это было просто и элегантно для пользователя, можно обойтись
>без ssh, а поставить apache+mod_ssl, написать простой CGI скрипт, который при
>правильном вводе пароля будет открывать NAT, и раз в минуту проверять
>не закрыл ли клиент окно в браузере. Если закрыл - NAT
>на его IP убирается.
Вот при ssh именно и не надо думать о том чтобы что-то проверять - все уже и так работает.
Окстись [, Пендальф] !
authpf это всего лишь шелл, а даже если по ssh, оно его вскоре высвапливает.
Хранить пароль в открытом виде в bat-файле на рабочем столе небезопасно, т.к. появится очередная дыра в WinXP и кто-то соберет урожай учетных записей и паролей сети. Лучше использовать авторизацию по ассиметричным ключам и pageant (еще одна утилита из пакета Putty). Недостаток решения - висящее окно терминала у клиента. В принципе недолго написать своего клиента, используя готовый ssh-компонент.
авторизацию по uucp не делаете?
и сделали бы, но не умеем... :-(
нифига не понял. чем это отличается от простого vpn? и там и там пароль. а если есть чужой пароль, то...
и там и там можно менять МАС и ip. так что в чем преимущества?
Просто некоторые патологически любят изобретать велосипед.
Некоторые просто любят изобретать, а некоторым это почему-то не нравится.
Да ради бога, с чего вы это взяли?
Помню, как в журнале "Радио" за шестьдесят какой-то год была статья "как сделать пульт ДУ к телевизору" - из шкивов, верёвочек, и палочек. Респект, хуле!
Только тогда это изобретали от невозможности сделать по-другому.
Для чего такие изобретения нужны в наши дни - непонятно. И делать из этого статью в журнале вряд ли кому-нибудь придёт в голову.
Человек привел в статье скрипт в одну строчку. Ну где тут "изобретение" хоть велосипеда, хоть чего. Решение очень простое и к ресурсам не требовательно и IMHO этим и примечательно. Для mpd нужно много чего крутить (постов на опеннет типа "и снова мпд" вооооон сколько). Для apache+ssl тоже cgi-скрипт писать надо. А тут все уже написано.
>нифига не понял. чем это отличается от простого vpn? и там и
>там пароль. а если есть чужой пароль, то...
>и там и там можно менять МАС и ip. так что в
>чем преимущества?
В том, что не создается еще одного интерфейса на win и не ловим всех связанных с этим приятностей.
совершенно не вижу смысла такого решения. По сравнению с mpd+radius+mysql+apache - не дотягивает по функционалу оооочень сильно, хотя наверно на слабых машинах побыстрее.По сравнению с простым mpd (ведь биллинг и проч. в статье не описывалось) - плюсов совершенно не вижу.
Я возможно не слишком умён, но по-моему кошерно делать биллинг на netflow или sflow. Соответственно берем pfflowd... А дальше - хоть flowscan, хоть flow-tools, даже NeTAMS сойдёт... И черви обнаружить есть возможность, и p2p-трафик узреть... Но напильник сотрёте не один, пока всё подымете.
В vpn-решениях кроме NAT выдается еще и DNS вообще то, а тут пользователю придеться прописывать самостоятельно, что не очень удобно например при использовании внутреннего DNS-сервера ничем не связанного с внешним миром.
А dhcpd простите на что?
Даже в этом случае можно без проблем своровать трафик у уже авторизованного клиента - это решение только "на время" (пока клиенты не научаться обманывать эту систему)
>Даже в этом случае можно без проблем своровать трафик у уже авторизованного
>клиента - это решение только "на время" (пока клиенты не научаться
>обманывать эту систему)Расскажите, как это сделать без проблем. Читал уже подобное обсуждение. Можно сменить ip/mac на ip/mac авторизованного пользователя, в данный момент находящегося в сети. Тогда из-за конфликта мак-адресов клиент или нарушитель вылетят из сети, либо оба будут работать с огромными тормозами. То есть в любом случае проблемы будут. Или я что-от упускаю.
При тех же реквизитах ip/mac конфликта не будет. Будут dup'ы на ping и arp-request, но этого можно избежать, как можно избежать и ответа своей машинки на отсутствие приложения с портом клиента authpf (tcp как никак). Тут конечно не все без проблем, но при туннелированнии трафика через udp или icmp вполне можно работать одновремменно...
Однако народ насколько я понял там постояно должен висеть шел от клиента к серваку. Соответсвенно как толко хитромудрый чел меняет на чужой айпи свой вместе с маком. Ему будет кукиш с маслом. Или я не прав?
>Однако народ насколько я понял там постояно должен висеть шел от клиента
>к серваку. Соответсвенно как толко хитромудрый чел меняет на чужой айпи
>свой вместе с маком. Ему будет кукиш с маслом. Или я
>не прав?Да. Для того, чтобы у злоумышленника всё работало, надо ещё и SSH сессию перехватить.
Используя в настройках sshd следующие параметры
ClientAliveInterval 15
ClientAliveCountMax 3
можно лишить интернета того, кто просто подменил IP-MAC, менее, чем за минуту.
На самом деле, ничего такого особенного в authpf - нет. Написать его аналог можно легко и не напрягаясь, куда более удобный и никак не связаный с SSH, работающий хоть по HTTP. Используется возможность динамического навешивания наборов и суб-наборов правил на PF динамически через управляющую структуру pfctl. Юзер логинится - authpf выдергивает из своего конфига эти правила, подменяет переменную $user_ip на IP коннектящегося юзера, добавляет в якорь authpf суб-набор с именем пользователя - и всех делов.
С таким же успехом можно создать скрипт на перле, который слушает определенный порт, получает коннект - и вызывает системной коммандой pfctl с параметрами, че-та типа `echo "pass in from $ip to any" | pfctl -a perlpf:User -f -`
Намного интереснее другое - на эти правила можно поставить логгирование и таким образом считать трафик с привязкой пакетов к имени пользователя, снимая статистику с интерфейса pflog0.