Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Иногда требуется читать и писать на раздел HDD, который форматирован под NTFS.

Что потребовалось для решения данной задачи:

1. Установить

• /usr/ports/sysutils/fusefs-ntfs
• /usr/ports/sysutils/ntfsprogs

2. Добавить

а) в /etc/rc.conf

fusefs_enable=»YES»

б) в /etc/sysctl.conf

sysctl vfs.usermount=1

3. Запустить fusefs

/usr/local/etc/rc.d/fusefs start

4. Смонтировать диск

ntfs-3g /dev/da1s1 /mnt/usb_hdd

для монтирования после ребута сервера добавим в /etc/fstab

/dev/da1s1 /mnt/usb_hdd ntfs-3g rw 0 0

так пока не пробовал, т.к. сервер удаленный и есть сомнение что будет работать.

Посему поставил монтирование через файл /etc/rc.local строчкой:

/usr/local/bin/ntfs-3g /dev/da1s1 /mnt/usb_hdd

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор:  madmax

Коммутатор и Access Lists

Для фильтрации трафика коммутатор может использовать следующие типы ACL:

• Router ACL
• Port ACL
• VLAN ACL
• MAC ACL

Router ACL

Как и подразумевается в названии, Router ACL подобны на IOS ACL и используются для фильтрации сетевого трафика на SVI (интерфейсы SVI это Layer 3 на VLAN, физические Layer 3 интерфейсы и Layer 3 интерфейсы EtherChannel). Поддерживаются как стандартные, так и расширенные ACL. Для получения более детальной информации по Router ACL, обратитесь к соответствующей документации.

Port ACL

Port ACL подобны Router ACL, но работают на физических интерфейсах и интерфейсах Layer 2 коммутатора. Port ACL поддерживают фильтрацию только входящего трафика. Port ACL могут быть расширенного, стандартного и MAC-extended типа.

Обработка Port ACL подобна Router ACL: коммутатор проверяет ACL, назначенный данному интерфейсу и разрешает или блокирует пакет.

Когда ACL наложен на транковый порт, проверяется трафик всех проходящих через транк VLAN-ов — как данные, так и голос.

Основная прелесть Port ACL состоит в том, что может фильтроваться как IP трафик (используя IP access lists) так и non-IP трафик (используя MAC access list).

Внимание: Port ACLs не поддерживается на интерфейсах EtherChannel.

VLAN ACL (VACL)

VLAN ACL (так же известные как VLAN map) осуществляют пакетную фильтрацию всех типов трафика внутри VLAN или входящих/выходящих из него. В отличие от Router ACL, VACL не определяет направление трафика (input или output). Все пакеты находящиеся в VLAN (маршрутизируемые или внутренние) проверяются VACL. Для пакетной фильтрации в зависимости от направления трафика есть возможность использовать комбинацию VACL и Private VLAN.

VACL обрабатываются на аппаратном уровне, не оказывая влияния на производительность коммутатора. Производительность так же не зависит от объема VACL. Поэтому они упоминаются также как wire-speed ACL.

VACL на порту Layer 2

На рисунке ниже показана работа VACL на briged интерфейсе для Host A в VLAN 5 передающего данные на Host B в VLAN 10.

VACL маршрутизируемом порту

На рисунке ниже показана работа IOS ACL и VACL на маршрутизируемом интерфейсе. Порядок выполнения определяется следующим образом:

1. VACL для input VLAN
2. Input IOS ACL
3. Output IOS AC
4. VACL для output VLAN

Конфигурирование VACL

Для конфигурирования VACL (VLAN access map) необходимо выполнить следующие действия:

1. Определить стандартный или расширенный ACL, который будет использоваться на VACL.
2. Определить VLAN access map.
3. Описать критерий попадания
4. Описать выполняемое действие при попадании
5. Наложить VLAN access map на соответствующий VLAN.
6. Посмотреть, а что же у нас получилось?

В данном примере мы определяем и накладываем VACL, который будет отбрасывать пакеты, попадающие в access list 1 из сети 192.168.1.0/24, при этом все остальные пакеты, попадающие в access list 2 будут переданы. VACL применяется к VLAN-ам с 5 по 10.

Switch(config)#access-list 1 permit 192.168.1.0 0.0.0.255
Switch(config)#access-list 2 permit any
Switch(config)#vlan access-map mymap 10
Switch(config-access-map)#match ip address 1
Switch(config-access-map)#action drop
Switch(config-access-map)#exit
Switch(config)#vlan access-map mymap 20
Switch(config-access-map)#match ip address 2
Switch(config-access-map)#action forward
Switch(config-access-map)#exit
Switch(config)# vlan filter mymap vlan-list 5-10
Switch(config-access-map)#end

Switch# show vlan access-map
Vlan access-map «mymap» 10
Match clauses:
ip address: 1
Action:
drop
Vlan access-map «mymap» 20
Match clauses:
ip address: 2
Action:
Forward

Switch# show vlan filter
VLAN Map mymap is filtering VLANs:
5-10

MAC ACL

MAC ACL, также известный как Ethernet ACL предназначен для фильтрации non-IP трафика на VLAN или физических интерфейсах Layer 2 используя MAC адреса в именованном расширенном MAC extended ACL.

Шаги по конфигурации MAC ACL подобны обычным именованным расширенным ACL. MAC ACL могут применяться только для фильтрации входящего трафика.

Для определения MAC Extended ACL используется команда mac access-list extended.

После того, как MAC ACL будет создан, его необходимо наложить на интерфейс Layer 2 используя команду mac access-group [acl-name] in

В примере ниже мы покажем, как создать и применить MAC ACL для блокировки всех пакетов AppleTalk Address Resolution Protocol (AARP), пропуская отсальной трафик

Switch(config)# mac access-list extended my-mac-acl
Switch(config-ext-macl)# deny any any aarp
Switch(config-ext-macl)# permit any any
Switch(config-ext-macl)# exit
Switch(config)# interface Fastethernet0/10
Switch(config-if)# mac access-group my-mac-acl in
Switch(config-if)# end
Switch#

Оригинал:   http://dreamcatcher.ru/cisco/003_switches.html

Ссылки:

• Configuring IP Access Lists

Приехали на инсталл очередные серверы:

• IBM  x3250 M2 [4194K1G]
• Intel на материнке S5520UR

Оба c RAID-контроллерами LSI SAS 1064E :

mpt0@pci0:1:0:0:        card=0x03061014 chip=0x00561000 rev=0x02 hdr=0x00
vendor     = 'LSI Logic (Was: Symbios Logic, NCR)'
device     = 'SAS 3000 series, 4-port with 1064E -StorPort'
class      = mass storage
subclass   = SCSI

На IBM используются обычные SATA диски, а на Intel — SCSI, организованные в RAID-1 (зеркало), который FreeBSD видит как устройство da0.

И все бы ничего, но syslog на одном из серверов (после физического удаления и последуюшего возвращения на место  одного из хардов) выдал в messages вот такую инфу:

Oct 21 22:16:28 bill kernel: mpt0:vol0(mpt0:0:0): RAID-1 - Degraded
Oct 21 22:16:28 bill kernel: mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing )
Oct 21 22:16:28 bill kernel: mpt0:vol0(mpt0:0:0): Low Priority Re-Sync
Oct 21 22:16:28 bill kernel: mpt0:vol0(mpt0:0:0): 170387769 of 285155328 blocks remaining
Oct 21 22:16:59 bill kernel: mpt0: mpt_cam_event: 0x14
Oct 21 22:17:43 bill kernel: mpt0: mpt_cam_event: 0x14
Oct 21 22:19:43 bill last message repeated 3 times

Резонно возник вопрос: «А как посмотреть текущее состояние RAID?».

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

[intel:~] camcontrol periphlist da0

pass0:  generation: 4 index: 1 status: MORE
da0:  generation: 4 index: 2 status: LAST
[intel:~] camcontrol inquiry da0
pass0: <Intel Logical Volume 0001> Fixed Direct Access SCSI-2 device
300.000MB/s transfers , Command Queueing Enabled

и утилиты из портов (make search key=' LSI ' | more) ничего не знают про 1064E.

В гугле же нашлось два решения:

1. Анализировать состояние переменной sysctl dev.mpt.0.nonoptimal_volumes:

если значение не равно нулю, то есть проблемы с состоянием RAID.

2. Собрать из сорцов mptutil (сохраненная в архиве копия сорцов). Сборка, как ни странно, прошла «на ура»: просто даем «make«. После сборки mptutil запустилась — уже хорошо:

[intel:~] mptutil

usage: mptutil [-u unit] <command> ...

Commands include:
show adapter              - display controller information
show config               - display RAID configuration
show drives               - list physical drives
show events               - display event log
show volumes              - list logical volumes
fail <drive>              - fail a physical drive
online <drive>            - bring an offline physical drive online
offline <drive>           - mark a physical drive offline
name <volume> <name>
volume status <volume>    - display volume status
clear                     - clear volume configuration
create <type> [-vq] [-s stripe] <drive>[,<drive>[,...]]
delete <volume>
add <drive> [volume]      - add a hot spare
remove <drive>            - remove a hot spare

Пробуем получить состояние массива:
[intel:~] mptutil show volumes

mpt0 Volumes:
Id     Size    Level   Stripe  State  Write-Cache  Name
da0 (  136G) RAID-1          OPTIMAL   Disabled

То, что нужно!

Дальнейшее использование информации о состоянии RAID-массива ограничено только вашей фантазией.

З.Ы. Сборка и работоспособность mptutil тестировалась на FreeBSD 7.0 и 7.2 — везде полет нормальный.

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Пишу заметочку себе, но м.б. кому нить ещё пригодится.

История

Сижу, конфигурю себе джуник, никого не трогаю 🙂

Закончил делать конфиг, выполняю:

virus@juniper# commit check

и… и получаю сей конфуз:

error: init: write failed: No space left on device
error: configuration check-out failed: daemon file propagation failed

или такой вариант конфуза:

virus@juniper# commit check

error: init: write failed: Unknown error: 0
error: init: write failed: No space left on device
error: write failure for file ttys
error: configuration check-out failed: daemon file propagation failed

Почесав репу 🙂 полез смотреть, что же у меня там со свободным местом то происходит:

virus@juniper# run show system storage

Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad0s1a             885M       142M       672M       17%  /
devfs                   1.0K       1.0K         0B      100%  /dev
devfs                   1.0K       1.0K         0B      100%  /dev/
/dev/md0                 30M        30M         0B      100%  /packages/mnt/jbase
/dev/md1                179M       179M         0B      100%  /packages/mnt/jkernel-9.4R1.8
/dev/md2                 31M        31M         0B      100%  /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3                4.8M       4.8M         0B      100%  /packages/mnt/jdocs-9.4R1.8
/dev/md4                 48M        48M         0B      100%  /packages/mnt/jroute-9.4R1.8
/dev/md5                 32M        32M         0B      100%  /packages/mnt/jpfe-common-9.4R1.8
/dev/md6                2.0G       8.0K       1.8G        0%  /tmp
/dev/md7                2.0G       2.0G    -160.8M      109%  /mfs
/dev/ad0s1e              98M        26K        90M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              34G       470M        31G        1%  /var

мдаааа…. подумал я, минус 160 метров это круто……

начал поиски, куда же все место подевалось ? и нашел таки куда:

virus@juniper# run file list detail /mfs/var/lpdfd/

/mfs/var/lpdfd/:
total 4120268
-rw-r-----  1 root  wheel      24576 May 7  12:16 __db.001
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.002
-rw-r-----  1 root  wheel     270336 May 7  12:16 __db.003
-rw-r-----  1 root  wheel    1146880 May 7  12:16 __db.004
-rw-r-----  1 root  wheel     475136 May 7  12:16 __db.005
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.006
-rw-r-----  1 root  wheel         25 May 7  12:17 __db.register
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.egen
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.gen
-rw-r-----  1 root  wheel   10485760 May 7  18:41 log.0000000001
-rw-r-----  1 root  wheel   10485760 May 8  01:15 log.0000000002
-rw-r-----  1 root  wheel   10485760 May 8  07:49 log.0000000003
-rw-r-----  1 root  wheel   10485760 May 8  14:23 log.0000000004
-rw-r-----  1 root  wheel   10485760 May 8  20:57 log.0000000005
-rw-r-----  1 root  wheel   10485760 May 9  03:31 log.0000000006
-rw-r-----  1 root  wheel   10485760 May 9  10:05 log.0000000007
-rw-r-----  1 root  wheel   10485760 May 9  16:39 log.0000000008
-rw-r-----  1 root  wheel   10485760 May 9  23:13 log.0000000009
-rw-r-----  1 root  wheel   10485760 May 10 05:47 log.0000000010
-rw-r-----  1 root  wheel   10485760 May 10 12:20 log.0000000011
-rw-r-----  1 root  wheel   10485760 May 10 18:54 log.0000000012
-rw-r-----  1 root  wheel   10485760 May 11 01:28 log.0000000013
-rw-r-----  1 root  wheel   10485760 May 11 08:02 log.0000000014
.................................................................
-rw-r-----  1 root  wheel   10485760 Jun 28 11:29 log.0000000190
-rw-r-----  1 root  wheel   10485760 Jun 28 18:03 log.0000000191
-rw-r-----  1 root  wheel   10485760 Jun 29 00:37 log.0000000192
-rw-r-----  1 root  wheel   10485760 Jun 29 07:11 log.0000000193
-rw-r-----  1 root  wheel   10485760 Jun 29 13:45 log.0000000194
-rw-r-----  1 root  wheel   10485760 Jun 29 20:19 log.0000000195
-rw-r-----  1 root  wheel   10485760 Jun 30 02:53 log.0000000196
-rw-r-----  1 root  wheel   10485760 Jun 30 09:26 log.0000000197
-rw-r-----  1 root  wheel   10485760 Jun 30 16:00 log.0000000198
-rw-r-----  1 root  wheel   10485760 Jun 30 22:34 log.0000000199
-rw-r-----  1 root  wheel   10485760 Jul 1  05:08 log.0000000200
-rw-r-----  1 root  wheel   10485760 Sep 17 15:53 log.0000000201
-rw-r-----  1 root  wheel     131072 May 7  12:16 lpdfd.db

Я ессно сократил вывод, иначе много места займет :), вообщем файлов с log.0000000001 по log.0000000201 включительно.

Полез в Google, долго рылся в кучи всяких линков ниочем прежде чем найти всего одну путную ссылку, в которой чел рассказывал хоть о чем то похожем.

Почитал что люди пишут, посмотрел на версию софта на этом маршрутизаторе:

virus@juniper> show version

Hostname: juniper
Model: m7i
JUNOS Base OS boot [9.4R1.8]
JUNOS Base OS Software Suite [9.4R1.8]
JUNOS Kernel Software Suite [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M7i/M10i) [9.4R1.8]
JUNOS Online Documentation [9.4R1.8]
JUNOS Voice Services Container package [9.4R1.8]
JUNOS Services AACL Container package [9.4R1.8]
JUNOS Services LL-PDF Container package [9.4R1.8]
JUNOS AppId Services [9.4R1.8]
JUNOS IDP Services [9.4R1.8]
JUNOS Routing Software Suite [9.4R1.8]

пробуем удалить:
virus@juniper# run file delete /mfs/var/lpdfd/log.0000000201

и ессно хрен там:

rm: /mfs/var/lpdfd/log.0000000201: Permission denied

Стало понятно что я не удалю файлы из под своего аккаунта и нуна войти под root.

Консольный кабель подключен к COM порту и я полез через него, набрав в консоле, своей любимой OS FreeBSD, команду:
cu -l /dev/cuad0

Ну что ж, под root`ом я вошел, пробуем удалить файл снова:

root@juniper% cd /mfs/var/lpdfd/
root@juniper% rm log.0000000201

Отлично ! Файл спокойно удалился. Таким образом я потер все остальные файлы с логами, оставив тока с 10-к.

Смотрим что у нас там с местом ?

root@juniper% df -h

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    885M    142M    672M    17%    /
devfs          1.0K    1.0K      0B   100%    /dev
devfs          1.0K    1.0K      0B   100%    /dev/
/dev/md0        30M     30M      0B   100%    /packages/mnt/jbase
/dev/md1       179M    179M      0B   100%    /packages/mnt/jkernel-9.4R1.8
/dev/md2        31M     31M      0B   100%    /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3       4.8M    4.8M      0B   100%    /packages/mnt/jdocs-9.4R1.8
/dev/md4        48M     48M      0B   100%    /packages/mnt/jroute-9.4R1.8
/dev/md5        32M     32M      0B   100%    /packages/mnt/jpfe-common-9.4R1.8
/dev/md6       2.0G    8.0K    1.8G     0%    /tmp
/dev/md7       2.0G    100M    1.7G     5%    /mfs
/dev/ad0s1e     98M     26K     90M     0%    /config
procfs         4.0K    4.0K      0B   100%    /proc
/dev/ad1s1f     34G    470M     31G     1%    /var

С местом у нас теперь все путем ! Ну что ж, пробую откоммитить, для этого захожу в CLI:
root@juniper% cli
и чекаем конфиг:
root@juniper> commit check
и наконец получаем искомое:
configuration check succeeds

Ссылки

• gossamer-threads.com

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Как всегда начнем статью со слов благодарности тем, кто на нее откликнется, оставит комментарии и свои взгляды на решение проблемы. ))

Проблема или задача: мониторинг трафика провайдера на наличие ddos атак как со стороны своих абонентов и так и на них. Статья носит теоретический характер, практическая реализация зависит от каждого конкретного провайдера.

Немного теории здесь и здесь.

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

Учет трафика в сети провайдера в основном работает по следующей схеме — данные с оборудования о трафике абонента попадают на коллектор (в нашем случае используется netflow), где эти данные и обрабатываются.  Наша задача как раз и состоит в анализе этого трафика. Предлагаются следующие характеристики для анализа трафика:

— ip адрес;

— протокол;

— количество пакетов в потоке;

— количество байт в потоке.

Дальше просто анализируем количество потоков для одного ip адреса. Порог срабатывания в каждой сети и для каждого абонента может быть разный, опытным путем установили следующие значения: если из 1000000 потоков содержится более 10000 одинаковых записей, то скорее всего у клиента сетевая проблема (вероятно компьютер абонента заражен вирусом и участвует в атаке). Далее действия могут быть разными, пишем, звоним абоненту или сразу блокируем, все зависит от правил во взаимоотношении с клиентами. При количестве одинаковых потоков более 100000 проблема на сети провайдера будет видна невооруженным взглядом (конечно это будет зависеть от производительности оборудования).

Статья основана на собственном опыте, если у кого-то есть свои «выкладки», то будет интересно на них посмотреть.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор:  zaikini