DDOS

четверг, 12 ноября 2009 г.
Анатомия DoS-атак
DoS-атаки подразделяются на локальные и удаленные. К локальным относятся различные эксплойты, форк-бомбы и программы, открывающие по миллиону файлов или запускающие некий циклический алгоритм, который сжирает память и процессорные ресурсы. На всем этом мы останавливаться не будем. А вот удаленные DoS-атаки рассмотрим подробнее. Они делятся на два вида:
Удаленная эксплуатация ошибок в ПО с целью привести его в нерабочее состояние.
Flood - посылка на адрес жертвы огромного количества бессмысленных (реже – осмысленных) пакетов. Целью флуда может быть канал связи или ресурсы машины. В первом случае поток пакетов занимает весь пропускной канал и не дает атакуемой машине возможность обрабатывать легальные запросы. Во втором - ресурсы машины захватываются с помощью многократного и очень частого обращения к какому-либо сервису, выполняющему сложную, ресурсоемкую операцию. Это может быть, например, длительное обращение к одному из активных компонентов (скрипту) web-сервера. Сервер тратит все ресурсы машины на обработку запросов атакующего, а пользователям приходится ждать.

В традиционном исполнении (один атакующий - одна жертва) сейчас остается эффективным только первый вид атак. Классический флуд бесполезен. Просто потому что при сегодняшней ширине канала серверов, уровне вычислительных мощностей и повсеместном использовании различных анти-DoS приемов в ПО (например, задержки при многократном выполнении одних и тех же действий одним клиентом), атакующий превращается в надоедливого комара, не способного нанести какой бы то ни было ущерб. Но если этих комаров наберутся сотни, тысячи или даже сотни тысяч, они легко положат сервер на лопатки. Толпа - страшная сила не только в жизни, но и в компьютерном мире. Распределенная атака типа "отказ в обслуживании" (DDoS), обычно осуществляемая с помощью множества зомбифицированных хостов, может отрезать от внешнего мира даже самый стойкий сервер, и единственная эффективная защита - организация распределенной системы серверов (но это по карману далеко не всем, привет Google).

Методы борьбы
Опасность большинства DDoS-атак – в их абсолютной прозрачности и "нормальности". Ведь если ошибка в ПО всегда может быть исправлена, то полное сжирание ресурсов - явление почти обыденное. С ними сталкиваются многие администраторы, когда ресурсов машины (ширины канала) становится недостаточно, или web-сайт подвергается слэшдот-эффекту (twitter.com стал недоступен уже через несколько минут после первого известия о смерти Майкла Джексона). И если резать трафик и ресурсы для всех подряд, то спасешься от DDoS, но потеряешь добрую половину клиентов.

Выхода из этой ситуации фактически нет, однако последствия DDoS-атак и их эффективность можно существенно снизить за счет правильной настройки маршрутизатора, брандмауэра и постоянного анализа аномалий в сетевом трафике. В следующей части статьи мы последовательно рассмотрим:
способы распознавания начинающейся DDoS-атаки;
методы борьбы с конкретными типами DDoS-атак;
универсальные советы, которые помогут подготовиться к DoS-атаке и снизить ее эффективность.

В самом конце будет дан ответ на вопрос: что делать, когда началась DDoS-атака.
Борьба с flood-атаками

Итак, существует два типа DoS/DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них.

1. ICMP-флуд.
Очень примитивный метод забивания полосы пропускания и создания нагрузок на сетевой стек через монотонную посылку запросов ICMP ECHO (пинг). Легко обнаруживается с помощью анализа потоков трафика в обе стороны: во время атаки типа ICMP-флуд они практически идентичны. Почти безболезненный способ абсолютной защиты основан на отключении ответов на запросы ICMP ECHO:

# sysctl net.ipv4.icmp_echo_ignore_all=1

Или с помощью брандмауэра:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

2. SYN-флуд.
Один из распространенных способов не только забить канал связи, но и ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициализации большого числа одновременных TCP-соединений через посылку SYN-пакета с несуществующим обратным адресом. После нескольких попыток отослать ответный ACK-пакет на недоступный адрес большинство операционок ставят неустановленное соединение в очередь. И только после n-ой попытки закрывают соединение. Так как поток ACK-пакетов очень велик, вскоре очередь оказывается заполненной, и ядро дает отказ на попытки открыть новое соединение. Наиболее умные DoS-боты еще и анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты. Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. Оборонительные мероприятия обычно включают в себя:

Увеличение очереди "полуоткрытых" TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

Уменьшение времени удержания "полуоткрытых" соединений:

# sysctl -w net.ipv4.tcp_synack_retries=1

Включение механизма TCP syncookies:

# sysctl -w net.ipv4.tcp_syncookies=1

Ограничение максимального числа "полуоткрытых" соединений с одного IP к конкретному порту:

# iptables -I INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above
10 -j DROP
3. UDP-флуд.

Типичный метод захламления полосы пропускания. Основан на бесконечной посылке UDP-пакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких сервисов от внешнего мира и установки лимита на количество соединений в единицу времени к DNS-серверу на стороне шлюза:

# iptables -I INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1
4. HTTP-флуд.

Один из самых распространенных на сегодняшний день способов флуда. Основан на бесконечной посылке HTTP-сообщений GET на 80-ый порт с целью загрузить web-сервер настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто целью флуда становится не корень web-сервера, а один из скриптов, выполняющих ресурсоемкие задачи или работающий с базой данных. В любом случае, индикатором начавшейся атаки будет служить аномально быстрый рост логов web-сервера.

Методы борьбы с HTTP-флудом включают в себя тюнинг web-сервера и базы данных с целью снизить эффект от атаки, а также отсеивание DoS-ботов с помощью различных приемов. Во-первых, следует увеличить максимальное число коннектов к базе данных одновременно. Во-вторых, установить перед web-сервером Apache легкий и производительный nginx – он будет кэшировать запросы и отдавать статику. Это решение из списка "must have", которое не только снизит эффект DoS-атак, но и позволит серверу выдержать огромные нагрузки. Небольшой пример:

# vi /etc/nginx/nginx.conf

# Увеличиваем максимальное количество используемых файлов

worker_rlimit_nofile 80000;

events {

# Увеличиваем максимальное количество соединений

worker_connections 65536;

# Использовать эффективный метод epoll для обработки соединений

use epoll;

}

http {

gzip off;

# Отключаем таймаут на закрытие keep-alive соединений

keepalive_timeout 0;

# Не отдавать версию nginx в заголовке ответа

server_tokens off;

# Сбрасывать соединение по таймауту

reset_timedout_connection on;

}

# Стандартные настройки для работы в качестве прокси

server {

listen 111.111.111.111 default deferred;

server_name host.com www.host.com;

log_format IP $remote_addr;

location / {

proxy_pass http://127.0.0.1/;

}

location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {

root /home/www/host.com/httpdocs;

}

}

В случае необходимости можно задействовать nginx-модуль ngx_http_limit_req_module, ограничивающий количество одновременных подключений с одного адреса (http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоемкие скрипты можно защитить от ботов с помощью задержек, кнопок "Нажми меня", выставления кукисов и других приемов, направленных на проверку "человечности".
Универсальные советы

Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:
Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту (sshd спасет отца русской демократии). Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки - пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.

Добавь в /etc/sysctl.conf следующие строки:

# vi /etc/sysctl.conf

# Защита от спуфинга

net.ipv4.conf.default.rp_filter = 1

# Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная
машина, она сразу ответит. Дефолтовое значение - 2 часа.

net.ipv4.tcp_keepalive_time = 60

# Повторить пробу через десять секунд

net.ipv4.tcp_keepalive_intvl = 10

# Количество проверок перед закрытием соединения

net.ipv4.tcp_keepalive_probes = 5

Следует отметить, что все приемы, приведенные в прошлом и этом разделах, направлены на снижение эффективности DDoS-атак, ставящих своей целью израсходовать ресурсы машины. От флуда, забивающего канал мусором, защититься практически невозможно, и единственно правильный, но не всегда осуществимый способ борьбы заключается в том, чтобы "лишить атаку смысла". Если ты заимеешь в свое распоряжение действительно широкий канал, который легко пропустит трафик небольшого ботнета, считай, что от 90% атак твой сервер защищен. Есть более изощренный способ защиты. Он основан на организации распределенной вычислительной сети, включающей в себя множество дублирующих серверов, которые подключены к разным магистральным каналам. Когда вычислительные мощности или пропускная способность канала заканчиваются, все новые клиенты перенаправляются на другой сервер (или же постепенно "размазываются" по серверам по принципу round-robin). Это невероятно дорогая, но очень стойкая структура, завалить которую практически нереально.

Другое более-менее эффективное решение заключается в покупке дорогостоящих хардварных систем Cisco Traffic Anomaly Detector и Cisco Guard. Работая в связке, они могут подавить начинающуюся атаку, но, как и большинство других решений, основанных на обучении и анализе состояний, дают сбои. Поэтому следует хорошенько подумать перед тем, как выбивать из начальства десятки тысячи долларов на такую защиту.
Кажется, началось. Что делать?

Перед непосредственным началом атаки боты "разогреваются", постепенно наращивая поток пакетов на атакуемую машину. Важно поймать момент и начать активные действия. Поможет в этом постоянное наблюдение за маршрутизатором, подключенным к внешней сети (анализ графиков NetFlow). На сервере-жертве определить начало атаки можно подручными средствами.

Наличие SYN-флуда устанавливается легко - через подсчет числа "полуоткрытых" TCP-соединений:

# netstat -na | grep ":80\ " | grep SYN_RCVD

В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3). Если это не так - ты атакован, срочно переходи к дропанью атакующих.

С HTTP-флудом несколько сложнее. Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт (HTTP-флуд):

# ps aux | grep httpd | wc -l

# netstat -na | grep ":80\ " | wc -l

Значения, в несколько раз превышающие среднестатистические, дают основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:

# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less

Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о наличии таковой, если один адрес повторяется в списке слишком много раз (да и то, это может говорить о посетителях, сидящих за NAT'ом). Дополнительным подтверждением будет анализ пакетов с помощью tcpdump:

# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host IP-сервера

Показателем служит большой поток однообразных (и не содержащих полезной информации) пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или определенный cgi-скрипт).

Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо больше эффекта, если ты сделаешь это на маршрутизаторе):

# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j
DROP

Или сразу по подсетям:

# iptables -A INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j
DROP

Это даст тебе некоторую фору (совсем маленькую; зачастую IP-адрес источника спуфится), которую ты должен использовать для того, чтобы обратиться к провайдеру/хостеру (с приложенными к сообщению логами web-сервера, ядра, брандмауэра и списком выявленных тобой IP-адресов). Большинство из них, конечно, проигнорируют это сообщение (а хостинги с оплатой трафика еще и порадуются - DoS-атака принесет им прибыль) или просто отключат твой сервер. Но в любом случае это следует сделать обязательно, – эффективная защита от DDoS возможна только на магистральных каналах. В одиночку ты справишься с мелкими нападками, направленными на истощение ресурсов сервера, но окажешься беззащитным перед более-менее серьезным DDoS'ом.

Как добавить Skype-контакты в Pidgin.

среда, 11 ноября 2009 г.
Один мой знакомый очень не любит Pidgin. Ну, не нравится он ему и все тут! Он - упертый поклонник SIM. А я, напротив, весьма не прочь использовать Pidgin для общения через ICQ и Jabber. Все ОК, но нет в Pidgin поддержки Skype… Вернее не было, а теперь вот есть! Рассмотрим способ добавления Skype-контактов в Pidgin.

Для добавления Skype-контактов в Pidgin, воспользуемся Skype API Plugin для Pidgin, который поможет нам реализовать наше “желание”.

Скачаем его, выполнив в консоли команду:

$ wget http://eion.robbmob.com/skype4pidgin.deb

Установим пакет skype4pidgin, выполнив:

$ sudo dpkg -i skype4pidgin.deb

Теперь, для корректной работы, нам необходимо выкачать и добавить в систему библиотеку libskype.so.

Для 32-битных систем, она доступна здесь. Владельцам 64-битных нужна эта ссылка.

После того, как мы успешно скачали необходимую нам библиотеку (например при помощи той же команды wget), необходимо поместить ее в каталог /usr/lib/purple-2/.

Теперь, когда все сделано, просто перезапустите Pidgin и выберите в его опциях возможность использования Skype. И это будет работать!

Удаление файлов конфигурации от удаленных ранее пакетов

Посмотреть список пакетов, которые были удалены, но файлы конфигураций остались, можно с помощью
# dpkg -l | grep '^rc'

а удалить их:
# dpkg -P имя_пакета

или для большого количества:
# dpkg -l | awk '/^rc/{print $2}' | xargs dpkg -P

Типы RAID массивов

Технология обеспечения отказоустойчивости с помощью массивов жестких дисков называется RAID - Redundant Array of Inexpensive Disks (избыточный массив недорогих дисков). Наличие избыточности, однако, не гарантирует 100% надежности хранения данных. При выходе системы из строя (например, из-за поломки RAID-контроллера) восстановление данных с RAID массива является более сложной и трудоемкой задачей, чем восстановление информации с отдельного жесткого диска. Она занимает длительный отрезок времени и требует значительных трудозатрат. Иногда для восстановления информации с RAID массива даже приходится писать специальные программные модули, позволяющие «собрать» испорченные данные, распределенные по многим жестким дискам.



Рассмотрим основные характеристики уровней RAID массивов с точки зрения надежности и сложности восстановления данных.

RAID 0
Массив RAID 0 по существу не является отказоустойчивой системой, но способен значительно повысить производительность. В обычной системе данные последовательно записываются на каждый диск raid массива, пока не будет исчерпан его объем. Массив RAID 0 распределяет данные по дискам массива следующим образом. Если, например, в RAID0 используются четыре диска , то данные записываются на первую дорожку первого диска, затем на первую дорожку второго диска, первую дорожку третьего и первую дорожку четвертого. Затем данные записываются на вторую дорожку первого диска и т. д. Такое распределение данных позволяет одновременно читать и записывать данные на четырех дисках и тем самым увеличивает производительность системы. С другой стороны, если один из дисков RAID 0 выйдет из строя, восстановление данных придется делать тоже на всех четырех дисках. Таким образом, технология RAID 0 является самой быстрой, но и самой ненадежной с точки зрения сохранения информации.

RAID 1
Массив RAID 1 реализует метод зеркаливания/дуплексирования данных, создавая для каждого диска массива вторую копию данных на отдельном диске. Дуплексирование помимо данных на диске дублирует также адаптерную плату и кабель, обеспечивая еще большую избыточность. Метод хранения двух копий данных - надежный способ реализации отказоустойчивой дисковой подсистемы, и он нашел широкое применение в современных архитектурах хранения данных.

RAID 2
Массив RAID 2 распределяет данные на жестких дисках массива побитно: первый бит записывается на первом жестком диске, второй бит - на втором жестком диске и т. д. Избыточность обеспечивается за счет нескольких дополнительных дисков, куда записывается код коррекции ошибок. Эта реализация дороже, поскольку требует больших накладных расходов: raid массив с числом основных дисков от 16 до 32 должен иметь три дополнительных жестких диска для хранения кода коррекции. Массив RAID 2 обеспечивает высокую производительность и надежность, но его применение ограничено главным образом рынком компьютеров для научных исследований из-за высоких требований к минимальному объему дискового пространства массива. В сетевых файловых серверах этот метод в настоящее время не используется.

RAID 3
Массив RAID 3 распределяет данные на жестких дисках массива побайтно: первый байт записывается на первом жестком диске массива, второй байт - на втором жестком диске и т. д. Избыточность обеспечивает один дополнительный жесткий диск, куда записывается сумма данных по модулю 2 (XOR) для каждого из основных дисков массива. Таким образом, массив RAID 3 разбивает записи файлов данных, храня их одновременно на нескольких жестких дисках и обеспечивая очень быстрые чтение и запись. XOR-сегменты на дополнительном диске позволяют обнаружить любую неисправность дисковой подсистемы, а специальное ПО определит, какой из дисков массива вышел из строя. Использование побайтного распределения данных позволяет выполнять одновременное чтение или запись данных с нескольких дисков для файлов с очень длинными записями. В каждый момент времени может выполняться только одна операция чтения или записи.

RAID 4
Массив RAID 4 аналогичен массиву RAID 3, за тем исключением, что данные распределяются на жестких дисках по блокам. Для хранения XOR-сегментов также используется один дополнительный диск в raid массиве. Такая реализация raid массива удобна для файлов с очень короткими записями и большей частотой операций чтения по сравнению с операциями записи на raid, поскольку в этом случае при подходящем размере блоков на диске возможно одновременное выполнение нескольких операций чтения. Однако по-прежнему допустима только одна операция записи на дисковый массив в момент времени, так как все операции записи используют один и тот же дополнительный диск для вычисления контрольной суммы в raid массиве.

RAID 5
В массиве RAID 5 как и RAID 4, использует поблоковое распределение данных, но XOR-сегменты распределены по всем жестким дискам массива. Это позволяет выполнять несколько операций записи на диски одновременно. Массив RAID 5 также удобен для файлов с короткими записями.

RAID 7
Массив RAID 7 является разработкой компании Storage Computer.Массив RAID 7 не является, по существу, уровнем RAID, поскольку не предлагает новых способов организации данных. Основные изменения коснулись способов доступа к данным raid массива. Все жесткие диски, которых может быть до 48 (46 - непосредственно для данных, 1 для четности, 1 - в горячем резерве), подключены к индивидуальным каналам, что позволяет организовать асинхронный доступ к данным raid массива. Система поддерживает подключения к 12 хостам, обмен данными с которыми тоже осуществляется асинхронно. Доступом к каждому жесткому диску и операциями с каждым хостом заведует свой интеллектуальный контроллер с ассоциированным буфером. В системе имеется объединенный кэш и процессор управления доступом, работающий в системе реального времени. В случае отказа жестких дисков или других элементов запрос помещается в кэш, в то время как система перестраивает данные.Массив RAID 7 поддерживает все традиционные уровни RAID, но преимущественно ориентируется на уровни RAID 3 и RAID5, автоматически адаптируя способ организации хранения данных под конкретные задачи.

RAID 10
Массив RAID 10 объединяет технологии RAID 1 и RAID 0. Жесткие диски сначала зеркалируются в массив RAID 1, а потом используется попеременная запись RAID 0

Cron и почта. Красивые и правильные отчёты о выполнении скриптов

Сегодня хочется поговорить о правильном оповещении себя любимого по почте о ходе выполнения скриптов в cron'е, т.к. на мой взгляд, самым главным в администрировании является молниеносная реакция на произошедшие события и ошибки.

Я использую планировщик сron в повседневно практике как средство резервного копирования, как средство мониторинга логов и выполнения других скриптов =). И в этом случаем для меня очень важен результат таких действий. Ведь может закончится место на диске, не правильно выставиться права на файлы после перезагрузки да и просто «коллеги» могу напакостить.
Сразу оговорю условия. Я буду рассматривать задачу с точки зрения шлюза в интернет, так как в этом случае наличие на нём установленного и настроенного почтовика стремится к нулю.
Так вот, cron по умолчанию отсылает результаты выполнения команд (проще говоря, то что должно выводится в консоль) на локальную почту пользователя. Пользы от такого довольно мало. Что бы поменять почту, на которую будут отсылаться письма, нужно определить переменную MAILTO в crontab'е:

$ crontab -e

MAILTO = user@ya.ru
# m h dom mon dow command
*/1 * * * * echo "123"; date

Однако, подождав, мы не получим ничего на нашу почту. Почта не ушла потому что у нас нет настроенного smtp сервера. И устанавливать такие монстры как sendmail, postfix и exim мы не будем. Зачем нам всё это на маленьком роутере, да и безопасности эти демоны ни капельки не добавят.

В этом случае лучшим решением, на мой взгляд, является msmtp. Маленькая программка, единственным назначением которой, является пересылка почты используя «большие» smtp сервера, к примеру gmail. Ставим:

$ sudo apt-get install msmtp

Конфигурируем на использование учётки на gmail:

$ nano ~/.msmtprc

defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log

account gmail
host smtp.gmail.com
port 587
protocol smtp
auth on
from user@gmail.com
user user@gmail.com
password passWoRd

# Set a default account
account default : gmail

Не забываем права:

$ chmod 600 ~/.msmtprc

От этой учётки (той, которую указали в конфиге) мы будем получать письма.
Тепрь делаем финт ушами и создём симлинк на sendmail:

$ sudo ln -s /usr/bin/msmtp /usr/sbin/sendmail

Сейчас при выполнении команды из crontab'а к нам на почту (ту что мы указали в MAILTO) благополучно приходит почта с того адреса, который мы указали в конфиге msmtprc. =)
Ещё один маленький нюанс. Мы все помним, что есть три стандартных потока: stdin stdout и stderr. По умолчанию из крона отсылаются два потока: стандартный поток вывода и стандартный поток вывода ошибок. Для того чтобы мы получали только вывод ошибок на почту необходимо поменять строку в crontabe на следующую:

*/1 * * * * echo "123" > /dev/null

Так мы отправили весь стандартный вывод в «бездну».
И наоборот — чтобы получать только вывод скрипта и никаких ошибок:

*/1 * * * * echo "123" 2>/dev/null

Напомню, что 2 — это поток вывода ошибок.
Ну и напоследок, отправляем всё в небытие (не по теме, но может кому-то пригодится):

*/1 * * * * echo "123"> /dev/null 2>&1

Тут мы отправили стандартный вывод в /dev/null и тудаже вывод ошибок.
Вернёмся к почте. При такой отправке результатов к нам на почту приходят письма примерно с такой темой:

Cron echo "123" 2> /dev/null

Что не есть информативно. Куда лучше было бы получать письма, в теме которых было что-то красивое и удобное. Однако для этого одним только MAILTO из crontab'а не обойтись.
Здесь нам понадобится команда mail. Если у вас её нет, тогда поставим heirloom-mailx:

$ sudo apt-get install --no-install-recommends heirloom-mailx

Теперь нужно указать в конфиге mail, что мы будем использовать msmtp.

$ nano ~/.mailrc

set sendmail="/usr/bin/msmtp"

Проверяем отправку почты

$ mail -s "Здесь будет тема письма." user@ya.ru

Далее пишем текст письма и нажимаем Ctr-D (^D ;).
Ну и собственно кронтаб:

*/1 * * * * echo "123" | mail -s "Проверка крона" user@ya.ru

Или вот так, если логи/текст у нас уже сформированы и хранятся в файле super_logs.txt

*/1 * * * * mail -s "Проверка крона" user@ya.ru < super_logs.txt

Вместо вывода

Каждый из способов чем-то лучше другого. Для себя же я отсановился на варианте отправки результатов выполнения скрипта через утилиту mail, а ошибки принимаю через директиву MAILTO.

Техники запоминания

1. Метафора. Соединяйте факты с чем-то, что вы уже понимаете. Связывайте абстрактные идеи с реальными опытами. Например, представьте, что производная – это спидометр машины.

2. Диаграмма. Диаграммы и схемы – это материальное выражение связей между идеями, которые возникают в вашем разуме. Вы можете составить несколько разных схем для того, чтобы запомнить одну и ту же информацию, если посмотрите на неё с разных сторон. В этом случае вам удастся вспомнить все, даже если вы забудете одну из ассоциаций.

3. Различие. Сыграйте на различии – запоминайте похожие вещи по тому, в чем они различны. Не нужно строить идеальных схем – важно только создать набросок в памяти, чтобы в нужную минуту вспомнить его и получить нужные факты. Это помогает даже тогда, когда вы не можете придумать метафору или нарисовать схему. Например: Конфуций жил в то же время, что и Сократ, но в Древнем Китае. Или: Ускорение – это как земное притяжение, только приложенное в любом направлении.

4. Визуализация. Другой путь сделать идею более конкретной – представить её. Причем вовсе не обязательно представлять все так, как это изложено – придумывайте персонажей и ситуации. Пусть страны на мировой арене будут членами какого-то общества, а мировая история – всего лишь разговором и несколькими жестами за их ужином в столовой. Можно заменить это на воссоздание любых других чувств – слуха, обоняния, осязания и т.д.

5. Объяснить ребенку. Научить чему-то – лучший способ этому научиться. Что бы вы сейчас ни учили, подумайте, как вы объяснили бы это пятилетнему ребенку? Это заставит вас упростить предмет и свести мысли к конкретным высказываниям – а значит, связать их в стройную схему и запомнить.

6. Детское воображение. Посмотрите с другой стороны. Повертите идею в руках и так, и эдак. Покопайтесь в ней как следует, не ища в процессе особого смысла. Вы не потеряете времени впустую, это – такой же ключ к лучшему пониманию и запоминанию, как и все остальные подобные советы.

7. Вместе. Одна голова хорошо, а две лучше. Работа в команде – это множество различных взглядов на одну проблему, а значит, в несколько раз больше связей. Мозговой штурм и групповые обсуждения – очень полезные вещи, которые помогают нам обучаться быстрее.

Правило 70%. Еще одно полезное правило: приступайте к следующему разделу, освоив 70% материала. Это позволит вам достичь быстрого прогресса, не зацикливаясь на деталях, которые можно выучить потом или узнать из контекста. Вы будете постоянно напряжены, чувства пресыщения информацией не возникнет. Например, добейтесь семидесятипроцентного понимания формулы и сразу начинайте учить доказательство. Выучите новые слова на 70% и составляйте диалог. Так запоминание станет проще, быстрее и интереснее.