On X server you can export your display so the apps starts on one server and interfaces shows on another X server. Here is example how to do it.
Configuration:
On remote Linux (192.168.10.5):
# export DISPLAY="192.168.10.9:0"
On local Linux (192.168.10.9):
KDM/GDM/XDM by default on Debian use option -nolisten tcp. You need to remove it to allow X server to accept connections. Restart of display manager is needed.
# xhost + 192.168.10.5
Next step is to start application on remote Linux and it will show on your local Linux X server.
# yast2
Wednesday, May 1, 2013
Wednesday, April 24, 2013
Novell Enterprise Linux Server Install and Migration Notes
Novell NetWare 5.1 to Novell Enterprise Linux (OES2) migration scenario: The idea is to add new OES2 server to the existing NetWare 5.1 tree, add replica of the tree, transfer data files from storage volumes and then remove old NetWare 5.1 server.
Notes are for this version of Novell Linux:
# cat /etc/novell-release
Novell Open Enterprise Server 11 (x86_64)
VERSION = 11.1
PATCHLEVEL = 1
You get this error when trying to add the new server to existing tree. This is bug in installation process. The Unix Config Object which is needed to map users between eDirectory and linux/unix workstation/servers is not created in installation process. Solution is to remove /etc/nam.conf file and recreate it with namconfig.
This is known bug. Use command line to start what you need:
Open your iManager with a browser, login to old server and then add the replica:
Partitions and Replica Management -> Replica View
Enter tree name: .YourTreeName. and hit OK. Now you can see your servers and replicas. Use the "Add Replica" button. If you get an error try using 'ndsrepair' on all servers and then try again.
Notes are for this version of Novell Linux:
# cat /etc/novell-release
Novell Open Enterprise Server 11 (x86_64)
VERSION = 11.1
PATCHLEVEL = 1
Note #1
Updates - you need your registration codes and email address so you can use online updates and install from online repositories. YAST -> Software Management -> Configuration -> Online Update. This will launch browser and lead you to novell site where you need to enter your registration email/codes so the server can be authenticated as licensed one. If everything is ok the new repositories will be added automatically.
Note #2
Time between all servers in the tree must me synchronized. Use same time server for both servers.
Note #3
If you get error about Secure LDAP connection with Novell NetWare 5.x you need to generate valid certificate for Secure LDAP on NetWare with ConsoleOne app.
Note #4
"This user does not have the correct credentials to authenticate to the CIMOM client."You get this error when trying to add the new server to existing tree. This is bug in installation process. The Unix Config Object which is needed to map users between eDirectory and linux/unix workstation/servers is not created in installation process. Solution is to remove /etc/nam.conf file and recreate it with namconfig.
# rm -f /etc/nam.conf
# namconfig add -a cn=admin,o=company_ltd -r o=company_ltd -w ou=servers,o=company_ltd -S 192.168.20.5:389 -l 636
Enter the admin(cn=admin,o=company_ltd) password:
namconfig.getSchemaName: schema name = cn=schema
NAM Schema is extended successfully.
NAM Unique id schema is already extended.
uidNumber and gidNumber attribute indices already exist in the LDAP server
Creating the Unix Config object...done.
Creating the Unix Workstation object...done.
Adding the workstation context...done.
Stopping the service 'namcd'...done.
Stopping the service 'nscd'...done.
Starting the service 'namcd'... Done.
Starting the service 'nscd'... Done.
Configure done successfully.
Now you can use iManager to enable users for linux (Linux User Management -> Enable Users for Linux)
Note #5
Removing the tree# ndsconfig rm -a cn=adminuser.o=admincontextNow start YAST and use OES Installation and Configuration utility to add it to the existing tree.
Note #6
OES Installation and Configuration utility won't startThis is known bug. Use command line to start what you need:
# yast edirectoryor you can see what options you have with the command:
# yast --listYou can also use yast2 (graphical interface) in the same way.
Available modules:
add-on
add-on-creator
apparmor
arkmanager
audit-laf
autofs
autoyast
backup
bootloader
ca_mgm
checkmedia
common_cert
dhcp-server
dirinstall
disk
dns-server
dsl
edirectory
fingerprint-reader
.....
Note #7
Adding replica to the newly connected serverOpen your iManager with a browser, login to old server and then add the replica:
Partitions and Replica Management -> Replica View
Enter tree name: .YourTreeName. and hit OK. Now you can see your servers and replicas. Use the "Add Replica" button. If you get an error try using 'ndsrepair' on all servers and then try again.
Note #8
You can use miggui tool to transfer existing files/services to the new server but if you have files in cyrillic or in some other encoding created in the old days when nobody cared about encodings this tool won't work.
Thursday, April 11, 2013
Installing ezmlm on Debian squeeze with existing qmail and vpopmail system.
This is a quick explanation how to install and configure ezmlm-idx on Debian Squeeze on existing qmail/vpopmail installation.
Since ezmlm-idx is not on an official Debian release we need to build our own deb package. First we need to add experimental sources in /etc/apt/sources.list:
# ezmlm-make /home/vpopmail/domains/lists.example.com/testlist /home/vpopmail/domains/lists.example.com/.qmail-testlist testlist lists.example.com
Change ownership of newly created files and directories.
# chown vpopmail:vchkpw /home/vpopmail/domains/lists.example.com/* -R
# chown vpopmail:vchkpw /home/vpopmail/domains/lists.example.com/.* -R
This will make mailing list "testlist" on domain lists.example.com. You can subscribe by sending mail at address testlist-subscribe@lists.example.com. For more information you can see man pages of ezmlm and by sending mail to testlist-help@lists.example.com.
Since ezmlm-idx is not on an official Debian release we need to build our own deb package. First we need to add experimental sources in /etc/apt/sources.list:
Update and get the source:
deb-src http://ftp.bg.debian.org/debian/ experimental main contrib non-free
# apt-get updateInstall additional packages needed by ezmlm-idx (if you are planning to use it with mysql/pgsql):
# apt-get source ezmlm-idx
# apt-get install libmysqlclient-dev libpq-devThere is a Debian specific bug (probably that is why ezmlm-idx is not in the official release) inside this package and it is path to qmail-queue program. The path to qmail-queue is hardcoded in file conf-qmail: "/var/lib/qmail" and ezmlm-manage tries to launch it from there. Solutions are either to edit conf-qmail file and change path to /usr/sbin or to make a link:
# mkdir /var/lib/qmailNow build the package:
# ln -s /usr/sbin /var/lib/qmail/bin
# cd ezmlm-idx-7.1.1If everything is ok there will be three new deb packages.
# dpkg-buildpackage -uc -rfakeroot
# ls -laInstall it:
total 2232
drwxr-xr-x 3 root root 4096 Apr 8 11:58 .
drwxr-xr-x 10 root root 4096 Apr 8 11:50 ..
drwxr-xr-x 5 root root 24576 Apr 8 11:58 ezmlm-idx-7.1.1
-rw-r--r-- 1 root root 104602 Apr 8 11:58 ezmlm-idx-mysql_7.1.1-1~exp0_i386.deb
-rw-r--r-- 1 root root 105098 Apr 8 11:58 ezmlm-idx-pgsql_7.1.1-1~exp0_i386.deb
-rw-r--r-- 1 root root 5508 Apr 8 11:57 ezmlm-idx_7.1.1-1~exp0.diff.gz
-rw-r--r-- 1 root root 837 Apr 8 11:57 ezmlm-idx_7.1.1-1~exp0.dsc
-rw-r--r-- 1 root root 2447 Apr 8 11:58 ezmlm-idx_7.1.1-1~exp0_i386.changes
-rw-r--r-- 1 root root 1284294 Apr 8 11:58 ezmlm-idx_7.1.1-1~exp0_i386.deb
-rw-r--r-- 1 root root 718954 Apr 17 2012 ezmlm-idx_7.1.1.orig.tar.gz
# dpkg -i ezmlm-idx_7.1.1-1~exp0_i386.debNow we can make our mailing list. If vpopmail is installed in /home/vpopmail here is the command to make new mailing list:
Selecting previously deselected package ezmlm-idx.
(Reading database ... 42574 files and directories currently installed.)
Unpacking ezmlm-idx (from ezmlm-idx_7.1.1-1~exp0_i386.deb) ...
Setting up ezmlm-idx (7.1.1-1~exp0) ...
Processing triggers for man-db ...
#
# ezmlm-make /home/vpopmail/domains/lists.example.com/testlist /home/vpopmail/domains/lists.example.com/.qmail-testlist testlist lists.example.com
Change ownership of newly created files and directories.
# chown vpopmail:vchkpw /home/vpopmail/domains/lists.example.com/* -R
# chown vpopmail:vchkpw /home/vpopmail/domains/lists.example.com/.* -R
This will make mailing list "testlist" on domain lists.example.com. You can subscribe by sending mail at address testlist-subscribe@lists.example.com. For more information you can see man pages of ezmlm and by sending mail to testlist-help@lists.example.com.
Labels:
build,
deb,
debian,
dpkg-buildpackage,
ezmlm,
ezmlm-idx,
ezmlm-make,
install,
mailing list,
package,
qmail,
source,
squeeze,
vpopmail
Friday, April 5, 2013
Опасностите от DNSSEC протокола или как "събориха" www.spamhaus.org.
Нека да започнем с малко предистория... Краят на 90-те се появи първата атака от типа DDoS или Distributed Denial of Service, останала в историята като smurf атака. Накратко - чрез изпращането на ICMP пакети с подправен source IP адрес (с IP-то на жертвата) до broadcast адреси на големи мрежи се получаваше умножен в пъти ответен трафик към жертвата.
Този тип атаки биха се осъществили при наличието на три фактора:
Тъй като icmp smurf атаката отдавна лесно се филтрира, и е заложено на новите рутери по default да не отговарят на icmp broadcast запитвания, като че ли напоследък този тип атаки бяха позабравени.
Ако се запитаме, кой протокол отговаря на гореспоменатите изисквания, веднага изниква един основен протокол в интернет - DNS. DNS работи както по UDP, така и по TCP (повече може да прочетете за това в една моя статия: http://geroyblog.blogspot.com/2012/07/dns-1-resolvers-cache.html). При наличието по дизайн на DNS cache сървъри се вижда, че dns протоколът отговаря и на изискването да има умножител на трафик. В случаят това са DNS cache сървърите.
Какво имам в предвид?
Нека да направим едно рекурсивно запитване към някой dns cache сървър (например google public dns - 8.8.8.8).
Запитване за mx запис без да се използва TCP:
Ако променим 192.168.1.76 адреса, който е нашият, сложим този на "жертвата" и изпратим 1 мегабайт заявки към публичния DNS съръвр на google, "жертвата" ще получи 19.5 мегабайта трафик. Умножение има, и то не малко, но като цяло не би трябвало да достигне ефекта на ICMP Smurf атаката.
Не толкова отдавна беше предложен, приет, променен, надграждан много пъти една нова надстройка на текущия DNS протокол, която според създателите им (главно isc.org) би решила проблемa със сигурността му.
Тъй като и аз се оплетох при четене на RFC (над 20 rfc - http://www.dnssec.net/rfc), които стандартизират DNSSEC и като цяло мнението ми е, че е прекалено усложнен протокол, ще го кажа на кратко.
Идеята на DNSSEC е за всеки DNS запис да имате подписан със сертификат кореспондиращ запис. Това би предотвратило DNS cache poisoning атакаите при положение, че протокола масово навлезе при всички операционни системи - както сървърни, така и клиентски софтуер. Ако направим запитване за MX - запис, наблюдаваме следният ефект:
Като цяло, изводът е, че DNSSEC протокола по дизайн е великолепен умножител на трафик. Наскоро проверявах, и се оказа, че всички основни домейни като .com, .net, .org, .info и т.н., както и cc-домейните (country code) като .bg, .ru, .se и т.н. са подписани и поддържат DNSSEC.
Какви са защитите срещу това?
В общи линии трябва да се ограничат UDP - заявките за DNS да са до 512 байта от самите рутери по пътя. За DNSSEC да се използва само TCP (което би забавило отговорите така че няма пълно щастие). Rate limit на заявките по UDP към 53-ти порт от firewalls или от самата имплементация на софтуера за DNS cache сървър. Филтриране на трафик от spoofed source IP адреси.
Статията е публикувана и на адрес: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=games&key=455227892
Този тип атаки биха се осъществили при наличието на три фактора:
- Използването на stateless протокол, при който не се очаква обратна връзка - например ICMP, UDP;
- Наличието на рутери по трасето до жертвата, позволяващи трафик с фалшив source IP адрес;
- Пожелателно е да има някакъв вид умножение на трафик, тоест жертвата да получи в пъти повече трафик, отколкото атакуващият изпраща.
Тъй като icmp smurf атаката отдавна лесно се филтрира, и е заложено на новите рутери по default да не отговарят на icmp broadcast запитвания, като че ли напоследък този тип атаки бяха позабравени.
Ако се запитаме, кой протокол отговаря на гореспоменатите изисквания, веднага изниква един основен протокол в интернет - DNS. DNS работи както по UDP, така и по TCP (повече може да прочетете за това в една моя статия: http://geroyblog.blogspot.com/2012/07/dns-1-resolvers-cache.html). При наличието по дизайн на DNS cache сървъри се вижда, че dns протоколът отговаря и на изискването да има умножител на трафик. В случаят това са DNS cache сървърите.
Какво имам в предвид?
Нека да направим едно рекурсивно запитване към някой dns cache сървър (например google public dns - 8.8.8.8).
Запитване за mx запис без да се използва TCP:
# dig mx +notcp google.com @8.8.8.8При пуснат tcpdump се вижда,че изпратената заявка е 28 байта, а полученият отговор е 136 байта.
11:26:05.900877 PPPoE [ses 0xbb] IP 192.168.1.76.64805 > 8.8.8.8.53: 26451+ MX? google.com. (28)Приблизително 4.9 пъти умножение на трафика. Ако направим запитване ANY - трафика се увеличава до 546 байта, при което умножението се качва до 19.5 пъти.
11:26:05.945839 PPPoE [ses 0xbb] IP 8.8.8.8.53 > 192.168.1.76.64805: 26451 5/0/0 MX aspmx.l.google.com. 10, MX alt2.aspmx.l.google.com. 30, MX alt1.aspmx.l.google.com. 20, MX alt3.aspmx.l.google.com. 40, MX alt4.aspmx.l.google.com. 50 (136)
Ако променим 192.168.1.76 адреса, който е нашият, сложим този на "жертвата" и изпратим 1 мегабайт заявки към публичния DNS съръвр на google, "жертвата" ще получи 19.5 мегабайта трафик. Умножение има, и то не малко, но като цяло не би трябвало да достигне ефекта на ICMP Smurf атаката.
Не толкова отдавна беше предложен, приет, променен, надграждан много пъти една нова надстройка на текущия DNS протокол, която според създателите им (главно isc.org) би решила проблемa със сигурността му.
Тъй като и аз се оплетох при четене на RFC (над 20 rfc - http://www.dnssec.net/rfc), които стандартизират DNSSEC и като цяло мнението ми е, че е прекалено усложнен протокол, ще го кажа на кратко.
Идеята на DNSSEC е за всеки DNS запис да имате подписан със сертификат кореспондиращ запис. Това би предотвратило DNS cache poisoning атакаите при положение, че протокола масово навлезе при всички операционни системи - както сървърни, така и клиентски софтуер. Ако направим запитване за MX - запис, наблюдаваме следният ефект:
# dig mx +notcp +dnssec isc.org @8.8.8.8Нека направим запитване ANY записи за домейна isc.org:
; <<>> DiG 9.4.1-P1 <<>> mx +notcp +dnssec isc.org @8.8.8.8
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27208
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;isc.org. IN MX
;; ANSWER SECTION:
isc.org. 6419 IN MX 10 mx.pao1.isc.org.
isc.org. 6419 IN MX 10 mx.ams1.isc.org.
isc.org. 6419 IN RRSIG MX 5 2 7200 20130501233249 20130401233249 50012 isc.org. v0fb7TcHcwdjN2XZqSZfogavpS7T1ODK+rau7j1hiMJML2UdSPGpqiwf xyizY5yIcObHmF926xebjOsg1WFPJy85Fdhv/r2uD+Ibzo7QQL3QbQbp FqQlgpZUQHUFU/dpmZswRoZcMlRC4AhpkbsvYic4xbFV6O4z0hpgYUQ9 jgM=
;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr 2 11:58:14 2013
;; MSG SIZE rcvd: 251
# dig any +notcp +dnssec isc.org @8.8.8.8Тук се вижда, че при заявка от 36 байта се получава отговор от 3064 или 85.1 пъти повече трафик! Сега ако сменим source IP адреса на пакета с този на жертвата и това бъде направено от ботнет от 50000 зомбирани компютри, досещате ли се какво се получава?
; <<>> DiG 9.4.1-P1 <<>> any +notcp +dnssec isc.org @8.8.8.8
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 5644 IN SOA ns-int.isc.org. hostmaster.isc.org. 2013040200 7200 3600 24796800 3600
isc.org. 5644 IN RRSIG SOA 5 2 7200 20130501233249 20130401233249 50012 isc.org. k/eRQT9zlZu+9HQr3WLl5ZwCAagwbD4cKkbYX7poLGzWFDWbgPC2ZN6J ZmNEQnz6dS4GYiuFX5NiEEyxHAVlpxUz6mdBM21TjHEH6OBqOsyOHMbA RMi9ijCN2coY2X28uhZ/cpcZccTPXQwEIN2PwqILVxbMq31+2bEXUZa5 DOY=
isc.org. 5644 IN NS sfba.sns-pb.isc.org.
isc.org. 5644 IN NS ams.sns-pb.isc.org.
isc.org. 5644 IN NS ns.isc.afilias-nst.info.
isc.org. 5644 IN NS ord.sns-pb.isc.org.
isc.org. 5644 IN RRSIG NS 5 2 7200 20130501233249 20130401233249 50012 isc.org. opQ2IchpAm1TXFiXBDxCeHwnFDBWzn41PCeoKRpLmLqSGyx867360zSc sBDXtE4Co4Z5IG7S4jUVZd8iXz0Y3CK3FZ/Yd1PD9c3T0Xwjku+HvF8j /h9LrlnFGi40i/4k1vE/5sTb+U4NEYKLowKb/gsoXRgVrgiASKRnAdsw vXg=
isc.org. 5644 IN A 149.20.64.42
isc.org. 5644 IN RRSIG A 5 2 7200 20130501233249 20130401233249 50012 isc.org. Y9xN05o0BP+l2S6wTHlIPbLo8DuBVZOhZZ750IO6nS+3cHZ0XJEa3DzL 2O1gXQW8kCadF4yrLFT5XmBhfDbI94VBzBiYGvZ2vRcjPYtto4O2sxPw NQ+u6e/IcnHIIdueklz1dI8LgLn8+ZwtZ9+CUCRMhjwQtlejbxQEjLBe Gmo=
isc.org. 5644 IN MX 10 mx.ams1.isc.org.
isc.org. 5644 IN MX 10 mx.pao1.isc.org.
isc.org. 5644 IN RRSIG MX 5 2 7200 20130501233249 20130401233249 50012 isc.org. v0fb7TcHcwdjN2XZqSZfogavpS7T1ODK+rau7j1hiMJML2UdSPGpqiwf xyizY5yIcObHmF926xebjOsg1WFPJy85Fdhv/r2uD+Ibzo7QQL3QbQbp FqQlgpZUQHUFU/dpmZswRoZcMlRC4AhpkbsvYic4xbFV6O4z0hpgYUQ9 jgM=
isc.org. 5644 IN TXT "$Id: isc.org,v 1.1791 2013-03-27 00:02:30 ziegast Exp $"
isc.org. 5644 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 5644 IN RRSIG TXT 5 2 7200 20130501233249 20130401233249 50012 isc.org. qW2z10OjWeBpQ34YhbbluUFK5N8ELTxDXsa3dN1LI+/KEu9F/rzWh+KL ndoq2PsMeznJ6vTFVOSwm+602sIPb++cajgg1+fZAewNAWALJpEYLpYp TgIwbwZo7NoyGo1EUmMjqslFP+2uOgylIl8MHv/+XzbNivBZBNG0n4eQ Rb8=
isc.org. 5644 IN AAAA 2001:4f8:0:2::d
isc.org. 5644 IN RRSIG AAAA 5 2 7200 20130501233249 20130401233249 50012 isc.org. Vj/4QQYtDNPw8oNU3H7lXSIKsQQLSOQiyTq1oYgbCPp4sWcx8RMyW64e 962azK7av5/NqE0c4WSQ2NXN/rBL17U7iwdeFkVO8ZVQSNGp7Kanah8T LCzhpNqcV0Op2PIor1JgcuNXiYLp3b5H0KpAI+Ibue3wzfsr48LYs0D2 7ik=
isc.org. 5644 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 5644 IN RRSIG NAPTR 5 2 7200 20130501233249 20130401233249 50012 isc.org. pXwjHqeueJk64dm4FJKz7JuwBjaa2CK3zJ4sODtnnsj7yeesTHckfnHk O+DJUVlgXf/GbxQ0tQ1y+qZXjmHKmsjp+oapsmebC9T6pZZwy3EHznQW KLDhhcnbLztyXWMS8o0cDm1uk35YhGvfhLpgMV2grfVaX0WU8VZTLLjq HBI=
isc.org. 2044 IN NSEC _adsp._domainkey.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 2044 IN RRSIG NSEC 5 2 3600 20130501233249 20130401233249 50012 isc.org. fg3o/hFWeDIoFMo/pyKRGAz+LiE5f4HTJq6YvunBP/UpRenEFxZhVBxa tTn0v5ZeNq1XzLTm1JWl0yKUVmYwaHDnrH86j35iK+GnJ42UyQo0iv5r PHd6rakaPmMfq+6TK9FP1kUjJDgH/syYDRbSHbaynIBTR2zhpB8Y45xM Xa0=
isc.org. 5644 IN DNSKEY 256 3 5 BQEAAAABwuHz9Cem0BJ0JQTO7C/a3McR6hMaufljs1dfG/inaJpYv7vH XTrAOm/MeKp+/x6eT4QLru0KoZkvZJnqTI8JyaFTw2OM/ItBfh/hL2lm Cft2O7n3MfeqYtvjPnY7dWghYW4sVfH7VVEGm958o9nfi79532Qeklxh x8pXWdeAaRU=
isc.org. 5644 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 5644 IN RRSIG DNSKEY 5 2 7200 20130501230129 20130401230129 12892 isc.org. UFxebBneKnZHasXdUtdD6LsSbso2twRVuVOLuG6sMdfkV2io52GASy/a xIHHAJTOZYHOGyfqCrEKDkTJ3V6e0i9g52B5dy8IsAZY5IaGK4OmcCWr utkqzzBofeLkWP0UqNMc7xZsi6zD4CPqqi1sxT1sb7/fimImTTBJnr44 hcES7tVDttq9Nd0/wc+sSyFo9KIkhPNQgIc/t2SZ0jGJqJOiOnUI3SkH qVAkn+a0Km1cbkqd19JxMEPc+KP1ke4InCQPD+yHS/wWsjeJ2Ajh97vp +1HzivRA9rTRr20P3HrolyVzOPvV8r4n6LXmJDOHRfAnwzq+vnWqNPlE sLO6pQ==
isc.org. 5644 IN RRSIG DNSKEY 5 2 7200 20130501230129 20130401230129 50012 isc.org. vxFVIb9MIY4AnMTiADKkAtFo0nwgNh4B2UTSCDF7m5q3S8iJGTlfO3EK PK0ilpinqnHXFWx+k3UiR8eRf7xMPBKONjNA8GdcAZ7XgdPgi2Ri0yOs DXApZLKgByIkc5B976UKJ5wRFR/eGs5Loqby+j6HHpeNRS0v5N2rfbUI 3kU=
isc.org. 5644 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 5644 IN RRSIG SPF 5 2 7200 20130501233249 20130401233249 50012 isc.org. ZBxS3Pg0D3apDPAbIUcRVTBkIaScqYyWt2jUkeWbSZ4FrEpY4V8ZA2VN vsw/uu5WcAnxu42xOjLqGi0tLbpbcfKu7NnzijgzJcxGaBw3iIJrK9lS htqMysY1F14hn4r3NXzfN9hWps0v7IKPAbnKQHKtcThDjF7hE7S7EbLU gy4=
;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr 2 11:54:43 2013
;; MSG SIZE rcvd: 3064
Като цяло, изводът е, че DNSSEC протокола по дизайн е великолепен умножител на трафик. Наскоро проверявах, и се оказа, че всички основни домейни като .com, .net, .org, .info и т.н., както и cc-домейните (country code) като .bg, .ru, .se и т.н. са подписани и поддържат DNSSEC.
# dig any +dnssec com @8.8.8.8Тук стигаме и до атаката срещу анти-спам листата spamhaus.org. Тъй като те предоставяха лист от спамерски IP адреси дистрибутирани чрез DNS, тази атака доведе до отказ на услуги на този анти-спам доставчик. Атаката е била осъществена чрез множество DNS open recursive resolvers и DNSSEC протокола. Ендовременно с това се забелязва увеличение на спам - мейлите, които се разпространяват по интернет. Това означава, че атака е координирана.
; <<>> DiG 9.4.1-P1 <<>> any +dnssec com @8.8.8.8
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55969
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;com. IN ANY
;; ANSWER SECTION:
com. 899 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1364891984 1800 900 604800 86400
com. 899 IN RRSIG SOA 8 1 900 20130409083944 20130402072944 23975 com. ifejuy4CNjIISV4kpWe1jjrwM03nluADb6K43W4px4UWPj0JI8bQ61oN KEs1708MkGIbH9hLehTTEwKEZ0sKj91LXUyiWzIPF/oCjWkX+IeZYCTM tAM1euj+hOiaNiPVtQBChcgaQ0CiJM+DFxrofs/uk0Xcytvxw0MoJwVp DIY=
com. 21599 IN NS j.gtld-servers.net.
com. 21599 IN NS g.gtld-servers.net.
com. 21599 IN NS i.gtld-servers.net.
com. 21599 IN NS k.gtld-servers.net.
com. 21599 IN NS l.gtld-servers.net.
com. 21599 IN NS d.gtld-servers.net.
com. 21599 IN NS c.gtld-servers.net.
com. 21599 IN NS m.gtld-servers.net.
com. 21599 IN NS a.gtld-servers.net.
com. 21599 IN NS h.gtld-servers.net.
com. 21599 IN NS f.gtld-servers.net.
com. 21599 IN NS e.gtld-servers.net.
com. 21599 IN NS b.gtld-servers.net.
com. 21599 IN RRSIG NS 8 1 172800 20130408041926 20130401030926 23975 com. AOYql4O2Zi6v013LUQXSo5K0VuzmfSZzb9Qk/UEAlziHoDUVDvhkceQu 8nseo8PKKJZwhmjhRde5mIuVFfTHIb6Hbv+29UnXhBVguD54I4J7lbRE BEMnJIjrJSs84W8uUgiUsZ4dKuMU0pTXcEonLIfQuUNfltuTifYOOPm+ Mk8=
com. 21599 IN DNSKEY 257 3 8 AQPDzldNmMvZFX4NcNJ0uEnKDg7tmv/F3MyQR0lpBmVcNcsIszxNFxsB fKNW9JYCYqpik8366LE7VbIcNRzfp2h9OO8HRl+H+E08zauK8k7evWEm u/6od+2boggPoiEfGNyvNPaSI7FOIroDsnw/taggzHRX1Z7SOiOiPWPN IwSUyWOZ79VmcQ1GLkC6NlYvG3HwYmynQv6oFwGv/KELSw7ZSdrbTQ0H XvZbqMUI7BaMskmvgm1G7oKZ1YiF7O9ioVNc0+7ASbqmZN7Z98EGU/Qh 2K/BgUe8Hs0XVcdPKrtyYnoQHd2ynKPcMMlTEih2/2HDHjRPJ2aywIpK Nnv4oPo/
com. 21599 IN DNSKEY 256 3 8 AQPcnY9mVa8t+3ab9SsbKjGh38DXxdCZsL0sCdUEzyj1b3nN9BFLolfM o7PyfRhOw29YvgwHq1wRB2nRWcOpuUZhgZNOxWqLoOu84KR7HtQmY1yZ uSkh9WA6mUDQT+i/7zpUVbtmZqNJm5SuQZFE0hn+N5CMxnXOLOsHJsn6 WvB1sQ==
com. 21599 IN RRSIG DNSKEY 8 1 86400 20130408182533 20130401182033 30909 com. ohJvhu03H5M8PrkIcQDoozJjpokwWKKNfFqUXeU/pdvlY3X63IyJWXTZ 8qBp0lvhYWKHTpmGCCDBTC1X/DO+RXyYZAiQBeh8MVjyW4ZC8gz2/lS7 NTGRHmhCOFjsvYk6WNHy9vUqUomNuDDD9qIAS1HkYCmNGuo/2umLb+zU lsU8gcl6TyZIyepbeuTZQ4rkf+O53yJLngitaAoVCDI+hJE0OWZNAYg0 8AmJyuEZcnYlFUbuqR/SnL5FAfdo7XY9I5y5eJnWRT1YoFFcp6NTwZl8 KLlSLRhfLmIsP8mPGf3inJNnJ79MB6m6aArvo5aXWDhBM4HxbjkRZlO3 +cBu4g==
com. 21599 IN TYPE51 \# 5 0100000000
com. 21599 IN RRSIG TYPE51 8 1 86400 20130408041926 20130401030926 23975 com. 2dfpD6RLPMGOM3HrPfvhSAPKb26oCeF0jX6Kd8xrCI3/YhiRJu80ilPA 5mQo9uduxAPHcn0E+G+Vu69PEmlTySbDgjZ6m4TA6LeCx1wEdX+6x7uc Z2ksNVqQBitZnjl+3Fb+ou2ekJjSk8mUjqbsHNtz/4u2nJ4zD1/bkDcc 0Jc=
;; Query time: 326 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr 2 12:06:02 2013
;; MSG SIZE rcvd: 1528
Какви са защитите срещу това?
В общи линии трябва да се ограничат UDP - заявките за DNS да са до 512 байта от самите рутери по пътя. За DNSSEC да се използва само TCP (което би забавило отговорите така че няма пълно щастие). Rate limit на заявките по UDP към 53-ти порт от firewalls или от самата имплементация на софтуера за DNS cache сървър. Филтриране на трафик от spoofed source IP адреси.
Статията е публикувана и на адрес: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=games&key=455227892
Monday, March 25, 2013
Ураганен вятър в Габрово - последствия #2
От Градище към телевизионната кула по пътеката.
Телевизионната кула - разни неща паднали.
От кулата по пътя надолу.
През гората наодлу. Пътят е непроходим и пеша!
Телевизионната кула - разни неща паднали.
От кулата по пътя надолу.
През гората наодлу. Пътят е непроходим и пеша!
Tuesday, March 19, 2013
Ураганен вятър в Габрово - последствия.
Ето малко снимки от последствията от урагана на 14.03.2013 в Габрово.
Гората над "Петкова Нива"
Полянката до "Горското Ханче"
Такова чудо лично аз никога не бях преживявал.
Гората над "Петкова Нива"
Местност "Градище"
Полянката до "Горското Ханче"
Такова чудо лично аз никога не бях преживявал.
Tuesday, March 12, 2013
Debian GNU/Linux mounting Novell NetWare volumes
This is example of mounting Novell NetWare 5.1 partitions with Debian GNU/Linux (in this case - unstable with kernel 3.2.0).
First we need ncpfs package.
Then we need ncpfs module in kernel (it comes with debian kernel).
Novell Context is support.gabrovo.hq
Username is niki
Server IP address is 10.1.42.24
Volume to mount is called - data
-o tcp - use tcp (or -o udp)
-S 10.1.42.24 - server name/ip address.
-A 10.1.42.24 - which server to ask for name addresses.
-U niki.support.gabrovo.hq - niki is the user name and support.gabrovo.hq is context tree.
-V data - name of the volume to mount - "data".
If you did something wrong when mounting you can clear all your connections to novell with the following command:
First we need ncpfs package.
# apt-get install ncpfs
Then we need ncpfs module in kernel (it comes with debian kernel).
# modprobe ncpfs
Novell Context is support.gabrovo.hq
Username is niki
Server IP address is 10.1.42.24
Volume to mount is called - data
# ncpmount -o tcp -S 10.1.42.24 -A 10.1.42.24 -U niki.support.gabrovo.hq -V data /mnt/Mount options and what they mean as follow:
Logging into 10.1.42.24 as NIKI.SUPPORT.GABROVO.HQ
Password:
# ls -la /mnt/
total 5
drwxr-xr-x 1 root root 512 Jan 1 1986 .
drwxr-xr-x 24 root root 4096 Mar 7 14:12 ..
dr-xr-xr-x 1 root root 512 Mar 12 13:57 MAN
# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 389G 23G 362G 6% /
udev 10M 0 10M 0% /dev
tmpfs 596M 848K 595M 1% /run
/dev/disk/by-uuid/2e00092b-1986-4e86-9887-996ff2949e05 389G 23G 362G 6% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.4G 172K 3.4G 1% /run/shm
10.1.42.24/NIKI.SUPPORT.GABROVO.HQ 137G 132G 4.9G 97% /mnt
-o tcp - use tcp (or -o udp)
-S 10.1.42.24 - server name/ip address.
-A 10.1.42.24 - which server to ask for name addresses.
-U niki.support.gabrovo.hq - niki is the user name and support.gabrovo.hq is context tree.
-V data - name of the volume to mount - "data".
If you did something wrong when mounting you can clear all your connections to novell with the following command:
# ncplogout -a
Subscribe to:
Posts (Atom)