BSDPORTAL.RU
в общем то суть в другом, на сколько я понимаю все работать должно как сделал я. Другое мешает. до natd не доходит ничего, те. делаю -v параметр стучусь, он ниче не показывает. такое ощущение что он не пускает файрволом, как во фре указываются правила ? Сначала запрещаем все, потом что то разрешаем ?
немогу понять в чем проблемма. или сделать flush у ipfw и попробовать так ? если пашет значит правила нормальные и их надо куда то просто вставить в правильное место в rc.firewall ?
Заголовок сообщения: Re: natd + ipfw, как проверить ?
Добавлено: Сб 11 дек, 2004 12:10 am
| Site Admin |
st-alk-er писал(а):
как во фре указываются правила ? Сначала запрещаем все, потом что то разрешаем ?
правила читаются по порядковому номеру и ты прописываешь правила разрешающие то,что тебе надо.Но если в ядро добавить опцию IPFIREWALL_DEFAULT_TO_ACCEPT ,то всё в конце будет разрешатся и перед этим правилом лучше добавить правило deny all
_________________
Заголовок сообщения:
Добавлено: Сб 11 дек, 2004 12:22 am
st-alk-er молодой человек, я извиняюсь за грубость, но вы хотите и рыбку сьесть и в кресло сесть. ИМХО вам надо изучить man ipfw и man natd.conf и много вопросов сразу отпадёт! Если вы хотите что бы вам тут написали готовый фаервол и сказали как его запустить, то так и надо говорить! Все притензии в privateЛС, дабы не разводить тут флейм!
_________________
Single-user mode
unscheduled in the nighttime?
Something just went «boom!»
Заголовок сообщения:
Добавлено: Сб 11 дек, 2004 3:07 am
прочел что написал. туго
в общем пишу подробнее, небыло времени на тот момент
в общем нужно пробросить 4899 порт
пишем в rc.firewall
#внешний IP (выдуман, понятно почему)
if1IP=»213.140.120.110″
#интерфейс смотрящий в нет
if1=»rl0″
#Куда пробрасываем пакеты
ifLIP=»192.168.100.11″
#на сколько понимаю (делал по примеру, ибо незнаю Фри)
#завертаем на порт natd (6666) все приходящее откуда угодно на #внешний IP по порту 4899 через внешний интерфейс
$ add divert 6666 tcp from any to $ 4899 via $
#непонятно почему используем ip а не tcp, не кидайтесь
#пожалуйста, я только начинаю разбираться, правило делает проброс
#на natd от машины с прогой на 4899 куда угодно, через внешний
#интерфейс (а может tcp надо ??)
$ add divert 6666 ip from $ to any via $
#просто открываем проход пакетов отовсюду на наш внешний
#интерфейс дабы не резался фаерволом порт 4899
$ add allow tcp from any to $ 4899 via any
#natd запускаем на внешнем интерфейсе, порт 6666, переадресация на
#локальную тачку по адресу 192.168.100.11 и по порту 4899
natd -n $ -p 6666 -redirect_port tcp $:4899 4899
при таком раскладе не работает, хотя по логике вещей должно. При запуске natd с параметром -v никаких результатов не валится, т.е. нет ничего на OUT или IN
вот и подозреваю что правило
$ add allow tcp from any to $ 4899 via any
стоит не там где надо
Flush спасет меня или подача правил для работы natd не правильная, помогите пожалуйста дельным советом, не откажусь так же от: «готовый фаервол и сказали как его запустить» буду признателен, ибо все учу на практике как правило, спасибо !
Заголовок сообщения:
Добавлено: Сб 11 дек, 2004 4:52 pm
Проблема все еще есть.
if1IP=»111.126.13.146″
if1=»rl0″
ipLIP=»192.168.100.11″
natd -p 6666 -n $ -redirect_port tcp $:4899 4899
$ add pass all from any to any via lo0
$ add pass all from any to any via xl0
$ add pass all from any to any via xl1
$ add deny ip from 192.168.0.0/16 to any in via rl0
$ add deny ip from 172.16.0.0/12 to any in via rl0
$ add deny ip from 10.0.0.0/8 to any in via rl0
# $ add divert 8668 ip from any to any out via rl0
# $ add divert 8668 ip from any to 81.176.7.126 in via rl0
#Это правило писал не я, но если его закоментировать пропадает инет
#Если же писать так как есть natd не перекидывает 4899 порт
#и нет инета. видимо конфликт с этими правилами, объясните, немогу
#понять в чем беда
$ add divert 8668 ip from any to any via rl0
#Otkrivaem Remote Admin
$ add divert 6666 tcp from any to $ 4899 via $
$ add divert 6666 ip from $ to any via $
$ add allow tcp from any to $ 4899 via any
#End
$ add pass tcp from any to any established
$ add pass ip from 81.176.7.126 to any out xmit rl0
$ add pass tcp from 81.176.7.126 to any out via rl0 setup
$ add pass tcp from any to any 25,110 via rl0
$ add pass tcp from any 25,110 to any via rl0
$ add pass udp from any to any 53 via rl0
$ add pass udp from any 53 to any via rl0
$ add pass all from any to any via xl0
$ add allow icmp from any to 81.176.7.126 in via rl0 icmptype 0,3,4,11,12
$ add allow icmp from any to any via xl0 icmptype 0,3,4,11,12
$ add allow icmp from 81.176.7.126 to any out via rl0 icmptype 3,8,12
$ add allow icmp from 81.176.7.126 to any out via rl0 frag
# $ add deny icmp from any to any frag
$ add pass icmp from any to any
$ add deny tcp from any to 81.176.7.126 23,80,137,139 in via rl0
$ add pass tcp from any to any 3128
$ add pass tcp from any 3128 to any
$ add pass tcp from any to any 22 in
# $ add unreach host tcp from any to 81.176.7.126 1025-65535 in setup
$ add drop udp from any to any 1-1024 in
$ add deny log all from any to any via rl0
$ add deny log ip from any to any
# $ add pipe 1 ip from any to any in via rl0
# $ pipe 1 config bw 1024Kbit/s
# $ add pipe 2 ip from any to any out via rl0
# $ pipe 2 config bw 1024Kbit/s
natd_enable=»YES»
natd_program=»/sbin/natd»
natd_interface=»rl0″
#natd_flags=»-p 6666 -n rl0 -redirect_port tcp 192.168.100.11:4899 4899″
#natd_flags=»»
Защищаем SSH от брутфорса на любом порту
Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».
Как можно достичь этих двух противоположных целей?
Я использую модуль iptables под названием hashlimit, который умеет подсчитывать кол-во пакетов в определенный промежуток времени и через некоторое время сбрасывать счетчик.
Все делается тремя правилами:
iptables -A INPUT -p tcp -m tcp —dport 22 -m state —state NEW -m hashlimit —hashlimit 1/hour —hashlimit-burst 2 —hashlimit-mode srcip —hashlimit-name SSH —hashlimit-htable-expire 60000 -j ACCEPT
iptables -A INPUT -p tcp -m tcp —dport 22 —tcp-flags SYN,RST,ACK SYN -j DROP
iptables -A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 22 -j ACCEPT
Что делает второе и третье правило понятно. Все самое интересное в первом: оно разрешает 2 попытки подключения в течение часа. Как только вы превышаете 2 попытки за указанное время, правило с -j ACCEPT перестает работать, пользователь вместо этого попадает в следующее правило с -j DROP (точно также можно поставить TARPIT). После этого вы не сможете подключиться, и начинается обратный отсчет 60 000 миллисекунд, после которых информация о вашей попытке «протухает» (параметр —hashlimit-htable-expire). То есть реально вам придеся ждать не 1 час, а всего 1 минуту. Вся военная хитрость состоит в том, что если вы не дождетесь этого времени и попробуете еще раз подключиться, то пакет будет убит, а счетчик снова сброшен в начальное состояние — 1 минуту! Таким образом, если вы нетерпеливый брутфорсер и будете тупо долбать порт после блокировки, то вы с каждой попыткой будете продлевать свой бан! То есть забаните себя навечно!
Добропорядочный же пользователь наборот имеет несколько попыток подключения без ожидания между ними прежде чем попадет в «баню».
Модуль hashlimit сохраняет свое состояние в /proc — поначалу там пусто:
# cat /proc/net/ipt_hashlimit/SSH
после первой попытки подключения туда попадает инфа:
# cat /proc/net/ipt_hashlimit/SSH
55 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 11533000 230400000 115000000
первое число — кол-во оставшихся секунд, можно смотреть как оно равномерно тикает:
# cat /proc/net/ipt_hashlimit/SSH
20 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 117429000 230400000 115000000
После того как я это сделал, мне очень захотелось проверить. И надо же! На ловца зверь бежит! Меня тут же начал брутфорсить какой-то китаец. Первые 4 попытки прошли, а дальше он в течение часа (!) тупо долбился в закрытую дверь. За весь этот час ему удалось проверить всего 4 пароля! Дальше, видимо, надоело.
Таким образом решены две проблемы:
— если пользователь вдруг опечатался, ему не нужно долго ждать новых попыток
— брутфорсеры сами себя загоняют в «вечный» бан.
Что делать, если вы вдруг с нескольких попыток не смогли ввести пароль? Не суетиться — подождать спокойно минуту и попробовать еще несколько раз.
А если уж снова не смогли — то лучше пойти проспаться, в таком состоянии в консоль лучше не лазить :))
P.S. И да, чуть не забыл — у меня SSH на нестандартном порту 🙂
UPD: Немного про настройку hashlimit.
UPD2: Как достичь того же самого с помощью более распространенного модуля recent: раз, два.
UPD3: Само собой способ годится не только для защиты от подбора пароля по SSH, но может быть использован и для различных других сервисов, где слишком частое подключение сигнализирует о чем-то неладном.
UPD4: Ограничение подключений с помощью самого SSHD.
FreeBSD/Fail2ban/IPFW
Когда я начинал свой путь в этой операционной системе, то даже в официальной документации, в качестве сетевого фильтра указывают ipfw. Правила его довольно интуитивны, но что бы сразу разобраться, особенно с NAT будет не просто. Я всегда иду от «паранойи», то есть нужно закрыть все и всем и открывать только по мере необходимости. Но первое что необходимо открыть, как правило это SSH. И если оставить его на стандартном порту, то тут же все «хакеры» и сканеры начнут беспощадно пытаться авторизоваться и просто зафлудить ssh порт. Что делать? А если это ещё и Postfix, Ngninx и прочее? По этому к нам на помощь приходит IPFW + Fail2ban, последний написан на Python по этому мы можем менять и писать дополнения к нему на свой вкус. Я не буду освещать в этой статье полностью настройку IPFW, этому стоит посвятить отдельную статью. Но ради примера я покажу самый простой пример настройки.
И так, мы начнем с настройки ipfw. Я напишу комментарии к каждому правилу что бы было более понятно. Обычно для этого создается исполняемый скрипт /etc/rc.firewall, по умолчанию этот скрипт присутствует в системе и вы можете много из него подчерпнуть. Но я показываю маленький пример.
#!/bin/sh - # Задаем переменную. fwcmd="/sbin/ipfw -q" # Удаляем все правила и счетчики которые были до момента перезапуска. $ -f flush # Разрешаем все на локальном интерфейсе. Через него работают многие демоны. $ add allow all from any to any via lo0 # Разрешаем подключаться всем, к нам на порт SSH. $ add allow tcp from any to me 22 via eth0 # Разрешаем проходить пакетам с хостов соединение с которыми уже установлено. $ add allow all from any to any established via eth0 # Разрешаем исходящий трафик с сервера. Серверу можно все. ;) $ add allow all from me to any out via eth0 # Запрещаем все остальное. $ add deny all from any to any С ipfw все, теперь нам необходимо поставить fail2ban. Я все программное обеспечение ставлю из портов, так проще конфигурировать и отключать не нужные мне опции. По этому идем в порты, конфигурируем и ставим.
# cd /usr/ports/security/py-fail2ban # make config-recursive # make install cleanПосле установки можно переходить к настройке. Как написано в документации необходимо создать свой собственный файл jail.local скопировав его при этом с идущего по умолчанию jail.conf. Я не знаю зачем авторы это делают, наверное для удобства что вы храните ваши правила в отельном файле. Но для меня лишний файл это только путаница. По этому я просто буду расскоментировать то что мне необходимо в самом jail.conf.
# cd /usr/local/etc/fail2ban/ # nano jail.confВ качестве примера приведу три ловушки ssh, postfix, nginx. Хочу обратить внимание на то, что в основном файле конфигурации необходимо пройтись по настройкам и закоментировать или наоборот то что вам необходимо. В конец файла дописываем наши ловушки.
[sshd] # Включаю агрессивное поведение, то есть любая ошибка авторизации будет считаться за попытку. # Это полезно когда кто-то пытается просто сканировать ваши порты. mode = aggressive # Это пожалуй самое главное, мы используем фильтр ipfw по этому будем пользоваться уже предустановленным скриптом bsd-ipfw, # далее идет имя таблицы куда будут попадать адреса которые необходимо блокировать. banaction = bsd-ipfw[table=ssh] # Объявляем ловушку активной. enabled = true # Указываем какие регулярные выражения нам использовать для определения IP. filter = sshd # Если ваш демон работает в отличном от стандартного порта, укажите его тут. port = 2255 # Укажите путь по которому находятся логи ssh, что бы фильтровать их. logpath = /var/log/auth.log # Укажите фильтру какая программа используется по умолчанию, обычно этот параметр трогать не надо. backend = %(sshd_backend)s # Количество попыток по истечении которых адрес будет заблокирован. maxretry = 2 # Количество часов, минут, дней на которые адрес будет заблокирован. bantime = 12h [postfix] mode = aggressive port = smtp,465,submission logpath = %(postfix_log)s backend = %(postfix_backend)s banaction = bsd-ipfw[table=postfix] enabled = true maxretry = 2 bantime = 48h [nginx-http-auth] port = http,https logpath = %(nginx_error_log)s mode = aggressive banaction = bsd-ipfw[table=nginx-auth] enabled = true maxretry = 2 bantime = 12h Собственно на этом все. После всего этого можно запускать fail2ban. Необходимо только добавить его в /etc/rc.conf
# echo 'fail2ban_enable="YES"' >> /etc/rc.conf # service fail2ban startПосле чего, можно проверить статус сервера и запущенные ловушки. В моем случае их больше чем указано в данной статье. У вас будет то количество, которое вы активируете.
# fail2ban-client status Status |- Number of jail: 6 `- Jail list: nginx-http-auth, postfix, postfix-rbl, postfix-sasl, roundcube, sshdДалее можно посмотреть правила ipfw, они покажут сколько пакетов было заблокировано и можно посмотреть каждую таблицу отельно.
# ipfw show 00100 281951 70046972 allow ip from any to any via lo0 00111 0 0 unreach port ip from table(ssh) to me 2255 00112 0 0 unreach port ip from table(nginx-auth) to me 80,443 00113 124 7292 unreach port ip from table(postfix) to me 25,465,587 00114 0 0 unreach port ip from table(postfix-rbl) to me 25,465,587 00115 0 0 unreach port ip from table(postfix-sasl) to me 25,465,587,143,993,110,995 00116 0 0 unreach port ip from table(roundcube) to me 80,443 # ipfw table postfix list 60.167.82.42/32 0 121.66.35.37/32 0 121.229.45.222/32 0 162.142.125.221/32 0 164.52.6.242/32 0 167.248.133.46/32 0 202.202.217.76/32 0 222.205.127.251/32 0 # fail2ban-client status postfix Status for the jail: postfix |- Filter | |- Currently failed: 1 | |- Total failed: 70 | `- File list: /var/log/maillog `- Actions |- Currently banned: 8 |- Total banned: 19 `- Banned IP list: 60.167.82.42 162.142.125.221 121.229.45.222 121.66.35.37 167.248.133.46 164.52.6.242 202.202.217.76 222.205.127.251 Как видим все ловушки у нас есть и активны, теперь при достижении лимита попыток адрес «хакера» попадает в бан, на то время, которое вы указали. Напоминаю так же, что в документации по fail2ban есть все необходимые ключи для работы, в том числе и директива добавления своих адресов в белый список, что бы вы «не выстрелили себе в ногу».
Но что делать если нужной программы нет в списке ловушек fail2ban, все фильтры которыми располагает программа находятся в папке /usr/local/etc/fail2ban/filter.d/, если вам необходимо внести какие-то изменения в существующий фильтр или написать новый. Например меня часто напрягало что сканируют почтовый сервер. По этому я внес изменения в фильтр postfix просто дописав туда необходимое регулярное выражение.
# nano /usr/local/etc/fail2ban/filter.d/postfix.conf # Fail2Ban filter for selected Postfix SMTP rejections # # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = postfix(-\w+)?/\w+(?:/smtp[ds])? _port = (. \d+)? prefregex = ^%(__prefix_line)s> .+ $ mdpr-normal = (?:\w+: reject:|(?:improper command pipelining|too many errors) after \S+) mdre-normal=^RCPT from [^[]*\[\]%(_port)s: 55[04] 5\.7\.1\s ^RCPT from [^[]*\[\]%(_port)s: 450 4\.7\.\d+ (<[^>]*>)?: Helo command rejected: Host not found\b ^EHLO from [^[]*\[\]%(_port)s: 504 5\.5\.\d+ (<[^>]*>)?: Helo command rejected: need fully-qualified hostname\b ^(RCPT|VRFY) from [^[]*\[\]%(_port)s: 550 5\.1\.1\s ^RCPT from [^[]*\[\]%(_port)s: 450 4\.1\.\d+ (<[^>]*>)?: Sender address rejected: Domain not found\b ^from [^[]*\[\]%(_port)s:? # Добавил правила для сканнера. ^scanner [^[]*\[\]%(_port)s:?И теперь все чисто и прекрасно.
squid — блокировка анонимайзеров
Привет!
Заблокировал доступ к социальным сетям, но ушлые юзеры пользуются анонимайзерами и рассказывают другим. Одно дело, что они обходят блокировку, но также на анонимных прокси куча вирусов и рекламы. Есть ли всегда актуальный список анонимайзеров для блокировки? Или подскажите как заблочить их с помощью squid.
Знаю, что тема изрядно изъезжена, но 100% решения в гугле так и не нашел.
riso ★
10.04.13 12:14:31 MSK
← 1 2 →
Исходя из принципу, что на каждую хитрую задницу найдется свой болт с левой резьбой, заблочишь анонимайзеры — хакир Вася поднимет на домашней тачке VPN и будет срать вконтактике через него.
Без административного ресурса — задача не решаема в принципе.
Ну и имхо эффективней смотреть на решение сотрудником своих обязанностей. А там — пусть хоть весь день вконтактике зависает — если его так прет.
kombrig ★★★
( 10.04.13 12:23:17 MSK )
Последнее исправление: kombrig 10.04.13 12:23:44 MSK (всего исправлений: 1)
Абсолютно надежного решения в этом вопросе нет.
Для себя решений нашел несколько, кои и озвучу:
1. Доступность сайтов по «белому листу». 100% избавляешь от нежелательного контента. Стоит делать на «гостевых» местах.
2. Отслеживать все анонимайзеры и блочить их. Их очень много, но в статистики Squid они всегда всплывают на вверх, и их легко отследить. Обычные пользователи устанут искать новые лазейки и просто перестанут пользоваться. С упорытыми бороться только административными методами.
3. Административное воздействие. Все сайты доступны. Но руководство регулярно (например раз в месяц) просматривает TOP-100 популярных сайтов по посещениям; по объему. Обычно это самый действенный метод. Весь интернет доступен, что иногда важно, но все же никто не смотрит порно.
И помни, что Squid — это прежде всего кеширующий прокси, а не средство блокировки или административного воздействия на пользователей.
ivanlex ★★★★★
( 10.04.13 12:25:06 MSK )
Ответ на: комментарий от kombrig 10.04.13 12:23:17 MSK
Если порты не пробрасывать, то никакие VPN Васе не помогут. А порты должны быть проброшены только для тех приложений, которые не умеют работать через интернет, и только у тех пользователей, у которых они установлены.
Тогда никакие VPN не страшны, никакие аськи, скайпы, торренты или i2p. Нужно следить за трафиком и не допускать утечек. Для этого мы и нужны.
ivanlex ★★★★★
( 10.04.13 12:29:48 MSK )
Ответ на: комментарий от kombrig 10.04.13 12:23:17 MSK
Административные наказания пока что не рассматриваются, т.к. генеральному все равно кто где шарится. Это моя инициатива, канал забивают разными медиа + отупели совсем коллеги, целыми днями в контактиках.
riso ★
( 10.04.13 12:33:55 MSK ) автор топика
nokogerra ★
( 10.04.13 12:36:07 MSK )
Ответ на: комментарий от ivanlex 10.04.13 12:25:06 MSK
Вроде как видел в инете acl для блокирование ответов приходящих с другого прокси. Но найти не могу.
Белые листы не рассматриваю, т.к. гостей нет и разброс сайтов оч большой. С портами все ок, порезано все, кроме необходимого.
riso ★
( 10.04.13 12:38:02 MSK ) автор топика
Ответ на: комментарий от ivanlex 10.04.13 12:29:48 MSK
И как отсутствие проброшеных портов повлияет на тот же OpenVPN клиент, лезущий на домашний сервер на 443 или 80-м порту?
kombrig ★★★
( 10.04.13 12:44:07 MSK )
Ответ на: комментарий от riso 10.04.13 12:33:55 MSK
Тут тебе режик советуют ставить. Но мой совет — не ставь сторонних редиректоров типа режиков или самса. У Squid есть собственных редиректор, пусть он и не такой «прошареный» как сторонние, но зато он легкий, легко настраивается и мало жрет ресурсов.
Мой совет — сделай правило на .mp3/.avi/.mp4 и другие (а еще лучше по mime их фильтруй), а редиректором перенаправляй на файлы-заглушки, приготовленные заранее. Например, пользователь хочет клип посмотреть во «вконтактике», а у него просматривается видео корпоративного собрания; хочет музычку послушать, а у него играет гимн корпорации.
И сделай расписание, что бы за час до работы, час после работы и в обеденный перерыв у тебя фильтры выключались. Тогда тебя и пользователи с потрохами не сожрут, и руководство оценит. Потому что людям действительно нужно время расслабляться от рабочей обстановки, если кто то это делает таким образом, так что же — пусть. Это дополнительная причина для них не искать анонимайзеры.
ivanlex ★★★★★
( 10.04.13 12:44:57 MSK )
Ответ на: комментарий от kombrig 10.04.13 12:44:07 MSK
И каким же образом пакет с тачки из корпоративной локалки уйдет во вне на любой порт, если шлюз данный траф не пропускает?!
ivanlex ★★★★★
( 10.04.13 12:46:42 MSK )
Ответ на: комментарий от riso 10.04.13 12:33:55 MSK
А тебе не кажется, что ты чуть-чуть превышаешь полномочия?
Если не хватает канала — докладную директору с описанием проблемы и возможными путями решения — а там на его усмотрение.
kombrig ★★★
( 10.04.13 12:47:34 MSK )
Ответ на: комментарий от ivanlex 10.04.13 12:46:42 MSK
Ты предлагаешь 80 порт прикрыть? тогда решаем методами iptables — и удаляем сквид —
kombrig ★★★
( 10.04.13 12:49:56 MSK )
Ответ на: комментарий от ivanlex 10.04.13 12:44:57 MSK
блокировки снимаются в обед и после работы. Mime — сделаю.
на сколько я понял, это список доменов для бана, не ?
riso ★
( 10.04.13 12:50:36 MSK ) автор топика
Ответ на: комментарий от kombrig 10.04.13 12:47:34 MSK
В моих полномочиях делать все, чтобы сеть работала стабильно. Если пользоваться интернетом только по проф нужде, все хорошо, канала хватает.
riso ★
( 10.04.13 12:53:12 MSK ) автор топика
Ответ на: комментарий от kombrig 10.04.13 12:49:56 MSK
Все порты должны быть закрыты. Squid должен раздавать инет и только. Зачем его удалять? Он кеширует контент, снижая нагрузку на канал, в довесок позволяет нарезать доступ.
А порты — только тем, кто в них нуждается. Например в бухгалтерии банк клиент конектится к ip «xxx.xxx.xxx.a1» на порт «nnn1». Следовательно разрешим исходящие пакеты с ПК бухгалтерии на этот ip xxx.xxx.xxx.a1:nnn1 и ответы с него. А уж чем разрешать, iptables/ipfw или аппаратный шлюз — это уже дело десятое. Но таких дыр, как ты указал, быть не должно. Это просто недопустимо с точки зрения информационной безопасности, и грозит утечками любой информации.
ivanlex ★★★★★
( 10.04.13 12:56:20 MSK )
Ответ на: комментарий от nokogerra 10.04.13 12:36:07 MSK
Спасибо! Скажи, он обновляется ?
riso ★
( 10.04.13 12:56:56 MSK ) автор топика
Ответ на: комментарий от riso 10.04.13 12:50:36 MSK
вообще это редиректор, на ресурсе режика часто дополняются бан-листы, но использовать его не обязательно — можно использовать бан листы в качестве acl, имхо.
nokogerra ★
( 10.04.13 12:59:21 MSK )
Ответ на: комментарий от riso 10.04.13 12:50:36 MSK
Да, там бан лист, но он от режика. Он конечно подойдет и к просто Squid, но вдруг ты захочешь сам режик испытать, хотя попробуй — вдруг понадобится.
Кроме того, можешь взять черные листы у юзергета (они свободно публикуются). Но я бы не стал ими пользоваться. Со временем сформируешь свой лист.
ivanlex ★★★★★
( 10.04.13 13:00:20 MSK )
Ответ на: комментарий от ivanlex 10.04.13 12:56:20 MSK
Я дома поднял openvpn сервер на 80 порту tcp. И лезу на него из локалки. Вариант только L7 фильтрация.
Ну или доступ строго по белому списку.
kombrig ★★★
( 10.04.13 13:01:52 MSK )
Ответ на: комментарий от ivanlex 10.04.13 12:29:48 MSK
Если порты не пробрасывать, то никакие VPN Васе не помогут.
у меня дома ssh на 443 порту, дальше продолжать?
lazyklimm ★★★★★
( 10.04.13 13:02:28 MSK )
Ответ на: комментарий от kombrig 10.04.13 13:01:52 MSK
есть прокси, которые на 80м порту запрещают шифрованный трафик
lazyklimm ★★★★★
( 10.04.13 13:03:00 MSK )
Последнее исправление: lazyklimm 10.04.13 13:05:45 MSK (всего исправлений: 1)
Ответ на: комментарий от ivanlex 10.04.13 13:00:20 MSK
полагать что свой лист будет более-менее полным по-моему как минимум аррогнатно — в тех же режиковских листах сотни доменных имен и каждый день они пополняются благодаря его комьюнити. как показывает практика пользователи всегда находят лазейки — лучший способ — постоянно обновлять бан листы с таких ресурсов как режик и др.
nokogerra ★
( 10.04.13 13:04:54 MSK )
Ответ на: комментарий от kombrig 10.04.13 13:01:52 MSK
Не пролезет. Шлюз просто не передаст твой пакет на внешний eth. Да и с чего бы ему это делать?! Шлюз принимает только пакеты с компа бухгалтерии и только на ip «xxx.xxx.xxx.a1:nnn1». Так с чего ты решил, что подключишься к своему домашнему VPN?
ivanlex ★★★★★
( 10.04.13 13:05:06 MSK )
Ответ на: комментарий от nokogerra 10.04.13 13:04:54 MSK
Очень часто в этих листах оказываются адреса, которые по критериям добавляющего, относятся к бану, а по критериям твоей организации — нет.
ivanlex ★★★★★
( 10.04.13 13:06:20 MSK )
Ответ на: комментарий от lazyklimm 10.04.13 13:02:28 MSK
ivanlex ★★★★★
( 10.04.13 13:07:07 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:00:20 MSK
ага, спасибо, это уже дает результаты.
riso ★
( 10.04.13 13:07:43 MSK ) автор топика
Ответ на: комментарий от ivanlex 10.04.13 13:05:06 MSK
А мы доступ дали по белому листу?
kombrig ★★★
( 10.04.13 13:08:56 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:07:07 MSK
который год пытаюсь. 443 порт _естественно_ открыт, даже если будет забанено доменное имя моего домашнего компа — всегда могу завести новое, на afraid.org их хоть носом жуй. По ip-шнику тоже не особо надежно, он у меня динамический. Так что либо только белые списки, либо целиком банить подсеть моего домашнего провайдера.
lazyklimm ★★★★★
( 10.04.13 13:09:28 MSK )
Не надо блокировать. Просто взымайте плату за хождение по непонятным сайтам во время работы.
AGUtilities ★★★
( 10.04.13 13:11:03 MSK )
Ответ на: комментарий от kombrig 10.04.13 12:23:17 MSK
А там — пусть хоть весь день вконтактике зависает — если его так прет.
AGUtilities ★★★
( 10.04.13 13:12:12 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:05:06 MSK
а у нас закрыт доступ к xxx.xxx.xxx.xxx:80?
kombrig ★★★
( 10.04.13 13:12:13 MSK )
Ответ на: комментарий от AGUtilities 10.04.13 13:11:03 MSK
список непонятных сайтов тоже где-то нужно брать 🙂
lazyklimm ★★★★★
( 10.04.13 13:12:29 MSK )
Ответ на: комментарий от kombrig 10.04.13 13:08:56 MSK
Через Squid. Для начала полный доступ, но только через Squid.
ivanlex ★★★★★
( 10.04.13 13:12:30 MSK )
Ответ на: комментарий от kombrig 10.04.13 12:23:17 MSK
Ну и имхо эффективней смотреть на решение сотрудником своих обязанностей. А там — пусть хоть весь день вконтактике зависает — если его так прет.
при всей нелюбви к соцсетям — согласен
lazyklimm ★★★★★
( 10.04.13 13:13:07 MSK )
Ответ на: комментарий от kombrig 10.04.13 13:12:13 MSK
Конечно. С чего бы ему быть открытым, если инет ты получаешь с прокси, адрес которой не обязательно должен совпадать с адресом шлюза.
ivanlex ★★★★★
( 10.04.13 13:13:29 MSK )
Ответ на: комментарий от lazyklimm 10.04.13 13:09:28 MSK
А с чего ты решил, что 443 порт открыт просто так?!
ivanlex ★★★★★
( 10.04.13 13:14:50 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:14:50 MSK
главное чтобы 443 порт не был блокирован для моей домашней машины, а выше я уже описал, почему это сложно реализовать на практике
lazyklimm ★★★★★
( 10.04.13 13:16:47 MSK )
Ответ на: комментарий от lazyklimm 10.04.13 13:16:47 MSK
Ну в целом верно. Если лазить по SSH через прокси на 443, то в принципе все верно. Но вот только у меня бы такие сомнительные ресурсы максимум пол-дня бы продержались. А через пару дней уже бы директор поинтересовался у такого сотрудника, что за сеансы связи он тут устраивает с непонятными (а самое главное — сомнительными) ресурсами.
P.S. Административное воздействие должно быть все же главным способом. А резалка трафика — второстепенной, ну что бы у пользователей не было соблазнов.
ivanlex ★★★★★
( 10.04.13 13:20:24 MSK )
Последнее исправление: ivanlex 10.04.13 13:25:34 MSK (всего исправлений: 1)
Ответ на: комментарий от ivanlex 10.04.13 13:12:30 MSK
Давай вводную обозначим.
Есть HTTP-Proxy 1.2.3.4. на 80 порту. Открытые порты: 80, 8080, 443. Authentication mode: basic.
Согласись, типовой конфиг прокси.
Есть домашний комп с белым динамическим ip.
Задача поднять VPN с домашним ПК. Примерный конфиг openvpn server
port 443 proto tcp dev tun ca ca.crt cert xxx.crt key xxx.key dh dh1024.pem server 192.168.2.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.lпролезть в инет без фильтрации.og verb 3конфиг клиента
client dev tun proto tcp remote xxx.dyndns.info 443 resolv-retry infinite nobind persist-key persist-tun http-proxy 1.2.3.4 80 authfile.txt basic ca ca.crt cert client.crt key client.key ns-cert-type server comp-lzo verb 3 Настроить dyndns и завернуть трафик в туннель предоставим читателю в качестве упражнения.
kombrig ★★★
( 10.04.13 13:31:58 MSK )
Последнее исправление: kombrig 10.04.13 13:32:59 MSK (всего исправлений: 1)
Ответ на: комментарий от ivanlex 10.04.13 13:20:24 MSK
А через пару дней уже бы директор поинтересовался у такого сотрудника, что за сеансы связи он тут устраивает с непонятными (а самое главное — сомнительными) ресурсами.
а я бы поинтересовался у директора, с какого перепугу я не могу нормально пользоваться джаббером, качать с svn/git репозиториев (более критично, я же всё-таки разработчик) итд итп.
А так — «папа денег не даёт, костик деньги сам возьмет»
Сопсна, уже третья контора (все достаточно серьёзные, over1000 сотрудников), в которой использую подобный способ подключения, нигде проблем не возникало.
lazyklimm ★★★★★
( 10.04.13 13:32:38 MSK )
Последнее исправление: lazyklimm 10.04.13 13:35:15 MSK (всего исправлений: 1)
Ответ на: комментарий от ivanlex 10.04.13 13:20:24 MSK
Выше было ТС-ом сказано, что директору пофиг где шарятся пользователи. Все это закрытие — инициатива не в меру прыткого админа.
kombrig ★★★
( 10.04.13 13:38:27 MSK )
Ответ на: комментарий от lazyklimm 10.04.13 13:32:38 MSK
Я работаю в организации несколько другого характера. Официально у нас даже за джабер за жабры подвесят. Есть внутрикорпоративная система обмена сообщениями, ей и пользуйся. А svn/git репозитарии все же можно отличить от непонятного узла в сети, с которым ты постоянно держишь связь. Вдруг ты конфиденциальные данные на лево сливаешь?!
Все это утрировано, конечно. Но на любого умника найдется другой уник. Это я к тому, что у кого-то специфика работы такова, что и на VPN глаза закроют, и на SSH. Вот только на компьютерах не только айтишники работают. И вся эта фильтрация не на них направлена.
И вообще, вам не кажется, что менеджер по работе с клиентами, который договора должен заключать, да обзванивать клиентов на предмет пролонгации, вдруг регулярно стал к сомнительным узлам подключаться с шифрованием?!
ivanlex ★★★★★
( 10.04.13 13:50:28 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:20:24 MSK
А без локальных актов предприятия регламентирующие этот вопрос я как сотрудник пошлю админа в пешее путешествие с эротическим уклоном и рисую заяву о нарушении ст 138 ч.2 УК РФ(тайна переписки).
kombrig ★★★
( 10.04.13 13:51:07 MSK )
Ответ на: комментарий от kombrig 10.04.13 13:38:27 MSK
Ну, в данном случае прыткий админ должен подойти у руководству и показать проблему, что дескать канал просаживается по причине, и разложить причину на составляющие. Ну и в качестве решения предложить видимые пути (здесь их как минимум три, плюс еще и их комбинации). Я видел, что ты предлагал такой вариант топикастеру. А уж дальше от него зависит.
ivanlex ★★★★★
( 10.04.13 13:54:57 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:54:57 MSK
Дальше идет обсуждение технических и юридических вопросов данной ситуации.
kombrig ★★★
( 10.04.13 13:56:02 MSK )
Последнее исправление: kombrig 10.04.13 13:58:25 MSK (всего исправлений: 2)
Ответ на: комментарий от kombrig 10.04.13 13:51:07 MSK
На данную статью ссылаться не можешь, так как работодатель не не является оператором связи и не несет ответственность за тайну переписке по корпоративному оборудованию. Интернет дается сотруднику для исключительно рабочих целей, и не допускается для личного использования.
ivanlex ★★★★★
( 10.04.13 13:58:59 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:58:59 MSK
Без соответствующих документов это не совсем так.
kombrig ★★★
( 10.04.13 14:02:03 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:50:28 MSK
Вдруг ты конфиденциальные данные на лево сливаешь?!
при желании я их могу сливать мелкими порциями без палева
на любого умника найдется другой уник.
обратное тоже верно 🙂
вам не кажется, что менеджер по работе с клиентами, который договора должен заключать, да обзванивать клиентов на предмет пролонгации, вдруг регулярно стал к сомнительным узлам подключаться с шифрованием?!
кажется, но я-то не менеджер
lazyklimm ★★★★★
( 10.04.13 14:02:04 MSK )
Ответ на: комментарий от ivanlex 10.04.13 13:58:59 MSK
Есть эта статья, а также закон о персональных данных. Т.е. ты как админ не имеешь права читать и хранить переписку/историю посещений без согласия сотрудника (с приказом N. ознакомлен, число подпись, расшифровка).
kombrig ★★★
( 10.04.13 14:11:09 MSK )
Последнее исправление: kombrig 10.04.13 14:11:34 MSK (всего исправлений: 1)
Ответ на: комментарий от kombrig 10.04.13 14:11:09 MSK
Это не совсем верно. Это ты, как работник, не имеешь право использовать оборудование работодателя для личной переписки. Кроме того, историю посещений (логи, кешированный контент) храню не я, а оборудование. И вся информация на оборудовании работодателя, созданная работниками в рабочее время, является собственностью работодателя.
Так что, если ты с рабочего ПК отправлял любовнице только что сочиненное любовное стихотворение по средствам связи работодателя, то эта информация принадлежит работодателю.
Если ты писал с собственного телефона/смартфона/ноутбука по средством собственной связи или посредством связи своего оператора связи — то это твоя информация, и у работодателя нет прав ее читать, и в этом случае работает вышеприведенная тобой статья.
P.S. Все это сотню раз обсасывалось, и обсуждалось, причем и компетентными юристами. Посмотри на сторонних интернет-ресурсах. Не стоит вести личную переписку посредством чужого оборудования. Да — это не этично. Но этика и закон — это немного разные вещи.
P.P.S. По поводу 152ФЗ. То тут не работодатель будет виноват за раскрытие персональных данных твоей любовницы из твоего письма. А ты! Работодатель не несет ответственности за преступления своих сотрудников, которые они осуществили посредством его оборудования.