Cisco and vlan которые могут то работать то нет

Они когда-то были зарезервированы и поэтому на одних IOS они работают на других нет

1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

Повышение безопасности домена

1). В групповых политиках для машин пользователей
1.1). Через реестр
По умолчанию - 10
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\winlogon. Ключ CachedLogonsCount (если нет создать REG_SZ тип) = 0 сделать.
Через груповые политики
1.2) Через груповые политики
Конфигурация компьютера, Конфигурация Windows, Параметры безопасности, Локальные политики, Параметры безопасности, Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена) = 0
Брутить эти хешированные пароли и логины могут Cain&Abel (локально) и PWDumpX (удаленно).
Но поскольку при разблокировке станции (выход из скринсейвера, если он требует логин пароль, или станция заблокирована вручную) нужны логин и пароль кешированнию подвергается текущая сессия в памяти. Если используется кеширование доменные контролер не используется, для его использования при разблокировке
Конфигурация компьютера, Конфигурация Windows, Параметры безопасности, Локальные политики, Параметры безопасности, Интерактивный вход в систему: требовать проверки на контроллере домена для отмены блокировки - вкл.
2). Отключение отражения (Smb relay - бюлетень MS08-068). Апдейты отключают рефлексию на хост инициировавший соединение соединение (но это не откл. рефлесию на другие хосты и по другим протоколам). "Подписывание SMB" к сожалению по умолчанию откл., только на контролере домена (начиная с Win2000) вкл.
Клиент
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (с согласия сервера)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными с клиентами (если возможно)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters
EnableSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. В Windows Server 2003, Windows XP и Windows 2000 значение по умолчанию – 1 (включен).
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (всегда)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными с клиентами (всегда)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters
RequireSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. В Windows Server 2003, Windows XP и Windows 2000 значение по умолчанию – 0 (необязательный).
Сервер
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (с согласия клиента)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными между серверами (если возможно)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
EnableSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. На контроллерах домена под управлением Windows Server 2003 и Windows 2000 значение по умолчанию – 1 (включен). На контроллерах домена под управлением Windows NT 4.0 значение по умолчанию – 0 (отключен).
В Windows Server 2003 и Windows XP политика «Сервер сети Microsoft: использовать цифровую подпись (всегда)»
и в Windows 2000 политика «Использовать цифровую подпись при обмене данными между серверами (всегда)» сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. На контроллерах домена под управлением Windows Server 2003 и Windows 2000 значение по умолчанию – 1 (обязательный). На контроллерах домена под управлением Windows NT 4.0 значение по умолчанию – 0 (необязательный).
(http://support.microsoft.com/kb/887429/ru)

rpm - использование (ньюансы)

1). Верификация

# rpm -V util-linux-2.12q-26

S.5....T /bin/arch

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

s означает изменение размера файла,
5 – нарушение сигнатуры md5 файла,

T – изменение времени последней модификации (то есть времени копирования файла в систему в нашем случае).

2). В режимах установки-удаления довольно часто возникает необходимость воспользоваться опциями --nodeps или --force. Первая позволяет установить (удалить) пакет независимо от того, удовлетворяются ли все его зависимости, вторая – установить пакет даже в том случае, если в системе имеются файлы более свежих версий. Некоторый интерес представляют опции --aid, которая автоматически удовлетворит возникающие зависимости и --test, которая и означает тестирование операций, то есть весь вывод о возникающих проблемах будет осуществлен, но реальных операций не производится. Очень удобно моделировать поломку системы в результате каких-либо действий.

3). # rpm -q --queryformat %{DESCRIPTION} <имя пакета>

выведет описание пакета, а команда

# rpm -q --queryformat %{DISTRIBUTION} <имя пакета>

– название дистрибутива, в составе которого находится пакет.

Причем замена -q на -qp позволит ту же самую информацию получить от rpm-файла не установленного в систему пакета. Можно получить список только конфигурационных файлов пакета, или только файлов документации, или только файлов, содержащих в имени регулярное выражение, то есть в принципе что угодно.

4). Формат rpm-пакета.

Формат пакета состоит из бинарного заголовка и cpio-архива, который содержит бинарные файлы в таком дереве каталогов, в каком они будут находится в системе после установки пакета. Файловый менеджер mc понимает множество всяких архивов, и в том числе – упаковку rpm. Если в панели mc выделить rpm-пакет и нажать ввод, мы увидим псевдофайловую систему, состоящую из следующих компонентов: каталога INFO, архива CONTENTS.cpio, того самого, содержащего бинарные файлы, файла HEADER и псевдоскриптов INSTALL и UPGRADE. В каталоге INFO содержатся файлы, имена которых соответствуют именам полей spec-файла, содержимое – значениям полей. Файл HEADER – по сути то же самое, только в одном файле. Ссылки INSTALL и UPGRADE соответствуют командам rpm -ih <имя пакета> и rpm -Uh <имя пакета>. То есть, если на них нажать, эти действия и произойдут.

В реальном формате никакой файловой системы нет. Просто mc умеет по-своему интерпретировать бинарный заголовок пакета, за что его разработчикам большой респект.

При желании можно выделить cpio-архив из всего пакета. Для этого существует утилита rpm2cpio.

5). Соберем пакет.

В rpm версии v.4 режим сборки пакета оформлен в виде отдельной утилиты – rpmbuild. Воспользуемся самым эффективным методом изучения технологии, то есть, соберем модельный rpm-пакет. Нет и вопроса, что должна делать программа, которую мы упакуем в rpm. Она должна говорить: «Hello, world!»!

В rpm-based дистрибутивах существует специальное дерево каталогов, предназначенное исключительно для сборки пакетов. Оно лежит в /usr/src (в Suse Linux – в /usr/src/packages) и содержит каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS. Предназначены они соответственно для хранения временных каталогов сборки, собранных бинарных rpm, исходного кода, хранения файлов спецификации, собранных src.rpm-пакетов. Src.rpm содержат исходный код и spec-файлы и предназначены для пересборки на целевых машинах с целью лучшей адаптации к архитектуре и системному окружению этих машин. Для сборки нам потребуется исходный код программы, который традиционно упаковывается в tar.gz или в tar.bz2 и spec-файл. Spec-файл для rpm примерно то же, что Makefile для утилиты make. Это подробнейший сценарий того, что должно происходить при сборке со всеми необходимыми определениями и служебными полями. Итак, за дело.

Создадим текст программы на С. Файл назовем hi.c и поместим его в каталог SOURCES. Отредактируем содержание файла в любимом текстовом редакторе следующим образом:

#include

int main(int argc, char **argv)
{
fprintf(stdout,"Hello, World!\n");
return 0;
}

Не забудем пустую строку в конце файла. Запакуем исходный код в tar.gz (команду отдаем, находясь в каталоге /usr/src/packages/SOURCES):

# tar cvfz ./hi-0.1.tar.gz ./hi.c

Далее spec-файл. По сути дела, умение создавать хорошо пересобираемые rpm-пакеты – это умение писать spec-файлы. Они имеют сложную структуру, подробности которой рассмотреть не представляется возможным в журнальной статье, поэтому обсудим главное. Файл делится на секции, каждая секция отвечает за свою часть работы. Создадим файл под именем hi.spec в каталоге SPECS и наполним его следующим содержанием:

Summary: Приветствующая утилита.
Name: hi
Version: 0.1
Release: 1
Copyright: GPL v.2
Group: Tests
Source:%{name}-%{version}.tar.gz
BuildRoot: /tmp/hi
%description
Тестовая программка для вывода приветствия.
%prep
%setup -c hi
%build
gcc -o hi hi.c

%install
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
cp hi $RPM_BUILD_ROOT/usr/local/bin
%clean
rm -rf $RPM_BUILD_ROOT
%files
/usr/local/bin/hi
Проанализируем функции отдельных секций spec-файла.

Все, что написано до строки %prep, составляет секцию introduction. Она содержит описания, определения версий и релизов, корень сборки и другую служебную информацию. Значения всех этих полей используются через имена полей в качестве переменных при сборке и включаются в одноименные поля бинарного заголовка rpm-пакета.

Секция prep отвечает за подготовку исходного кода к сборке. В нашем примере секция содержит строку %setup -c hi, которая вызывает макрос RPM. Макрос, в свою очередь, распаковывает исходный текст Си из архива.

Секция build содержит инструкции по сборке. В данном случае мы указали имя выходного бинарного файла – hi. Если проект большой, как правило должен быть сгенерирован Makefile, поэтому секция может содержать нечто подобное:

./configure CXXFLAGS=-03 –prefix=$RPM_BUILD_ROOT/usr

make

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

rm -fr $RPM_BUILD_ROOT

make install

В нашем проекте нет Makefile, поэтому мы указали все непосредственно.
Секция clean содержит команды удаления каталогов сборки.
Секция files – список файлов проекта.

Итак, у нас имеется исходный код в виде tar.gz-архива и spec-файл. Больше для сборки пакета ничего не требуется. Естественно, в системе должны быть установлены средства разработки.

Для сборки пакета вызываем утилиту rpmbuild с ключом -b. Второй символ набора ключей означает цель сборки. Опция -a указывает на необходимость собрать как rpm-пакет, так и src.rpm. Укажем также целевую архитектуру. Находясь в каталоге SPECS, отдадим следующую команду:

rpmbuild -ba --target i586 ./hi.spec

Если в последней строке консольного вывода Вы увидите: + exit 0, значит все прошло как надо. В каталоге RPMS/i586 должен обнаружиться файл

hi-0.1-1.i586.rpm, в каталоге SRPMS – файл hi-0.1-1.src.rpm. Воспользуемся уже имеющимися знаниями, и установим пакет hi в систему:

# cd /usr/src/packages/RPMS/i586

# rpm -Uhv ./hi-0.1-1.i586.rpm

Теперь, если Вы скажете в консоли:

$ hi

получите ответ: Hello, World!
Для установки src.rpm-пакета воспользуйтесь командой:

# rpm -i /путь к каталогу/hi-0.1-1.src.rpm

При этом в систему скопируются исходный код и spec-файл (в то самое дерево каталогов для rpm-сборки). Если нужно просто собрать бинарный пакет, достаточно сказать:

# rpmbuild --rebuild /путь к каталогу/hi-0.1-1.src.rpm

Трюки и советы по командной строке

1). Количество линий в файле
sed -ne '$=' ~/.bashrc
2). Сокращенный вывод при подсчете размера текущего каталога (оставляем только подкаталоги)
du -h . | grep -v '/.*/' | sort -n
3). календарь за месяц
cal 01 2011
4). uptime графически
uptime | awk '{while($3--) a=a"="; print "|" a ">"}'
5). к какому пакету относится файл txt1
fedora# rpm -qf txt1
debian# dpkg -S txt1
gentoo# equery belongs txt1
freebsd# pkg_info -W txt1
freebsd# pkg_info -E txt1

Консольные юниксовые снифферы паролей

Как отснифать
dsniff
dsniff -i eth0 -w ./password (если хотим сохранить в файл)
Как прочитать (если сохранено в файле)
dsniff -r ./password
http://www.protocols.ru/modules.php?name=News&file=article&sid=29 - можно почитать
еще утилитки из той же области

Arpspoof, спуфит указанный вами ip-адрес.
arpspoof 192.168.0.2
У этого компьютера будет, выходит сообщение, что ip-адрес занят и используется в сети, при этом иногда нарушается работа некоторых сетевых программ. К примеру, спуфинг кс-сервака закончился диссконектом всех клиентов.

Urlsnarf, перехват URL. Просто запускаем и ждем, все выводится прямо на экран, можно перенаправить в файл.
urlsnarf > url.log( Ждем…)
192.168.21.21 - - [19/Mar/2007:02:58:30 +0300] "GET http://club.itdrom.com/gallery/gal_source/delphi/d-a-p2 HTTP/1.1" - - "http://club.itdrom.com/gallery/gal_source/delphi/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)"
Что нам дают эти на первый взгляд не нужные url? Можно узнать пароли к некоторым сайтам, где бывает человек, версии ОС, браузера.

Dsniff, основной сниффер, перехват POP, AIM, HTTP, FTP, NIS, NNTP…. Использовать лучше в фоне, а вывод направить в файл.

nohup dsniff 2>1 >> ds.log &
03/19/07 00:30:13 tcp 192.168.4.66.1044 -> 64.12.200.89.5190 (aim)
418823169
18
03/19/07 02:56:03 tcp 192.168.2.61.1744 -> 194.67.23.102.110 (pop)
USER daniil98
PASS 1234567890
03/19/07 02:16:26 tcp 192.168.2.61.1540 -> 213.24.222.132.21 (ftp)
USER fc1
PASS fc1

Остальные утилиты:
Macof - arp-флудер сети.
Dnsspoof – подделывает PTR-записи DNS(??).
Filesnarf – перехватывает файлы по NFS.
Msgsnarf – перехват сообщений IRC, ICQ, AIM (не знаю почему так и не заработал…)
Mailsnarf – перехват почты POP, SMTP. (ноу эффект…)
Sshmitm – какая-то сложная атака перехвата сеансов на SSH (не пробовал, да и врятли это получится…)
Webmitm – тоже только для web.

http://forum.antichat.ru/showthread.php?p=313506 - почитать

торможение ssh и samba

Если у вас тормозит ssh и в логах (messages) такие сообщение

Nov  6 15:17:00 redhat smbd[13689]:   Unable to connect to CUPS server localhost:631 - В соединении отказано
Nov  6 15:17:00 redhat smbd[13689]: [2010/11/06 15:17:00, 0] printing/print_cups.c:cups_connect(69)

то скорее ssh тормозит из-за samba, проблему решило добавление в конфиг samba таких строк

load printers = no
printing = bsd
printcap name = /dev/null

и после перезапуска samba все стало нормально

настройка аудита Linux

Ставим пакет audit, и пускаем сервис service auditd start (предварительно проверив уровни запуска chkconfig --list auditd)

1). Настраиваем наблюдение за конфигами и логами системы аудита
#vim /etc/audit/audit.rules
# наблюдение за конфигруционными файлами
-w /etc/audit/auditd.conf -p wa
-w /etc/audit/audit.rules -p wa
-w /etc/libaudit.conf -p wa
-w /etc/sysconfig/auditd -p wa

 # наблюдение за журнальными файлами
-w /var/log/audit/
-w /var/log/audit/audit.log

где
-w - путь к файлу или директории (маски не позволительны)
-p - эквивалент фильтра perm (пример -F perm=aw, есть еще r (read), x (execute))
wa - w - запись (write), a - смена атрибутов (attribute change)

2). наблюдение за важными системными конфигурационнными файлами

# настройки и задания at
-w /var/spool/at/
-w /etc/at.deny

# задания cron
-w /etc/cron.deny -p wa
-w /etc/cron.d/ -p wa
-w /etc/cron.daily/ -p wa
-w /etc/cron.hourly/ -p wa
-w /etc/cron.monthly/ -p wa
-w /etc/cron.weekly/ -p wa
-w /etc/crontab -p wa
-w /var/spool/cron/root

# файлы паролей и груп
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow

# конфигурационные и журнальные файлы входа в систему
-w /etc/login.defs -p wa
-w /etc/securetty
-w /var/log/faillog
-w /var/log/lastlog

# список и имена хостов
-w /etc/hosts -p wa

# стартовый скрипты демонов
-w /etc/rc.d/init.d
-w /etc/rc.d/init.d/auditd -p wa

# пути поиска библиотек
-w /etc/ld.so.conf -p wa
-w /etc/ld.so.conf.d

# настройки времени
-w /etc/localtime -p wa

# системный переменные
-w /etc/sysctl.conf -p wa

# правила загрузки модулей
-w /etc/modprobe.d/

# модули системы PAM
-w /etc/pam.d

# настройки сервера SSH
-w /etc/ssh/sshd_config

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

# изменения прав доступа к файлам
-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown32

-a - добавить правило в список
entry - события происходящие на входе в системный вызов
always - собитие записываетсь в журнал собитий
-S - имя системного вызова

# создание, открытие или изменение размеров файлов
-a entry,always -S crate -S open -S truncate -S truncate64 -S ftruncate -S ftruncate64 -S

# создание и удаление каталогов
-a entry,always -S mkdir -S rmdir

# удаление и создание ссылок
-a entry,always -S unlink -S raname -S link -S symlink

# изменение расширенных атрибутов файлов
-a entry,always -S setxattr
-a entry,always -S lsetxattr
-a entry,always -S fsetxattr
-a entry,always -S removexattr
-a entry,always -S lremovexattr
-a entry,always -S fremovexattr

# создание файлов устройств
-a entry,always -S mknod

# монтирование файловых систем
-a entry,always -S mount -S umount -S umount2

# использование системного вызова ptrace для отладки процессов
-a entry,always -S ptrace

перегружаем демон

4). анализ журнальных файлов /var/log/audit/ нельзя делять редакторами (нечитабельны). Делает утилитами
aureport - общий анализ
aureport -f - список файлов к который происходил доступ
лучше запросить за определенный период (--end не обязателен)
aureport -f --start 09/20/10 13:00 --end 09/20/10 16:00
вместо времени можно использовать
now, recent (10 минут назад), today (начиная с полуночи), yesterday, this-week, this-month, this-year.
aureport -f --summary - какие файлы сколько раз были открыты

60. 06.11.2010 19:13:01 /etc/pam.d/crond 5 yes /usr/sbin/crond -1 11037
5 - номер системного вызова (чтобы видеть имя флаг -i)
yes - успешность или нет системного вызова
(deleted) -
-1 - UID (AUID) - пояснение ниже
11037 - номер события

каждое событие можно проанализировать утилитой
auserch -a номер_события (11037 - в нашем логе)
также можно искать события по именам системных вызовов (ключ -i)
auserch -sc ptrace -i
идентификаторам пользователей
ausearch -ui 500
именам исполняемых файлов
ausearch -x /usr/sbin/crond

имени терминала
ausearch -tm pts/0
именам демонов
ausearch -tm cron
или клуючам поиска
ausearch -k etc_access
можно также использовать временные промежутки

еще флаги aureport для генерации отчетов
-s - системный вызовы
-au - попытки аутентификации
-l - успешные логины
m - модификация экаунта
--failed - отчеты можно получать только для событий, завершившихся неудачно

пользователь может использовать команды su sudo, чтобы менять свой (UID), чтобы это обойти используется Audit UID (AUID), которые закрепляются за пользователем при входе в систему и не меняются, по умолчанию эта функция отключена по этому и -1, активация
/etc/pam.d/login добавить session required pam_loginuid.so
перед строкой (session    include    common-session -  dedian), у меня (rpm based), можно до и после

session    include      system-auth
также нужно проверить или установщик не добавил уже эту строку, ту же операцию проделываем с другими файлами
/etc/pam.d/sshd gdm(kdm или kde) crond atd

источник: Пингвин под колпаком (Аудит системный событий в Linux) (Хакер, 11/142/2010 — 126)
Дополнительная информация
http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
http://linux.die.net/man/7/audit.rules
http://www.xakep.ru/post/54897/?print=true