Не прозрачный Squid3 пускает всех

[vet_fbi]

Доброго времени суток, друзья.
Я не новичок но и еще не достаточно опытен в плане Linuxа, поэтому прошу строго не судить.

У меня проблема следующего характера. Сделал squid3 c ncsa на Ubuntu 14.04.4 LTS в VirtualBox 4.3 по инструкциям:
http://interface31.ru/tech_it/2009/11/linux-nastrojka-routera-nat-dhcp-squid.html
http://interface31.ru/tech_it/2014/02/ubuntu-server-nastraivaem-router-nat-dhcp-squid3.html
Выхлоп: прокси работает с ncsa но и без авторизации всех пускает. Пробовал все предложенное по данным ссылкам - ничего не помагает.
А самый главный прикол - это то, что год назад его уже делал и все работало сходу. Правда на Ubuntu 14.04.1 LTS.

Помогите, пож., три дня уже разбираюсь.. немогу)

[fisher74]

конфиг кальмара будет или телепатить?

[vet_fbi]

Добрый день. Вот, пожалйуста.

squid.conf

(Нажмите, чтобы показать/скрыть)

   auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/passwd
   auth_param basic children 5
   auth_param basic realm Squid proxy-caching web server
   auth_param basic credentialsttl 2 hours
      acl password proxy_auth REQUIRED
acl localnet src 192.168.0.0/24   # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80      # http
acl Safe_ports port 21      # ftp
acl Safe_ports port 443      # https
acl Safe_ports port 70      # gopher
acl Safe_ports port 210      # wais
acl Safe_ports port 1025-65535   # unregistered ports
acl Safe_ports port 280      # http-mgmt
acl Safe_ports port 488      # gss-http
acl Safe_ports port 591      # filemaker
acl Safe_ports port 777      # multiling http
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
#http_access allow localnet
http_access allow password
http_access allow localhost
http_access deny all
http_port 192.168.0.1:3128
cache_mem 1024 MB
maximum_object_size_in_memory 512 KB
cache_dir ufs /var/spool/squid3 2048 16 256
maximum_object_size 4 MB
access_log daemon:/var/log/squid3/access.log squid
logfile_rotate 31
refresh_pattern ^ftp:      1440   20%   10080
refresh_pattern ^gopher:   1440   0%   1440
refresh_pattern -i (/cgi-bin/|\?) 0   0%   0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .      0   20%   4320

nat

(Нажмите, чтобы показать/скрыть)

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -i lo -j ACCEPT

iptables -P FORWARD -i eth1 -p tcp --dport 80 -j REJECT

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE

iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i eth0 -o eth1 -j REJECT

#iptables -t nat -A PREROUTING -i eth1 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.1:3128

[fisher74]

Для НЕпрозрачного кальмара nat не нужен.
Уверены, что именно кальмар пускает без пароля? Если кальмара остановить что происходит?
Если ip_forward запретить, что происходит?

PS скрипты по загрузке правил не нужны, показывайте реально загруженные правила, которые можно извлечь командой sudo iptables-save

[vet_fbi]

1. После остановки кальмара без указывания прокси пускает, как и пускал; с указыванием - не пускает и не просит аутентификацию
2. Запрещаю ip_forward (комментирую строчку echo 1 > /proc/sys/net/ipv4/ip_forward). Сквид начал работать как следует - не пускать без аутентификации и пускать с аутентификацией.
3. Результат "iptables-save" во вложении.

[fisher74]

Значит проблема не в кальмаре, а в правилах netfilter.
Оно и понятно, в правилах нет ограничения для транзита, ходят все везде.
Настраивайте брандмауэр и оставьте кальмара в покое.

[vet_fbi]

Спасибо, большое. Знать бы чем его подкрутить? Какого правила не хватает ..

[fisher74]

Не хватает сформированной политики безопасности.
Вкратце. Есть два основных решения:
1. всё запрещено, кроме того, что разрешено
2. всё разрешено, кроме того, что запрещено

[vet_fbi]

Выходит так?:

1.# Запрещаем все по умолчанию
iptables -P FORWARD DROP

2. перед строкой:
# Разрешаем доступ из внутренней сети наружу
добавляем:

# Запрещаем HTTP через NAT
iptables -A FORWARD -i eth1 -p tcp --dport 80 -j REJECT

[fisher74]

Это Вам решать. Если изначально кальмар определяется как непрозрачный, то зачем вообще разрешать форвард через шлюз?

[vet_fbi]

1. Читал какой-то форум. Там пишет человек, что убрать форвард - это плохо для впн и раздачи интернета. Чем конкретно, не написал.
2. А форвардинг (проброс) портов при этом будет работать?
3. Да и вообще для чего он нужен, этот форвард?

Ощущение, что отвечаю на свой вопрос..

[fisher74]

1. Если интернет раздаётся средствами прокси, то форвард тут стороной вообще. VPN? У Вас подключаются клиенты из вне по VPN?
2. Нет, не будет. А Вы пробрасываете?
3. Для того чтобы вообще сообщить ядру о том, что передача пакетов с одного интерфейса на другой вообще возможна.

А вообще настройка брандмауэра несколько отличается от темы настройки прокси-сервера. Вы уже убедились, что кальмар настроен верно и не пускает без пароля.

[vet_fbi]

Дело в том, что почти год назад делал такой сервер и все работало. Форвард не комментил, сквид с ncsa сходу работал, права как следует все работали в файлике нат, был и форвардинг портов и впн. А сейчас все по другому.. Вот это мне не ясно.
Пользователь добавил сообщение 15 Августа 2016, 11:36:06:Вот сегодня поправил натовский файл и начало работать, как в прошлый раз

(Нажмите, чтобы показать/скрыть)

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -i lo -j ACCEPT

iptables -A FORWARD -i eth1 -p tcp --dport 80 -j REJECT

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE

iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i eth0 -o eth1 -j REJECT

Но перед этим я уже так дела раз десять и ничего не работало... хм, что за хрень