Заблокировать все страны
Как средствами IPTables заблокировать подключения извне и от хоста (входящие и исходящие ВСЕ) со всех стран, кроме России?
Как средствами IPTables заблокировать подключения извне и от хоста (входящие и исходящие ВСЕ) со всех стран, кроме России?
Открываю полученный поток
# flow-cat /flow/2015/2015-07/2015-07-17/ft-v05.2015-07-17.113355+0200 | flow-export -f2 -m"UNIX_SECS,DPKTS,DOCTETS,FIRST,LAST,SRCADDR,DSTADDR,SRCPORT,DSTPORT,PROT,TOS,TCP_FLAGS" | tail -n2
1437125808,1,52,1048515621,1048515621,192.168.0.1,172.16.0.1,80,58515,6,0,18
1437125808,11,2060,1048510946,1048511818,172.16.1.2,192.168.0.2,443,51919,6,0,26
KIND LENGTH DESCRIPTION
18 3 Trailer Checksum Option.
26 TCP Compression Filter.
Привет, ЛОР.
Мне нужна система для мониторинга в небольшой сети (до 20 машин).
Требования такие:
Пока смотрю варианты из этого списка, но процесс идет не быстро. На что стоит в первую очередь обратить внимание, а на что не стоит вообще тратить время?
Привет всем!
Интересует вопрос: можно ли создать в linux «файл», при чтении из которого выводились бы результаты работы заданного скрипта/программы? Если да, то как это сделать? Заранее спасибо.
При отключение одного из дисков рейда, система не грузится, не важно какой диск.
В конфете grob я нашел вот этот код:
set root='mduuid/e8e53b21bbb5a860f6596e0a4d15dccf'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/e8e53b21bbb5a860f6596e0a4d15dccf' b566fce0-ed95-42b6-9b66-7c865478e5ff
else
search --no-floppy --fs-uuid --set=root b566fce0-ed95-42b6-9b66-7c865478e5ff
fi
font="/usr/share/grub/unicode.pf2"
fi
А вот все uid дисков системы.
/dev/sda1: UUID="e8e53b21-bbb5-a860-f659-6e0a4d15dccf" UUID_SUB="67c920f6-ab57-aece-42ad-2a6c2aea1293" LABEL="secondmail:0" TYPE="linux_raid_member" PARTUUID="00074912-01"
/dev/sda5: UUID="fbcdd9b6-baf4-4870-4ba2-54986a7d1ba4" UUID_SUB="7e7086ec-1fc8-dc20-2d57-ba3388058731" LABEL="secondmail:1" TYPE="linux_raid_member" PARTUUID="00074912-05"
/dev/sdb1: UUID="e8e53b21-bbb5-a860-f659-6e0a4d15dccf" UUID_SUB="1385ff3b-1d92-fbea-732c-8e4f31fe8a4f" LABEL="secondmail:0" TYPE="linux_raid_member" PARTUUID="000480bf-01"
/dev/sdb5: UUID="fbcdd9b6-baf4-4870-4ba2-54986a7d1ba4" UUID_SUB="d255c016-9c5c-2d9f-e1f7-f11dcfc54203" LABEL="secondmail:1" TYPE="linux_raid_member" PARTUUID="000480bf-05"
/dev/md0: UUID="b566fce0-ed95-42b6-9b66-7c865478e5ff" TYPE="ext4"
/dev/md1: UUID="d3847043-7ffe-47fe-b7ad-0d6d568fb49d" TYPE="swap"
подскажите, Спасибо за помощь.
Схема работы серверов такова. dns распределяет клиентов на load balancer, load balancer распределяет нагрузку уже на бэкенды.
/ > nginx backend
/ nginx balancer - > nginx backend
Client > DNS Round Robin >
\ nginx balancer - > nginx backend
\ > nginx backend
Неважно какой клиент, DDoS или рядовой пользователь, обращается на веб-сервер, запрашивая абсолютно любой документ.
Идея в том, чтобы NGINX Load Balancer защищал бэкеды от ддос-атаки средством которое я только что придумал «Cookie Terminate», по аналогии с уже известным «SSL Terminate».
Клиент заходит на сайт первый раз, NGINX Load Balancer устанавливает клиенту Cookie, в которой содержится аналог CSRF-токена, — пароль, известный только серверу. Без этой Cookie сервер не пропускает запросы дальше на бэкенды, никогда.
Впервый раз у клиента ещё нет Cookie, она ему только что была установлена, поэтому показываем ему статическую заглушку, HTML-страничку с использованием JavaScript, на котором JavaScript всего-навсего перезагружает страницу, таким образом делая повторное обращение к серверу, но уже с использованием этой Cookie из браузера, и если Cookie установлена (а она уже была установлена), нам покажут уже отдачу реального бэкенда, который NGINX Load Balancer пропустил т.к. кука имеется.
Вооот.. При всех повторных обращениях никакой заглушки показано не будет, NGINX Load Balancer по наличию этой куки с аналогом CSRF-токена всегда пропускает клиента.
То есть, что имеем. NGINX Load Balaner устанавливает Cookie если её нет, и отдает заглушку с JavaScript, JavaScript заглушка перезагружает страницу спустя несколько секунд, повторяя тем самым запрос на сервер, а сервер уже отдает реальный контент по ссылке, т.к. Cookie при повторном имеется.
Сама Cookie что из себя представляет. это hash-токен, который генерируется на этом же NGINX Load Balancer'е, который невозможно сгенерировать на стороне клиента чтобы тебя всегда пропускали. hash-токен таким образом должен содержать информацию и соль известную только серверу.
К примеру, установим туда IP-адрес клиента и соль... md5($remote_addr.$salt) грубо говоря.
И при последующих запросах клиента серверу — сервер смотрит на куку, восстанавливает хэш и сверяет их, реально ли кука соответствует данным или нет. Если нет — посылаем клиента нафиг, выдаём всё ту же заглушку.
ЛОР, взлетит ли такой метод защиты от DDoS? Какие подводные камни?
Как быть, если DDoS'ящий клиент сперва зашёл на сайт, получил эту куку, а затем начинает DDoS атаку уже с использованием этой куки, по которой Load Balancer всегда клиента пропускает, с того же IP-адреса, который содержится в hash-токене. Думаю над этим =)
Как быть с поисковыми движками... А шо, можно просто включать эту защиту только на время DDoS атак. Вот. А всё остальное время пусть выключено будет.
Какие ещё будут предложения?
Есть у меня вот такой незасмыловатый скрипт
find "$SOURCEDIR" -type f -name "*2015_0[1-3]_[0-3][0-9].txt.tar.gz" | while read file
do
glacier-cmd upload $GLACIER_VAULT "$file" --description \""$(basename "${file}")"\" >> "$LOGFILE"
COUNTER=$((COUNTER+1)) && echo $COUNTER > "$COUNTER_FILE"_1
done
Всё прекрасно работает, но только ооооооочень медленно. Он за полдня роботы загрузил 45000 файлов, а всего их 3,7млн.
Вот сижу и думаю, можноли как-то одновременно запускать несколько(или много) экземпляров glacier-cmd, но что бы оно не грузило одни и теже файлы.
Может подкинете идею?
#!/bin/bash
echo
echo "Проверяется \"[ 5 > 4 ]\""
if [ 5 > 4 ]
then
echo "5 > 4 -- это истина."
else
echo "5 > 4 -- это ложь."
fi
echo
echo "Проверяется \"[ 5 < 4 ]\""
if [ 5 < 4 ]
then
echo "5 < 4 -- это истина."
else
echo "5 < 4 -- это ложь."
fi
echo
echo "Проверяется \"[[ 5 > 4 ]]\""
if [[ 5 > 4 ]]
then
echo "5 > 4 -- это истина."
else
echo "5 > 4 -- это ложь."
fi
echo
echo "Проверяется \"[[ 5 < 4 ]]\""
if [[ 5 < 4 ]]
then
echo "5 < 4 -- это истина."
else
echo "5 < 4 -- это ложь."
fi
echo
echo "Проверяется \"(( 5 > 4 ))\""
(( 5 > 4 )) && echo "5 > 4 -- это истина."
(( 5 > 4 )) || echo "5 > 4 -- это ложь."
echo "Проверяется \"(( 5 < 4 ))\""
(( 5 < 4 )) && echo "5 < 4 -- это истина."
(( 5 < 4 )) || echo "5 < 4 -- это ложь."
echo
exit 0
Проверяется «[ 5 > 4 ]» 5 > 4 — это истина.
Проверяется «[ 5 < 4 ]» 5 < 4 — это истина.
Проверяется «[[ 5 > 4 ]]» 5 > 4 — это истина.
Проверяется «[[ 5 < 4 ]]» 5 < 4 — это ложь.
Проверяется "(( 5 > 4 ))" 5 > 4 — это истина.
Проверяется "(( 5 < 4 ))" 5 < 4 — это ложь.
Внимание, вопрос:
Почему [ 5 < 4 ] — это истина, а [[ 5 < 4 ]] — это ложь?
Добрый день, LOR!
Пришел к вам за советом. :)
Имею в своем распоряжении около сотни виртуалок. Их «оркестрацией», т.е. распространением конфигураций, обновлением и контролем состояния, занимаемся при помощи Puppet (версии 3.7.4). В последнее время немного достала медлительность Puppet (терпимо) и ужасный синтаксис встроенного языка (вот это уже жуткая жуть).
Джентльмены, есть ли у кого-то здесь опыт удачной миграции с Puppet на Chef/SaltStack/Ansible/<что-то еще?>.
Можете прокомментировать?
И стоит ли игра (переезд с Puppet) свеч?
Нашли ли вы счастье в новой системе «оркестрации» серверов?
Заранее спасибо!
Здравствуйте коллеги! Есть следующая задачка: Нужно сделать что-то типа авторизации в BIND по ip адресам. Адреса из белого списка обслуживать (отвечать на все запросы), а всем остальным на любой запрос выдавать ip web-сервера где им будут объяснять почему им не хотят отвечать.
С первой частью более-менее понятно, можно использовать VIEW и таким образом отделить мух от котлет. А как реализовать вторую часть пока понять не получается.
Может кто знает как сие реализовать.
Заранее благодарен
С уважением, Евгений.
ощщем, ЛОР, пилю очередной тупняк, проходи мимо.
бенчмарк
ab -n 100000 -c 100 -k -H "Accept-Encoding: gzip, deflate" localhost/ 2>&1 | egrep "^(Failed|Requests)"
процессор Pentium G3258 с разгоном до 3.9GHz, остальное не важно. хотите пофапать на хай-лоад?
значит к делу. вот такой конфиг, (сервер _) отлавливает все запросы, которые не подходят под другие хосты.
server {
listen 80;
server_name _;
location = /_.gif {
empty_gif;
}
}
ab localhost/_.gif выдаст вам результат в 200000 (двести тысяч!) запросов в секунду. empty_gif это модуль, поэтому такой быстрый.
к сожалению, со статикой картина чуть более печальна. ab localhost/index.html (файлик, что идет вместе с nginx'ом), сообщает о выполнении 125000 тире 150000 запросов в секунду, что тоже не так плохо. то есть, берете свой проект, оборачиваете всю динамику в fastcgi_cache, дабы nginx кэшировал запросы в статику и получаете очень быстрый сайт, мягко говоря.
рецепт успеха
worker_processes 4;
worker_priority -5;
worker_rlimit_nofile 9000;
timer_resolution 100ms;
events {
use epoll;
worker_connections 9000;
multi_accept on;
}
чтобы не расходовать ресурс жесткого диска, I/O, желательно отключить логи, ну или, указать buffer=, да побольше.
error_log /var/log/nginx/error.log warn;
access_log /var/log/nginx/access.log main buffer=64k;
access_log off;
log_not_found off;
очень ресурсоемкая директива
ssi on;
с ней производительность просядет до копеечных 40000 тысяч на статике и на 20% на динамике, что лучше откажитесь от нее вообще. забудьте.
gzip on;
баллада о двух стульях и матери. придется выбирать между процессорным временем и линком. ресурсоемкая операция, производительность сервера страдает на 20%, но зато пропускная способность сети может быть увеличена в 3 раза за счет сжатия трафика.
open_file_cache max=9000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
с этим думаю ясно, кэш дескрипторов файлов. нужен.
забудьте о существовании if в nginx, не злоупотребляйте location, каждый отнимает много ресурсов.
любой другой ара-тюнинг по вкусу, на самом деле получится что-то вроде экономии на спичках, так например, tcp_nodelay дает разницу всего в 1000 запросов при 200000 к _.gif (empty_gif). посему смотреть нужно строго по ситуации, конкретных советов уже не дам.
теперь от статики к динамике. обязательно установить php opcache.
# curl http://php.net/distributions/php-5.5.23.tar.xz | tar -xJ -v
# cd php-5.5.23
# ./configure --disable-all --enable-opcache
# make build-modules
# install -m 755 modules/*.so /usr/lib/php/extensions
# echo "zend_extension=opcache.so" > /etc/php/conf.d/opcache.ini
хороший прирост в скорости дает Ъ-распараллеливание и правильная настройка. запускать нужно два бэкенда, абсолютно одинаковых, на одном хосте.
upstream php-fpm {
server unix:/var/run/php5-fpm.sock0 weight=100 max_fails=5 fail_timeout=5;
server unix:/var/run/php5-fpm.sock1 weight=100 max_fails=5 fail_timeout=5;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass php-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
настройка php-fpm'ов /etc/php/pool{0,1}.conf
[global]
log_level = notice
emergency_restart_threshold = 0
emergency_restart_interval = 0
process_control_timeout = 0
daemonize = yes
[pool0]
listen = /var/run/php5-fpm.sock0
listen.owner = www
listen.group = www
listen.mode = 0660
user = www
group = www
pm = static
pm.max_children = 8
pm.max_requests = 500
второй точно такой же
:%s/pool0/pool1
:%s/sock0/sock1
# /usr/sbin/php-fpm --fpm-config /etc/php/pool0.conf
# /usr/sbin/php-fpm --fpm-config /etc/php/pool1.conf
# /usr/sbin/nginx -t && /usr/sbin/nginx -s reload
а теперь получите пятикратный прирост производительности php. вот.
Как говорили древние отцы-основатели редактирования текстов: « Damnosa quid non imminuit dies¹ ? »
Но мы им отвечаем: « Tempora mutantur et nos mutamur in illis² ! »
Делимся полезными и интересными кусками из своих конфигов, а также демонстрируем, кто на какой статусной строке в данный момент остановился и использует. Также это касается не общеизвестных плугинов или настройки/интеграции общеизвестных и общеиспользуемых. В общем синтастик или ЗадротДерево сюда не нужно, наверное, писать.
Я могу предложить (кое-что известное, но будет полезно новичкам, если такие есть):
А теперь по статусной строке. Почти два года сидел на airline, но вот недавно перешел на lightline, которая быстрее стартует и легче кастомизируется, а также не содержит кучу неиспользуемых (лично мной) возможностей. Попробовал еще ezbar, но японец пилит его под себя, хотя там есть кое-что интересное, насчет скорости:
lightline: 229.019 000.003:
ezbar: 250.312 000.002:
airline: 276.823 000.003:
Вот такая у меня статусная строка: картинка, настройка здесь и здесь. Середина прозрачная, выведен размер файла, имя файла справа, голубой квадратик с + это модифицированный, но не сохраненный файл.
Показывайте ваши ништяки.
--------
¹ - лат. что не изменит губительное время
² - лат. времена меняются и мы меняемся с ними
Почему сервера, даже те, в которых не планируется втыкать по 20 хардов, такие огромные, железные и тяжелые?
Почему не делаются облегченные, полупластиковые (?) корпуса для, например, одноюнитовых железок?
Я пытался найти ответ, придумал два ответа:
1) нужна жесткая рама для защиты материнской платы при переноске. Тут возникает вопрос: нафига нужна такая огромная материнская плата, если ARM-ы давно научились засовывать в телефон. Т.е. может причина для создания больших плат есть, просто я её не знаю.
2) железный корпус не создает убийственной статики, а пластмассовый при переноске выработает электричества, которого хватит спалить целую стойку.
Собственно, проблема современных корпусов в повышенной стоимости (железо дорогая штука) и дорогой логистике: сервачок маленький, а в коробку можно целого (почти целого) человека запихать.
Задача такая:
Приложение выкладывает файлы ежедневно в каталог со множеством подкаталогов.
Несколько раз в день rsync переносит то, что добавилось в backup. Т.е. переносится только новое и в итоге мы имеем копию.
rsync -avz -e "ssh -i losevo" losevo@losevo.ru:/home/losevo/storage /iSCSI2/attachments
Теперь задумываюсь, что бы хранить не сами файлы, а нечто сжатое. Файлы сжимаются легко, сейчас их порядка 100Гб, а получается около 15Гб. Лишь бы каждый раз передавать только разницу.
Все, что читал или жмут и передают все стразу, или не жмут.
Подскажите направление, куда копать?
Примерно год назад решил попробовать awesome. Хотелось чего-то максимально кастомизируемого, но более монолитного и системонезависимого. Данный wm показался интересным в этом плане, так что вооружившись напильником попытался сделать на его основе годное, согласно своим представлениям, окружение.
Еще скриншоты: традиционный с окнами[1] и все остальные[2][3][4][5][6][7].
На панели можно увидеть
Виджеты на рабочем столе - перенес свои луа скрипты от коньков на базу awesome. Тут нет готовых датчиков, но на помощь снова приходит vicious. В целом средствами осома такие штуки пилить даже удобнее, ибо тру модульность и интерактивность. Зависимые от сети вещи подключены через модификацию asyncshell. Может быть имело смысл все через него пускать, но поздновато осознал насколько это нужная и полезная штука, лень переделывать.
Для пущего уюта установил uselessgap тайлинг от Lain. Сделал активные грани экрана. Немного переписал awful.menu, добавив автоскрытие, возможность вставлять неиндексируемые элементы(заголовки, разделители), автоматическую расстановку хоткеев и еще по мелочи[2][4]. На базе menubar запилил запускалку приложений[3] в стиле synapse, очень нравится такой визуал. Сильно скучал по классическому альттабу, даже накостылял кое-что, но потом некто Joren Heit выкатил няшный Familiar Alt Tab. Скрестив его и свои наработки получил такую переключалку[5][6]. Адским костылем с помощью asyncshell и rsvg-convert прикрутил адекватное масштабирование векторных иконок, заодно добавив смену цвета на лету. Сделал подсказку по хоткеям[7], как сами знаете где, с интерактивной подсветкой (пока без модификаторов).
Многое еще нужно допиливать, но надежда завершить все это и нормально оформить изрядно подтаяла за прошедшее время, так что решил вбросить то что есть, в сыром виде. Все скрипты можно посмотреть здесь. Пользуясь случаем, хочу поблагодарить unlog1c за его конфиги, некоторые вещи откровенно позаимствовал оттуда.
Awesome 3.5.6, compton, тема gtk - Boje, иконки ACYL, шрифты play и prototype.
Прочитал на днях вот эту статейку: http://www.dwheeler.com/essays/filenames-in-shell.html. Это просто жесть. Я наверное не видел ни одного баш скрипта, который бы делал все правильно, как там описано. Не легче ли использовать какой-нибудь там питон для этого, а не терпеть внезапные унижения собственным шеллом, когда ты впервые запустишь скрипт на файлах с русскими символами / пробелами / переносами строк / еще какими-нибудь внезапными названиями?
Друзья, поделитесь, пожалуйста, опытом защиты от атаки syn flood spoofing ip.
Льется трафик с фейковых IP. Через 30-120 секунд после начала атаки - сервер становится недоступен.
Задача «переваривать трафик» 5-10 минут. Далее дата центр включает защиту и фильтрует сам.
Подозреваю, что можно это сделать за счет увеличения лимитов sysctl.
Если скопипастить все - то пост выйдет огромным. По ссылке полное описание проблемы и тесты.
Конкректно в моём случае представлено управление плеером, а также вызов окна терминала с htop по клику на cpubar.
Связь - напрямую через dhcpcd, без NetworkManager.
Конфиги: https://github.com/Bfgeshka/dotfiles
Добрый день. Есть вопросы к опытным пользователям такого железа. Буду благодарен за ответы.
1) Когда вылетает один диск - он пищит ? Интересует именно пищание, не рассылка e-mail, алерты и пр.
2) Вот вылетел один диск, мы меняем диск, начинаем восстановление, и обнаруживается ошибка на ещё одном. Он этот ещё один выбраковывает сразу же или по окончанию процесса ребилда массива ?
3) Вообще, смысл в 6-м рейде вместо 5-го, исходя из вашей практики, был хоть раз ? То, что он, теоретически, надёжнее, это понятно. Но не оборачивается ли это на практике какими-то граблями ?
но нуно двигать в Brno, Czech Republic or Westford, Massachussets, USA
http://blogs.gnome.org/uraeus/2015/01/21/want-to-join-our-innovative-developm...
← назад | следующие → |