Categorie: Ftp

Uitvoeren snelheidstest (4)

Naar aanleiding van het vorige bericht heb ik maar even een hele simpele test uitgevoerd vanaf mijn servertje. Ik heb namelijk even een iso binnengehaald vanaf de debian ftp server, de nederlandse mirror uiteraard:

ftp> get debian-40r3-amd64-kde-CD-1.iso
local: debian-40r3-amd64-kde-CD-1.iso remote: debian-40r3-amd64-kde-CD-1.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for debian-40r3-amd64-kde-CD-1.iso (678758400 bytes).
226 File send OK.
678758400 bytes received in 168.75 secs (3927.9 kB/s)

Ik heb trouwens het eerste stukje weggelaten, het was nog even zoeken waar de iso’s geplaatst waren. Maar het geeft in elk geval aan dat ik wat betreft de downloads de snelheid van 35 mbit/s redelijk halen kan. Dit komt namelijk neer op 35 / 8 * 1024 = 4480 KiB/s, er gaat echter nog een stukje overhead af van het TCP/IP protocol. Dit is tussen de 10% en 20%, dus tussen de 3584 KiB/s en 4032 KiB/s, de gehaalde waarde ligt rond de 12% dus dat is netjes.

Ook aan de kant van Armorica gaat het goed trouwens:

ftp> get debian-40r3-amd64-netinst.iso
local: debian-40r3-amd64-netinst.iso remote: debian-40r3-amd64-netinst.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for debian-40r3-amd64-netinst.iso (151877632 bytes).
226 File send OK.
151877632 bytes received in 32.19 secs (4607.3 kB/s)

Ik heb hier wel een iets kleiner bestand binnengehaald, de nauwkeurigheid zal dus iets lager zijn maar ik mag er wel vanuit gaan dat er snelheden haalbaar zijn van boven de 4000 KiB/s.

Ik moet dus echt verder zoeken naar de oorzaak van de slechte resultaten tijdens de vorige tests.

Uitvoeren snelheidstest (3)

Het duurt nogal voordat er resultaten komen van de snelheidstesten waar ik mee bezig ben. Ik kom namelijk nog niet aan de waarde die ik hoor te hebben. Nu kan het natuurlijk best zijn dat mijn werkelijke snelheid bij lange na niet in de buurt komt van de geadverteerde snelheid. Maar ik denk eerder dat er iets misgaat bij het testen. Ik kreeg namelijk gisteravond met het installeren van OpenArena een downloadsnelheid die schommelde tussen de 3500 en 4000 KiB/s, vlak daarna heb ik nog een test uitgevoerd en die zie je onderin de volgende lijst:

Datum	Tijd	Download	Upload
18-06	16:23	2,62		1,56
18-06	21:52	0,82		0,98
18-06	22:58	1,55		1,29
18-06	23:47	2,04		1,49
19-06	0:19	2,45		1,40
19-06	6:18	2,85		1,59
19-06	9:18	2,49		1,60
19-06	12:18	2,71		1,63
19-06	15:18	2,58		1,65
19-06	18:19	2,07		1,45
20-06	0:20	1,95		1,43
20-06	6:18	2,82		1,64
21-06	0:18	2,48		1,60
21-06	6:18	2,85		1,61
25-06	22:03	1,61		1,26

De gemeten waarde’s hier zijn in MiB/s, de downloadsnelheid is hier nog niet de helft van de waarde die ik even daarvoor gehaalt heb op mijn werkstation.

Voor de volledigheid hier nog even het script wat ik gebruik om de snelheidstesten uit te voeren:

#!/bin/sh

cd ~/test
filename="400MB.test"
hostname="tecumseh.homeip.net"
username="supergeheimtestgebruiker"
password="supergeheimwachtwoord"
echo -e "***tecumseh.homeip.net Download snelheid***\n" >> speedtest.log
ftp -inv $hostname >> speedtest.log << EOF
quote USER $username
quote PASS $password
binary
put $filename
bye
EOF

echo -e "\n"
echo -e "***tecumseh.homeip.net Upload snelheid***\n" >> speedtest.log
ftp -inv $hostname >> speedtest.log << EOF
quote USER $username
quote PASS $password
binary
get $filename
bye
EOF

#REMOVE GARBAGE (REMOVE EVERY LINE EXCEPT FOR ONES CONTAINING '*' AND 'MB') FROM LOG FILE AND EMAIL IT
#sed -n -e '/*/p' -e '/MB/p' speedtest.log >> email.log
mail -s "Speed Test Results" ********@provider.nl < speedtest.log
rm speedtest.log
#rm email.log

Uiteraard zijn de logingegevens en het mailadres hier even veranderd. Zoals je ziet heb ik de sed regel weggelaten. Dit leverde nogal onverwachte resultaten op. Namelijk een bijna leeg mailtje waarin enkel de regels kwamen waarin het testbestand genoemd wordt (400MB.test)

Ik moet nu dus nog even op zoek naar een manier om uit te vogelen waar de bottleneck zit.

Snelheidstest glasvezel

Ik heb het in diverse posts al gehad over de snelheid van mijn glasvezelverbinding. Nu is er nog geen test uitgevoerd die voldoende data gebruikt heeft om betrouwbare resultaten te geven. In het laatste glasvezel topic bied Henk aan om een Strato testserver te mogen gebruiken om mijn snelheid op wetenschappelijke wijze te bepalen.

Voor het wetenschappelijke verhaal heb ik een stukje in de mail gekregen van Henk:

> Ik wil dus nog uitzoeken of je met behulp van een script
> snelheidswaarde’s kunt meten op meerdere momenten tijdens een grote
> upload. Ik ga daarbij aannemen dat de 1e 20% van een upload niet
> representatief is. Wellicht heb jij daar nog ideeën over.

Dit klinkt heel goed. Alleen gaat die handshake en window scaling vrij snel, ofwel de eerste 20% gaat wat ver. Zelf neem ik altijd een bestand dat minimaal een minuut kost. Je moet namelijk aannemen dat de gemeten tijdsduur ± 1 seconde is. Ofwel als jij 120 MiB weet te uploaden in een minuut kom je uit op:

120 / 59 = 2,03
120 / 61 = 1,97

Je ziet dat allebei afgerond kan worden op 2,0 MiB/s ofwel één cijfer achter de komma en dat is goed genoeg voor dit soort testen.

Als je snelheid een heel stuk meer is, wordt één minuut mogelijk al te weinig:

240 / 59 = 4,07
240 / 61 = 3,93

Kortom je moet dus zoveel data gebruiken dat met de gevonden tijd een nauwkeurig uitspraak is te doen…

Aangezien mijn theoretische snelheid op 35 mbit zit volgens Concepts ICT heb ik een snelheid van:

35 / 8 = 4,375 MiB/s

Een test die een duur heeft tussen de 1,5 en 2 minuten heeft dus een bestand nodig van minimaal 393,75 MiB (90 * 4,375) en maximaal 525 MiB (120 * 4,375). Aangezien het TCP/IP protocol een verlies van zo’n 10% heeft neem ik de laagste waarde en rond die iets naar boven af en zo kom ik uit op een testbestand van 400 MiB. Deze maak ik dan ook aan:

Arkon:~/test# dd if=/dev/zero of=400MB.test bs=1M count=400
400+0 records in
400+0 records out
419430400 bytes (419 MB) copied, 28.3245 seconds, 14.8 MB/s

Om zeker te zijn dat mijn machine’s de test wel volledig uit kunnen voeren zal ik de test eerst uitvoeren tussen mijn server Arkon en mijn werkstation. Als ik daarmee niet boven de 4,5 MiB/s uitkom dan heeft het verder testen geeneens nut.

Voor het testen maak ik gebruik van een bash script. Na lang zoeken heb ik er een gevonden, zo’n ster ben ik nog niet in het zelf bedenken van scripts. Wel heb ik hierin ondertussen de sed regel gecomment en uiteraard de variabelen aangepast. Er werdt me wel heel veel weggelaten, zoals bijvoorbeeld de snelheid. En daar gaat het uiteindelijk om.

***FTP SERVER UPLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 39.745 seconds (measured here), 10.06 Mbytes per second
419430400 bytes sent in 39.73 secs (10308.5 kB/s)
221 Logout.

***FTP SERVER DOWNLOAD SPEED***

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Using binary mode to transfer files.
331 User tecumseh OK. Password required
200 TYPE is now 8-bit binary
local: 400MB.test remote: 400MB.test
226-File successfully transferred
226 48.714 seconds (measured here), 8.21 Mbytes per second
419430400 bytes received in 48.21 secs (8495.7 kB/s)
221 Logout.

Ruim 10 MiB/s voor de upload en ruim 8 MiB/s voor de download. Dit ligt ruim 2x boven de hierboven genoemde theoretische snelheid van mijn verbinding. De systemen hier kunnen het dus aan.

Fail2ban

Naar aanleiding van de Problemen Arkon (4) heb ik vandaag een volautomatisch blockprogramma geinstalleerd. De keuze is gevallen op fail2ban. Waarom zul je denken? Ik had het namelijk de vorige keer over snort en snortblock. Snort is inderdaad een intrusion detection systeem wat al een behoorlijke tijd aan de weg timmert. Blokkeer mogelijkheden zitten er niet in en snortblock was een shell script wat iemand van het Freesco support forum in elkaar geknutseld heeft. In hoevere dit bijgehouden wordt weet ik niet, dus vandaar dat ik op zoek ben gegaan naar een vervanger. Uiteindelijk kwam ik uit op fail2ban als enkel pakket wat zowel het detecteren als het blokkeren voor zijn rekening neemt. Continue reading “Fail2ban”

PureFTPd-mysql installeren (6)

De ftp-server draait al een paar dagen op poort 2121. Vanuit het interne netwerk is daar geen enkel probleem mee. Maar van buitenaf is er een behoorlijk probleem. De ftp-client wil in passive mode gaan en kan vervolgens niet connecten.

Na wat nazoekwerk kom ik erachter dat de router (een sitecom DC-202v5) een stukje verkeer aan het blokkeren is. De poorten die namelijk gebruikt worden voor de Passive verbinding worden niet doorgelaten.

Aanmaken bestand PassivePortRange:

Arkon:~# nano /etc/pure-ftpd/conf/PassivePortRange
Arkon:~# /etc/init.d/pure-ftpd-mysql restart
Restarting ftp server: Running: /usr/sbin/pure-ftpd-mysql-virtualchroot -l mysql:/etc/pure-ftpd/d
40000 45000

En vervolgens het herstarten van de ftp-server:

/etc/init.d/pureftpd restart

En die forwarden. Als het goed is moet het nu wel lukken.

PureFTPd-mysql installeren (5)

Voordat ik het uitzoekwerk van snortblock afgerond heb zal ik toch iets moeten doen om ftp misbruik te beperken. De enige snelle oplossing die ik hiervoor het is het aanpassen van het poortnummer. Dit kan ik in mijn geval op 2 plaatsen doen, namelijk in de router door een poort door te sturen naar het interne ip adres van Arkon op poort 21 (standaard). Of door pureftpd te laten luisteren op een andere poort. Dit doe je door een bestand aan te maken in /etc/pureftpd/conf en hierna de server te herstarten:

Arkon:~# nano /etc/pure-ftpd/conf/Bind
Arkon:~# /etc/init.d/pure-ftpd-mysql restart
Restarting ftp server: Running: /usr/sbin/pure-ftpd-mysql-virtualchroot -l mysql:/etc/pure-ftpd/db/mysql.conf -l pam -O clf:/var/log/pure-ftpd/transfer.log -u 1000 -j -A -E -S **** -B

In dit bestand zet je enkel het poortnummer waarop je de ftp-server wil draaien.

Zoals je (niet) ziet staat nu het poortnummer op een andere poort door middel van de optie -S die staat voor –bind

Nu nog even de gegevens in de router updaten naar deze wijziging zodat we ook van buitenaf bereikbaar zijn op dat poortnummer. Helaas werkt mijn router niet zo vernuftigd zoals ik hierboven noemde, ik kan enkel poorten 1:1 doorsturen. Een poortwissel met het forwarden kent ie niet 🙁

Problemen Arkon (4)

Ik heb een flauw vermoeden waar de problemen vandaan komen die mijn systeem plat hebben gegooid. Ik zie namelijk in de messages log veelvuldig de volgende regels langs komen:

Feb 19 14:49:18 Arkon pure-ftpd: (?@80.190.202.###) [WARNING] Authentication failed for user [Administrator]
Feb 19 14:49:28 Arkon pure-ftpd: (?@80.190.202.###) [INFO] PAM_RHOST enabled. Getting the peer address

Tijd voor een banscript.

In het verleden heb ik al eens gewerkt met snortblock, ik moet er echter opnieuw induiken omdat dit een volledig voorgeconfigureerd Freesco pakket is en dat draait hier niet meer. Het mooie hiervan is dat er na een aantal mislukte poging het ip gebant wordt en dat dit voor meerdere protocollen gebruikt kan worden.

PureFTPd-mysql installeren (3)

De ftp-server draait nu dus helemaal naar behoren. Maar hoe zit het nu met de rechten die de bestanden meekrijgen. Elk bestand krijgt nu de groep ‘ftpgroup’ en user ‘ftpuser’ mee. Op zich prima natuurlijk. Maar als je ook enkele gebruikers hebt met shell toegang dan wil je die toch de beschikking geven over hun eigen bestanden.

Heel simpel te realiseren, als je in de pureftpd mysql tabel onder GID en UID het juiste id-nummer van de gebruiker meegeeft dan komt dat meteen goed.

PureFTPd-mysql installeren (2)

Het installeren van de ftp-server ging gisteren voorspoedig. Vandaag kwam ik er echter achter dat ik niet de mogelijkheid heb om symlinks te volgen. Als de ftp-login dus gebruikt wordt om een website te beheren dan heb ik een probleem want ik wil de homedir van de gebruikers wel onder /home laten staan. En de website blijft onder /var/www dus dan blijft enkel het symlinken over.

Nu is dat vrij makkelijk op te lossen. Door in het bestand /etc/default/pure-ftpd-common de optie virtualchroot op true te zetten.

# VIRTUALCHROOT:# whether to use binary with virtualchroot support
# valid values are "true" or "false"
# Any change here overrides the setting in debconf.VIRTUALCHROOT=true

Hiermee kun je dus de symlinks volgen maar daarbuiten kun je nergens naartoe.

Even de ftp-server herstarten met

Arkon:~# /etc/init.d/pure-ftpd-mysql restart

en de boel is aangepast.