UNI-FIX Computer

Når du har haft din første server på nettet i et par uger vil du uden tvivl opdage at alt muligt rakkerpak på nettet står og banker på døren konstant … det kan være alt fra rigtigt hackere til scriptkiddies og automatiserede bots, orme og vira … alt i alt en masse ting som vi rigtig gerne vil undgå at blive forstyrret af 🙂

Vi starter som altid med at installere software:

root@lab1:~# apt-get install fail2ban

Dernæst skynder jeg mig og white-liste min egen ip … særligt når jeg eksperimenterer med opsætningen, jeg redigerer /etc/fail2ban/jail.conf og i linie ca 15-20 ser du flg:

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 
bantime  = 600

Der tilføjer jeg min egen IP:

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 192.168.1.5
bantime  = 600

Derefter genstarter jeg fail2ban og starter en tail på logfilen:

root@lab1:~# tail -f /var/log/fail2ban.log 
2012-05-10 20:52:39,750 fail2ban.jail   : INFO   Jail 'ssh' stopped
2012-05-10 20:52:39,750 fail2ban.server : INFO   Exiting Fail2ban
2012-05-10 20:52:40,003 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4-SVN
2012-05-10 20:52:40,004 fail2ban.jail   : INFO   Creating new jail 'ssh'
2012-05-10 20:52:40,004 fail2ban.jail   : INFO   Jail 'ssh' uses poller
2012-05-10 20:52:40,016 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2012-05-10 20:52:40,017 fail2ban.filter : INFO   Set maxRetry = 6
2012-05-10 20:52:40,018 fail2ban.filter : INFO   Set findtime = 600
2012-05-10 20:52:40,018 fail2ban.actions: INFO   Set banTime = 600
2012-05-10 20:52:40,083 fail2ban.jail   : INFO   Jail 'ssh' started

Som du måske har regnet ud så handler fail2ban ligeså meget generelt om serveren som om selve Apache, og lige her i første omgang er den sat op til at tage sig af ssh-syndere … det er jo dejlig nemt at teste … jeg finder en offentlig maskine, som ikke er den jeg lige har whitelistet, og laver et ulovligt loginforsøg:

lab2:~# ssh lab1.mikjaer.com -l root
root@lab1.mikjaer.com's password: 
Permission denied, please try again.
root@lab1.mikjaer.com's password: 
Permission denied, please try again.
root@lab1.mikjaer.com's password: 
Permission denied (publickey,password).

og så modtager vi flg. på vores log:

2012-05-10 20:54:44,257 fail2ban.actions: WARNING [ssh] Ban 192.168.1.10

og mit næste forsøg resulterer i flg:

lab1:~# ssh lab1.mikjaer.com -l root
ssh: connect to host lab1.mikjaer.com port 22: Connection timed out

Kort og kontant … effektivt! Efter 600 sekunder (ban time) kommer den her automatisk:

2012-05-10 20:58:34,529 fail2ban.actions: WARNING [ssh] Unban 192.168.1.10

Lad os aktivere et af filtrene til apache, på linie ca. 152:

[apache]

enabled = false
port    = http,https
filter  = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

Det er meget svært og gætte hvad der skal ændres ikke? Korrekt!, enables = true:

[apache]

enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

Så genstarter jeg fail2ban … og forsøger at gætte mit htaccess password, og efter 6 forsøg bliver jeg blacklistet 😀

Det er nemt selv at skrive regler, og der er en masse forudefinerede relger 🙂 Så se og kom igang og vær proaktiv med sikkerheden.

Der er mange, rigtig mange, og det vil blive for uoverskueligt at skulle lave et indlæg om hver, så derfor kommer her et par stykker som jeg bare løber hurtigt igennem.visitors /var/log/apache2/access.log > /var/www/dump.html

————–

http://goaccess.prosoftcorp.com/

———————

root@specialhosting:~# apt-get install analog

edit # vi /etc/analog.cfg

udkommenter stierne til apache config filerne, så kun /var/log/apache2/access.log er synlig, fjern udkommeringen fra OUTFILE og HOSTNAME, og kør så “analog” i den mappe du ønsker resultet skal lagres i.

GlusterFS er et netværks filsystem, der blandt andet tillader os at holde mapper i sync på tværs af netværket, der er meget mere i Gluster end det … nok til at jeg kunne lave en hel måned kun med det … men vi holder os til emnet lidt endnu 🙂

Vi tager udgangpunkt i det CDN vi lavede igår, og lægger GlusterFS ovenpå det. Det giver muligvis ikke særlig meget mening når vi kun har 2 noder, men når vi kommer meget over 2 begynder det at være svært at holde styr på at de er i sync, og der er virkelig ingen forskel på at sætte GlusterFS op til to eller til tyve noder.

Gluster findes godtnok i Debian’s pakkesystem, mén det er for at sige det mildt en gammel og ikke særlig brugbar version derfor bruger vi den .deb pakke som Gluster selv stiller til rådighed, flg. udføres på begge noder (lab1 og lab2)

root@lab1:~# wget http://download.gluster.org/pub/gluster/glusterfs/3.1/3.1.7/Debian/glusterfs_3.1.7-1_amd64.deb
root@lab1:~# apt-get install nfs-common libibverbs-dev fuse-utils
root@lab1:~# dpkg -i glusterfs_3.1.7-1_amd64.deb
root@lab1:~# update-rc.d glusterd defaults
root@lab1:~# update-rc.d fuse defaults
root@lab1:~# /etc/init.d/glusterd start
root@lab1:~# echo fuse >> /etc/modules

Og det var faktisk det der skulle til for at installere Gluster, nu skal vi have sat en storage pool op, en storage pool er en fællesbetegnelse for en række sammenknyttede Gluster nodes med tilhørende diskplads.

Først opretter vi /data på begge maskiner:

root@lab1:~# mkdir /data
root@lab2:~# mkdir /data

Dernæst beder vi de to maskiner forbinde til hinanden og dermed danner vi vores storage pool:

root@lab1:~# gluster peer probe lab2.mikjaer.com
Probe successful

og for at verificerer kører vi:

root@lab2:~# gluster peer status
Number of Peers: 1

Hostname: 109.202.159.61
Uuid: b11650fa-1a38-41ff-8f11-e681e93db4aa
State: Peer in Cluster (Connected)

og får bekræftiget at maskinerne har fat i hinanden, så langt så godt 🙂

Nu skal vi have oprettet en gluster-volume og have den startet, og det er ligeså nemt som det hidtil har været:

root@lab1:~# gluster volume create cdn-data lab1.mikjaer.com:/data lab2.mikjaer.com:/data
Creation of volume cdn-data has been successful. Please start the volume to access data.
root@lab1:~# gluster volume start cdn-data
Starting volume cdn-data has been successful

Jeg har valgt at kalde min volume for “cdn-data” og lade den benytte diskplads på hhv. lab1 og lab2 fra mappen /data, og så runder vi af med at starte den … hvilket vil sige at Gluster gør den tilgængelig til f.eks. at blive mounted, hvilket sjovt nok er næste skridt. Men lad os lige starte med at gemme vores gamle /var/www, just in case:

root@lab1:~# mv /var/www/ /var/www-old
root@lab1:~# mkdir /var/www

og nu vil jeg mounte vores Gluster volume på den /var/www, det gøres således:

root@lab1:~# modprobe fuse
root@lab1:~# mount -t glusterfs 127.0.0.1:/cdn-data /var/www

og på lab2:

root@lab2:~# modprobe fuse
root@lab2:~# mount -t glusterfs 127.0.0.1:/cdn-data /var/www

og så flytter vi indholdet af lab1:/var/www-old til lab1:/var/www … som jo så nu burde være en mounted GlusterFS volume og dermed øjeblikkeligt være tilgængelig på den anden node også, nemlig lab2:/var/www, lad os se:

root@lab1:~# cp /var/www-old/test.iso /var/www
root@lab2:~# ls /var/www/
test.iso
root@lab1:~# md5sum /var/www/test.iso
b663727d7f5b572c329cea8e2ff5e29c  /var/www/test.iso
root@lab2:~# md5sum /var/www/test.iso
b663727d7f5b572c329cea8e2ff5e29c  /var/www/test.iso

Og mindsanten om ikke det virker 🙂

Nu mangler vi bare lige at sikre opsætningen ved boot, og på grund af en mindre fejl i Debian pakkerne skal det gøres ved at tilføle linien “mount -a” i /etc/rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
mount -a
exit 0

Derudover skal dit nye share selvfølgelig tilføjes til /etc/fstab, den linie du skal tilføjes ser sådan her ud:

127.0.0.1:/cdn-data  /var/www    glusterfs       defaults        0       0

Reboot begge maskiner og se det hele komme op af sig selv … du har nu et CDN der selv syncer web-root 🙂

Hvis du har mange statiske filer som folk tit downloader kan det give mening at opbygge en speciel konstruktion til formålet kaldet et Content Delivery Network, som i princippet blot er en række servere optimeret til at levere ligepræcis det indhold du ønsker, rasende hurtigt, fra forskellige lokationer.

Vi vil selvfølgelig lave det med Apache, og her i dette indlæg vil jeg starte med et simpelt setup som jeg i efterfølgende indlæg vil bygge videre på. Jeg ønsker at bruge mine lab maskiner som base for CDN’et:

lab1.mikjaer.com : 109.202.159.61
lab2.mikjaer.com : 109.202.159.62

Begge maskiner er installeret med Debian og Apache, hverken MySQL eller PHP skal bruges her, vi skal nemlig udelukkende hoste statisk indhold. I det her tilfælde har jeg valgt at hoste et par store .iso filer for at have noget at teste med.

Selve “tricket” ligger i DNS Opsætningen, vi benytter noget som kaldes en RRD( Round Robin DNS) Opsætning, som i princippet blot handler om at oprette flere A-Records for den samme adresse, så vil navneserverne selv sørge for at blande dem og sende dem ud i forskellig rækkefølge. Det betyder at forskellige brugere vil tilgå forskellige adresser. Fordelingen vil være, givet et stort nok grundlag, nogenlunde ligeligt fordelt mellem adresserne.

Den eksakte opsætning af dine A Records afhænger af din DNS Udbyder, så det vil jeg ikke gennemgå, men resultatet skulle gerne ende med at se således ud:

root@lab1:~# host -t a cdn.mikjaer.com
cdn.mikjaer.com has address 109.202.159.62
cdn.mikjaer.com has address 109.202.159.61

Som du kan se får du nu en liste over alle ip adresserne istedet for blot én som normalt, i teorien kan du oprette så mange du vil. I realiteten skal du holde dig omkring max 10. da du ellers kan få problemer med blandt andet caching og pakke-fragmentering.

For at demonstrere princippet med den tilfældige rækkefølge har jeg kørt den to gange direkte mod navneserveren (min lokale navneserver cache’r resultatet og derfor vil du ikke se rækkefølgen ændre sig så længe vi bruger den)

root@lab1:~# host -t a cdn.mikjaer.com ns1.mikjaer.com | grep has\ address
cdn.mikjaer.com has address 109.202.159.61
cdn.mikjaer.com has address 109.202.159.62
root@lab1:~# host -t a cdn.mikjaer.com ns1.mikjaer.com | grep has\ address
cdn.mikjaer.com has address 109.202.159.62
cdn.mikjaer.com has address 109.202.159.61

Dertil skal det nævnes at flere nyere browsere genkender RRD og i tilfælde af udfald automatisk vil spørge en af de andre servere.

Nu er der faktisk ikke så meget andet at gøre end at lægge data på dit nye CDN, lad os uploade en ISO:

mike$ scp debian-6.0.3-amd64-netinst.iso root@lab1.mikjaer.com:/var/www/test.iso
root@lab1.mikjaer.com's password:
debian-6.0.3-amd64-netinst.iso                        100%  168MB   1.1MB/s   02:35
mike$ scp debian-6.0.3-amd64-netinst.iso root@lab2.mikjaer.com:/var/www/test.iso
root@lab2.mikjaer.com's password:
debian-6.0.3-amd64-netinst.iso                        100%  168MB   1.1MB/s   02:37

For at teste lidt på det har jeg åbnet 2 vinduer der kører en Apache Status:

root@lab1:~# watch -n 1 apachectl status

og for at generere lidt trafik til mit screenshot kører jeg flg. kommando på 2 andre maskiner:

root@lab3:~# watch wget --delete-after http://lab1.mikjaer.com/test.iso

Resultatet ser således ud:

Hvert “W” repræsenterer en process der bliver serviceret, og den ene af dem vil altid være Apachestatus selv, og dermed er der altså to processer igang, i og med at det er en lukket test kan jeg roligt antage at begge processer er mine egne. Evt. kan jeg stoppe dem og se at de forsvinder hvis jeg vil være helt sikker.

Nu åbner jeg apachestatus på begge servere og kører den her fra én server:

root@lab3:~# watch wget --delete-after http://cdn.mikjaer.com/test.iso

og kan nu se hvordan download processen på Apachestatus hopper fra den ene til den anden skærm, hvilket jo viser at RRD virker, som en sidste finale vil jeg skrive et hurtigt script der illustrere det endnu bedre:

test.sh:

#!/bin/bash
for (( c = 1; c<=100; c++))
do
        wget --delete-after http://cdn.mikjaer.com/test.iso &
done

Sæt execute permissions og kør scriptet:

root@lab3:~# chmod 755 test.sh
root@lab3:~# ./test.sh

På begge, eller flere, klient maskiner, og så på dine Apachetop vinduer hvordan processerne fordeler sig jævnt ud på dit CDN:

Og du kan se, i løbet af ingenting har vi opbrugt de 12MB/s som et 100mbit netkort kan levere, og belastningen bliver fint fordelt på de to noder i vores CDN.

Hvis det ikke virker for dig skyldes det typisk at du bruger en lokal DNS som cacher resultaterne, det gør Google’s DNS’er f.eks. Det vil ikke udgøre et reelt problem fordi at dine besøgende typisk vil være geografisk spredt ud over landet/verden og dermed også flere forskellige DNS Caches. Dertil skal lægges at nyere browsere (dvs. ikke wget) selv tager højde for RRD og håndterer det korrekt.

Hvis det her virkelig skal batte noget skal du selvfølgelig ikke bruge virtuelle servere som jeg har gjort, du skal bruge fysiske servere der sider på hver deres forbindelser – eller ihvertfald på en så stor forbindelse at du ikke ender med en flaskehals der ?

ps. Hvis du får brug for at stoppe test.php scriptet igen, så log ind på maskinen med en anden terminal og skriv:

root@lab1:~# killall -9 test.sh
root@lab1:~# killall wget