Контроль полосы пропускания
http://www.atmsk.ru/popups/articleswindow.php?id=27&print=print
Материал не готов, пока сюда сваливаются заметки и информация
к размышлению.
Проброс (туннелирование) портов через ssh
Имеем wneshnijserver и внутреннюю mashina за файрволлом.
mashina$ ssh -R new_port_tam:localhost:port_nash wneshnijserver
mashina$ ssh -C -L port_tam:localhost:new_port_nash wneshnijserver
-L - притащить порт к нам на localhost
-R - вытащить наш порт на удаленный хост.
-C - компрессировать трафик
1. Обеспечить логин из интернета на внутреннюю машину
mashina$ ssh -R 2222:localhost:22 wneshnijserver
wneshnijserver@username password:
wneshnijserver$
Проверяем:
wneshnijserver$ netstat -an | grep 2222
tcp 0 0 127.0.0.1:2222 0.0.0.0:* LISTEN
Логинимся:
wneshnijserver$ ssh -p 2222 localhost # если на mashina ssh2
wneshnijserver$ ssh -1 -p 2222 localhost # если на mashina ssh1
2. Пройти с внутренней машины на наружный порт, защитив и скомпрессовав
трафик
mashina$ ssh -C -L 3128:localhost:8080 wneshnijserver
Проверяем
mashina$ netstat -an | grep 8080
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN
Используем:
Netscape > Preference > Proxy > localhost: 8080
Как ограничить доступ к squid
1. Привязываем squid только к одному интерфейсу
http_port 10.10.10.7:3128 # было http_port 3128
http_port 12.0.0.7:3128
2. Прописываем группы пользователей
# acl rfc-user ident moshkow root
# адреса, с которых пускаем по IP
acl our_network src 10.10.10.1-10.10.10.4
acl our_network2 src 12.0.0.0/255.255.255.0
# с других адресов пускать пользователей, сказавших пароль
acl passwd_user proxy_auth REQUIRED
http_access allow our_network
http_access allow our_network2
http_access allow passwd_user
http_access deny all # остальным - нельзя
# программа, которая будет проверять пароли из файла /etc/passwd
authenticate_program /usr/lib/squid/ncsa_auth /etc/passwd
####################################
/usr/lib/squid/ncsa_auth /etc/passwd
Password:
root parolroota
OK
### с /etc/shadow этот фокус не пройдет - нет права на чтение
NAT в RedHat 8++
10 - внутршка, 172 - снаружи
1.
включить ip forwarding, возможно включен по умолчанию,
/sbin/sysctl -w net.ipv4.ip_forward = 1
2.
/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/255.255.255.0 -o if1 -j SNAT --to-source 172.10.10.1
3.
/sbin/iptables-save > /etc/sysconfig/iptables
chkconfig --levels 2345 on
Зажатие трафика
Ограничение полосы - ipfw или altq.
Ограничение трафика - ipa + пару скриптов на перле.
Два раных дефаулт гатевааы для разных адресов
Iproute2 создаёшь две таблицы, у одной один default route, у другой - другой.
И раскидываешь в них всё по исходным адресам.
Примерно так
ip route add default via a.c.b.c table tablenumberone
ip rule add from v.x.y.w/24 table tablenumberone
Аналогично поступается со второй таблицей. И с третьей. И, подозреваю, с две сотни пятьдесят пятой.
Второе правило может, например, выглядеть как-то так
ip rule add from v.x.y.w/24 table to k.l.m.o tablenumberone
Объяснять, думаю, не стоит.
Вообще, очень удобная вещь. На редкость мощная и универсальная. Я имею в виду iproute2.
Можно, конечно, и iptables всё регулировать, но мне вышеобозначенный вариант больше по душе.
И ты даже не представляешь, сколько всего гугл показывает, если его об iproute2 спросить :-).
Но начинать стоит с http://lartc.org.
Работа с ipchains. Redhat 7.0
# убедились, что в ядре есть поддержка
ls -al /proc/net/ip_fwchains
# запрет тцп-пакетов с зданного адреса
ipchains -A input -s 155.208.157.51 -p tcp -j DENY
ipchains -L # просмотр правил
ipchains -F # удаление правил
Запуск маскарадинга для диалап-клиентов. IPFWADM, redhat 6.2
echo 1 > /proc/sys/net/ipv4/ip_forward # без форвардинга не заработает
ipfwadm -F -p deny # запретить всем
ipfwadm -F -a m -S 195.0.0.2/0 -D 0.0.0.0/0 # разрешить адресу 195.0.0.2
Ограничить траффик конкретной машины в сети
while sleep 5
do
ipfw add 111 drop ip from baduser.host.name to any
sleep 15
ipfw delete 111
done
Date: 7 May 1998
From: Igor Mikhayliuk
Как-то раз, Среда Май 06 1998 10:06, Dima Volodin писал All:
DV > Нет такого стандарта. Есть такое _умолчание_, что если порт не указан, то
DV > это - 80 в случае http и 443 в случае https. Про вообще же говоря, вот
DV > живой пример из жизни - попавши как-то за фиревол, сконфигуренный одним
DV > умельцем от NT, я никак не мог воспользоваться поиском по CNNовскому
DV > сайту - он у них (у CNN) висит на каком-то левом порту (скажем, 8765).
DV > Раздражало страшно. Пришлось сделать конфигурацию из трех пальцев, ssh и
DV > далекого proxy. Слава богу, что хоть 22 порт открыт был (после некоторого
DV > брызганья слюной с моей стороны).
Злобный какой админ попался, хорошо, хоть не влагостойкий.
;)
DV > Короче, суть в том, что у "не хотящего разбираться с каждой очередной
DV > инетовской прогой" весьма смутное представление о TCP в частности и об IP
DV > вообще, и таки ему надо бы сначала разобраться с предметом, а потом уже
DV > приступать к конфигурению фиреволов.
Это, видимо, заявление из серии: "WinNT админ суксь и мастдай"?
DV > И в менее раздраженном тоне -
Вот это есть хорошо весьма.
:)
DV > окрывать надо все _исходящие_ TСРшные
DV > соединения, входящие же пускать только на конкретные хосты и порты,
DV > на
DV > которых висят публично доступные сервисы. Кроме того, обычно открывают
DV > UDРшный трафик на domain (53), ntp (123), real-чего-то там и т.д. и, для
DV > блезиру, входящий icmp. Чтобы работал ping, надо окрыть и исходящий icmp,
DV > и чтобы работал traceroute - udp на тех верхних портах, которыми он
DV > бесстыдно пользуется. Хотя, насколько я слыхал, MSовский tracert работает
DV > не так, как юниксный traceroute, тут не мне рассказывать. Ну и,
DV > естественно, блокируется весь исходящий трафик с чужими src (это не
DV > столько security, сколько хороший тон), весь входящий трафик на чужой dst
DV > и весь входящий трафик со своим src.
В общем сжато и очень хорошо описал, спасибо.
DV > Скорее всего, чего-то забыл, но тут достаточно народу, чтобы исправить и
DV > дополнить.
А теперь, все-таки уточню, откуда растут ноги у моего исходного письма. Велл
ноун сервайсес на то и велл ноун, чтобы все знали, какие протоколы/порты они
используют. Всем известно, что ФТП по умолчанию использует 21-ый порт, а
некоторым даже известно, что еще и 20-й. Но когда дело доходит до чего-то менее
традиционного, возникает проблема. Она решается путем последовательного чтения
доки, если не помогло, поиска в Инете, на худой конец, с использованием
сниффера. Естественно на это уходят силы и время.
Поэтому мне казалось логичным, что где-нибудь существуют накопленные данные о
том, какие программы что юзают. У меня даже есть подозрение, что в хелпе/доках
на крутой файрволл, сниффер и т.п. такое вполне можно найти. И я попросил
помощи
клуба.
Возможно, нежелание разбираться в каждой принесенной юзером мульке кажется тебе
ламеризмом, но мне жалко тратить на это время. А иногда я просто не знаю, как с
этим справиться. Живой пример - мне уже темечко продолбили с сетевой чатилкой
WinTalk. Штука действительно удобная, но доки к ней вообще нету, с автором
связаться не удалось, весьма ограниченный сниффер, которым я располагаю,
показывает мне только результат - сессию на паре последовательных произвольных
портов за 1024. Как она устанавливает сессию, понятия не имею. Я даже напрягся
и
скачал триалку какого-то монстрообразного сниффера, Guardian Session Wall-3, и
был весьма обрадован, когда обнаружил, что этот монстр, с более, чем
двадцатиметровым дистрибутом благополучно трапает видеоподсистему.
:(
В общем, отнесись с пониманием к тому, что админу НТевой сетки так же сложно
находить инфу/программы, касающиеся WAN, как юниксоиду какой-нибудь DTP пакет.
А человеку, который работает в маленькой фирме и, кроме сетки, ковыряется в
железе, вытирает сопли юзерам, сопровождает ДБ и много чего еще делает по
работе, не всегда хватает времени на глубокое освоение тонкостей сетевого
взаимодействия.
:)
Sentry Port Scan Detector 0.60
Date: 28 May 1998 05:45:05 -0000
From: [email protected]
Sentry is a port scan detector for Linux, *BSD, and most UNIX variants.
Sentry monitors your systems for port probing activity and will then take
any of the following actions:
1) Log the attacker hostname/IP and ports probed.
2) Run external program.
3) Configure routing table to drop route of attacking host.
4) Configure local packet filter (ipfwadm/ipfw) to drop all packets from
attacking host.
Sentry will now detect and respond to stealth scans against your host from
advanced scanners such as nmap:
http://www.insecure.org/nmap/index.html
* Еще для firewall потребуется *
NAT - Network Address Translation - настраивается в ядре командой
ipfwadm
Отключить роутинг.
Kernel reconfigure
Закрыть входные сервисы.
TCPD
Proxy для httpd, ftp, и т.д.
squid
Proxy для телнета, ftp, X11
TIS fw tollkit
Proxy для произвольного TCP всего
socks5
Пример настройки фильтра IPFWADM
Date: 17 Jun 1998
From: MushyPea
On Tue, 16 Jun 1998, Avery Pennarun wrote:
> Here is the script I use on my home IP masquerade system. It is designed
> to deny everything except what is specifically allowed in some of the
> definitions near the top. Note that there is one fatal problem -- the
> input firewall is changed to allow incoming data back to ports 1024
> through 65535, because any of those might have been used to create an
> _outgoing_ connection (and thus might have data been sent back to them).
> NFS servers might run on one of these high port numbers, so watch out.
I do the following:
1) To make the script more readable, use variables:
ME="a.b.c.d/32"
HI="1024:65535"
ANY="0.0.0.0/0"
2) Use "-y -o" options to log all connection attempts (ie. SYN bit set) to
syslog (you need verbose firewall logging compiled into the kernel), and
accept the packets in both directions for these connections.
2a) Example of a bi-directional service
# SMTP mail traffic
/bin/echo -n "SMTP/"
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} ${HI} -D ${ANY} 25 -y -o
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} ${HI} -D ${ANY} 25
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} 25 -D ${ME} ${HI}
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 25 -y -o
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 25
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} 25 -D ${ANY} ${HI}
2b) A tricky one - FTP
# Incoming FTP
/bin/echo -n "FTPin/"
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 20:21 -y -o
/sbin/ipfwadm -I -a accept -P tcp -S ${ANY} ${HI} -D ${ME} 20:21
/sbin/ipfwadm -O -a accept -P tcp -S ${ME} 20:21 -D ${ANY} ${HI}
3) Drop everything else - note, the 'without logging' section only applies
if you ever set your interface(s) into promiscuous mode... it's wise not
to log packets to/from elsewhere, otherwise the machine load hits the
roof, and the log file expands rapidly... I found out the hard way. ;)
# Deny everything else
# with logging... (target = me)
/sbin/ipfwadm -I -a deny -S 0/0 -D ${ME} -o
/sbin/ipfwadm -O -a deny -S ${ME} -D 0/0 -o
# without logging... (target != me)
/sbin/ipfwadm -I -a deny -S 0/0 -D 0/0
/sbin/ipfwadm -O -a deny -S 0/0 -D 0/0
Hope that's of some help - oh, one thing - if you decide to use logging,
make sure the logfile is on another partition somewhere, in case someone
floods your box to try and fill up the disk! Logging is worth the effort
- I've detected port scans and other such nasties this way.
Ian.
--
Ian Marsh
[email protected] ... Email
http://www.etchq.demon.co.uk/ ... WWW
http://www.dominion.net.uk/ telnet://dominion.net.uk:2468/ ... Dominion
http://www.alpha4.com/ telnet://alpha4.com:3214/ ... MBa4
From: Adam Sulmicki
One of reasons for presenting is that in all examples shown so far
it seemed that everyone suggested to leave named full-open. However,
it does not always have to be case. Say, if you are running an private
network then you want just to allow named get data transfers from
trusted host and that is all.
[root@eax /root]# cat ipfwadm-named
#!/bin/sh
#allow connection only from trusted named servers
ME="1.2.3.4" # MY ip
NS1="10.20.30.41" # IP of the primary name server
NS2="10.20.30.42" # IP of the secondary name server
NS3="10.20.30.43" # IP of the trietary name server
SRV="domain"
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS1 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS1 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS2 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS2 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P udp -S $NS3 $SRV
/sbin/ipfwadm -I -a accept -D ${ME} $SRV -W eth0 -P tcp -S $NS3 $SRV
/sbin/ipfwadm -I -a reject -D ${ME} $SRV -W eth0 -P tcp -o -v -x -e
/sbin/ipfwadm -I -a reject -D ${ME} $SRV -W eth0 -P udp -o -v -x -e
And while we are speaking about named. Here is an example
as someone from "Catholic liberal arts institution" (as per their web
page) connecting to my box. I assume that person was scanning
whole subnet searching for vulnerable versions of named.
1. Security Problems in the TCP/IP Protocol Suite
-- S.M. Bellovin then of AT&T
ftp://research.att.com/dist/internet_security/ipext.ps.Z
2. A Weekness in the 4.2 BSD Unix TCP/IP Software
-- R.T. Morris then of AT&T
ftp://research.att.com/dist/internet_security/117.ps.Z
*3.* Network (In)Security Through IP Packet Filtering
-- D. Brent Chapman
ftp://coast.cs.purdue.edu/pub/doc/firewalls/Brent_Chapman_packet_filtering.ps.ZOn the subject of firewall and IP packet filtering just go
to (and read the whole directory):
ftp://coast.cs.purdue.edu/pub/doc/firewalls/
In case of interest, the source of the IP filter that
OpenBSD uses, are at:(claims it runs under linux 2.0.31 too)
http://cheops.anu.edu.au/~avalon/
But one of the best monitoring tools is tcpdump, its
current version being 3.4, and you need libpcap-0.x, to
work. Both of the packages are ready to download from:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
ftp://ftp.ee.lbl.gov/libpcap.tar.Z
ftp://ftp.ee.lbl.gov/tcpslice.tar.Z
The last one is for reading files with live snapshots
from your net, these written by tcpdump, at later times,
when needed.
WARN: untar libpcap where your *current untarred* tcpdump
files lie, in other words under the tcpdump-3.4 directory!
Еще один firewall - LRP
From: Rob Bringman
To:
[email protected]
I am the Firewall-1 administrator where I work and it has a very nice
GUI tool for defining objects (can be hosts, networks, DNS domains,
groups of hosts, etc.) and a straightforward way of building a
rulebase.
At home I use the LRP with a mini-qmail daemon forwarding the e-mail
via qmqp to the real mailhost, and sshd for remote admin. It has
ipautofw, ipportfw and masquerading.
I really can't think of anything I can do with the Firewall-1 machine
that I can't do with this LRP machine. The whole OS used to fit on a
floppy until I added the mini-qmail and sshd packages. Now it boots
off a small HD and runs only on ramdisks. Except for the GUI and the
price, I'd say they are about equal in terms of power and protection.
I've looked into TIS but never used it. It involved running proxy
daemons on the firewall for telnet ftp and snmp. I like the LRP much
better.
(for those that don't know, LRP is the Linux Router Project. see
http://www.linuxrouter.org )
TCPwrapper: hosts.deny
# /etc/hosts/deny
#
# deny all, send an alert email to root...
ALL : ALL : \
banners /etc/banners/deny : \
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s "$(uname -n) wrappers\: %d refused for %c" \
root@localhost ) &
====8<------ end of cut --------------------------
This will deny access to anyone not specifically allowed (from
/etc/hosts.allow), give banners message (specific for the daemon being
called - see the man pages), and generate a very informative mail message
sent to root. (You can add other recipients to that line, btw).
We have found this to be VERY useful here...
[mod: Some remarked that things like "%u" are "client controlled" and
could be used to exploit Tony's system. The manual however claims:
Characters in % expansions that may confuse the shell
are replaced by underscores.
so that should be OK. -- REW]
Но я все же предпочту записывать эти логи в файл а не напрягать свой send-
mail - иначе атакующий повысив частоту попыток завести мою машину.
IPFilter
Как у ipfILTER обнулить статистику без перезагрузки?
ipf -z -f my_ipfilter_rules_file
Для того, чтобы использовать ssh1 & ssh2 одновременно, надо:
1. Поставить ssh-1.2.26 (первым!)
2. Поставить ssh-2.x.x
3. В "sshd2_config" добавить (возможно изменив пути):
Ssh1Compatibility yes
Sshd1Path /usr/sbin/sshd1
4. В "ssh2_config" добавить (возможно изменив пути):
Ssh1Compatibility yes
Ssh1Path /usr/bin/ssh1
Настроить в ssh2 ограничения доступ непросто, поэтому самый простой способ -
запускать его через inetd.conf и доступ регулировать стандартными файлами TCP-wrappera hosts.allow/hosts.deny
/etc/inetd.conf
ssh2 stream tcp nowait root /usr/sbin/tcpd sshd2 -i
/etc/hosts.allow
sshd2 : 123.232.175.0/255.255.255.0, 127.0.0.0/255.0.0.0, 234.567.890.12
Если посмотреть логи Linux серверов, то можно обнаружить большое количество
сообщений от демона sshd, свидетельствующих о попытке подбора паролей по ssh.
Dec 6 11:03:11 artur sshd[2177]: Invalid user test from 193.220.141.151
Dec 6 11:03:11 artur sshd[2177]: Failed password for invalid user test from 193.220.141.151 port 46079 ssh2
Dec 6 11:03:15 artur sshd[2180]: Failed password for root from 193.220.141.151 port 46144 ssh2
Обратите внимание на задержку между попытками - несколько секунд. На той
стороне находятся "роботы". Чтобы ограничить количество попыток соединения
с одного IP адреса можно воспользоваться модулем recent нетфильтра.
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
настройка протстого шлюза
# iptables -F INPUT
# iptables -A INPUT -m state -state EASTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -i lo -j ACCEPT
# iptables -P INPUT DROP
# iptables -F FORWARD
# iptables -P FORWARD ACCEPT
# iptables -t nat -F
# iptables -t nat -A POSTROUTING -o {внешний интерфей} -j SNAT to {внешний IP}
# Если ip динамический то
# iptables -t nat -A POSTROUTING -o {внешний интерфейс} -j MASQUERADE
Популярность: 1, Last-modified: Sun, 08 Jan 2006 12:19:38 GmT