Контроль полосы пропускания
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
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
- http://www.insecure.org/nmap/index.html
- http://www.ejj.net/~sonny/fwconfig/fwconfig.html
- http://www.linuxrouter.org )
# /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 обнулить статистику без перезагрузки?
ipf -z -f my_ipfilter_rules_file
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
<!--
lj=kyprizel
DDoS.
есть машина которую хотелось бы защитить от DDoS атаки типа syn-flood+icmp flood,
сохранить в рабочем состоянии web-server(apache) до момента окончания DDoS || отфильтровывания левого трафа вышестоящим провайдером(для тех кто в танке -> вероятность атаки достаточно велика).
OS: FreeBSD 4.9
OS: FreeBSD 4.9
некоторые опции ядра:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT #need ?
options TCP_DROP_SYNFIN
options RANDOM_IP_ID
options ICMP_BANDLIM
некоторые правила ipfw:
allow tcp from any to any limit src-addr 10 #update: стоит или нет?
allow icmp from any to me in icmptypes 0,3,4,11,12
allow icmp from me to any
deny tcp from any to me tcpoptions mss,window,!sack,ts,!cc
deny ip from any to any
sysctl.conf выглядит примерно так:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.link.ether.inet.max_age=1200
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.maskrepl=0
kern.ipc.somaxconn=1024
net.inet.tcp.drop_synfin=1
net.inet.tcp.delayed_ack=0
net.inet.ip.portrange.last=50000
et.inet.tcp.rfc1644=1
et.inet.tcp.rfc1323=0
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
kern.maxfiles=65535
net.inet.ip.fw.one_pass=0
есть задумка поставать snort для предотвращения старта чаилдов апача для нереальных соединений, но не получится ли так, что сам снорт съест слишком много ресурсов?
может быть кто-нибудь на практике сталкивался с подобной проблемой и поделится некоторыми наработками?
UPD: из открытых портов атакующий видит только 80(ssh доступен только со своих хостов).
сервер стоит на 100Mbt канале у большого провайдера, т.е. подразумевается, что канал выдержит.
(Добавить комментарий)
kyrilka
2004-02-03 13:07 (ссылка)
Lyboi PIX
(Ответить)
ikoev
2004-02-03 13:15 (ссылка)
mod_throttle для апача
(Ответить)
nightblade_
2004-02-03 13:23 (ссылка)
Из общих соображений, если есть вероятность атаки, зарежь нах все по максимуму, включая icmp. Надо будет померять скорость, залогинишься и изнутри померяешь. Оставь только ssh и те из сервисов, что нужны в публичном доступе тем, кто не имеет логина. Разреши им отвечать по TCP наружу лишь при наличии установленной сессии. А снорт тебе не поможет, только ресурсы сожрет - не для того он писан, собственно. :)
О своей сети ты практически ничего не сказал - ни где этот сервер живет, ни что на нем кроме апача, ни какие функции несет. Более подробно ответить затруднительно.
(Ответить) (Ветвь дискуссии)
Re:
kyprizel
2004-02-03 13:36 (ссылка)
из открытых портов атакующий видит только 80(ssh доступен только со своих хостов).
сервер стоит на 100Mbt канале у большого провайдера, т.е. подразумевается, что канал выдержит, либо "обойти это аппаратное ограничение не представляется возможным :)".
(Ответить) (Уровень выше) (Ветвь дискуссии)
(параноидально)
nightblade_
2004-02-03 14:02 (ссылка)
А ты не боишься атаки от "своих", или вкупе со спуфом?
При помощи ipfw не реализуемо, но если поставить перед сервером простенький раутер с iptables (типа любого из LEAF на древнем i486), можно воткнуть туда расширение strings и фильтровать контент пакетов как предлагается например в snort2iptables. Реально, для каждого известного эксплоита можно найти сигнатуру и выставить правило log'n'drop. Что касается банального флуда, пусть им займется раутер.
Собственно, схема не нова, но практически неубиваема, при грамотной реализации.
(Ответить) (Уровень выше) (Ветвь дискуссии)
Re: (параноидально)
kyprizel
2004-02-03 14:11 (ссылка)
атаки от своих или спуфа ожидать имхо не стоит, т.к. никто не знает "своих" адресов, а если узнает, то тут уж извините...а если на сервер астероид упадет 8)
насчет роутера - может это и вариант, но, к сожалению, достаточно сложно реализуемый в условиях co-location.
Может быть что-то еще кроме ipfw? Буду рад услышать лубые советы по данному вопросу.
(Ответить) (Уровень выше) (Ветвь дискуссии)
drouk
2004-02-03 14:20 (ссылка)
Я бы на "не знает "своих" адресов" не полагался - закройте на фаерволах или даже на раутерах раутинг на "свои" адреса отовсюду кроме своего офиса, а от атаки от своих, действительно ничто не спасет ;(
, то там есть замечательная весчь как порт pf из openbsd.
линк по теме: http://www.openbsd.org.ua/faq/pf/
удачи. рекомендую посмотреть установку таймаутов на различные виды соединений...
Ну если "свои" и "чужие" раутятся через разные интерфейсы, то ipfw можно сказать, чтоб различал кому через какой можно общаться и вопрос закроется.
На счет спуфа я не был бы так категоричен - посмотри логи любого файервола за сутки, сколько тебе там приватных сорсадресов попадется. Шанс небольшой, что попадут в дырку, но и не нулевой. Особенно, если серьезная атака, а не шум от скрипткиддизов.
К сожалению, на сетевом уровне во фре больше не вижу вариантов. Только на уровне приложений - например, поставить фильтрующий прокси и адресовать валидные запросы вебсерверу, невидимому напрямую снаружи. Тоже черезжопье определенное и тоже лишний point of failure.
-->
Если посмотреть логи 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