Рубрики
Наследие

Конфигурация socks-сервера dante с авторизацей

Установка dante не представляет собой ничего сложного, а вот конфигурация выглядит на первый взгляд очень непростой.
На самом деле ничего сложного нет, вот пример конфига с авторизацией:

logoutput: /var/log/socks.log
internal: eth0:1 port = 1080
external: eth0:2
method: username none
clientmethod: none
compatibility: reuseaddr
connecttimeout: 30
client pass {
from: 0.0.0.0/0 port 1-65535 to: 0.0.0.0/0
}

pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
protocol: tcp udp
log: connect error
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

Рубрики
Старье

Защищаем сервер от взлома через upload

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

Немного теории о том, как это происходит и как от этого защититься.

Злоумышленник размещает на сервере свои скрипты, которые получают список домашних директорий пользователей и начинают поиск директорий для upload, где разрешена запись всем.
Найдя такие директории, они закачивают туда свои скрипты и через них производят попытку взлома.

Защита от подобных действий так же проста, как и сама уязвимость, — достаточно запретить запуск скриптов в таких директориях. Однако пользователи этого не делают.

Для решения этой проблемы нами был разработан и протестирован на FreeBSD следующий скрипт, который рекурсивно обходит пользовательские директории и создает .htaccess файл, отключающий исправление скриптов:


#!/bin/sh
HOME=/home
NOBODY=nobody

htaccess () {
cat << EOF >> "$j/.htaccess"

RemoveType php
Options -ExecCGI -Indexes
EOF
}

fixupload () {
if [ -e "$j/.htaccess" ]; then
if [ -z "`grep RemoveType "$j/.htaccess"`" ]; then
htaccess
fi
else
htaccess
chown $i:$i "$j/.htaccess"
fi
}

cd $HOME
for i in *; do
if [ -d $i/public_html ]; then
# Fix 777 upload
for j in `find $i/public_html -type d -perm 777`; do
fixupload
done
# Fix 775 nobody upload
for j in `find $i/public_html -type d -perm 775 -group $NOBODY`; do
fixupload
done
# Fix 755 nobody upload
for j in `find $i/public_html -type d -perm 775 -user $NOBODY`; do
fixupload
done
fi
done

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

Рубрики
Наследие

squid — обеспечим себе анонимность.

Установка и конфигурация прокси-сервера squid с авторизацией по паролю и привязкой исходящего IP к каждому из логинов.

Вначале установим squid любым образом — из пакетов, портов или исходных кодов. Затем генерируем файл паролей с помощью htpasswd. Для примера, создадим 5 логинов one, two, …, five.

Пример конфига squid.conf:


hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
auth_param basic program /путь/к/ncsa_auth /путь/к/файлу/с/паролями
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
acl auth1 proxy_auth one
acl auth2 proxy_auth two
acl auth3 proxy_auth three
acl auth4 proxy_auth four
acl auth5 proxy_auth five
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl password proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443 563
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535
acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl CONNECT method CONNECT
acl AUTH proxy_auth_regex -i $
acl TRUST src 127.0.0.1-127.0.0.1/255.255.255.255
no_cache deny QUERY all manager localhost to_localhost SSL_ports Safe_ports CONNECT AUTH TRUST auth1 auth2 auth3 auth4 auth5
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow AUTH
http_access allow password
http_access deny all
http_access allow TRUST
http_access deny all !auth1 !auth2 !auth3 !auth4 !auth5
http_reply_access allow all
icp_access allow all
tcp_outgoing_address первыйIP auth1
tcp_outgoing_address второйIP auth2
tcp_outgoing_address третийIP auth3
tcp_outgoing_address четвертыйIP auth4
tcp_outgoing_address пятыйIP auth5

Далее инициализируем хранилище: squid -z и стартуем squid.

Рубрики
Наследие

Конфиденциальность информации — нюансы защиты

Предположим, Вы создали некоторое ПО, которое обеспечивает платный онлайновый сервис, и Вы опасаетесь, что это ПО может быть похищено хостером.
Или иначе — у Вас есть архив собственных фоторабот, который Вы продаете.
Возможно, у Вас на сервере просто сетевой диск с ценной базой данных, за которую конкуренты и мать родную продадут.

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

Классифицируем уровни возможных рисков:

  1. Локальный несанкционированный доступ к комплектующим сервера.
  2. Локальный несанкционированный доступ к серверу.
  3. Удаленный несанкционированный доступ к серверу авторизированных пользователей.
  4. Удаленный несанкционированный доступ к серверу неавторизированных пользователей.

Под локальным доступом к комплектующим сервера мы подразумеваем возможности физического похищения информации. Например, просто унести дисковый накопитель; возможность внедрить аппаратно-программный комплекс, направленный на получение конфиденциальной информации и прочее.
Это самый простой и эффективный способ похитить информацию. Следовательно, необходимо предусмотреть возможность активных или пассивных мер защиты. Например, срабатывание устройства, генерирующего электромагнитный импульс при вскрытии корпуса — это активная мера защиты. А вот специализированный контроллер диска, который не даст доступа к носителю без ввода пароля, или просто зашифрованный диск — пассивная.

Под локальным доступом к серверу мы подразумеваем физический доступ к серверу без вскрытия корпуса. Обладая физическим доступом, можно перезагрузить сервер, попытаться зайти в служебный режим работы, загрузиться с внешнего носителя, снять пароль в BIOS, поставить black box в разрыв между сетевой картой и витой парой и т.п.
Необходимо предусмотреть возможность входа сотрудников провайдера, однако в то же время необходимо исключить доступ к конфиденциальной информации.
Полностью блокировать загрузку с внешних носителей и локальный вход в служебном режиме работы невозможно. Следовательно, необходимо разделить аппаратно или программно сервер на публичную часть и приватную. Хорошим примером служит зашифрованный диск, представляющий собой обычный файл. Для того, чтобы его примонтировать, необходимо ввести пароль, причем это можно сделать удаленно. Естественно, что целостность публичной части должна быть под контролем. Как минимум, установка tripwire обязательна.

Удаленный доступ к системе авторизированными пользователями наиболее опасен, так как они имеют доступ к конфиденциальным данным и вопрос защиты тут зависит в большей степени от человеческого фактора, чем от технических средств защиты. Для защиты же от кражи пароля у авторизированного пользователя существует достаточно много методов, самый простой из которых — это изоляция пользователя в своей среде (chroot;jail) с эмуляцией прав суперпользователя в ней. Злоумышленник, похитивший пароли, сразу выдаст себя попытками скачать эксплоиты, компиляцией и прочими действиями.

Удаленный доступ к системе неавторизированными пользователями должен быть предотвращен с неменьшим старанием, чем остальные. Классическим примером кражи файла служит взлом через upload. Приведем пример.
Предположим, что на веб-сервере есть директория, куда пользователи могут сохранять файлы. Злоумышленник загружает туда специальный скрипт php, после чего обращается к нему с веб-сервера и получает полный доступ к содержимому сайта. Он может скачать все файлы, узнать доступ к базе данных из незашифрованного конфигурационного файла и пр.

Отметим, что защита должна быть комплексной и разрабатываться специалистами. И естественно, что это достаточно дорогое удовольствие.

Рубрики
Старье

Исправляем недостатки конфигурации Apache в Plesk.

Разработчики Plesk помещают каждый конфигурационный файл пользователя в отдельную директорию, что при достаточно большом числе пользователей способно серьезно замедлить работу веб-сервера Apache, так как открытие множества медленных файлов требует значительно больше ресурсов, чем открытие одного большого файла.

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

Все что нужно — изменить конфиг апача так, чтобы он включал в себя файл httpd.include.conf вместо httpd.include.


PLESK=/etc/httpd/conf/httpd.include
WORK=/etc/httpd/conf/httpd.include.conf

grep -v Include $PLESK > $WORK

for i in `grep Include $PLESK`; do
[ -e $i ] && cat $i >> $WORK
done