Как посмотреть логи freenas – Облака — белогривые лошадки или безопасный ownCloud для «маленьких» в FreeNAS / Habr

alexxlab

Содержание

Как посмотреть логи в Linux

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

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

В этой статье мы рассмотрим основные части системы логирования в Linux, файлы логов, а также утилиты, с помощью которых можно посмотреть логи Linux.

Содержание статьи:

Расположение логов по умолчанию

Большинство файлов логов Linux находятся в папке /var/log/ Вы можете список файлов логов для вашей системы с помощью команды ls:

ls -l /var/log/

-rw-r--r-- 1 root root 52198 май 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 ноя 14 15:07 apache2
drwxr-xr-x 2 root root 4096 апр 25 12:31 apparmor
drwx------ 2 root root 4096 май 5 10:15 audit
-rw-r--r-- 1 root root 33100 май 10 10:33 boot.log

….

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторых из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

/var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.

/var/log/dmesg — содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.

/var/log/auth.log — содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.

/var/log/boot.log — Содержит информацию, которая регистрируется при загрузке системы.

/var/log/daemon.log — Включает сообщения от различных фоновых демонов

/var/log/kern.log — Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.

/var/log/lastlog — Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.

/var/log/maillog /var/log/mail.log — журналы сервера электронной почты, запущенного в системе.

/var/log/user.log — Информация из всех журналов на уровне пользователей.

/var/log/Xorg.x.log — Лог сообщений Х сервера.

/var/log/alternatives.log — Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.

/var/log/btmp — лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp

/var/log/cups — Все сообщения, связанные с печатью и принтерами.

/var/log/anaconda.log — все сообщения, зарегистрированные при установке сохраняются в этом файле

/var/log/yum.log — регистрирует всю информацию об установке пакетов с помощью Yum.

/var/log/cron — Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.

/var/log/secure — содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.

/var/log/wtmp или /var/log/utmp — системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.

/var/log/faillog — лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.

/var/log/mysqld.log — файлы логов Linux от сервера баз данных MySQL.

/var/log/httpd/ или /var/log/apache2 — лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log

/var/log/lighttpd/ — логи linux веб-сервера lighttpd

/var/log/conman/ — файлы логов клиента ConMan,

/var/log/mail/ — в этом каталоге содержатся дополнительные логи почтового сервера

/var/log/prelink/ — Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о .so файлах, которые были изменены программой.

/var/log/audit/— Содержит информацию, созданную демоном аудита auditd.

/var/log/setroubleshoot/ — SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.

/var/log/samba/ — содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.

/var/log/sa/ — Содержит .cap файлы, собранные пакетом Sysstat.

/var/log/sssd/ — Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

Просмотр логов в Linux

Чтобы посмотреть логи на Linux удобно использовать несколько утилит командной строки Linux. Это может быть любой текстовый редактор, или специальная утилита. Скорее всего, вам понадобятся права суперпользователя для того чтобы посмотреть логи в Linux. Вот команды, которые чаще всего используются для этих целей:

  • less
  • more
  • cat
  • head
  • grep
  • tail
  • zcat
  • zgrep
  • zmore
  • vi
  • nano

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

Смотрим лог /var/log/messages, с возможностью прокрутки:

less /var/log/messages

Просмотр логов Linux, в реальном времени:

tail -f /var/log/messages

Открываем лог файл dmesg:

cat /var/log/dmesg

Первые строки dmesg:

head /var/log/dmesg

Выводим только ошибки из /var/log/messages:

grep -i error /var/log/messages

Кроме того, посмотреть логи на linux можно и с помощью графических утилит. Программа System Log Viewer может быть использована для удобного просмотра и отслеживания системных журналов на ноутбуке или персональном компьютере с Linux.

gnome-ubuntu-system-log

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

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!

Облака — белогривые лошадки или безопасный ownCloud для «маленьких» в FreeNAS / Habr


ownCloud, как утверждает Википедия — это Свободное и открытое веб-приложение для синхронизации данных, расшаривания файлов и удалённого хранения документов в «облаке». И, как мне кажется, довольно интересное решение для организации собственного домашнего облака.

Однако, ownCloud, устанавливающийся в виде плагина в системе FreeNAS, да и просто из коробки, имеет ряд недостатков, от которых хотелось бы избавится даже при использовании дома:

  • Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика.
    Заменим базу данных на MariaDB    .
  • Во-вторых, отсутствует работа по https, а мне совсем не нравится мысль о том, что кто-то может перехватить мои файлы. Включим https.
  • В-третьих, начисто отсутствует защита от банального подбора пароля методом брутфорса. Защитимся от брутфорса с помощью fail2ban.
  • В-четвёртых, мне лень часто просматривать логи на предмет взлома, но очень хочется оперативно узнавать о таких попытках. Настроим push-оповещения о попытках подбора пароля с помощью сервиса pushover.net.


Хочу сразу оговориться. Я не являюсь IT-специалистом, я всего лишь менеджер проектов в одном из российских системных интеграторов, а данная «инструкция» родилась в попытках настроить все 4 указанных пункта на своей домашней системе, FreeNAS работающей из-под Esxi. Инструкция написана новичком для новичков, поэтому если где-то есть явные ляпы или ошибки в командах и конфигах, то прошу указать их в комментариях.

Все настройки будем делать из консоли, ручками, максимально приближено к тому, как это, как мне видится, делают «взрослые» айтишники.

1 Подготовка Jail для ownCloud

1.1 Создаём Jail

Данный шаг описывать не буду. Если у вас получилось установить FreeNAS и он у вас работает, то проблем с данным шагом у вас быть не должно. Создание первого Jail может занять довольно продолжительное время.
1.2 Открываем доступ по SSH к данному Jail

Удобнее всего дальнейшую настройку выполнять не через web-терминал, а через полноценную программу-терминал. Например, putty. Для этого откроем доступ по SSH к нашему Jail и создадим нового пользователя, от которого и будем проводить дальнейшую настройку.

Выбираем в web-интерфейсе FreeNAS созданный нами Jail и нажимаем внизу кнопку Shell.

В веб-консоли Jail вводим:

# sysrc sshd_enable="YES"

Запускаем демон для работы ssh:
# service sshd start

Создаём пользователя от имени которого будем потом настраивать нашу систему. Пользователь будет иметь привилегии
superuser, для чего мы включим его в группу wheel.
# adduser

Настройки adduser

Usrname: Новый пользователь от имени которого мы будем производить все манипуляции в терминале. Вводим, например, superstepa.
Full name: Полное имя этого пользователя. Вводим, например, Dyadya Stepa Policeman.
Uid (Leave empty for default): Ну раз просят оставить пустым, то так и сделаем. Смело жмём Enter.
Login group [superstepa]: Мы хотим чтобы наш пользователь обладал всеми правами местного администратора — superuser, а следовательно включаем его в группу wheel.
Login group is wheel. Invite superstepa into other groups? []: Нажимаем Enter.
Login class [default]: Жмём Enter.
Shell (sh csh tcsh git-shell nologin) [sh]: Оставляем по-умолчанию sh. Просто жмём Enter.
Home directory [/home/superstepa]: И опять Enter.
Home directory permissions (Leave empty for default): И снова Enter.
Use password-based athentications? [yes]: Хотим чтобы аутентификация этого пользователя проходила по паролю? Конечно да! Жмём Enter.
Use an empty password? (yes/no) [no]: Мы же за безопасность и не хотим чтобы у нового пользователя с правами superuser был пустой пароль. А значит очередной раз жмём Enter.
Use a random password? (yes/no) [no]: Я просто уверен, что придуманный нами пароль самый надежный. И мы хотим использовать именно его. А следовательно Enter.
Enter password: Ага, а вот и он. Вводим свой пароль.
Enter password again: Вводим его снова.
Lock out the account after creation? [no]: Нет, блокировать этот аккаунт не нужно. Просто Enter.
OK? (yes/no): Проверяем всё ли верно и если да, то пешем yes.
Add another user? (yes/no): Других пользователей нам не надо. No.

2 Установка и подготовка к работе ownCloud

Присоединяемся с помощью программы-терминала к нашему Jail.
Вводим имя созданного нами пользователя и его пароль.
На приглашение командной строки $ пишем su. Теперь приглашение командной строки сменится на что-то типа root@ownCloud:/usr/home/superstepa #, а все наши команды будут выполняться от имени superuser.
Для упрощения, приглашение командной строки я буду обозначать символом #, а мои комментарии, которые вводить не надо, буду начинать с //.
2.1 Устанавливаем необходимые пакеты

Сначала обновляем текущие пакеты:
# pkg upgrade

Затем устанавливаем необходимые для работы ownCloud пакеты (на все возникающие вопросы отвечаем yes):
# pkg install mariadb100-server php56-extensions php56-bz2 php56-curl php56-exif php56-fileinfo php56-gd php56-mbstring php56-mcrypt php56-pdo_mysql php56-openssl php56-zip php56-zlib pecl-APCu pecl-intl

Для того, чтобы включить работу по https, собираем с нужными нам пакетами, а затем и устанавливаем из портов, web-сервер nginx:
# portsnap fetch extract   // скачиваем копию коллекции портов, это может занять много времени
# cd /usr/ports/www/nginx && make config   // конфигурируем и собираем web-сервер nginx

В процессе сборки убеждаемся, что выбраны следующие пакеты:
IPV6
HTTP
HTTP_CACHE
HTTP_DAV
HTTP_FLV
HTTP_GZIP_STATIC
HTTP_PERL
HTTP_REWRITE
HTTP_SSL
HTTP_STATUS
WWW
# make install

2.2 Создаём самоподписанные ключи и сертификаты
# cd /usr/local/etc/nginx/

Создаём корневой ключ server.key (алгоритм шифрования des3, длиной 1024 bit):
# openssl genrsa -des3 -out server.key 1024

Для этого система дважды попросит ввести парольную фразу. Придумываем её и вводим.

Создаём корневой сертификат:

# openssl req -new -key server.key -out server.csr

Отвечать на вопросы можно как угодно. Главное:
— на первый запрос Enter pass phrase for server.key ввести правильный пароль от корневого ключа созданного ранее,
— обязательно ответить на все вопросы, иначе клиент ownCloud в дальнейшем может отказаться от синхронизации файлов,
— запомнить введённые данные, чтобы в дальнейшем можно было легко вспомнить, что сертификат именно Ваш,
— запомнить пароль введённый на вопросе A challenge password []:.
Можно изменить срок действия нашего сертификата, например до 10000 дней, добавив в команду выше аргумент -days 10000.
# cp server.key server.key.org   //копируем наш ключ
# openssl rsa -in server.key.org -out server.key   //удаляем пароль из ключа
# openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt // Генерируем сертификат

2.3 Включаем автозапуск web-сервера, PHP и базы данных
# sysrc nginx_enable="YES" php_fpm_enable="YES" mysql_enable="YES"

2.4 Устанавливаем редактор для удобного редактирования конфигов

Всё-таки мы еще «маленькие» и пользоваться предустановленным редактором vi нам еще сложновато, поэтому поставим простенький редактор nano (на все возникающие вопросы отвечаем yes).
# pkg install nano

Внимание:После установки редактора, попробуйте его запустить командой nano. В каких-то непонятных пока мне случаях что-то идёт не так и вместо запуска появляется следующая ошибка:
Shared object «libiconv.so.2» not found, required «libgmoudle-2.0.so.0

Для того чтобы это исправить выполним всего 2 команды:
# pkg delete -f gettext
# pkg upgrade


2.5 Корректируем конфиг веб-сервера nginx

Как настоящие администраторы, всегда перед корректировкой конфига делаем его копию, чтобы в случае возникновения проблем всегда можно было откатиться назад:
# cp /usr/local/etc/nginx/nginx.conf /usr/local/etc/nginx/nginx.old

И редактируем файл конфига:
# nano /usr/local/etc/nginx/nginx.conf

Всё содержимое конфига заменяем на следующее:
worker_processes 2;
 
events {
    worker_connections  1024;
}
 
http {
    include      mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    access_log  logs/access.log  main;
    sendfile        off;
    keepalive_timeout  65;
    gzip off;
     ssl_certificate /usr/local/etc/nginx/server.crt;                       // для того чтобы работал https
     ssl_certificate_key /usr/local/etc/nginx/server.key;               // для того чтобы работал https
    
          server {
             listen 443 ssl;                                                                 // для того чтобы работал https
             root /usr/local/www;
             location = /robots.txt { allow all; access_log off; log_not_found off; }
             location = /favicon.ico { access_log off; log_not_found off; }
             location ^~ /owncloud {
                 index index.php;
                 try_files $uri $uri/ /owncloud/index.php$is_args$args;
                 client_max_body_size 512M;                       // максимальный размер файла для загрузки
                 location ~ ^/owncloud/(?:\.|data|config|db_structure\.xml|README) {
                deny all;
                 }
            location ~ \.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                fastcgi_pass unix:/var/run/php-fpm.sock;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                include fastcgi_params;
                fastcgi_param MOD_X_ACCEL_REDIRECT_ENABLED on;
            }
            location ~* \.(?:jpg|gif|ico|png|css|js|svg)$ {
                expires 30d; add_header Cache-Control public;
            }
        }
    }
}


Выход из редактора по нажатию Ctrl+X. Не забываем при выходе сохранять изменения.
2.6 Корректируем конфиг php
# cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini
# nano /usr/local/etc/php.ini

В файле находим следующие строки (используем Ctrl+W для поиска) и даём им указанные значения:
always_populate_raw_post_data = -1   // не забываем убирать ; в начале строки
date.timezone = Europe/Moscow   // либо указать Ваш часовой пояс
cgi.fix_pathinfo=0
upload_max_filesize = 512M   // либо указать максимальный размер файла доступный для загрузки в наше облако
post_max_size = 512M   // либо указать максимальный размер файла доступный для загрузки в наше облако


2.7 Корректируем php-fpm.conf:
# cp /usr/local/etc/php-fpm.conf /usr/local/etc/php-fpm.old
# nano /usr/local/etc/php-fpm.conf

В файле находим следующие строки (используем Ctrl+W для поиска) и даём им указанные значения:
listen = /var/run/php-fpm.sock
listen.owner = www   // не забываем убирать ; в начале строки
listen.group = www
env[PATH] = /usr/local/bin:/usr/bin:/bin


2.8 Корректируем /var/db/mysql/my.cnf:
# cp /var/db/mysql/my.cnf /var/db/mysql/my.old
# nano /var/db/mysql/my.cnf

В файле будет пусто, поэтому внесём в него следующие строки:
[server]
skip-networking
skip-name-resolve
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table
expire_logs_days = 1


2.9 Запускаем веб-сервер nginx, PHP, MariaDB и настраиваем базу данных:
# service nginx start && service php-fpm start && service mysql-server start

Если всё было сделано верно, то всё запустится без ошибок и можно попробовать пройти в браузере по адресу https://<YOUR_JAIL_IP>.
Нам напомнят, что сертификат у нас самоподписанный, но приняв его мы попадём на страницу с надписью 403 Forbidden.

Настраиваем базу данных MariaDB:

# mysql_secure_installation

Настройки MariaDB:

Enter current password for root (enter for none): По умолчанию пароля нет, жмём Enter.
Set root password? [Y/n]: Вводим Y.
New password: Вводим новый пароль root.
Re-enter new password: Повторяем введённый ранее пароль.
На все остальные вопросы отвечаем Y, либо просто жмём Enter


Настраиваем базу данных ownСloud введя свои значения, где owncloud — название базы, ownclouduserdb — имя пользователя для работы с базой, а passwordownclouddb — пароль этого пользователя:
# mysql -u root -p
    CREATE DATABASE owncloud;
    GRANT ALL PRIVILEGES ON owncloud.* TO 'ownclouduserdb' IDENTIFIED BY 'passwordownclouddb';
    FLUSH PRIVILEGES;
    quit;

2.10 Скачиваем и устанавливаем актуальную версию OwnCloud

По ссылке смотрим текущую актуальную версию ownCloud. На момент написания статьи это была версия 8.0.2.

Скачиваем архив, где вместо 8.0.2 указываем текущую актуальную версию:

# fetch "http://download.owncloud.org/community/owncloud-8.0.2.tar.bz2"

Разархивируем:
# tar jxf owncloud-*.tar.bz2 -C /usr/local/www

Удаляем ненужный теперь нам архив:
# rm owncloud-*.tar.bz2

Назначаем системных владельцев (пользователя и группу) ownCloud:
# chown -R www:www /usr/local/www/owncloud /mnt/files

2.11 Создаём задание в crone:
# setenv EDITOR nano   // для редактирования будем использовать установленный нами редактор nano
# crontab -u www -e

Прописываем в нём:
*/15 * * * * /usr/local/bin/php -f /usr/local/www/owncloud/cron.php

Если всё было прописано верно, то мы получим следующее системное сообщение:
crontab: installing new crontab

Идём теперь в браузере по адресу https://<YOUR_JAIL_IP>/owncloud и производим там последние настройки. Не забываем, что нам надо изменить тип применяемой базы данных, а для этого нажмём Хранилище и база данных и выберем наш тип базы: MySQL/MariaDB.
Заполняем поля
Имя пользователя: Имя администратора нашего облака. Например, Stepanadministratovich.
Пароль: Пароль администратора.
Каталог с данными: Я предпочитаю /mnt/files/. В этот каталог я потом монтирую существующие у меня Volumes хранилища FreeNAS. Если надо объяснить как, то пишите в комментариях.
Пользователь базы данных: Мы его создавали ранее на шаге 2.9 ownclouduserdb.
Пароль базы данных: Также назначали ранее на шаге 2.9 passwordownclouddb.
Название базы данных: Всё тот-же шаг 2.9 owncloud.


Наш ownCloud уже готов к работе.

3 Дополнительные настройки


3.1 Просим поисковых роботов (Yandex, Google и т.д.) не индексировать наш сайт:
# ln -s /usr/local/www/owncloud/robots.txt /usr/local/www

4 Защита от подбора пароля


4.1 Устанавливаем fail2ban из портов:
# cd /usr/ports/security/py-fail2ban
# make install clean

Структура каталогов fail2ban

Fail2ban лежит по следующему пути: /usr/local/etc/fail2ban. Структура расположенных там каталогов и файлов:
папка action.d — содержит файлы действий
папка filter.d — файлы фильтров
файл fail2ban.conf — основной файл конфигурации
файл jail.conf — файл настройки защиты конкретных сервисов


4.2 Настраиваем логирование в ownCloud:

Создаём файл в который будут писаться логи ownCloud при неудачной попытке входа:
touch /var/log/owncloud-acces.log

Файл должен быть доступен для записи пользователю www:
# cd /var/log/
# chown www:www owncloud-acces.log

Включаем логирование неудачных входов в ownCloud:
# nano /usr/local/www/owncloud/config/config.php

В файле находим или добавляем перед самой последней строкой следующие строки (пользуйтесь поиском Ctrl+W) и даём им указанные значения:
'logtimezone' => 'Europe/Moscow',                   // или другой Ваш часовой пояс
'logfile' => '/var/log/owncloud-acces.log',
'loglevel' => '2',
'log_authfailip' => true,


Проверим ведётся ли логирование неудачных входов:Несколько раз пробуем войти в web-интерфейс ownCloud с заведомо неправильным паролем или именем пользователя.

Затем выполним в консоли команду:

# nano /var/log/owncloud-acces.log

Если всё сделано правильно, то в файле появятся записи вида:
{»reqId»:«es09787k250rv52fu0iu44124z494687»,«remoteAddr»:«192.168.1.1»,«app»:«core»,«message»:«Login failed: ‘Admin’ (Remote IP: ‘192.168.1.10’, X-Forwarded-For: »)»,«level»:2,«time»:«2015-04-04T18:59:50+03:00»}

4.3 Создаём файл фильтра для fail2ban:
nano /usr/local/etc/fail2ban/filter.d/owncloud.conf

В файле пишем следующее:
[Definition]
failregex={"app":"core","message":"Login failed: user '.*' , wrong password, IP:<HOST>","level":2,"time":".*"}   // для версий ownCloud<= 7.0.1
          {"app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}   // для версий  ownCloud=7.0.2-7.0.5
          {"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"}   // для версий  ownCloud>=8


По сути это парсер, который во всей той служебной информации, которую ownCloud пишет в свой лог, должен найти ip-адрес того, кто пытался подобрать пароль на вход. Те элементы, что никогда не меняются в записях лога — указаны тут в явном виде. Те, что меняются — заменены на *. Ну а собственно ip-адресс, который мы ищем, заменён на переменную \.
4.4 Редактируем файл настроек сервисов:
# cp /usr/local/etc/fail2ban/jail.conf /usr/local/etc/fail2ban/jail.old
# nano /usr/local/etc/fail2ban/jail.conf

Добавляем в самом низу файла jail.conf:
[owncloud]
enabled = true
filter = owncloud
port = https
logpath = /var/log/owncloud-acces.log   // путь к файлу логов ownCloud, который указывали на шаге 4.2
ignoreip = 192.168.1.59   // здесь указываются ip-адреса которые банится не будут
maxretry = 2   // количество неудачных попыток до бана
bantime = 86400   // время бана в секундах
findtime = 600   // время в течение которого введено необходимое для бана к-во попыток в секундах
action = bsd-ipfw   // указываем какие файлы действий выполнять
             pushover-notify   // описание данного файла действий будет ниже по тексту статьи, вводить здесь название данного действия необходимо с новой строки и после нажатия клавиши Tab.


4.5 Проверяем работает ли наш фильтр и может ли он найти в логе ownCloud нужные строки с попытками неудачного входа:
# fail2ban-regex /var/log/owncloud-acces.log /usr/local/etc/fail2ban/filter.d/owncloud.conf

Если всё верно, то внизу выдачи будет строка вида:
Lines: 2 lines, 0 ignored, 2 matches, 0 missed [processed in 0.0 sec]

4.6 Настраиваем действия, которые будут производится в случае неудавшихся попыток входа:
# cp  /usr/local/etc/fail2ban/action.d/bsd-ipfw.conf /usr/local/etc/fail2ban/action.d/bsd-ipfw.local
# nano /usr/local/etc/fail2ban/action.d/bsd-ipfw.conf

Оставляем в нём всё по умолчанию. В нём уже прописано правило, что при отправке в бан, ip-адрес добавляется в table(1) файервола ipfw:
actionban = ipfw table \<table\> add \<ip\>

Добавляем в сам файервол ipfw правило, блокирующее все ip-адреса, находящиеся в таблице table(1), т.к. пока нет никаких правил у файервола что делать с адресами из этой нашей таблицы(1):
# ipfw add 1 deny all from table\(1\) to me

Немного примеров по работе с ipfw:
ipfw list                                                  //Просмотреть имеющиеся правила
ipfw delete 13                                        //Удалить правило 13
ipfw add 14 <правило>                         //Добавить правило 14
ipfw table 1 add 192.168.1.5               //добавление в таблицу
ipfw table 1 add 192.168.1.0/24             //добавление в таблицу подсеть
ipfw table 1 list                                    //посмотреть что в таблице
ipfw add deny ip from table(10) to me      //Всё с таблицы 50 ко мне
ipfw table 1 delete 192.168.1.5              //удаляем из таблицы
ipfw table 1 flush                                  //чистим всю таблицу


4.7 Запускаем fail2ban:

Перед запуском создадим для fail2ban файл описывающий действие pushover-notify, о котором была уже речь выше и о котором мы ещё поговорим:
#touch /usr/local/etc/fail2ban/action.d/pushover-notify.conf

Прописываем автостарт fail2ban в /etc/rc.conf:
# sysrc fail2ban_enable="YES"

И запускаем его:
# /usr/local/etc/rc.d/fail2ban start

Если всё сделали правильно, то он запустится, если нет — разбирайтесь где ошибка. Если запустился, то проверяем на бан: заходим со стороннего ip-адреса с неправильным паролем. Должно забанить на время, которое мы указали в файле jail.conf.
Немного примеров по работе с fail2ban, которые могут пригодится в процессе отладки:
fail2ban-client status   // Посмотреть какие джейлы активны
fail2ban-client status owncloud   // Посмотреть статус конкретного джейла, где owncloud - это имя нашего джейла
fail2ban-client set owncloud unbanip MYIP   // Удалить конкретный ip-адрес из бана, где MYIP - этот самый ip-адрес


Собственно теперь у нас есть ownCloud, работающий на «взрослой» базе данных по https с защитой от подбора паролей.
Почти всё, но давайте ещё добавим уведомление о блокировке при неправильном вводе пароля в виде push-уведомлений на наш телефон.
5 Уведомление о блокировке ip-адреса

Для push-уведомлений будем использовать сервис pushover.net. Я думаю Вам теперь не составит труда разобраться с его API. Но если возникнут сложности, то пишите в комментариях и я добавлю соотвествующее описание по работе с данным сервисом.
5.1 Настраиваем уведомления pushover о неудачных попытках входа и бане:
# nano /usr/local/etc/fail2ban/action.d/pushover-notify.conf

В файле прописываем следующее:
[Definition]
actionstart=
actionstop=
actioncheck=
actionban = url -k https://api.pushover.net/1/messages.json -F token=<token> -F user=<user> -F title="ownCloud Alarm" -F message="<ip> is banned after <failures> attemts against <name>"
actionunban = url -k https://api.pushover.net/1/messages.json -F token=<token> -F user=<user> -F title="ownCloud Alarm" -F message="<ip> is unbanned"

[Init]
name = default
token =  [API Token/key (application key)]
user = [User key]


, где [API Token/key (application key)] и [User key] соответствующие значения с сайта pushover.net.
Перезапускаем fail2ban
# /usr/local/etc/rc.d/fail2ban restart

Проверяем работу уведомлений выполнив несколько неудачных попыток входа в ownCloud:

Вот и всё. Не забываем пробросить на роутере порты 80 и 443 для доступа к ownCloud.
И да, для большей безопасности можно заменить стандартные порты на что-то более экзотическое.

Проект FreeNAS | HidX *nix Log

Хотелось бы написать по поводу этого, хорошо многим известного, проекта. В данной статье я постараюсь довольно детально описать FreeNAS, в целом для тех кто ещё не в курсе или не использует его дома или на работе. А так же опишу свой опыт работы с этим продуктом.

Сайт проекта: http://www.freenas.org

Что же такое FreeNAS?

Собственно по окончанию названия проекта, можно уже всё понять. NAS — сетевая система хранения данных, Free — свободная операционная система.

FreeNAS — это готовый дистрибутив, который базируется на урезанной до минимума FreeBSD, для организации сетевого хранилища. Весьма интересный и быстро развивающийся проект. В своём составе содержит приличный набор сетевых служб: CIFS (samba), FTP, NFS, Apple Mac AFP, RSYNC, iSCSI, WebServer, BitTorrent, Firewall и т.д.

Плюсами данного дистрибутива можно назвать: поддержку software RAID (* JBOD, RAID 0, RAID 1, RAID 5, RAID 0/1/5 (Vinum)), быстродействие, интеграцию с ActiveDirectory, богатый набор служб, гибкость и лёгкость в управлении. Кроме того в FreeNAS имеется мощная система журналирования с отправкой отчётов на E-mail.

Минимальные системные требования

Pentium processor or equivalent.
96 MB ram memory, 128 MB for update.
Bootable hard-drive, cd-rom, compact flash or USB flash drive. 64MB will be OK.
Keyboard and monitor.
Last FreeNAS cd-rom.

Управление:

Управление осуществляется через Web интерфейс, а так же на уровне консоли… через ssh.
Web интерфейс довольно понятный и позволит поднять файловое хранилище буквально за 5 минут с момента установки.
Web интерфейс имеет систему шаблонов и полностью на Русском языке.

RAID

К сожалению по поводу аппаратного Raid сказать ничего не могу. Думаю реализовать работу некоторых raid контроллеров на FreeNAS будет довольно проблематично.
Зато программный Raid работает на ура. Я конечно понимаю что программный raid использовать не очень правильно и не безопасно, но всё таки сам использую на backup сервере его второй год.

Как я уже говорил выше, FreeNAS поддерживает программный RAID (* JBOD, RAID 0, RAID 1, RAID 5, RAID 0/1/5 (Vinum)).

Основные сетевые службы.

FreeNAS имеет в своём составе кучу сетевых служб, которые можно отключать и включать по вашему усмотрению. Каждая служба имеет свой блок управления в Web интерфейсе.

Samba имеет целый блок управления в Web интерфейсе. Всё довольно понятно и просто.

при желании можно включить в самба конфиг свои гибкие настройки.

С недавних пор появился в составе FreeNAS встроенный фаервол. Это обычный блокиратор без специфических настроек, который целенаправленно защищает файловый сервер

Интеграция с ActiveDirectory

FreeNAS можно без проблем включить в состав ActiveDirectory или иного LDAP сервера. Делается это конечно же с помощью winbind.

Моё мнение и опыт:

Собственно я всегда был за то, что бы подобные задачи как файловый сервер или web сервер или torrent сервер собирались в ручную на стандартных дистрибутивах linux или freeBSD. Но попробовав FreeNAS стал более лояльно относиться к данным готовым проектам.

FreeNAS безусловно отличный проект. Он из серии «поставил и забыл». Файловый сервер будет работать как часы, в прочем на мой взгляд так происходит на всех BSD платформах :))

Данный проект использую у себя на работе. Поставил его на backup сервер с 4 — мя жёсткими дисками по 500Gb собранные в программный RAID5 (1,4 Tb).
Сервер работает у нас уже 2-й год и особых нареканий нет. Переодически обновляю версию FreeNAS.

Как на практике ведёт себя nas4free с битой памятью

Сегодня удалось позитивно завершить неочевидную дрянь с NAS у камрада sedmovetz
Это на выходе мы знаем, что дело в памяти, а начиналось так: (Прим исходная дискуссия в комментах здесь)

Анамнез
Из новых комплектующих был собран НАС: корпус — Fractal Design Node 304; MB — Gigabyte GA-H97N-WIFI; процессор — Celeron G1840 2.80GHz; RAM — Corsair DIMM DDR3 4096MBx2 1333MHz; БП — Hiper M/V 600W; ОС — SSD Sandisk X210 128GB; DATA — 3x4TB WD4000FYYZ RE).
Следуя руководству уважаемого хозяина блога на gpt-разделах на половинках трех дисков был собран raidz2 pool, на котором были созданы три датасета: один для хранения фотоархива, другой — для видеоархива, и еще один для текущего обмена файлами и их временного хранения в домашней локалке.
Пол года НАС изредка использовался только как расшаренная сетевая папка и нареканий не вызывал. Недели две назад была предпринята попытка сбросить на него весь домашний фото и видеоархив, для чего была выбрана программа GoodSync.
После запуска GoodSync в режиме одностороннего бэкапа через некоторое время стали появляться ошибки сетевого доступа, а потом и вовсе процесс остановился. Доступ к НАС через сетевой интерфейс сохранялся (можно было посмотреть логи, состояния и пр.), в проводнике НАС был виден, и даже можно было увидеть названия датасетов, но внутрь них он не пускал. Вэбинтерфейс тоже работал только до попытки запроса к нему, после чего наглухо зависал. Помогала только жесткая перезагрузка НАСа кнопкой.
После перезагрузки НАС опять работал как ни в чем не бывало. До очередного запуска GoodSync, после которого ситуация повторялась.

Диагностика
Изучаем — в системном логе проблем не видно, смарты у дисков приличные. Что, отмечу, кроме дисков резко снижает вероятность нехватки питания от БП. В этом случае диски отваливаются с руганью, примеры в блоге обсуждались.

Советую камраду прогнать длинный смарт тест — всё ОК, что не снимает, конечно, подозрение с дисков окончательно. Но сильно его уменьшает.

А вот zpool status выглядит неприятно

  pool: NASEL
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 4.50M in 16h46m with 0 errors on Wed Aug 19 16:09:59 2015
config:

	NAME                    STATE     READ WRITE CKSUM
	NASEL                   ONLINE       0     0     0
	  raidz2-0              ONLINE       0     0     0
	    gpt/disk1WD89922p1  ONLINE       0     0     2
	    gpt/disk1WD89922p2  ONLINE       0     0     2
	    gpt/disk2WD84775p1  ONLINE       0     0     4
	    gpt/disk2WD84775p2  ONLINE       0     0     2
	    gpt/disk3WD2CPT4p1  ONLINE       0     0     3
	    gpt/disk3WD2CPT4p2  ONLINE       0     0     1

errors: No known data errors

Видны ошибки чексумм, разбросанные +- равномерно по всем дискам. Пул пока держит инфу — но что-то её корёжит. Естественное подозрение — на память, прошу погонять мемтест, несмотря на уверенность камрада в качестве свежекупленной памяти.

Результат:

Вот оно! Спасибо вам, дорогой товарищ!
Memtest выдал более тысячи ошибок памяти (кто бы мог подумать!). «Старые» планки были с позором сданы в сервис на посмертную диагностику, а НАС получил свеженькие после теперь уже предварительного прогона Memtest-ом (0 ошибок). Вот уже двое суток полет нормальный.

Эпикриз
Странные глюки объяснялись битой памятью. Хочу акцентировать, что несмотря на тысячи(!) ошибок в мемтесте и эксплуатации на протяжении полугода, ZFS не допустил искажения информации в массиве. Это соответсвует моим более ранним мыслям о необходимости ECC памяти дома. Она, конечно, много лучше. Но первую волну ошибок ZFS удаётся отфильтровать. Да, надеяться, что именно вам повезёт и всё отфильтрует — не стоит. Но если следить за статусом пула, есть хорошие шансы инфу сохранить.

А вот в production ECC память обязательна. Особенно, если это не третий бекап, а интенсивная по памяти загрузка, как пример — базы данных.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *