Ctrl + ↑ Позднее

RSOP — Invalid Name Space

4 мая 2016, 11:56

Recently had an issue where an entire site was not downloading domain policies. After a thorough search and different attempts to fix the issue I came across a batch file that I want to list here for future reference:

make the following into a batch file

net stop winmgmt

pause

c:

cd c:\windows\system32\wbem

rd /S /Q repository

regsvr32 /s %systemroot%\system32\scecli.dll

regsvr32 /s %systemroot%\system32\userenv.dll

mofcomp cimwin32.mof

mofcomp cimwin32.mfl

mofcomp rsop.mof

mofcomp rsop.mfl

for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s

for /f %%s in ('dir /b *.mof') do mofcomp %%s

for /f %%s in ('dir /b *.mfl') do mofcomp %%s

mofcomp exwmi.mof

mofcomp -n:root\cimv2\applications\exchange wbemcons.mof

mofcomp -n:root\cimv2\applications\exchange smtpcons.mof

mofcomp exmgmt.mof

After running this re-run the GPUPDATE /force

Подсветка кода в эгее с помощью highlight.js

17 февраля 2016, 7:54

На демо странице highlight.js подбираем понравивщуюся тему оформления. Допустим, приглянулась гитхабовская тема.

В браузере открываем http://yandex.st/highlightjs/7.3/styles/github.min.css. Убеждаемся, что файл с темой есть, и мы не ошиблись в названии темы.

В папке с эгеей по пути user/extras/ создаем файл footer-post.tmpl.php. Подробнее — в документации.

Добавляем в файл код

<link rel="stylesheet" href="//yandex.st/highlightjs/7.3/styles/github.min.css">
<script src="//yandex.st/highlightjs/7.3/styles/github.min.css"></script>
<script>
hljs.tabReplace = ' ';
hljs.initHighlightingOnLoad();
</script>

hljs.tabReplace нужен для того, чтобы табуляции в коде заменялись на пробелы. Так как я часто копирую из редактора, данная опция приятна.

Форматер стратей — Нисден. Он понимает html код, так что тело вставляемого кода выглядит примерно так:

так что тело вставляемого кода выглядит примерно так:
<pre><code>
так что тело вставляемого кода выглядит примерно так:
...
</code></pre>
Теперь код в постах будет подсвечиваться.

Одно из больших преимуществ highlight.js, это то, что не обязательно указывать язык, который необходимо подсветить. highlight.js сам определяет на каком языке написан исходный код. Хотя можно явно указывать на каком языке написан исходный код, добавляя class к тегу pre.

Второй плюс — хостинг скриптов и стилей на яндексе.

Спасибо Илье Бирману за прекрасный движок блога и Ивану Сагалаеву за не менее прекрасный раскрашиватель исходного кода.

Tomcat — Digest Authentication

17 февраля 2016, 7:50

Digest authentication is one of authentication type available on web server. This is very similar with Basic authentication and, the main difference, is using a encoded password. This password is stored into Realm implementation and this allow you to store encoded text password on your web server.

In this article I’ll show you the digest authentication implementation on tomcat 7.

In the previous article I described how use basic authentication on glassfish server. It works well and, with the use of SSL layer, you can guarantee a good security level.

In the above scenario you’ve to put your password in clear on your Realm implementation (the default implementation used on tomcat is locate in WEB-INF/web.xml file). In default configuration, the password are stored, in clear text, inside tomcat-user.xml file.

If you’d like to avoid writing a clear text password inside a file under a web server, you can use a ‘digest’ password keeping the same basic’s authentication behaviour.

Let’s go to see how it works.

First, generate a digest password from your username, realm domain and password:

C:\apache-tomcat-7.0.23\bin\digest -a SHA role1:Digest:tomcat
role1:Digest:tomcat:7ae6875fc8dae751b0dae641da40239596427566

Next, put it inside a conf/tomcat-users.xml file.

<user name="role1"  password="7ae6875fc8dae751b0dae641da40239596427566" roles="role1"  />

Now it’s time to configure the web.xml inside the web app.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>OrderSecurityDigest</display-name>
  <security-constraint>
        <web-resource-collection>
            <web-resource-name>MySecureResource</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>role1</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
         <auth-method>DIGEST</auth-method>
         <realm-name>Digest</realm-name>
    </login-config>
 
</web-app>

Browsing the url http://localhost:8080/OrderSecurityDigest you’ll see the authentication popup. Put in your correct password (in clear text) and you’ll be authenticated into the web application.

Another interesting thing is the communication between the client and the server:

Authorization: Digest username=«role1», realm=«Digest», nonce=«1341216860988:9e5c9ca69c2da31090dfa800d4903f1f», uri=«/OrderSecurityDigest/», cnonce=«779639542ec4763a54d4ffc720610778», nc=00000001, response=«7ab0267c538298c72eeb5b9a2070db33», qop=«auth», opaque=«FFEAFA67F1EA622D2C11A7BB5E487ACE»
As you can see, you aren’t able to read a clear password from this called. Not bad.

More references are available at tomcat official web site: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#Digested_Passwords

UPDATE TOMCAT 7

I’ve noticed that this example don’t work on tomcat 7. That’s because, from the official documentation “If using digested passwords with DIGEST authentication, the cleartext used to generate the digest is different and the digest must use the MD5 algorithm“. So, the steps are:

Activate the MemoryRealm into the server.xml

<Realm className="org.apache.catalina.realm.MemoryRealm" digest="md5" />

Defined the role and the user into the tomcat-user.xml

<role rolename="manager-gui"/>
<user username="sysadmin" password="540a9c1784e90890e640dc4d296b4c10" roles="manager,admin"/>

And last my web.xml

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    id="WebApp_ID" version="3.0">
    <display-name>OrderSecurityDigest</display-name>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>MySecureResource</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>
    <security-role>
    <role-name>admin</role-name>
  </security-role>
  <login-config>
        <auth-method>DIGEST</auth-method>
        <realm-name>myrealm</realm-name>
    </login-config>
 
</web-app>

My password generation:

digest -a md5 sysadmin:myrealm:mypassword

IP SLA CISCO

17 февраля 2016, 7:10

Прочитал две статьи «Dual ISP на маршрутизаторах cisco без BGP» и «Одновременное использование двух провайдеров на маршрутизаторах cisco». На ум пришла мысль попробовать нарисовать и описать решение к ещё одной, немного нестандартной задаче.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).

Одно из возможных решений (так сказать «в лоб») может выглядеть так:
interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip policy route-map tracking
!
route-map tracking permit 10
match ip address 1
set default interface Dialer1 Dialer0
!
route-map tracking permit 20
match ip address 2
set default interface Dialer0 Dialer1
!
access-list 1 permit 192.168.0.101
access-list 2 deny 192.168.0.101
access-list 2 permit 192.168.0.0 0.0.0.255

Да, такая конструкция работает, но есть один недостаток, причём достаточно не очевидный.
Может наблюдаться такая ситуация, что и статус и протокол могут находиться в состоянии Up, а канал может не работать. Тогда эта конструкция ничем не поможет.
Что-же делать? Всё очень просто: использовать возможности sla.
Что нам для этого надо? Просто надо переписать route-map tracking и написать правила для sla.
interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip policy route-map tracking
!
track 123 rtr 1 reachability
!
track 124 rtr 2 reachability
!
ip sla 1
icmp-echo 195.5.5.208 source-interface Dialer1
timeout 2000
threshold 2
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 193.34.140.1 source-interface Dialer0
timeout 2000
threshold 2
frequency 3
ip sla schedule 2 life forever start-time now
!
route-map tracking permit 100
match ip address 1
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
!
route-map tracking permit 120
match ip address 2
set ip next-hop verify-availability 193.34.140.1 10 track 124
set ip next-hop verify-availability 195.5.5.208 20 track 123
!
route-map tracking permit 200
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
!
access-list 1 permit 192.168.0.101
access-list 2 deny 192.168.0.101
access-list 2 permit 192.168.0.0 0.0.0.255

Собственно всё банально просто. ;)
route-map перестаёт отрабатывать для пакета свои правила после того как обнаружит первое-же совпадение. Поэтому, собственно, порядок определения сиквенсов важен!
Теперь если мы взглянем на состояние интерфейсов то увидим:
#sh ip int br | i ^Dialer
Dialer0 193.34.141.151 YES IPCP up up
Dialer1 unassigned YES IPCP up up

При этом видим, что и статус и протокол Dialer1 находятся в состоянии up, т. е. первый вариант route-map tracking не сработал бы и клиент 192.168.0.101 просто не работал бы. Но если мы взглянем на статистику по route-map tracking из второго варианта то увидим:
#sh route-map tracking
route-map tracking, permit, sequence 100
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
Policy routing matches: 711 packets, 95929 bytes
route-map tracking, permit, sequence 120
Match clauses:
ip address (access-lists): 2
Set clauses:
ip next-hop verify-availability 193.34.140.1 10 track 124 [up]
ip next-hop verify-availability 195.5.5.208 20 track 123 [down]
Policy routing matches: 216 packets, 14100 bytes
route-map tracking, permit, sequence 200
Match clauses:
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
Policy routing matches: 0 packets, 0 bytes

Состояние в ip next-hop verify-availability 195.5.5.208 10 обозначено как down, а соответственно эти маршруты установлены не будут.

ps: Многие комментарии которые можно было бы вставить опущены, так как подразумевается, что предварительно были прочтены указанные выше две статьи, а, следовательно, читатель знает о чём идёт речь.

iptables rules for NAT with FTP active / passive connections

8 января 2016, 9:16
If you have an FTP server running behind a server that acts as the gateway or firewall, here are the rules to enable full NAT for active and passive connections.

# general rules for forwarding traffic between external interface tap0 and internal interface eth0
iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
iptables -A FORWARD -i tap0 -o eth0 -m state —state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tap0 -j ACCEPT

# NAT for active/passive FTP. 192.168.178.21 would be your internal ftp server
iptables -t nat -A PREROUTING -p tcp  —dport 20 -j DNAT —to 192.168.178.21:20
iptables -t nat -A PREROUTING -p tcp  —dport 21 -j DNAT —to 192.168.178.21:21
iptables -t nat -A PREROUTING -p tcp  —dport 1024:65535 -j DNAT —to 192.168.178.21:1024-65535
iptables -A FORWARD -s 192.168.178.21 -p tcp —sport 20 -j ACCEPT
iptables -A FORWARD -s 192.168.178.21 -p tcp —sport 21 -j ACCEPT
iptables -A FORWARD -s 192.168.178.21 -p tcp —sport 1024:65535 -j ACCEPT

# allowing active/passive FTP
iptables -A OUTPUT -p tcp —sport 21 -m state —state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp —sport 20 -m state —state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp —sport 1024: —dport 1024: -m state —state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp —dport 21 -m state —state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp —dport 20 -m state —state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp —sport 1024: —dport 1024: -m state —state ESTABLISHED,RELATED,NEW -j ACCEPT

You must also have IPv4 forwarding enabled, check by

# should return 1
cat /proc/sys/net/ipv4/ip_forward

# otherwise
sysctl -w net.ipv4.ip_forward=1
and edit /etc/sysctl.conf like so “net.ipv4.ip_forward = 1″

You also need to have ip_nat_ftp and ip_conntrack_ftp modules loaded. Check for them

lsmod | grep ip_nat_ftp
lsmod | grep ip_conntrack_ftp
# if no result then load them until next reboot, google for making it permanent depending on your OS
modprobe ip_nat_ftp
modprobe ip_conntrack_ftp

add to /etc/sysconfig/iptables-config
IPTABLES_MODULES=″ip_nat_ftp ip_conntrack_ftp″
Ctrl + ↓ Ранее