Матеріал не готовий, поки сюди звалюються замітки і інформація
до роздумів.
Проброс (туннелирование) портів через 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
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 \:. (Pid% p) \ n \
\ N \
User \:% u \ n \
Host \:% c \ n \
Date \: $ (date) \ n \
"| / Bin / mail -s" $ (uname -n) wrappers \:. refused for% c "\
root @ localhost)
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:
so that should be OK. - REW]
Але я все ж волію записувати ці логи в файл а не напружувати свій send-
mail - інакше атакуючий підвищивши частоту спроб завести мою машину.
Як у 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
DDoS.
є машина яку хотілося б захистити від DDoS атаки типу syn-flood + icmp flood,
зберегти в робочому стані web-server (apache) до моменту закінчення DDoS || відфільтровування лівого трафив вищим провайдером (для тих хто в танку -> ймовірність атаки досить велика).
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 каналі у великого провайдера, тобто мається на увазі, що канал витримає.
mod_throttle для апача
Із загальних міркувань, якщо є ймовірність атаки, заріж нах все по максимуму, включаючи icmp. Треба буде поміряти швидкість, залягання і зсередини поміряєш. Залиш тільки ssh і ті з сервісів, що потрібні в публічному доступі тим, хто не має логіна. Дозволь їм відповідати по TCP назовні лише при наявності встановленої сесії. А снорт тобі не допоможе, тільки ресурси зжере - не для того він писаний, власне. )
Про свою мережі ти практично нічого не сказав - ні де цей сервер живе, ні що на ньому крім апача, ні які функції несе. Більш докладно відповісти важко.
(Відповісти) (Гілка)
з відкритих портів атакуючий бачить тільки 80 (ssh доступний тільки зі своїх хостів).
сервер стоїть на 100Mbt каналі у великого провайдера, тобто мається на увазі, що канал витримає, або "обійти це апаратне обмеження не представляється можливим :)".
(Відповісти) (Вище) (Гілка)
А ти не боїшся атаки від "своїх", або вкупі зі спуф?
За допомогою ipfw не можна реалізувати, але якщо поставити перед сервером простенький раутер з iptables (типу будь-якого з LEAF на стародавньому i486), можна увіткнути туди розширення strings і фільтрувати контент пакетів як пропонується наприклад в snort2iptables. Реально, для кожного відомого експлоїта можна знайти сигнатуру і виставити правило log'n'drop. Що стосується банального флуду, нехай їм займеться раутер.
Власне, схема не нова, але практично неубіваємость, при грамотній реалізації.
(Відповісти) (Вище) (Гілка)
щодо роутера - може це і варіант, але, на жаль, досить складно реалізовується в умовах co-location.
Може бути щось ще крім ipfw? Буду радий почути лубие поради з даного питання.
(Відповісти) (Вище) (Гілка)
хай щастить. рекомендую подивитися установку таймаутів на різні види з'єднань.
Ну якщо "свої" і "чужі" раут через різні інтерфейси, то ipfw можна сказати, щоб розрізняв кому через який можна спілкуватися і питання закриється.
Якщо подивитися логи Linux серверів, то можна виявити велику кількість
повідомлень від демона sshd, які свідчать про спробу підбору паролів по ssh.
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 динамічний то
# Iptables -t nat -A POSTROUTING -o -j MASQUERADE