sudo iptables-restore < /etc/iptables.rules

fail2ban может защитить почти любой из ваших сервисов от брутфорса. Подбора пароля то есть.
Информации в целом в инете про него много, но не упомянуть fail2ban в рамках нового цикла статей «Безопасность в Debian» просто нельзя.

Итак. Каждый администратор сервера на Debian должен выполнить команду:
debian:~# aptitude install fail2ban

После установки и запуска fail2ban мы получаем намного более защищенный ssh. После 3х попыток неправильного ввода пароля с одного ip адреса — этому ip адресу будет закрыт 22й порт на сервере. Но это всё по умолчанию.
Сейчас же мы будем настраивать fail2ban.
Основная часть настроек хранится в конфигурационном файле /etc/fail2ban/jail.conf
Рассмотрим некоторые директивы:
ignoreip = 127.0.0.1 # указываем, на какие ip адреса, маски или хостнеймы не распространяется действие fail2ban
bantime = 600 # указываем сколько действует бан в секундах. Я указываю либо огромное число, либо -1 — что значит «навечно».
maxretry = 3 # через сколько неправильных попыток ввода пароля банить гада
destemail = root@localhost # на какой адрес слать уведомления о банах. Можно поменять, но нужно будет написать правила для писем.
banaction = iptables-multiport # через что банить. Если у вас нет shorewall, то менять это значение я не рекомендую.
mta = sendmail # через что отправлять письма админу о банах. Exim/sendmail/etc. Пишем тут тот MTA, который стоит у вас на сервере.

Чуть ниже следуют секции конфига, которые отвечают за блокировку тех, кто брутфорсит что-либо. Конечно же, здесь есть почти все сервисы, которые можно брутфорсить) списочек будет чуть ниже. Не изменяйте эти секции ни в коем случае! Те jails, которые вам необходимо включить — дописывайте в файл /etc/fail2ban/jail.local в форме:
[jail_name]
enabled = true
Например:
[apache]
enabled = true

Рассмотрим параметры секции [ssh] (который отвечает за бан тех, кто пытается сбрутить ssh-аккаунт).
enabled = true # включаем сервис.
port = ssh # указываем на каком порту/портах висит сервис. Некоторые умеют определяться автоматически по имени сервиса — вот как ssh
filter = sshd # указываем фильтр, по которому парсятся логи. Не следует менять. Вообще же можно написать свои фильтры и использовать их для любого вашего сервиса. Именно этот порт в нашем случае будет блокироваться для брутфорсера через iptables.
logpath = /var/log/auth.log # какой лог парсить. Нужно на тот случай, если вы изменяли дефолтный путь до лога сервиса
maxretry = 6 # количество попыток, после которых человека или бота банят.

Какие есть шаблоны по умолчанию: ssh, pam-generic, xinetd-fail, ssh-ddos, apache (неверные авторизации в каталогах, защищенных через .htpasswd), apache-noscript, apache-overflows, vsftpd, proftpd, wuftpd, postfix, couriersmtp, courierauth, sasl, named-refused-udp, named-refused-tcp.

Не забываем перезапускать fail2ban после изменения конфигурации командой /etc/init.d/fail2ban restart

Этого вполне достаточно, чтобы окопаться от брутфорса по самое «нехочу». Если вы поняли систему работы fail2ban — вы легко сможете написать скрипт, который будет защищать вас от http-ddos, udp-ddos, исходящего спама и много другого. Правила писать очень просто, нужно лишь указать правильный regexp в файле /etc/fail2ban/filter.d/имя_фильтра.conf
Тем более, что там есть примеры.
Только не дописывайте свои сервисы c опций enabled = true в jail.conf. Пишите шаблон в jail.conf, а включайте свой jail уже в jail.local.

https://debian.pro/72

Извиняюсь, что давно ничего не писал. Работа и эксперименты с виртуализацией отнимают очень много времени. Пока что ничего нового и особенного не откопал, лишь сделал некоторые выводы, которые напишу в финальной статье про KVM.
А сейчас, пожалуй, напишу как быстро настроить FTP сервер на Debian/Ubuntu. Способ действительно быстрый и не требует особого ковыряния в конфигах и базах.
За основу, как можно догадаться из заголовка, я беру vsftpd. Почему? Ну во-первых его название расшифровывается как very secure ftp daemon. Во-вторых именно его можно установить и настроить максимально быстро.
Что мы получим в итоге:
1) авторизоваться нужно (можно) будет по системным пользователям. То есть список пользователей и их домашние директории будут браться из /etc/passwd. Root в параде не участвует.
2) пользователи не могут выйти выше домашнего каталога в структуре ФС. То есть мы организуем ftp-chroot. Редки случаи, когда он помешает конечным пользователям, а вот безопасность он повышает ощутимо. Рут же может пользоваться sshfs, чтобы работать со всей ФС сразу.
3) Анонимы отключены. В принципе включаются 3мя строчками в конфиге, но в рамках данной статьи они не требуются.
Итак. Проверяем, что у нас не установлено никаких ftpd, если установлены — удаляем. Они нам не понадобятся.
Установим vsftpd:
root@Debian:~# aptitude install vsftpd
Скопируем стандартный конфиг на всякий случай (необязательно):
root@Debian:~# cp /etc/vsftpd.conf /etc/vsftpd.conf.default
Почистим стандартный конфиг от флуда разработчиков =) (вообще там интересно, советую почитать как-нибудь. )
root@Debian:~# echo » » > /etc/vsftpd.conf
И начнём писать новый. Собственно, чтобы следовать заголовку «Very fast way», предлагаю взять мой готовый конфиг.
Открываем /etc/vsftpd.conf нашим любимым редактором, например:
root@Debian:~# nano /etc/vsftpd.conf
и вставим в файл следующее:
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
ftpd_banner=Welcome to debian.pro ftpd!
#banned_email_file=/etc/vsftpd.banned_emails
chroot_local_user=YES
#chroot_list_enable=YES
#chroot_list_file=/etc/vsftpd.chroot_list
ls_recurse_enable=YES
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

В файл /etc/vsftpd.chroot_list мы можем записать пользователей, на которых не распространяется правило chroot. Для того, чтобы эта функция заработала — расскоментируйте строку #chroot_list_file=/etc/vsftpd.chroot_list в vsftpd.conf. Ну и не забудьте создать сам файл:
root@Debian:~# touch /etc/vsftpd.chroot_list
Перезагрузим vsftpd:
root@Debian:~# /etc/init.d/vsftpd restart

Ну и проверим наш ftpd. Много флуда, дальше читать совсем не обязательно) статья, собственно, закончена:
Попробуем зайти под анонимом:

root@support-desktop:~# ftp localhost
Connected to localhost.
220 Welcome to debian.pro ftpd!
Name (localhost:inky): anonymous
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

Попробуем зайти под локальным пользователем, немного погулять по хомяку и попробовать выйти из chroot:
root@support-desktop:~# ftp localhost
Connected to localhost.
220 Welcome to debian.pro ftpd!
Name (localhost:inky): inky
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rwxrwxrwx 1 1001 1001 316 Feb 26 17:27 diff.sh
-rwxr-xr-x 1 1001 1001 2281 Feb 26 22:35 diff2.sh
-rw-r—r— 1 1001 1001 1185 Feb 26 20:26 diff2.sh?
-rw-r—r— 1 1001 1001 357 Feb 07 14:47 examples.desktop
drwxr-xr-x 5 1001 1001 4096 Feb 23 05:06 iMacros
-rwxr-xr-x 1 1001 1001 57 Jun 09 15:53 script100
drwxr-xr-x 3 1001 1001 4096 Jul 25 13:10 scripts
-rw-r—r— 1 0 0 30888 Dec 13 2006 thunder.au
-rw-r—r— 1 1001 1001 22626 Feb 26 20:19 thunder2
-rw-r—r— 1 1001 1001 1642496 Feb 26 20:11 thunder2.au
drwxr-xr-x 2 1001 1001 4096 Feb 26 17:27 tmp
-rwxr-xr-x 1 1001 1001 7422 Jun 09 15:43 urgent
226 Directory send OK.
ftp> cd iMacros
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x 2 1001 1001 4096 Feb 22 01:43 Datasources
drwxr-xr-x 5 1001 1001 4096 Apr 11 16:41 Downloads
drwxr-xr-x 2 1001 1001 4096 Feb 22 01:46 Macros
-rwxr-xr-x 1 1001 1001 188 Feb 27 00:19 iMacros.log
226 Directory send OK.
ftp> cd ../
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rwxrwxrwx 1 1001 1001 316 Feb 26 17:27 diff.sh
-rwxr-xr-x 1 1001 1001 2281 Feb 26 22:35 diff2.sh
-rw-r—r— 1 1001 1001 1185 Feb 26 20:26 diff2.sh?
-rw-r—r— 1 1001 1001 357 Feb 07 14:47 examples.desktop
drwxr-xr-x 5 1001 1001 4096 Feb 23 05:06 iMacros
-rwxr-xr-x 1 1001 1001 57 Jun 09 15:53 script100
drwxr-xr-x 3 1001 1001 4096 Jul 25 13:10 scripts
-rw-r—r— 1 0 0 30888 Dec 13 2006 thunder.au
-rw-r—r— 1 1001 1001 22626 Feb 26 20:19 thunder2
-rw-r—r— 1 1001 1001 1642496 Feb 26 20:11 thunder2.au
drwxr-xr-x 2 1001 1001 4096 Feb 26 17:27 tmp
-rwxr-xr-x 1 1001 1001 7422 Jun 09 15:43 urgent
226 Directory send OK.
ftp> cd ../
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rwxrwxrwx 1 1001 1001 316 Feb 26 17:27 diff.sh
-rwxr-xr-x 1 1001 1001 2281 Feb 26 22:35 diff2.sh
-rw-r—r— 1 1001 1001 1185 Feb 26 20:26 diff2.sh?
-rw-r—r— 1 1001 1001 357 Feb 07 14:47 examples.desktop
drwxr-xr-x 5 1001 1001 4096 Feb 23 05:06 iMacros
-rwxr-xr-x 1 1001 1001 57 Jun 09 15:53 script100
drwxr-xr-x 3 1001 1001 4096 Jul 25 13:10 scripts
-rw-r—r— 1 0 0 30888 Dec 13 2006 thunder.au
-rw-r—r— 1 1001 1001 22626 Feb 26 20:19 thunder2
-rw-r—r— 1 1001 1001 1642496 Feb 26 20:11 thunder2.au
drwxr-xr-x 2 1001 1001 4096 Feb 26 17:27 tmp
-rwxr-xr-x 1 1001 1001 7422 Jun 09 15:43 urgent
226 Directory send OK.

И попробуем зайти под рутом:
root@support-desktop:~# ftp localhost
Connected to localhost.
220 Welcome to debian.pro ftpd!
Name (localhost:inky): root
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

Всё работает. Спасибо за внимание, удачного использования =)

https://debian.pro/87

Лето. Надоело сидеть за компом, решил отдохнуть и гулять-кататься побольше. Спам от мониторилок на андроид-телефон валится исправно. Хард клава любимого Зевсика с завтрашнего дня будет всегда со мной. (тьфу-тьфу-тьфу). Грех в такой ситуации не воспользоваться ssh-клиентом на телефоне с клавиатурой и 3g для управления VDSками. А ещё большим грехом было бы не рассказать всем вкратце, как же это делать.

Конечно же, вы настраивали KVM по мануалу /16 на этом сайте. И конечно же, у вас установлен libvirtd. Его консольным фронт-эндом является как раз таки virsh.
Итак. Virsh у нас есть. Если нет — смотрим статью /16.
Для проверки просто введем в консоли virsh
Теперь у вас открыт новый шелл:
virsh #
Сразу оговорюсь, что все последующие команды можно вводить в консоли virsh либо в обычной консоли с приставкой virsh.
То есть:
virsh # command vds
и
Debian:~# virsh command vds
эквивалентны. Но я рекоммендую использовать шелл virsh, так как там работает автодополнение команд virsh’a.
В дальнейшем в статье я не буду использовать приставки к командам. Знайте, что каждую из нижеперечисленных команд нужно писать с приставкой virsh либо в шелле virsh.
Так же условимся, что vdsX — это название VDSки, над которой вы желаете совершить действие.
Приступим. Поуправляем «питанием» виртуальных машин:
destroy vdsX — «выдергиваем кабель питания виртуалки»
reboot vdsX — передаст ядру VDSки команду reboot, как если бы она была написана из консоли.
shutdown vdsX — корректно выключаем VDS. Если не выключается — делаем destroy.
start vdsX — запускаем VDS
save vdsX file-name — сохранит состояние виртуалки в файл, выключит её и освободит RAM. Фактически — аналог команды hibernate. Только можно много состояний оперативки сохранять =) удобно для тестов. Учтите, что имя файла должно быть уникальным всегда (или его перезапишет, даже дампом другой виртуалки)
restore file-name — вернет виртуалку из сна. Саму виртуалку указывать не нужно, эта информация берется из файла. А жаль, на самом деле. Можно было бы создавать кучи одинаковых виртуалок и потом их поочередно грузить из файла и издеваться.
suspend vdsX — ещё один hibernate, но память, зарезервированная виртуалкой не освобождается. Надежнее, чем save/restore.
resume vdsX — возвращает vds из состояние, в которое мы её погрузили командой suspend

Просмотрим некоторую информацию о VDSах:
nodeinfo — выдаст нам информацию о вашем сервере. Бесполезную, но малоли)
list — выведет список всех виртуалок и их состояние — running, halted, suspended и т.д. Полезно для включения в отчёты, кстати.
dominfo vdsX — выведет информацию о виртуалке. Есть и полезная, например, там можно посмотреть, сколько времени CPU скушала виртуалка (да да, будем на это основывать облака в ближайшем будущем =)) )
domblkstat vdsX device — должно выводить статистику по блочному устройству виртуалки. Пока не разобрался как работает. Буду рад подсказке. Точнее не знаю, что вписать вместо device.
domifstat vdsX vnetY — позволяет просмотреть информацию по сетевому интерфейсу виртуалки. vnetY должен использоваться именно виртуалкой vdsX, чтобы команда дала корректный вывод. Команда ценна тем, что позволяет проверить — не дропаются ли сетевые пакеты виртуалки.
ttyconsole vdsX — укажет нам, какой /dev/pts используется vdsом. Полезно, если знаете, что с pts можно сделать удалённо.
vncdisplay vdsX — укажет нам IP и порт виртуального IP-KVM… а точнее VNC сервера для VDSки. В virt-manager можно добавить новые.

Изменим кое-какие лимиты виртуалок:
setmem vdsX summ — изменяет лимит памяти виртуалки. summ указывается в килобайтах. Работает без ребута. Память по этому лимиту сразу помечается хостом как используемая.
setmaxmem vdsX summ — изменяет верхнюю планку памяти для виртуалки. summ — в килобайтах. Память по этому лимиту виртуалка получит, только если есть свободная память на хосте. По этому лимиту память помечается как используемая хостом, только если она действительно используется виртуалкой. (вообще setmaxmem для KVM не советую использовать, только в облаках если)
setvcpus vdsX count — устанавливает количество count виртуальных ядер для VDS. Можно использовать только для выключенной виртуалки. Сумму count для всех VDS не делаем больше суммы ядер на хосте, а лучше оставляем одно про запас, если не для своих нужд используем весь сервер со всеми виртуалками.

И на закуску:
console vdsX — должно подключить нас к tty1 виртуалки. не работает частенько (
autostart —disable vdsX — отключает автостарт виртуалки при старте хоста. Если вы используете мануалы — заюзайте опцию для всех VDS — всё равно без br1/br2 (которые я рекоммендую не создавать при старте сервера, а создавать скриптами позже) — они не загрузятся.
autostart vdsX — включает автостарт виртуалки.

Остальные команды стоит посмотреть в man virsh, но вряд ли они вам понадобятся. Там ещё есть управление виртуальными устройствами VDSов, но это лучше делать через virt-manager. Ну и некоторые команды в моем случае заменены скриптами virt-install.

P.S. — почаще отдыхайте. Сегодня стал ощущать, что переутомлён… неприятно. А всего то 19 лет только( Зато я всё ближе и ближе к финалу stand-alone экспериментов )
28.07.2010 byinkvizitor68sl|Администрирование Метки: debian, kvm, ssh, virsh

По мотивам последних событий с моей работы решил написать этот пост, ибо ничего похожего в рунете к сожалению не обнаружил, а очень жаль, ибо перетаскивать виртуалки с VirtualBox и VMWare в благородный KVM все таки приходится. Один из популярных способов сводиться в сливу образа диска в KVM, а затем загрузка с установочного диска и востановление системы (а фактически новая установка поверх старых настроек). Лично меня подобная схема не устроила, потому что образ присланной виртуалки не содержал установочного диска с которого его можно было бы восстановить, а искать похожий образ муторно. Итак.

Мы имеем следующий набор. Виртуалка на VirtualBox или VMWare, гостевая система Windows (с linux такой свистопляски нет), и сервер с KVM на котором и будем размещать нашу виртуалку. В моем случае это сервер KVM который работает в связке с LVM, но я постараюсь затронуть и вариант когда KVM работает с файловыми образами диска.

Приступаем.

1. Готовим систему к переносу.

Не секрет, что и VirtualBox и VMWare для нормальной работы ставят в систему свои собственные дрова и утилиты. Так вот первое что нужно сделать – это избавиться от них. Удаляем и VirtualBox Guest Tools и VMWare tools...

Следующим шагом – необходимо будет отвязать нашу Windows от железа на котором она была установлена. К счастью для этого есть официальный мануал (http://support.microsoft.com/kb/314082/en-us). Мотаем его в самый низ, и создаем файлик Mergeide.reg содержащий код из мануала.

После того как файлик был создан и сохранен, запускаем его и вносим изменения в реестр. Теперь осталось проверить что все необходимые файлы для запуска в KVM есть, для этого идем в C:\Windows\system32\drivers\ и ищем там файлы:

atapi.sys
intelide.sys
pciide.sys
pciidex.sys

Если какого либо из этих файликов нет – то заходим внутрь архива C:\Windows\Driver Cache\i386\Driver.cab и копируем недостающие файлики оттуда.
На этом мы закончили приготовления системы, и можем ее без проблем выключить.

2. Готовим образ диска

Тут есть варианты. Все зависит от того какая у вас система виртуализации щас, и где KVM будет хранить свои образы дисков.

Так или иначе, вся схема создания образа делиться на две части, первая – это подготовка SGF (Single Growable File), и вторая – это перенос SGF в KVM.

VMWare

Нам необходимо сконвертировать vmdk файл нашей виртуалки в формат SGF. Этот формат фактически сырой RAW нашего диска, и имеет расширение VMDK. Для VMWare он делается так

“C:\Program Files\VMware\VMware Server\vmware-vdiskmanager” -r windows.vmdk -t 0 windows-sgf.vmdk

Если в этом месте возникают какие либо грабли, то попробуйте параметр “-t 0” заменить на “-t 2”. Хотя в большинстве случаев все должно пройти без проблем.

VirtualBox

Для того что бы сделать образ SGF в VBox’e необходимо в меню Файл -> Менеджер виртуальных дисков, выбрать диск интересующей нас виртуалки и нажать “Копировать”. В качестве источника оставляйте выбранный диск, Тип виртуального диска выбираем VMDK, Дополнительные атрибуты – Фиксированный виртуальный диск.

После того как копирование завершиться вы увидете два образа, с одинаковым именем, но второй будет иметь после имени “-flat”, например “windows.vmdk” и “windows-flat.vmdk”. Как раз второй образ с flat и будет нашим SGF диском.

3. Проверяем образ

Для того что бы избежать ошибок можно проверить полученный образ. Для этого в linux есть команда file. Вывод нормального образа должен иметь примерно следующий вид

# file windows-sgf.vmdk
windows-sgf.vmdk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845,
16563015 sectors, code offset 0x48

Если вывод говорит о том что это файл образа VMWare – значит мы не получили нужного нам формата образа.

4. Устанавливаем образ в KVM

Тут все зависит от настроек KVM. Используете ли вы файлы, либо используете LVM. Оба варианта приведены ниже

LVM

Тут особой писать нечего. dd он и в Африке dd.

# dd if=/path/to/windows-sgf.vmdk of=/dev/volgroup/partname

После этого можно кормить KVM этот раздел LVM

KVM File (qcom2)

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

qemu-img convert -f vmdk windows-sgf.vmdk -O qcow2 windows.qcow2

Я думаю что объяснять не нужно что меняя параметр “-О” можно выбрать другой формат хранения. После чего данный диск можно кормить KVM.

Стоит так же отметить, что qemu-img позволяет конвертировать не только SGF но и простые vmdk, хотя с менее предсказуемым результатом. Поэтому лучше конвертировать. Если при конвертации выпадает ошибка, попробуйте не использовать ключ “-f vmdk”, и дайте утилите самостоятельно определить формат образа. Говорят что помогает.

5. Первый запуск.

Я не буду расписывать как настраивать KVM, вы уже большие и сами знаете как это сделать, отмечу только тот факт, что Windows ни под каким соусом не поддерживает virtio, поэтому даже не пытайтесь.

После первого запуска система должна определить все новое железо, и установить на все драйвера. Тут будте внимательны. У меня был случай когда Windows не смогла найти драйвера на ACPI процессора, и мне пришлось его отключить в диспетчере устройств, что бы система не падала в BSOD. После установки всех устройств, систему лучше перезагрузить.

6. P2V

С виртуалками разобрались, но как быть с реальными машинами? Честно говоря не пробовал, но есть мнение что данный способ годиться и для реальных машин.

Подготовка машины происходит тем же способом, после выключения можно загрузиться с какого либо Linux LiveCD, и запустить команду на копирование всего физического диска (именно всегодиска , а не раздела) в заранее созданный LVM, или файл.

# dd if=/dev/sda | ssh user@kvm-host “dd of=/path/to/file.vmdk”

И конечно же вы догадались, что вместо file.vmdk, образ можно заливать сразу же в LVM. Не забудьте проверить md5 суммы у исходного и конечного образов.

Удачи в экспериментах.

https://debian.pro/515

Иногда возникает необходимость запускать графические приложения на сервере. Поднимать иксы из-за этого глупо. Дырка, ресурсы, иксы будут работать медленно на всяких Cyrus на 8 мб. А может и иксы не получится поднять вообще (ну нет нужных устройств в /dev, что поделаешь). С OpenVZ такое часто бывает.
У нас остается вариант использовать ssh -X. Но проброс иксов (кстати, в этом случае не обязательно на сервере иметь запущенным X-сервер) может работать медленно и у нас не получится запустить приложение в фоне (если уж быть совсем занудой, то получится, но с матами и этому будет посвящен отдельный трактат). В общем для запуска браузера на быстром коннекте подойдет, но не более.
Сейчас кто-то задаст вопрос «на кой черт оно тебе надо?». Поясню. Во-первых браузер доступный отовсюду с сохраненными паролями (таскать их на флешке и втыкать в вендовозки, которые могут копировать содержимое — опасно). VPN поднять получится далеко не на всех чужих ПК. Во-вторых — браузер, за сохранность которого мы можем не бояться в открытых сетях. Понятно, что это не для видео, а для банковских интерфейсов или webmoney/ЯД. В-третьих может придти заказчик и сказать «надо и всё тут». Ну а про случаи, когда нужна запущенная в фоне утилита с графической мордой я молчу. Мало ли что там быдлокодеры пишут =) Я же использовал данный способ для запуска Firefox с запущенными iMacros-скриптами на домашнем сервере, чтобы зря не гонять шумный десктоп (да-да, когда то у меня был шумный десктоп. Это сейчас водянка и огромные тихие кулеры на HDD).
Ладно, определились с целями (пусть будет джастфофан). Теперь определимся с реализацией.
У линуксячьего VNC-сервера есть режим эмуляции X-среды. Да, дергаются все библиотеки, но фактического запуска иксов не происходит. Экономятся ресурсы, не нужна видеокарта. А самое главное, что можно спокойно отключиться и с сессией ничего не случится.
Кто-то скажет про то, что медленно или некрасиво. Медленно решается туннелированием через SSH со сжатием. Некрасиво — нам ехать, а не шашечки.
Все действия я буду воспроизводить на OpenVZшной машинке, чтобы уж наверняка.
Поставим нужные пакеты:
root@remote-server:~# aptitude install xvnc4server
Оно спросит кучу зависимостей, что логично. Придется их ставить.
Ещё нам понадобится простенький, но функциональный оконный менеджер. В подобных случаях я использую обычно fluxbox (да и на десктопе его использовал очень долгое время). В нем есть все необходимое. Ещё я запускаю gnome-panel (уж очень удобные апплеты и менюшки), но это опционально.
Поставим fluxbox:
root@remote-server:~# aptitude install fluxbox
Теперь становимся пользователем и всё дальше выполняем от имени пользователя. В данном примере я использую пользователя inky
root@remote-server:~# su inky
Для начала запаролим VNC-сервер:
inky@remote-server:~$ vnc4passwd
Теперь впишем в конфиг vnc-сервера весь софт, который нужно запускать при старте vnc-демона.
inky@remote-server:~$ editor /home/inky/.vnc/xstartup
У меня файл выглядит так:
#/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
#x-window-manager &
fluxbox &
AeroFS &
gnome-panel &

Главное тут то, что нам нужно заменить x-window-manager & на fluxbox & или запуск любого другого оконного менеджера.
Всё готово для запуска. Собственно, запустим:
inky@remote-server:~$ vnc4server -geometry 1350x600
-geometry 1350×600 — разрешение виртуального экрана. Подберите себе сами удобное.
Внимательно ищем строчку вот такого рода:
New ‘remote-server:1 (inky)’ desktop is remote-server:1
Если :1 — то vnc слушает порт 5901, если :2 — то 5902 и так далее. Данная информация будет полезна анальным рабам стивобалмера, и тем, кто дочитает статью до конца (там будет про безопасность). Обычный же VNC клиент в Linux сможет прицепиться к адресу remote-server:1
Чтобы остановить vnc-server правильно используем такую команду:
inky@remote-server:~$ vnc4server -kill :1
Всё. Теперь мы можем цепляться к нашему VNC-серверу и запускать там какие-либо приложения. Если вы выбрали Fluxbox — не поленитесь сменить тему Флюкса на FluxNight — с ней намного комфортнее, чем со стандартной (пкм по столу, styles и там выбираете).
Теперь о безопасности. Понятное дело, что цепляться к VNC напрямую в прослушиваемой wifi-сети не очень хорошая идея. Мы обернем наш VNC в ssh туннель.
Закроем все соединения к VNC, кроме локальных (все команды дальше исходят из того, что vnc-server стартовал на :1):
root@remote-host:~# iptables -I INPUT -p tcp --dport 5901 ! -i lo -j DROP
root@remote-host:~# iptables -I INPUT -p tcp --dport 6001 ! -i lo -j DROP

Теперь никто не сможет подцепиться к нашему VNC снаружи.
Мы же пробросим себе порт VNC-сервера на локальную машину (выполняем уже на лаптопе):
user@laptop:~$ ssh -L 5910:127.0.0.1:5901 user@remote-server
Теперь мы можем VNC клиентами цепляться к localhost:5910 и localhost:10
Виндузятники могут пробросить порты в Putty или использовать openssh-клиент (у него такой же синтаксис как и в нормальных ОС).

В общем-то всё. Мы получили шифрование и сжатие VNC-трафика. Ну а то, про что было написано в начале статьи мы получили уже давно.
В ходе следования выполнения инструкций из статьи на сервере стало занято на 20 мегабайт больше памяти и на 100 метров больше дисково пространства, что более чем отлично. На VNC запустилось без особых вопросов. По скорости — на сервере в хетзнере из москвы я смог с ветерком полазить по gmail, убить ноутбук не хотелось.
Удачного использования и не светите свои данные в открытой сети ;)
P.S. — из VNC-клиентов крайне советую использовать Remmina — действительно клевая вещь. Она умеет целиком пробрасывать клавиатуру в VNC, вместе со всякими alt-f2 и c-a-del.

Практика:
10 Июль 2009 Ky6uk Написать комментарий К комментариям

Возникла необходимость организации NAT «на скорую руку», но практические знания отсутствовали как таковые. В голове были лишь обрывки теории по использованию iptables в качестве необходимого инструмента и небольшая практика составления фильтрующих правил для последнего. Необходимость заключалась в том, чтобы отдавать трафик с дополнительного интерфейса на определенный адрес в локальной сети.

Стоит заметить, что целью статьи не ставилось написание полного руководства по iptables, благо подобных мануалов в интернете предостаточно. Это скорее набор небольших практических советов для конкретных случаев с примерами.
Так же в статье подразумевается, что изначально все таблицы в iptables пусты, то есть не содержат ни одного правила, и по-умолчанию в цепочках стоят разрешающие ACCEPT политики.

И так, задача поставлена, интерфейсы сконфигурированы, консоль открыта, из гугла выужены несколько полезных ссылок (подробнее о которых в конце статьи) — можно приступать.
Начальные приготовления и настройка

Включаем форвардинг:
?
# echo 1 > /proc/sys/net/ipv4/ip_forward

Чтобы форвардинг автоматически включался при запуске системы, добавляем в файл /etc/sysctl.conf строку
?
net.ipv4.ip_forward = 1

Условные обозначения:
10.0.0.1/24 — локальный адрес, который требуется «натить»
10.0.0.254/24 — адрес нашей машины, которая будет шлюзом для 10.0.0.1
eth0 — интерфейс на шлюзе с адресом 10.0.0.254/24
eth1 — интерфейс на шлюзе с адресом 192.168.0.1/24
ppp0 — интерфейс на шлюзе с адресом из диапазона 172.27.27.0/24

Делаем доступ на все интерфейсы
?
# iptables -A POSTROUTING -t nat -s 10.0.0.1 -j MASQUERADE

Теперь все соединения от 10.0.0.1 будут перенаправляться согласно нашей таблице маршрутизации.
«-j MASQUERADE» используется в тех случаях, когда есть необходимость перенаправления на интерфейс с динамическим IP адресом. В нашем случае это интерфейс ppp0.

Есть мнение, что в цепочке POSTROUTING при маскараде не рекомендуется указывать параметр «-s«. В замен этому рекомендуется создавать правила в цепочке FORWARD, где и организовывать все перенаправления. Это избавляет от наплыва неверных пакетов с «левых» адресов, которые форвардятся только в одну сторону и остаются мертвым грузом. Но я не гарантирую что это так и сейчас речь не об этом.

Доступ на конкретный интерфейс.

Рассмотрим вариант, когда необходимо перенаправление на интерфейс с постоянным IP адресом. У нас это eth1.
Воспользуемся стандартной политикой SNAT:
?
# iptables -A POSTROUTING -t nat -s 10.0.0.1 -j SNAT --to 192.168.0.1

В данном случае все соединения от 10.0.0.1 будут перенаправлены на адрес 192.168.0.1.

Слово «перенаправлены» не совсем верно. Под перенаправлением следует понимать замену исходящего IP адреса (адреса источника) в пакете на указанный в параметре ––to. В нашем случае если исходящий адрес 10.0.0.1, то он будет заменен на 192.168.0.1

Организация обратного доступа

Использование SNAT имеет один недостаток, соединения могут быть инициированы только машиной, находящейся за NAT-ом. Получить же доступ в предыдущем примере из сети 192.168.0.0/24 к 10.0.0.1 уже не получится. Если же требуется организовать такой доступ, то тут на помощь приходит DNAT.
Добавим в iptables следующее правило:
?
# iptables -A PREROUTING -t nat -d 192.168.0.1 -j DNAT --to 10.0.0.1

Теперь любое соединение на адрес 192.168.0.1 будет непосредственно транслироваться в 10.0.0.1. Для правильной работы этого правила необходимо одно из вышеперечисленных.
Заключение

В заключении отмечу несколько дополнительных параметров iptables, которые я использовал при составлении статьи.
Перенаправление одного порта (192.168.0.1:10022 → 10.0.0.1:22):
?
# iptables -A PREROUTING -t nat -d 192.168.0.1 -p tcp --dport 10022 -j DNAT --to 10.0.0.1:22
# iptables -A POSTROUTING -t nat -s 10.0.0.1 -p tcp --dport 22 -j SNAT --to 192.168.0.1:10022

Вывод списка правил таблицы nat с порядковыми номерами:
?
# iptables -L -v --line-numbers -t nat

Удаление правила из цепочки POSTROUTING таблицы nat по его порядковому номеру (4):
?
# iptables -t nat -D POSTROUTING 4

Удаление всех правил в таблице nat:
?
# iptables -F -t nat
Полезные ссылки

NAT и iptables (Как раздать интернет через вторую сетевую карту)
SNAT with iptables
iptables tutorial

Старый способ активации службы терминал-сервера для w2k работает и на 2003 :)
Вот новая версия легендарного документа “Установка хрени”




Установка сервера терминалов под Win2K
1. Установить терминал сервер вместе с сервером лицензий для него.

2. Запустить активацию сервера лицензий

3. В окошке смотрим код – ID продукта у меня был 51879-006-0588392-50695

4. Заходим на https://activate.microsoft.com , выбираем русский язык, выбор активации сервера лицензий.

5. Вводим в анкете полученный ранее код, и заполняем поля помеченные звездочкой. (их надо запомнить)

6. Нажать далее, потом еще раз далее.

7. Получили код активации сервера лицензий.

8. На вопрос \’Установить маркеры лицензий в данное время?\’ отвечаем да

9. Открывается анкета, с заполненными ранее данными в которой надо указать программу лицензирования Лицензия Select License

10. Жмем далее. Вводим тип продукта – Лицензия W2k TS CAL на устройство, количество – например 100 (должно хватить) а в поле номер соглашения вводим один из этих номеров: 6565792; 5296992; 3325596; 4965437; 4526017 (я вводил первый)

11. Два раза Далее.

12. Получаем \’Код ключевого пакета лицензий\’

13. Переходим к самому терминалу.

14. При активации запрашивает код сервера лицензий (полученный в п. 7)

15. После активации спрашивает не хочется ли установить лицензии сейчас?

16. Говорим да и вводим код полученный в п. 12

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

Под Win2K3 не пробовал, но подозреваю что точно также, только в пункте 10 нужно вводить соответсвующий тип продукта.

http://forum.ru-board.com/topic.cgi?forum=107&topic=0002
http://www.hackzone.ru/news/view/id/1080/
http://forum.0day.kiev.ua/index.php?showtopic=264617
http://xupypr.livejournal.com/101108.html

iptables -t filter -nL – отобразить все цепочки правил

iptables -nL – отобразить все цепочки правил

iptables -t nat -L -отобразить все цепочки правил в NAT-таблице

iptables -t filter -F – очистить все цепочки правил в filter-таблице

iptables -F – очистить все цепочки правил в filter-таблице

iptables -t nat -F -очистить все цепочки правил в NAT-таблице

iptables -t filter -X -удалить все пользовательские цепочки правил в filter-таблице

iptables -t filter -A INPUT -p tcp --dport telnet -j ACCEPT – позволить входящее подключение telnet’ом

iptables -t filter -A OUTPUT -p tcp --dport http -j DROP -блокировать исходящие HTTP-соединения

iptables -t filter -A FORWARD -p tcp --dport pop3 -j ACCEPT  – позволить “прокидывать” (forward) POP3-соединения

iptables -t filter -A INPUT -j LOG --log-prefix “DROP INPUT”  – включить журналирование ядром пакетов, проходящих через цепочку INPUT, и добавлением к сообщению префикса “DROP INPUT”

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -включить NAT (Network Address Translate) исходящих пакетов на интерфейс eth0. Допустимо при использовании с динамически выделяемыми ip-адресами.

iptables -t nat -A PREROUTING -d 192.168.0.1 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.2:22  – перенаправление пакетов, адресованных одному хосту, на другой хост

iptables -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT – допускать не больше 2 соединений telnet с одного хоста

iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16 --connlimit-mask 24 -j REJECT – ограничить число одновременных запросов http до 16 на подсеть класса C (24 первых разряда)
Примечание: Чтобы отменить ошибочное правило не обязательно очищать все цепочки правил, для этого в опции iptables есть команда
-A, --append означает -добавить одно или несколько правил в конец указанной цепочки.

-D, --delete удалить

Так в нашем случае:

iptables -t filter -D OUTPUT -p tcp --dport http -j DROP – отменяет заданную нами ранее блокировку исходящих HTTP-соединений

можно также

iptables -t nat -D POSTROUTING 1
где 1 это номер правила по порядку, или удаляем все правила из таблицы POSTROUTING
iptables -t nat -F POSTROUTING

Еще примеры использования iptables:

Прописываем правила, закрывающие все порты за исключением 25 (smtp: принимаем почту) и 80 (http: показываем web страницы)

# iptables -A INPUT -i eth1 -p tcp --dport 25 -j ACCEPT
# iptables -A INPUT -i eth1 -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,ACK SYN -j REJECT --reject-with icmp-port-unreachable
# iptables -A FORWARD -o eth1 -p tcp -j DROP
Теперь наш сервер прикрыт с внешнего мира. Запуск команд netcat и nmap c самого сервера покажет тоже, что и до внесения правил, но если пробовать с другого компьютера, то заметим результат: доступ везде прикрыт, кроме как на разрешённые нами 25 и 80 порты.

iptables -t nat -A POSTROUTING -s 10.0.3.41 -d 217.217.217.217 -o eth1 -p tcp --dport 25 -j SNAT --to 116.116.116.116
Разрешаем прямой доступ к внешней почте. Подробнее: разрешаем доступ хосту 10.0.3.41 из внутренней сети обращаться к хосту 217.217.217.217 на 25 порт (smtp) протокола tcp; такие обращения пропускаем через интерфейс eth1, который имеет адрес 116.116.116.116
Для доступа к РОР добавляем такое же правило для порта 110

iptables -t nat -A POSTROUTING -s 10.0.3.41 -p tcp --dport 25 -j MASQUERADE
Более короткое правило, аналогичное вышеприведённому, только здесь пользователь с ip 10.0.3.41 имеет доступ к любому почтовому серверу в Интернете.




Можно посмотреть действующие правила в виде команд:
# iptables-save

Чтобы запомнить эти правила сохраняем новую конфигурацию в этот файл:

# iptables-save > /etc/sysconfig/iptables
Теперь при запуске системы прописанные нами правила восстановятся.



Дополнение: Разрешаем маршрутизацию на на один раз до перезагрузки
sysctl -w net.ipv4.ip_forward=1
Проверить
sysctl -a |grep forwarding
увидеть net.ipv4.conf.lo.forwarding = 1 или 0 если не открыт
Для того чтобы правило вступало в силу и после перезагрузки заходим в /etc/net/sysctl.conf находим
net.ipv4.ip_forward = 0 и изменяем на 1



Проверим, осуществляется ли автоматический запуск iptables, то есть запускается при перезагрузки сервера проверяем
chkconfig --list iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
видим, что нет. Добавляем и проверяем:
chkconfig --level 35 iptables on
chkconfig --list iptables
iptables 0:off 1:off 2:off 3:on 4:off 5:on 6: off



http://www.opennet.ru/docs/RUS/iptables/
http://ru.wikipedia.org/wiki/Iptables