Skip to content

By Тодор in Фун

Tags:

By Тодор in Uncategorized, Windows, Мрън-мрън

Та освен, че са доста неудобни за работа с една ръка HTC телефоните с тъч скрийн (Windows mobile) имат и друг ОГРОМЕН пропуск – сортират телефонния указател по “Фамилия, Име” – доста непрактично според мен.
Единият вариант е да се редактират всички контакти един по един, като за всеки се посочи в опцията “File as” как желаем да го виждаме.
Имало и малко по-лесенв ариант как да “преобразим” всички – Contact Changer.
Прикачам и копие на програмчето, за да пробвате.

Contact_changer_v1.3

(Конкретно се възмущавам от HTC Diamond)

By Тодор in Linux

За линукс рутери е много добра идея да се следи състоянието на ip_conntrack_count таблциата. Препълни ли се – повече не се препращат заявки. А и чисто статистически е добре да имате идея колко се товари рутера.
Най удобния инструмент за отдалечен мониторинг е SNMP, да но ip_conntrack_count по подразбиране го няма там.
Ето как да си го направим:

Пишем едноредово скриптче, което ще проверява колко конекции са заети (ip_conntrack_count):
#!/bin/bash
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

Записваме скрипта в /root/ctrack.sh
Правим го изпълним:
chmod +x /root/ctrack.sh

Някъде към края на snmpd.conf се добавя:
exec conntrac_count /root/ctrack.sh

Правим проверка:
# snmpwalk -v2c -c public localhost .1.3.6.1.4.1.2021.8
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: conntrac_count
UCD-SNMP-MIB::extCommand.1 = STRING: /root/ctrack.sh
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: 44234
UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

Изхода от скриптчето вече се вижда в UCD-SNMP-MIB::extOutput.1.

Сигурно стопляте колко мощен е този инструмент. Може да се добави и роботче за проверка на температурата на хард дисковете с нещо от сорта на:
/usr/sbin/smartctl -A /dev/hdа | grep -i temperaturе | awk '{print $10}'

Въпрос на фантастика ;)
Честито на успелите!

By Тодор in Мрън-мрън

By Тодор in Linux

Това е елементарна защита на хост с отворен достъп по SSH. Налага се поради огромния брой сканиращи роботчета и злонамерени персонажи, които опитват да налучкат пароли за достъп.
Логиката на тази защита е – следи се лог файла /var/log/secure и при наличие на повече от 5 грешни опита за влизане през SSH блокира достъпа на IP адреса чрез iptables правило.

Изваждане на списъка с “провинилите” се адреси:

# cat /var/log/secure | grep "]: Failed " | awk -F "from " '{print $2}' | awk '{print $1}' | sort | uniq -d -c | awk '{if ($1 > 5) print $2}' > /ssh-banned.txt
(всичко е на един ред)

Всички адреси, които са правили повече от 5 неуспешни опита да влязат през SSH ще се запишат в /ssh-banned.txt.

Следва да се блокира достъпа на тези адреси.
Добавя се това в началото на firewall скрипта, който ползвате:

#!/bin/bash
SSHBAN=/ssh-banned.txt
if [ -f $SSHBAN ]; then
for BAN_IP in `cat $SSHBAN`
do
iptables -A INPUT -s $BAN_IP -j DROP
done
fi

Скрипта парсва файла с адресите и добавя блокиращо iptables правило за всеки адрес от него.

За автоматизиране се добавя в cron:

*/10 * * * * cat /var/log/secure | grep "]: Failed " | awk -F "from " '{print $2}' | awk '{print $1}' | sort | uniq -d -c | awk '{if ($1 > 5) print $2}' > /ssh-banned.txt && /etc/rc.d/rc.fw

Приемам че firewall-ът е в /etc/rc.d/rc.fw, необходимо е дой да се стартира винаги след като списъка с баннатите адреси се опредни. Променете го с пътя до вашия.

(Примерът е за Red Hat базирани дистрибуции)

Tags: , , ,

By Тодор in FreeBSD, Linux, Solaris, Windows

Наистина могат да се намерят 49582638 причини да ползвате прокси – няма да изброявам нито една.
Бърз, лесен и най-вече сигурен начин е ползването на SSH прокси. Т.е. трафикът ви се прекарва през SSH тунел до “точката за достъп до Интернет” (проксито).

Конфигурира се PuTTY да направи тунел до отстрешната страна:
PuTTY Tunnel setup

PuTTY Tunnel setup

По желание може да се ползва и компресиране на трафика:
PuTTY Tunnel setup - compression

Закачайки се за отсрещния хост с SSH вече имате изграден тунел през локален TCP порт 45678. Не е задължително да ползвате root за да се логнете, всъщност най-добре да е ограничен акаунт с лимитиран шел – вместо bash, променете го на lynx да кажем.

Конфигурация на браузъра да ползва тунела:
Firefox SOCKS using SSH tunnel

Почти всяко мрежово програмче включително skype може да ползва SOCKS проксиране – настройва се елементарно, както виждате :)

Можете да споделите въпросите си в коментарите.

By Тодор in FreeBSD, Linux, Solaris, Windows

Налага се някои сайтове да са защитени с парола ползвайки basic механизъма на Apache или друг подобен. Сайтовете са защитени наистина… докато някой не открадне паролата, а това е лесно – много хора ползват елементарни пароли от сорта на “12345″, името си, фамилията, ЕГН, телефонен номер и т.н. Паролата може да бъде записана на листче, някой може да види какво натискате по клавиатурата и пак да бъде открадната.
Един по-добър метод е ползването на клиентски сертификати. В баузъра на клиента има инсталиран сертификат, който го идентифицира пред сървъра при опит за отваряне на защитен сайт. Сървърът предоставя достъп само на валидни за него сертификати.
Казах “по-добър метод”, което означава, че кражбата на сертификата е по-трудна от кражбата на парола. Значително по-трудна.

Създаваме СА (Certificate Authority):

# openssl genrsa -aes256 -out ca.key 2048
Generating RSA private key, 2048 bit long modulus
..............+++
...................................................................+++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:

Добре е да сложим парола на личният ключ – ако някой го докопа ще може да си вади колкото си иска сертификати с него.

# openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Enter pass phrase for ca.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:BG
State or Province Name (full name) [Berkshire]:Plovdiv
Locality Name (eg, city) [Newbury]:Plovdiv
Organization Name (eg, company) [My Company Ltd]:Kamenitza.ORG
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:Kamenitza.ORG
Email Address []:

Common Name: – името на организацията, която ще притежава сертификата, не е нужно да е интернет адрес.

Следва да се създаде потебителският сертификат:

# openssl genrsa -out todor.key 2048
Generating RSA private key, 2048 bit long modulus
.....................+++
..................................................................................+++
e is 65537 (0x10001)
# openssl req -new -key todor.key -out todor.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:BG
State or Province Name (full name) [Berkshire]:Plovdiv
Locality Name (eg, city) [Newbury]:Plovdiv
Organization Name (eg, company) [My Company Ltd]:Kandev
Organizational Unit Name (eg, section) []:Kandev
Common Name (eg, your name or your server's hostname) []:Todor Kandev
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
# openssl x509 -req -in todor.csr -out todor.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650
Signature ok
subject=/C=BG/ST=Plovdiv/L=Plovdiv/O=Kandev/OU=Kandev/CN=Todor Kandev
Getting CA Private Key
Enter pass phrase for ca.key:
# openssl pkcs12 -export -in todor.crt -inkey todor.key -name "Todor Kandev Cert" -out todor.p12
Enter Export Password:
Verifying - Enter Export Password:

Паролата сложена тук се ползва при инсталацията на сертификата. Без нея не може да бъде импортнат в браузъра.

todor.p12 – е потребителският сертификат, който трябва да се импортне в браузъра на клиента.

За да ограничим достъпа до дадена директория от сайт слагаме това в .htaccess файла:

SSLVerifyClient require
SSLVerifyDepth 1

Или в <directory> на конфигурационния файл на Apache.

Но най-важното е да кажем на Apache, кои са “доверените” сертификати и как да ги познава. За това трябва да се постави този ред в конфигурационният файл на Apache:

SSLCACertificateFile /ssl/ca/ca.crt

(естествено заменете пътя с вашия)

След рестартиране на Апача всичко би трябвало да работи.

(В статията приемам, че сайтът е вече конфигуриран успешно да работи с SSL сертификат през HTTPS)

By dimo in Uncategorized

Работеща (за моят случай ) кофигурация  за SIP TRUNK поставете я в PEER DETAILS , като не забравяйте да да зададете в

REGISTER STRING 35932ххххх:сип паролата(secret)@sip.cooolbox.bg/35932хххххх

PEER DETAILS

[out]
host=sip.cooolbox.bg
username=35932xxxxxx
secret=xxxxxxxxx
type=peer
canreinvite=no
fromdomain=sip.cooolbox.bg
dtmfmode=inband
dtmfmode=rfc2833
fromuser=35932xxxxxx
nat=yes
insecure=port,invite
dtmf=rfc2833
context=from-pstn

ако не сте объркали нещо имате работеща изходяща линия :)

By Тодор in FreeBSD, Linux, Solaris, Windows

IIS а и много други програми ползват сертификати в pkcs12 формат (и публичният и частният ключ се съхраняват в един файл – PFX).

openssl pkcs12 -export -in my.crt -inkey my.key -certfile my.bundle -out my.pfx

Tags:

By Тодор in Uncategorized

keystore – е хранилището за сертификати и лични ключове ползвани например за SSL криптиране в tomcat. За Java, управлението на подобни плючове е поверено на инструмента keytool.
За по-голямо неудобство този инструмент не може да импортва както и да експортва лични ключове.
Прикачам програмчето KeyTool IUI, с чиято помощ това става възможно.
ktl241sta.tar

By Тодор in Uncategorized, Windows

wmic product get /format:csv > Software_%Computername%.csv

Списъкът ще бъде експортнат в CSV файла.

By Тодор in Uncategorized

Това, че Гугъл вече поддържат синхронизация, подобно на Exchange е наистина страхотно и полезно. Ползвам Mail for Exchange от доста време и се радвам, че вече може да се ползва и с пощата на Гугъл.
Проблем обаче се оказа ъпгрейдването до версия 3.00.хх на Mail for Exchange – поради някаква причина, за която Гугъл мълчат, а Нокиа не ги е грижа (понеже те официално не поддържат ГМаил синхронизация), се появява съобщение за грешка веднага след синхронизация на e-mail съобщенията, гласящо “sync failed. contact your administrator if the problem persists”. Да се свържите с администратора, ще ви е толкова полезно, колкото и това подробно и изпълнено с дебъг информация съобщение на него.

Проблемът се решава с инсталирането на по-стара версия на Mail for Exchange…

Прикачвам няколко работещи версии тук:
MailForExchange(2.9.158)_S60_3_0
MailForExchange(2.9.158)_S60_3_1
MailForExchange(2.9.158)_S60_3_2

By Тодор in FreeBSD, Linux, Solaris

Преди да получим SSL сертификат за даден адрес първо трябва да се изгенерира файл който съдържа информация за собствника и адреса на сайта – Certificte Signing Request (CSR). Информацията от CSR-a бива подписана от избран от нас CA (Certificate Authority) – Thawte, VeriSign, GoDaddy и др, след което вече имаме готов сертификат.

Пъро се генерира личният ключ:
# openssl genrsa -out private.key 2048

С този личен ключ се генерира CSR:
# openssl req -new -key private.key -out certreq.csr

Попълват се данните за сертификата, като от най-голямо значение е Common Name, което трябва да съвпада с пълният адрес на сайта (mail.server.com).
Файлът certreq.csr съдържа “искането” за сертификат. След генерирането на подписаният сертификат, той вече не е нужен.

By Тодор in Linux

Това е нещо, което би помогнало на машина с бавни дискове или просто на някой, който желае да корегира скоростите по подразбиране на синхронизиране на масива при евентуално разпадане или друг повод.
До тук знаем, че статус на масивите можем да видим с:
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdc1[1] hda1[0]
200704 blocks [2/2] [UU]
md1 : active raid1 hdc2[1] hda2[0]
312367744 blocks [2/2] [UU]
[>....................] resync = 1.5% (4937472/312367744) finish=10184.0min speed=500K/sec

Текущата скорост на синхронизиране можете да видите и така:
# cat /sys/block/md1/md/sync_speed
549

Максималната и минимална разрешени скорости са тук:
# cat /sys/block/md1/md/sync_speed_max
500 (local)

# cat /sys/block/md1/md/sync_speed_min
500 (local)

В този пример ръчно съм настроил максималната и минимална скорост на 500KB/s.
По подразбиране минималната е 1000 а максималната 200000.
За да ги корегираме правим така:
# echo 500 > /sys/block/md1/md/sync_speed_min
# echo 500 > /sys/block/md1/md/sync_speed_max

Промените влизат в сила веднага, но не се запазват след рестарт. Ако желаете те да са валидни и след рестартиране на машината, добавете тези редове в rc.local.

By Тодор in Linux

На всеки рутер обслужващ повечко IP адреси се налага ръчно увеличаване на максималния размер на conntrack таблицата.
В Ubuntu Server 8.04 става така:

В /etc/modules се добавя следният ред:
nf_conntrack

Това зарежда модула при стартиране на машината.
След това в /etc/sysctl.conf се добавя този ред:
net/nf_conntrack_max=100000

Един рестарт и резултата може да се види в:
sysctl -a