Reborn

Това е първата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

• Общи насоки, идеи, нужни услуги и размисли – тук ще се постарая аргументирано да обоснова защо съм избрал този комплект от софтуер и услуги
• Инсталация на базовата система – ще опиша методът по който ще инсталираме и минимизираме нашата система
• Конфигуриране на DNS и DHCP услугите – тук ще опиша обосновано конфигурациите които смятам за оптимални
• Конфигуриране на рутирането – като цяло тук е сърцето на нашият рутер. Ще предложа някои трикове за улесняване на живота, както и насоки към по-специфични задачи
• Конфигуриране на елементарна система за наблюдение и статистика
• Разширяване възможностите на нашият рутер – ще опиша някои дреболии които могат да направят живота ни много по лесен, удобен и приятен

Е да започваме с първата част.
Идеята
От известно време си мисля за тази серия от статии. Темата със SOHO рутерите е интересна от много гледни точки. От една страна това трябва да са евтини машини. От друга трябва да са достатъчно ефективни за да вършат работата. И може би последната гледна точка е че никъде няма описано подобно нещо. И вече наистина последно – просто ми е приятно да го напиша.

Нужни услуги
Тук трябва да се вложи най много мисъл. Трябва да се определи точно какви услуги ще се изпълняват на нашият рутер. Абсолютният минимум е рутиране/маскиране и SSH. Реално това е напълно достатъчно но и леко неудобно. Моят минимум е следният:

• Рутиране/маскиране/НАТ – без него няма смисъл от рутер
• SSH – за мениджмънт от конзола
• Кеширащ DNS – за наша собствена фалшива зона, скорост и частична независимост от нашия доставчик
• DHCP сървър който да ни настройва мрежата автоматично
• Минималистична web базирана система за наблюдение, статистики и елементарни проверки

Като цяло това е един добър комплект услуги които предоставят удобство на работа и изискват минимална поддръжка. Лично аз предпочитам допълнително да имам следните допълнителни услуги:

• Самба – за да укротя малко windows машините в мрежата. Предоставя MasterBrowser и WINS
• NTP сървър – предоставя точно време
• FTP сървър – за да мога отдалечено да си качвам дреболии

Размисли
Така вече сме избрали услугите, остана изборът на дистрибуция. Лично аз предпочитам дебиан и на него ще реализирам целият проект. Всеки е свободен да избере каквото иска, и най-вече това което му е удобно. Трябва от рано да се помисли за това как ще се проверява сигурността, кой ще има право на достъп до машината, дали ще се ползват квоти/ограничения във времето. Какъв тип маскиране ще се ползва и още дреболии. Повечето от тези въпроси изникват в процеса на работа, така че моля първо прочетете цялата серия и тогава започнете работа.

Общи насоки
Това не е елементарен проект. Предполага се че имате прилична представа какво точно се опитвате да постигнете. Всяка грешка допусната по време на инсталацията може наистина да ви ухапе след време. Така че мислете навреме и по няколко пъти.

Серията продължава в The Perfect SOHO router – Part 2

Тук ще представя една относително елементарна идея за мизерен web сървър. Предупреждавам няма никаква функционалност и доста ограничени възможности.

Защо
Ами по ред причини. Може да искате да имате много елементарни статистики, да речем натоварване на машината. Може да искате да паркирате някаква много елементарна страничка. Не искате да пускате пълнофункционален сървър и може би още тон причини.

Предпоставки
Ще предположим следното:

• Този web сървър ще е статичен
• Ще сервира една единствена страница/файл независимо какво иска клиента
• Ще работи на порт 8080

Теория на операцията

• Трябва ни нещо което да посрещне входящата заявка – в случая ще ползваме netcat който популярно е наричан “TCP/IP swiss army knife” заедно с един малък wrapper script.
• Трябва по някакъв начин да разберем че е дошла заявка – в случая това изобщо не ни интересува. В момента в който дойде трафик на нашия порт значи някой праща заявка, като свърши трафика значи заявката е свършила и ще си сервираме нашият отговор.
• Трябва да конструираме правилен отговор за да не объркаме клиента който ни пита за нещо.
• След това си вмъкваме нашето съобщение/файлче.
• И накрая разбира се терминираме сесията.

Реализация
Wrapper script-а който ще напишем за netcatима една единствена цел. Да стартира netcat след като той излезе, като слага известно забавяне. Забавянето е необходимо от гледна точка на предпазване от DoS атака. Не е ефективно но е елементарно. А и все пак се очаква че това нещо няма да работи на production машина.

/var/www/bashserver/netcat-server.sh

#!/bin/bash
#
# Simple wrapper for keeping nc alive as it exits after successfull request
# at least on debian it acts this way.
# Author: vvitkov
# ver: 0.1
# date: 18.07.2007
# licence: CC BY-SA 3.0

NC=$(which nc)
while [ ] ; do
$NC -l -p  8080 -e /var/www/bashserver/webserver.sh
sleep 1
done

Идеята на цялото това нещо е да се върти безкраен цикъл в който се пуска nc с определени параметри, чака се да излезе, изчаква се две секунди, и след това цялата въртележка на нова сметка.
Параметрите с които се пуска nc са както следва:

• -l – локален режим. Тоест nc ще работи като сървър.
• -p – порта на който ще слуша.
• -е – при връзка изпълни този скрипт и върни каквото върне той.

С това първата ни задачка по посрещането на трафика е изпълнена.

/var/www/bashserver/webserver.sh

#!/bin/bash
#
# Simple bash webserver. Nothing fancy
# Author: vvitkov
# ver: 0.1
# date: 18.07.2007
# licence: CC NC-BY-SA 3.0

# Our simple file which we will serve
FILE='/var/www/bashserver/message.txt'
# Construct propper headers
echo -e "HTTP/1.0 200 OK\r"
echo -e "Content-Type: `/usr/bin/file -bi \"$FILE\"`\r"
echo -e "\r"

# Now lets spit our data
cat "$FILE"

# And lets finish the transmission.
echo -e "\r"

Простичко нали. И което е по интересното върши добра работа.

Идеи за развиване
Модифициране на webserver.sh така че да приема параметър с който да се описва порта на който да слуша. Втори параметър който да указва кой файл точно да се изпълнява а не да е твърдо закодирано за webserver.sh. Евентуално дори трети параметър който да се предава към файла който изпълняваме и да указва кой файл да връщаме.
Модифициране на webserver.sh така че да бъде научен да разбира от заявките, а не просто да сервира един единствен файл.

Заключение
Този вебсървър е със много ограничено приложение и кажи речи пълна неизползваемост, но за определени цели върши работа.

Комуникацията е нещо важно. Не трябва да се подценява стойността на подслушаната информация въпреки че може да ви изглежда абсолютно безполезна. Особенно неприятно е да разбереш че само защото някой е подслушал невнимателното ти споменаване за любим плод и вече банковата ти сметка е опразнена. Мдаааа черногледо но напълно вероятно.
И така за да не ви се случват подобни работи в интернет пространството се препоръчва използване на криптиране. В днешната ни статия ще опишем как да защитите един от комуникационните канали а именно моменталната комуникация или както е известна IM. За огромно съжаление на някои потребители няма да се спрем на защитаването на всички възможни IM протоколи а само на един, а именно jabber

Използван Софтуер
Gajim
PSI
GnuPG

Идеята
Идеята е да криптираме съобщенията си посредством асиметрично криптиране (в главната роля GnuPG) и после да ги пускаме в Jabber мрежата. Използваните (тествани) клиенти са Gajim, PSI. За другите клиенти поровете из нета.

Изпълнението
Предполагаме че вече имате инсталирано всичко необходимо, т.е. jabber клиент който поддържа GnuPG и самото GnuPG.

Първата стъпка е да си генерираме частен ключ. Препоръчва се частният ключ да е малък за да се подобри скоростта на работа. Също така е добре да е отделен а не официалният който ползвате.

Има различни инструменти но в случая ще използваме конзолното приложение gpg.

gpg --batch --gen-key params

Във файла params са описани параметрите за генериране на ключа. Повече информация за формата на файла може да се открие gen-key non-interactively

примерен файл

Key-Type:DSA
Key-Length:1024
Key-Usage:encrypt,sign
Passphrase:parola
Name-Real:test1
Name-Email:tes...@jabber.org
Name-Comment:jabber encryption
 
%commit

Вече си имаме ключ. Сега трябва да го закачим за нашият клиент.
Това става от настройките на акаунта ни

За PSI

За Gajim

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

И последната стъпка която е необходима е на хората с които ще си чатим сигурно да присвоим публични ключове. Естествено необходимо е да се сдобием с тези ключове но както обяснихме е полезно те да са публикувани.
Операцията по присвояването на публичните ключове се извършва в менюто за конкретният контакт.

За PSI

За Gajim

И накрая вече можем да започнем да си чатим сигурно. Единственото необходимо нещо е да включим криптирането посредством катинарчето в прозореца

За PSI

За Gajim

Е това е всичко. Сега вече поне с някои хора може да си чатите сигурно.