Добрый День! Ситуация такая, имеются несколько 3750 они же шлюзы для пользователей во внешний мир. Кто-то из пользователей поймал почтовый вирус, который в свою очередь делает рассылку. Как можно стандартными (без установки netflow и т.д. )способами посмотреть на этих 3750 трафик по портам (25 порт) и от какого внутреннего ip он сыпется? Вообще такое возможно? Спасибо.
>Добрый День! Ситуация такая, имеются несколько 3750 они же шлюзы для пользователей
>во внешний мир. Кто-то из пользователей поймал почтовый вирус, который в
>свою очередь делает рассылку. Как можно стандартными (без установки netflow и
>т.д. )способами посмотреть на этих 3750 трафик по портам (25 порт)
>и от какого внутреннего ip он сыпется? Вообще такое возможно? Спасибо.
>sh int gige 1/0/25
sh ip traff
>sh int gige 1/0/25
>sh ip traffСпасибо. Это всё здорово, но надо именно по протоколу smtp (или 25 порт) и от какого внутренного ip... это возможно?
На самом коммутаторе можно через debug. Причем желательно создать ACL для отбора интересующего трафика (например по порту, на который стучится вирус) и вывести debug ip-пакетов, подпадающих под этот ACL. Учтите, что существует опасность сильного падения производительности на время дебага. Если циска сильно удаленная, то можно подстраховаться отложенной перезагрузкой. Или пионером, который в случае чего сможет дернуть ее по питанию
>На самом коммутаторе можно через debug. Причем желательно создать ACL для отбора
>интересующего трафика (например по порту, на который стучится вирус) и вывести
>debug ip-пакетов, подпадающих под этот ACL. Учтите, что существует опасность сильного
>падения производительности на время дебага. Если циска сильно удаленная, то можно
>подстраховаться отложенной перезагрузкой. Или пионером, который в случае чего сможет дернуть
>ее по питаниюСпасибо! Вот это интересно, а можно поподробнее или ссылочку где этот процесс поподробнее расписан?
>>На самом коммутаторе можно через debug. Причем желательно создать ACL для отбора
>>интересующего трафика (например по порту, на который стучится вирус) и вывести
>>debug ip-пакетов, подпадающих под этот ACL. Учтите, что существует опасность сильного
>>падения производительности на время дебага. Если циска сильно удаленная, то можно
>>подстраховаться отложенной перезагрузкой. Или пионером, который в случае чего сможет дернуть
>>ее по питанию
>
>Спасибо! Вот это интересно, а можно поподробнее или ссылочку где этот процесс
>поподробнее расписан?Ну например навесить на интерфейс фильтр (смотря в какую сторону ловить):
access-list 101 permit tcp any host aaa.bbb.ccc.ddd eq smtp log
access-list 101 permit tcp host aaa.bbb.ccc.ddd any eq smtp logИ смотреть что делается в консоле. Либо в режиме терминального подключения дав предварительно комманду term mon. Всё будет видно и без включения дебага.
Есть еще более безабидный вариант - заставить слушать трафик T-metr и писать лог =)
>>На самом коммутаторе можно через debug. Причем желательно создать ACL для отбора
>>интересующего трафика (например по порту, на который стучится вирус) и вывести
>>debug ip-пакетов, подпадающих под этот ACL. Учтите, что существует опасность сильного
>>падения производительности на время дебага. Если циска сильно удаленная, то можно
>>подстраховаться отложенной перезагрузкой. Или пионером, который в случае чего сможет дернуть
>>ее по питанию
>
>Спасибо! Вот это интересно, а можно поподробнее или ссылочку где этот процесс
>поподробнее расписан?Ну например навесить на интерфейс фильтр (смотря в какую сторону ловить):
access-list 101 permit tcp any host aaa.bbb.ccc.ddd eq smtp log
access-list 101 permit tcp host aaa.bbb.ccc.ddd any eq smtp logИ смотреть что делается в консоле. Либо в режиме терминального подключения дав предварительно комманду term mon. Всё будет видно и без включения дебага.
Есть еще более безабидный вариант - заставить слушать трафик T-metr и писать лог =)
>[оверквотинг удален]
>
>access-list 101 permit tcp any host aaa.bbb.ccc.ddd eq smtp log
>access-list 101 permit tcp host aaa.bbb.ccc.ddd any eq smtp log
>
>И смотреть что делается в консоле. Либо в режиме терминального подключения дав
>предварительно комманду term mon. Всё будет видно и без включения дебага.
>
>
>Есть еще более безабидный вариант - заставить слушать трафик T-metr и писать
>лог =)Спасибо, надо будет попробывать :)
а T-metr это под win ставить каждому клиенту? или я что-то не допонял?
>[оверквотинг удален]
>>И смотреть что делается в консоле. Либо в режиме терминального подключения дав
>>предварительно комманду term mon. Всё будет видно и без включения дебага.
>>
>>
>>Есть еще более безабидный вариант - заставить слушать трафик T-metr и писать
>>лог =)
>
>Спасибо, надо будет попробывать :)
>а T-metr это под win ставить каждому клиенту? или я что-то не
>допонял?этот debug ip packet или сислог довольно мрачная штука, в смысле онлайн просмотра трафика, т.к
1. дебаг глючт. у меня глючит, то не показывает всё, то вобще не показывает.
2. сислог что валит на консоль не показывает все пакеты, а суммарно за определённый момент времени.эсть еще 1 способ. можно настроить port mirroring смысл которого зеркалировать весь трафик который проходит через оперделённый порт и пускать его (траффик) на другой.
А в этот другой порт включить капмутер и ethereal`ом смотреть весь трафик.Switch(config)# monitor session 1 source interface gigabitethernet1/0/1
Switch(config)# monitor session 1 destination interface gigabitethernet1/0/2за сорс можно брать vlan что покроет ряд портов
>Спасибо, надо будет попробывать :)
>а T-metr это под win ставить каждому клиенту? или я что-то не
>допонял?Т-metr ставится на машине администратора в режим снифер.
Создаётся правило для пакетов по адресу и 25-му порту, соотв.
Согласно правилу должен писаться лог.