Skip to content

Как получить список всех IPv4-сетей автономной системы

Описание алгоритма решения задачи "получить список всех сетей организации, если известен один IP-адрес".

1. Забиваем в гугл запрос "show ip bgp regex looking glass", находим какой-нибудь looking glass, поддерживающий команду "show ip bgp regex" и не обрезающий вывод. Например lg.as48972.net

2. Выясняем номер автономной системы с помощью команды whois или на каком-нибудь веб-сервисе. Для примера возьмем IP-адрес 46.219.4.0 одного из киевских провайдеров:

$ whois 46.219.4.0 | grep origin
origin:         AS31148

Итак, номер автономной системы провайдера Freenet (O3) - 31148.

3. Далее идем на найденный looking glass и в качестве аргумента указываем номер AS со знаком доллара на конце (если знак доллара не указать, то отобразятся еще и сети организаций, для которых AS 31148 является транзитной, что нам в данном случае не нужно):

Поиск всех префиксов заданной AS

Как найти все блоки адресов, принадлежащие организации

4. Жмем кнопку "Execute" и получаем длинный список примерно такого вида (приведен не полностью), где в самом левом столбце и перечислены искомые блоки адресов:

BGP table version is 0, local router ID is 95.130.232.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
* i46.219.1.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.2.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.3.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.4.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.5.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
*>i46.219.6.0/24    77.222.66.177                  90      0 16243 21219 31148 i
* i                 77.222.66.181                  90      0 16243 21219 31148 i
* i46.219.7.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.8.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.9.0/24    77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.10.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.11.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.12.0/24   77.222.66.181                  90      0 16243 21011 31148 i
*>i                 77.222.66.177                  90      0 16243 21011 31148 i
* i46.219.13.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.14.0/24   77.222.66.181                  90      0 16243 21011 31148 i
*>i                 77.222.66.177                  90      0 16243 21011 31148 i
* i46.219.15.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.16.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.17.0/24   77.222.66.181                  90      0 16243 21011 31148 i
*>i                 77.222.66.177                  90      0 16243 21011 31148 i
* i46.219.18.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.19.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.20.0/24   77.222.66.181                  90      0 16243 15772 28761 31148 i
*>i                 77.222.66.177                  90      0 16243 15772 28761 31148 i
* i46.219.21.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.22.0/24   77.222.66.181                  90      0 16243 21219 31148 i
*>i                 77.222.66.177                  90      0 16243 21219 31148 i
* i46.219.23.0/24   77.222.66.181                  90      0 16243 21011 31148 i

Если номер AS четрыхзначный, то может потребоваться поиграться с аргументом запроса, добавив экранированный обратным слешем пробел пред номером AS. То есть вписать в поле нечто такое: "\ 31148$" (чтобы не отображались те автономные системы, номер которых содержит номер нашей как подстроку).

Posted in Howto.

Tagged with .

rev="post-1585" 2 коментарі

By Admin – 24.06.2015

repoquery: поиск rpm-пакета, содержащего известный файл

Сегодня буду краток.

Есть такая часто возникающая задача – найти пакет, если не знаем его имени, но знаем имя какого-то бинарника, входящего в его состав.

Например, нужен бинарник phpize. Команда locate следов его присутствия не обнаружила даже после updatedb, "yum search" тоже не помогает. Значит, нужно установить пакет yum-utils, а затем делать так:

$ repoquery -q --file /*phpize
php-devel-0:5.3.3-40.el6_6.x86_64
php-devel-0:5.3.3-38.el6.x86_64

Немного поэкспериментировав, понял, что есть более краткая форма:

$ repoquery -f *phpize
php-devel-0:5.3.3-40.el6_6.x86_64
php-devel-0:5.3.3-38.el6.x86_64

Voilà!

Posted in *nix.

Tagged with , .

rev="post-1583" 1 comment

By Admin – 19.06.2015

Запрет использования нашего редиректора левыми сайтами

В большинстве популярных CMS из SEO-соображений (или для логирования переходов с сайта на другие сайты) имеется специальный скрипт-перенаправлялка, с помощью которого публикуемые в user-generated-content внешние ссылки автоматом преобразуется во внутренние. Работает такой скрипт просто – заставляет веб-сервер вернуть ответ с HTTP-статусом 30x (301, 302 или 303) и с передачей броузеру URL-а для перехода в HTTP-заголовке "Location:". На моем сайте такой скрипт живет по адресу "/go/".

Недавно на мой apache httpd стали приходить многочисленные зловредные запросы вот такого примерно вида (access-лог пишется в формате combined):

87.104.60.5 - - [06/May/2015:13:29:54 +0300] "GET /go/url=http://www.salmon.ro/christina/archives/000021.html HTTP/1.1" 303 - "http://davischiropracticinc.com/rd/?dku=http://redirect.rankey.com/redirect.html?site_url=avz.org.ua/go/url=http://www.salmon.ro/christina/archives/000021.html" "Opera/9.80 (Windows NT 6.2; Win64; x64) Presto/2.12.388 Version/12.16"

87.104.60.5 - - [06/May/2015:13:29:54 +0300] "GET /go/url=http://www.salmon.ro/christina/archives/000021.html HTTP/1.1" 303 - "http://shop.monard.se/redirector.php?url=http://www.lugnet.com/jump.cgi?http://avz.org.ua/go/url=http://www.salmon.ro/christina/archives/000021.html" "Opera/9.80 (Windows NT 6.2; Win64; x64) Presto/2.12.388 Version/12.16"

87.104.60.5 - - [06/May/2015:13:29:54 +0300] "GET /go/url=http://www.salmon.ro/christina/archives/000021.html HTTP/1.1" 303 - "http://www.guchol.net/redirect.php?url=http://www.christiancinema.com/catalog/redirect.php?action=url&goto=avz.org.ua/go/url=http://www.salmon.ro/christina/archives/000021.html" "Opera/9.80 (Windows NT 6.2; Win64; x64) Presto/2.12.388 Version/12.16"

Так как такие запросы обычно приходят большими пачками, то в это время load average резко растет, сервер начинает ощутимо тормозить и посетители моего сайта не могут нормально им пользоваться. Очевидно, что какая-то редиска использует нас в каких-то своих гнусных целях. Это, конечно же, нужно пресечь. Сделать это можно с помощью следующих директив модуля mod_rewrite (для случая, если наш защищаемый сайт имеет домен avz.org.ua):

RewriteCond %{HTTP_REFERER} !^http://(www\.)?avz\.org\.ua/.*
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.com.*
RewriteCond %{HTTP_REFERER} !^$
RewriteRule go/url=.* - [F]

Это означает, что если обращение к нашему редиректору происходит не с нашего сайта И не с гугловой выдачи И с не пустым HTTP-заговком Referer, то такие обращения блокируются, выдавая HTTP status code 403 (Forbidden) вместо кода 30x. Выдать 403 сразу на уровне апача намного быстрее, чем передавать запрос на обработку интерпретатору PHP.

Posted in Веб-приложения.

Tagged with , .

rev="post-1576" 1 comment

By Admin – 09.05.2015

yum: лечим [Errno 14] problem making ssl connection

Однажды после добавления на сервере с CentOS 6 очередного репозитория в yum я обнаружил, что yum c ним работать отказывается, выдавая печальное сообщение об ошибке "problem making ssl connection":

$ cat /etc/issue ; uname -r
CentOS release 6.4 (Final)
Kernel \r on an \m
 
2.6.32-358.2.1.el6.x86_64
 
$ sudo yum install apache-maven
Loaded plugins: fastestmirror, security
Setting up Local Package Process
Examining apache-maven-3.2.5-1.el6.noarch.rpm: apache-maven-3.2.5-1.el6.noarch
Marking apache-maven-3.2.5-1.el6.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
 * base: mirror.raystedman.net
 * extras: yum.tamu.edu
 * rpmforge: mirror.hmc.edu
 * updates: mirror.cogentco.com
http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml: [Errno 14] problem making ssl connection
Trying other mirror.

Сразу возник вопрос – какой нафиг SSL, если URL начинается с http? При более пристальном изучении URL-а с помощью curl-а оказалось, что там есть 302-ой редирект на URL, начинающийся с https:

$ curl -v http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml
* About to connect() to repos.fedorapeople.org port 80 (#0)
*   Trying 152.19.134.191... connected
* Connected to repos.fedorapeople.org (152.19.134.191) port 80 (#0)
> GET /repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-redhat-linux-gnu) libcurl/7.21.0 NSS/3.12.10.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4
> Host: repos.fedorapeople.org
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Wed, 25 Feb 2015 12:19:43 GMT
< Server: Apache/2.2.15
< Location: https://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml
< Cache-Control: max-age=0
< Expires: Wed, 25 Feb 2015 12:19:43 GMT
< Content-Length: 352
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml">here</a>.</p>
<hr>
<address>Apache/2.2.15 Server at repos.fedorapeople.org Port 80</address>
</body></html>
* Closing connection #0

Так как свежий maven был все еще очень нужен, продолжаем разбираться дальше. У yum-а есть переменная окружения, включающая отладочный лог:

# URLGRABBER_DEBUG=1 yum install apache-maven 2> /tmp/yum-debug.log

В результате в файле /tmp/yum-debug.log получаем 45КБ инфы от urlgrabber-а, самое полезная часть которой выглядит вот так:

< HTTP/1.1 302 Found
< Date: Wed, 25 Feb 2015 11:16:47 GMT
< Server: Apache/2.2.15
< Location: https://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml
< Cache-Control: max-age=0
< Expires: Wed, 25 Feb 2015 11:16:47 GMT
< Content-Length: 352
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
2015-02-25 11:16:47,307 header ended:
INFO:urlgrabber:header ended:
< 
* Closing connection #0
* Issue another request to this URL: 'https://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml'
* About to connect() to repos.fedorapeople.org port 443 (#0)
*   Trying 152.19.134.191... * connected
* Connected to repos.fedorapeople.org (152.19.134.191) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -8092
* Closing connection #0
* SSL connect error
2015-02-25 11:16:47,522 exception: [Errno 14] problem making ssl connection
INFO:urlgrabber:exception: [Errno 14] problem making ssl connection
2015-02-25 11:16:47,523 calling callback: (<bound method YumBaseCli.failureReport of <cli.YumBaseCli object at 0x7fd1ad643410>>, (), {})
INFO:urlgrabber:calling callback: (<bound method YumBaseCli.failureReport of <cli.YumBaseCli object at 0x7fd1ad643410>>, (), {})
http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/repodata/repomd.xml: [Errno 14] problem making ssl connection
Trying other mirror.
2015-02-25 11:16:47,523 MIRROR: failed
INFO:urlgrabber:MIRROR: failed
2015-02-25 11:16:47,523 GR   mirrors: [] 0
INFO:urlgrabber:GR   mirrors: [] 0
2015-02-25 11:16:47,524 MAIN mirrors: [http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/] 0
INFO:urlgrabber:MAIN mirrors: [http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6/x86_64/] 0
Error: Nothing to do

Не шибко информативно, однако. Но вот одна строчка из всей этой простыни NSS error -8092 навела на мысль, что можно попробовать обновить библиотеки NSS:

$ rpm -qi nss | sed -r '/^Description/,$ !d'
Description :
Network Security Services (NSS) is a set of libraries designed to
support cross-platform development of security-enabled client and
server applications. Applications built with NSS can support SSL v2
and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509
v3 certificates, and other security standards.
 
$ sudo yum -y update nss

И таки случилось чудо! Yum перестал выдавать ошибку, подхватил свежедобавленный репозиторий и поставил мне нужные RPM-пакеты.

Happy End :)

Кстати, еще может быть похожая беда, когда yum пишет "[Errno 14] Peer cert cannot be verified or peer cert invalid". В моём случае это было связано с неправильной установкой времени на сервере. После синхронизации часов эта ошибка пропала. Если установка правильного времени не помогла, тогда в качестве временного workaround-а может быть полезной установка опции sslverify=false в конфиге yum-а (/etc/yum.conf).

Posted in *nix, Howto.

Tagged with , , .

rev="post-1565" 5 коментарів

By Admin – 25.02.2015