Удаление старых файлов одной командой в Linux

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

Например, для файлов старше 5 дней:

find /path/to/files* -mtime +5 -exec rm {} ;

Для файлов, измененных в пределах 24…48 часов:

find /path/to/files* -mtime 1 -exec rm {} ;

Это версия для Debian, на RHEL надо писать чуть по-другому:

find /path/to/files* -mtime +0 -exec rm {} ;

Создать файлы для тестирования можно командой (например, дата 2 апреля):

touch -d ‘2 Apr’ /path/to/test_file
http://geckich.blogspot.com/

Nokia 5230 самопроизвольно выключается

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

Контакты на батарее иногда отходят (обычно после долгой эксплуатации).

В общем, вытаскиваем батарею и понимаем, что на ней есть зажимы для 3 штырьков, какие находятся на корпусе телефона. Это видно на фото.


Берем иглу или ножик с тонким кончиком и немного отгибаем зажимы так, чтобы они сильнее прижимались к штырькам на телефоне.

Усё, собираем, пользуемся.

http://geckich.blogspot.com/

Борьба со спамом средствами Postfix

В этой статье постараюсь изложить свой опыт по настройки MTA Postfix для максимальной фильтрации спама и нежелательных писем встроенными средствами и средствами модулей Postfix’а. Настройка Amavis, Spamassassin, Clam и т. п. отдельных средств фильтрации спама выходит за рамки данной статьи и я возможно напишу об этом позже.

Входные данные:

  • сервер под управлением ОС Debian 7, 
  • Postfix 2.9.x, 
  • домен: example.com, 
  • внешний IP – 222.222.222.222, 
  • внутренняя сеть – 192.168.1.0/24, 192.168.2.0/24. 

Считаю, что постфикс у вас уже настроен в плане авторизации, почтовых ящиков и прочего хозяйства.

Основной файл, где настраивается фильтрация спама, это main.cf

Для начала укажем адреса доверенных сетей с префиксами через “,” – для этих сетей большинство проверок работать не будут дабы не использовать лишние ресурсы:

mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.2.0/24

Далее следуют проверки HELO, т. к. многие спаммеры или пропускают команду SMTP HELO или посылают заведомо неверные данные.

smtpd_delay_reject = yes 
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/helo_access,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
1 – включаем проверки HELO и заодно совместимость с некоторыми клиентами
2 – сразу отклоняем письма от отправителей без HELO
3 – цепочка фильтрации HELO:

  • разрешить доверенным сетям,
  • разрешить авторизованным по sasl (если вы используете sasl)
  • проверка хеш-таблицы, которая собержит черный/белый список HELO, в который вы вправе добавить заведомо доверенные или нежелательные домены/адреса, например:
smap.com REJECT SPAM!
some_other_spam.com REJECT SPAM!
234.234.234.234 REJECT Some spam IP
trusted_domain.com OK
example.com REJECT Fake!
222.222.222.222 REJECT Fake!
Последние 2 строчки добавлены т. к. со всех наших сетей доступ уже был разрешен с помощью mynetworks и, если спаммер выдает себя за нас, то тут его как раз и отфильтрует.

  • далее происходит фильтрация заведомо неправильных доменов вроде “MAILSERVER” или “HOST@192.168!aol.com”
  • если с HELO письма всё хорошо, то оно проходит в следующую цепочку фильтрации

Также можно добавить перед permit опцию reject_unknown_hostname, но использование ее спорно – она фильтрует письма от доменов, которые не могут быть отрезольвены с помощью DNS. С одной стороны хорошо, а с другой – многие валидные системы имеют проблемы с DNS и их письма будут тоже отклонены.

Протестировать действие этих правил без риска ложных срабатываний можно, вставив в цепочку (до permit, естественно) опцию warn_if_reject – Postfix не будет фильтровать письма, а только писать в лог.
Далее следует цепочка фильтрации по отправителю письма.
smtpd_sender_restrictions = 
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access regexp:/etc/postfix/sender_access,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
  • вначале как и раньше – разрешаем “нашим” доступ
  • проверяем, как и в предыдущем случае, хеш-таблицу с белым/черным списком и “отфутболиваем” отправителей из неправильных и неизвестных доменов
  • пропускаем тех, у кого всё Ок с отправителем
Теперь письмо уже имеет достаточно большой шанс быть легитимным и, кстати, большинство спама уже должно быть отфильтровано. Остались наиболее “тяжелые” проверки. 
Далее следует проверка по получателю письма:
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_recipient_access regexp:/etc/postfix/recipient_access,
check_policy_service inet:127.0.0.1:10023,
check_policy_service unix:private/policy-spf,
permit
  • многие спаммеры посылают письма как можно быстрее сериями команд, не дожидаясь ответа – для фильтрации такого спама первая проверка
  • далее мы фильтруем неправильные и неизвестные домены
  • разрешаем “нашим”
  • опция reject_unauth_destination возможно самая важная – без нее наш сервер станет т.н. open relay
  • далее следует проверка по хешу блеклиста получателей – полезно добавлять туда даже локальных пользователей, если на их аккаунты сыпятся т. н. баунсы. Пример записи:

something@example.com REJECT This is not real account.

  • далее идет проверка через внешний сервис т.н. грейлистинга – в данном случае – Postgrey.
  • а также проверка Sender Policy Framework (SPF) – он них ниже.
  • ну и, конечно же, пропуск далее валидных писем
Теперь последняя цепочка проверок:
smtpd_client_restrictions = 
permit_mynetworks,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
permit

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

Для использования Spamassassin и Amavis необходимо так же добавить строчку:

content_filter = amavis:[127.0.0.1]:10024

Но настройка этих демонов – это тема для отдельной статьи.

Теперь поподробнее о SPF и Greylisting

SPF позволяет владельцу домена указать в TXT-записи, соответствующей имени домена, специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Агенты передачи почты, получающие почтовые сообщения, могут запрашивать SPF-информацию с помощью простого DNS-запроса, верифицируя таким образом сервер отправителя.

Пример SPF-данных в TXT-записи DNS:

example.org. IN TXT “v=spf1 +a +mx -all”

v= определяет используемую версию SPF. Далее следует перечисление механизмов верификации: в данном случае «a» разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; «mx» разрешает прием писем, если отправляющий узел указан в одной из MX-записей для example.org. Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться «~all» – в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).

Этой записи вполне может и не быть, но всё же.

Greylisting — способ автоматической блокировки спама, основанный на том, что «поведение» программного обеспечения, предназначенного для рассылки спама, отличается от поведения обычных серверов электронной почты. Еслипочтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать.

Установить это хозяйство достаточно просто:

aptitude install postfix-policyd-spf-python postgrey
Затем необходимо добавить в main.cf постфикса, как написано выше:

check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf,

в цепочку smtpd_recipient_restrictions (НО после reject_unauth_destination). Также необходимо добавить в этот файл (лучше в конец) опцию:

policy-spf_time_limit = 3600s

Еще в master.cf необходимо добавить следующее: 
policy-spf  unix  –       n       n       –       –       spawn
     user=nobody argv=/usr/bin/policyd-spf

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

Создать SPF-запись для своего домена можно с помощью мастера здесь:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx

Полезные ссылки:

http://www.postfix.org/postconf.5.html
http://www.freesoftwaremagazine.com/articles/focus_spam_postfix
https://help.ubuntu.com/community/Postfix/SPF

http://geckich.blogspot.com/

Asterisk и NAT

В общем, после долгих сношений с двумя понятиями – Asterisk + NAT решил запечатлить свой опыт здесь – может потом пригодиться мне или еще кому-нибудь.

Есть несколько сценариев работы * с НАТом в зависимости от того, находится сервер и/или клиенты за НАТом. НО. В каждом конкретном случае приходится “шаманить”, т. к. стандартные рецепты не всегда помогают.

У меня был самый тяжелый случай – и сервер Asterisk и клиенты находятся за НАТами… разными НАТами.

Вариантов тут может быть два:

– настроить всю кухню так, что телефоны будут подклучаться к * через свой НАТ, интернет и НАТ сети с * (т. е. путь будет такой: телефон –> НАТ  –> интернет  –> НАТ  –> астериск);

– установить второй сервер * внутри сети, где телефоны и связать 2 сервера * IAX транком – именно IAX, т. к. он более приспособлен для работы через НАТ (путь будет: телефон –> астериск2 –> IAX-транк –> астериск1).

Но, т. .к. настоящие герои всегда идут в обход (с), я решил делать вариант номер 1.

Итакс, начнемс.


1) Конфигурирование сервера с *

SIP телефоны были аппаратными, потому никаких особо вычурных конфигураций в sip.conf придумывать не надо было.

Обязательно надо добавлять опцию qualify = yes, чтобы поддерживать открытым порты на роутерах и чтобы сам * знал, что атм происходит с пиром (иначе возможна ситуация, когда звонки вроде идут, но не доходят или нет звука).

Вот пример конфига для телефонов Cisco SPA XXX:

[general]

pedantic = no
nat = no

rtptimeout = 10
rtpholdtimeout = 300
directmedia=nonat



[authentication]
deny = 0.0.0.0/0.0.0.0
permit = X.X.X.0/255.255.255.255
permit = Y.Y.Y.0/255.255.255.0


[c395]
disallow = all
allow = all
qualify = yes
type = friend
host=dynamic
call-limit=3
busylevel=1
rtpkeepalive = 15
nat=route
fromdomain=example.com
context=something
deny=0.0.0.0/0.0.0.0
permit=X.X.X.0/255.255.255.0
permit=Y.Y.Y.0/255.255.255.0
secret=*****
mailbox=395@default

2) Конфигурирование фаерволла за которым стоят телефоны практически не требуется, главное чтобы давали им какой-то порт для UDP наружу.

3) Конфигурирование фаерволла, за которым спрятан *

Тут уже несколько интересней. Зависит от фаерволла. Если есть настройки типа SIP Passthrough, то включаем, так же делаем порт-форвардинг SIP порта на сервер с * (UDP 5060 по-умолч, но лучше поменять).

Если таких настроек нет или они не дают результата, то – по матчасти – нужно открыть порты для SIP (UDP 5060 по умолч), а также для голосового траффика RTP (по умолч – UDP 10000-20000, изменяется в rtp.conf) и дописать в sip.conf:

[general]

externip = X.X.X.X
localnet = Y.Y.Y.0/24

localnet = Z.Z.Z.0/24
port = [ext_port]

4) Конфигурирование телефонов.

Конфигурирование, конечно же различается от телефона к телефону, но в общем – нужно включать поддержку NAT на тех телефонах, которые спрятаны за NAT. Если таковая поддержка есть в опциях, конечно.

Для Cisco SPA необходимо зайти на веб-морду для конфигурации (http://x.x.x.x/admin/advanced) затем в секции Line включить NAT как на рисунке:

а также, адрес прокси-сервера (т. е. адрес нашего *) указывать с учетом внешнего порта, какой форвардиться на * (х.х.х.х:ext_port).

Проверить всё это дело можно (после перезапуска астериска желательно всего, а не только модуля sip) набрав в командной строке Asterisk’а (asterisk -r):

asterisk*CLI> sip show peers

Name/username              Host            Dyn Nat ACL Port     Status     
*** 
c395/c395                x.x.x.x            D   N   A  24513    OK (134 ms) 
***

Т. е., команда выдает список пиров для протокола SIP и их состояние: Имя, IP-адрес (внешний, если пир за NAT), диманический он или статический в настройках sip.conf, далее используется пиром NAT или нет, контроль доступа есть/нет, порт пира (в случае с NAT – какой роутер форвардит для телефона) и собсно статус и время задержки.

Если телефоны за NAT не работают и в лог Asterisk’a сыплет записи вроде такой:

NOTICE[19903] chan_sip.c: Correct auth, but based on stale nonce received from ‘”с395″ <sip:с395@X.X.X.X>;tag=…………………’

То скорее всего поможет назначение телефону другого внутреннего IP – в таблице маршрутизации роутеров остаются “хвосты”.

Полезные ссылки:

1) http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html
2) http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions

http://geckich.blogspot.com/