Контроль полосы пропускания
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 )

          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


        <!--
        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