Vreemde IP adressen loggen uit op NAS/Router

[MartijnAbel]

Hallo medetweakers,

Ten eerste, ik weet niet of het topic of de verkeerde plek staat, zoja, excuus.

Enfin,

Ik heb inmiddels na meerdere keren mislukte backups op mijn NAS gekeken waar de crux kon liggen.
Tot mijn grote verbazing zie ik de logs van de NAS voorbij schieten met een aantal vreemde IP adressen hierin die een logout doen op mijn FTP.

Ik ben er middels een trace achtergekomen waar de IP adressen zich bevinden.

Het gaat om onderstaande IP adressen:

17-01-2015 00:55:54 182.118.45.220 China
16-01-2015 09:30:00 46.50.183.5 Rusland
13-01-2015 20:23:36 91.236.75.92 Polen
13-01-2015 00:49:41 182.118.60.56 China
11-01-2015 01:22:06 182.118.55.189 China

Deze IP adressen doen allemaal een logout op mijn FTP server terwijl er nergens in de logs iets terug te vinden is over een login op deze FTP.
Ik zou het ook vrij frappant vinden als men dit zou lukken gezien de sterkte van de wachtwoorden van de accounts die zich hierop bevinden.

Vervolgens ga ik eens in mijn router kijken en zie ik de log de afgelopen dagen vol staan met meldingen:

22:09:40 2015 Blocked incoming TCP packet from 95.101.203.9:443 to 213.93.13.xxx:50495 as FIN:PSH:ACK received but there is no active connection

Blocked incoming UDP packet from 78.96.254.59:49682 to 213.93.13.xxx:25854

Wat kan ik hier aan/tegen doen? De onderste blocked ip's komen als het goed is in iedergeval niet door, maar de hele lijst staat er wel bomvol mee.
De logout op de NAS baart me wel iets meer zorgen, aangezien er dan ook ergens een login moet gebeuren lijkt mij.

p.s. sommige blocked incoming TCP packet ip adressen komen notabene bij Microsoft vandaan ik snap er helemaal geen hout meer van.

[Fish]

mischien is dat een lek op een bepaald type ftp server die ze bij jou uitproberen

Ik zou zeggen internetruis en negeren. (wel je software up to date houden)
of als je het eng vind kun je gaan nadenken over whitelisten

kijk anders eens welke gesharde files reecent zijn benaderd/aangemaakt

[ Voor 14% gewijzigd door Fish op 17-01-2015 22:45 ]

[GioStyle]

Gebruik je FTP of SFTP? Ik zou mijn vingers niet meer aan FTP willen branden.

[D4NG3R]

Worden vaak 'internet echo's' genoemd, niks noemenswaardig en ook niet iets wat jouw direct aanvalt.

Gewoon geautomatiseerde portscanners. Mits jij je beveiliging goed op orde hebt gebeurt er niks.

[ Voor 33% gewijzigd door D4NG3R op 17-01-2015 22:51 ]

[MartijnAbel]

GioStyle schreef op zaterdag 17 januari 2015 @ 22:48:
Gebruik je FTP of SFTP? Ik zou mijn vingers niet meer aan FTP willen branden.

Mijn DNS-320L van D-Link heeft helaas niet de optie om sFTP te draaien. dus ik ben genoodzaakt om op het aloude bekende FTP te blijven hangen.
Is het een optie om Allow SSL/TLS connections only aan te zetten en dit te gebruiken al extra beveiliging?
Ik merk dat ik dan ook gebruik moet maken van een extra ftpes:// prefix voor de hostnaam/ip

D4NG3R schreef op zaterdag 17 januari 2015 @ 22:51:
Worden vaak 'internet echo's' genoemd, niks noemenswaardig en ook niet iets wat jouw direct aanvalt.

Gewoon geautomatiseerde portscanners. Mits jij je beveiliging goed op orde hebt gebeurt er niks.

Mijn beveiliging zou in orde moeten zijn, Modem--> Router--> Switch --> en dan pas de NAS.
Ik heb inmiddels wel de toegangspoort aangepast ipv de standaard poort 21(dunno waarom ik dat uberhaupt nog niet gedaan had )

Het frappante is en blijft alleen wel dat er dus vanaf IP adressen een logout geregistreerd word op de FTP. dan zou je toch verwachten dat er ook ergens een login voorkomt? of komt het door de brakke logvorming van mijn DNS-320L

Fish schreef op zaterdag 17 januari 2015 @ 22:43:
mischien is dat een lek op een bepaald type ftp server die ze bij jou uitproberen

Ik zou zeggen internetruis en negeren. (wel je software up to date houden)
of als je het eng vind kun je gaan nadenken over whitelisten

kijk anders eens welke gesharde files reecent zijn benaderd/aangemaakt

Whitelisten heb ik ook aan gedacht, is alleen nogal moeilijk te doen omdat ik de FTP vooral benader vanaf mijn door het werk beveiligde telefoon. aangezien deze niet een fixed IP adres heeft gaat dat dus nogal moeilijk(of is in iedergeval niet makkelijk in te stellen in de DIR-655 router)
software/firmware is de meest recente, dus goed up to date.

Ik ben er inmiddels ook achter dat er via het interne IP van de telefoon van mijn vriendin(Nexus 5) nogal wat packets verzonden werden naar de meest vreemde IP adressen.
Ik heb gekeken wat hier op draaide, maar dat viel best wel mee. wel meteen de Aliexpress, Wish en 1 of ander vreemd japans toetsenbord verwijderd. Bij haar stond ook de Turbo Client app geinstalleerd, een FTP toegangsapp met mijn gegevens en een auto logon. dit ook meteen maar weggegooid en mijn wachtwoord aangepast. blijkbaar dit ooit eens getest op haar telefoon.

Thx allemaal voor de antwoorden

[ Voor 93% gewijzigd door MartijnAbel op 18-01-2015 21:22 ]

[HollowGamer]

Tip: nooit je FTP direct hangen aan het internet. Gebruik een VPN voor als je buiten de deur op je (intern) netwerk wilt.
OpenVPN werkt daarvoor prima.

[MartijnAbel]

HollowGamer schreef op zondag 18 januari 2015 @ 14:13:
Tip: nooit je FTP direct hangen aan het internet. Gebruik een VPN voor als je buiten de deur op je (intern) netwerk wilt.
OpenVPN werkt daarvoor prima.

en de reden daarvan is? er hangen namelijk wel meerdere firewalls tussen(modem, router)
niet verkeerd bedoeld hoor, maar ben wel nieuwschierig waarom dat bijvoorbeeld via een VPN te laten verlopen. dat zou namelijk nog steeds niet mijn logs verklaren

[GioStyle]

FTP is met name onbetrouwbaar als het gaat om inloggen; je inloggegevens gaat onversleuteld over het internet.

[Fish]

alles, ook je bestanden

[Gomez12]

Enkel logout kan een methode zijn om extra info over de server te verkrijgen. Als er bekend is dat ftp-server x ipv bye iets zegt van "Bye and have a nice day" dan weet je dus dat het ftp server x is.

Doe dit geintje geautomatiseerd over 10.000 ip-adressen en je kan gewoon op internet op zoek naar exploits voor ftp server x en je hebt een grote kans dat je op alle servers die zeiden "Bye and have a nice day" naar binnen kan.

Het is gewoon een additionele methode van fingerprinting.

[HollowGamer]

MartijnAbel schreef op zondag 18 januari 2015 @ 16:24:
[...]


en de reden daarvan is? er hangen namelijk wel meerdere firewalls tussen(modem, router)
niet verkeerd bedoeld hoor, maar ben wel nieuwschierig waarom dat bijvoorbeeld via een VPN te laten verlopen. dat zou namelijk nog steeds niet mijn logs verklaren

Lees even de reacties hierboven.

(Meerdere) Firewall('s)/NAT.. het zegt allemaal niks. Het is geen beveiliging, het is eerder een gipsmuur die bescherming biedt. Het is goed mogelijk om een connectie te maken van binnen (je LAN) naar buiten. Denk alleen maar aan een 'foutieve' app die doodleuk (je) gegevens naar buiten stuurt.

Met een VPN voorkom je dit niet, maar zorg je ervoor dat je bepaalde poorten niet hoeft open te zetten voor het WWW. Je zorgt tevens voor (weer) een extra beveiliging door gebruik van SSL/TLS.

Wat ik eigenlijk wil zeggen: als gebruiker/admin ben je zelf de zwakste schakel.
Doe je niets aan de beveiliging van de computer/device zelf (bijvoorbeeld password/key/IP-whitelist beveiliging), dan heb je geen beveiliging als de Firewall omzeilt wordt.

[ Voor 10% gewijzigd door HollowGamer op 18-01-2015 20:12 ]

[MartijnAbel]

Qua beveiliging zit ik met mijn telefoon/tablets/computer goed. De telefoon van mijn vriendin zou ook goed moeten zijn, maar maakte toch vreemde connecties, dus die ook nagelopen.

Thx in iedergeval voor je reply!

GioStyle schreef op zondag 18 januari 2015 @ 17:05:
FTP is met name onbetrouwbaar als het gaat om inloggen; je inloggegevens gaat onversleuteld over het internet.

Aah k, op die manier. Had ik ook wel moeten weten aangezien je heel makkelijk in IE of FF je ww en gebr. naam in kunt voeren met het ftp adres dom dom dom van me.
Met de inschakeling van SSL/TLS zag ik dat er gebruik gemaakt word van 128bits Cipher. Dan zou, naar mijn weten, wel het inloggen en bestanden verzenden versleuteld moeten gaan toch?

Gomez12 schreef op zondag 18 januari 2015 @ 19:53:
Enkel logout kan een methode zijn om extra info over de server te verkrijgen. Als er bekend is dat ftp-server x ipv bye iets zegt van "Bye and have a nice day" dan weet je dus dat het ftp server x is.

Doe dit geintje geautomatiseerd over 10.000 ip-adressen en je kan gewoon op internet op zoek naar exploits voor ftp server x en je hebt een grote kans dat je op alle servers die zeiden "Bye and have a nice day" naar binnen kan.

Het is gewoon een additionele methode van fingerprinting.

Sinds de aanpassing van de beveiliging op de FTP heb ik geen vreemde logouts meer gehad de afgelopen 24 uur, gelukkig. Maar dan weet ik ook waarvoor dat gebruikt word dus. Thx!

[ Voor 90% gewijzigd door MartijnAbel op 18-01-2015 21:21 ]

[Mijzelf]

MartijnAbel schreef op zondag 18 januari 2015 @ 21:13:
Met de inschakeling van SSL/TLS zag ik dat er gebruik gemaakt word van 128bits Cipher. Dan zou, naar mijn weten, wel het inloggen en bestanden verzenden versleuteld moeten gaan toch?

Bij mijn weten inloggen wel, bestanden niet. FTP maakt gebruik van verschillende verbindingen tegelijkertijd. Eén commando verbinding, en één of meer data verbindingen. Inloggen en initiëren van data transport gaat over de commando verbinding (op poort 21), en de data verbindingen over een van de data poorten. Alleen de commando verbinding is geencrypt. Waarmee je login veilig is.
Overigens is encryptie behoorlijk duur. Als je een budget nas hebt en een dikke internetpijp, wordt de encryptie de beperkende factor in de transport snelheid. Dat geld voor alle vormen van encryptie, dus ook vpn en sftp.

MartijnAbel schreef op zaterdag 17 januari 2015 @ 23:03:
Mijn beveiliging zou in orde moeten zijn, Modem--> Router--> Switch --> en dan pas de NAS.

Die modem en switch hebben geen enkele invloed. Netwerktechnisch zijn ze volkomen transparant.

[HollowGamer]

@Mijzelf: Ik vind dat je overdrijft met 'duur'. Het is ook maar echt de vraag hoeveel invloed SSL/gebruik van VPN heeft op de upload-snelheid.
Ja, zonder zal zeker sneller zijn, maar het weeg niet op tegen de voordelen. De login afschermen is prima, maar ik heb toch ook graag dat niet kan worden gezien welke bestanden ik op en neer stuur.

Ook de belasting op het apparaat valt reuze mee. Als een Raspberry en een 'simpele' dd-wrt router al zonder problemen VPN ondersteunen, zonder dat de router 'vol loopt', dan moet een simpele NAS dit ook kunnen.

Het gebruik van VPN kan tevens een voordeel zijn, de 'andere' kan immers moeilijker je verkeer cappen, waardoor de snelheid vrijwel gelijk blijft.

[Mijzelf]

HollowGamer schreef op maandag 19 januari 2015 @ 11:46:
@Mijzelf: Ik vind dat je overdrijft met 'duur'. Het is ook maar echt de vraag hoeveel invloed SSL/gebruik van VPN heeft op de upload-snelheid.

Een simpel 'openssl speed' command kan je dat vertellen. Op een typische budget nas: (Kirkwood 800MHz):

openssl speed aes
<snip>
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc       9332.33k    11024.10k    11498.76k    11620.74k    11668.81k
aes-192 cbc       8263.59k     9500.21k     9893.33k    10027.30k    10055.82k
aes-256 cbc       7428.04k     8407.84k     8713.02k     8791.62k     8783.80k

Iets duurder (1.3 GHz Comcerto 2000)

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      33606.31k    37787.14k    39182.93k    39527.42k    39819.17k
aes-192 cbc      29163.45k    32217.62k    33353.73k    33664.68k    33614.51k
aes-256 cbc      26271.53k    28623.21k    29557.25k    29754.22k    29837.99k

Lijkt niet vreselijk, niet? Die Kirkwood 800 haalt nog altijd ruim 8MB/sec. Maar vergis je niet. De processor is 100% belast, dus zodra je nog iets anders gaat doen, zakt het allemaal dramatisch in.
Ssh verkeer tussen deze twee systemen:

~$ dd if=/dev/zero bs=16k count=2k | ssh user@nas "dd of=/dev/null"
user@nas's password:
2048+0 records in
2048+0 records out
33554432 bytes (34 MB) copied, 11.3275 s, 3.0 MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 9.082533 seconds, 3.5MB/s

(Het verschil in snelheid komt door de tijd die ik nodig heb om mijn password in te typen) Nog maar 3.5MB/sec over, en de enige overhead is netwerk. (Eerlijk gezegd weet ik niet welke encryptie ssh hier gebruikt, dus mogelijk is het verschil minder dramatisch. Blijft wel dat dit de echte ssh snelheid is.)

Ja, zonder zal zeker sneller zijn, maar het weeg niet op tegen de voordelen.

Dat is een afweging. Als jij een mkv van je server wilt trekken zal het je niet veel uitmaken wie er meekijkt. Maar een paar MB/sec extra worden wel belangrijk.

Het gebruik van VPN kan tevens een voordeel zijn, de 'andere' kan immers moeilijker je verkeer cappen, waardoor de snelheid vrijwel gelijk blijft.

Hè? Waarom zou je VPN verkeer moeilijker kunnen cappen dan platte FTP?

Als een Raspberry en een 'simpele' dd-wrt router al zonder problemen VPN ondersteunen, zonder dat de router 'vol loopt', dan moet een simpele NAS dit ook kunnen.

De router loopt niet vol, omdat hij via ICMP upstream laat weten dat hij minder snel moet gaan zenden. Dezelfde reden dat er nergens een ballonnetje ontstaat als je met een 100Mbit pijp gaat uploaden naar een ADSL verbinding.

[ Voor 7% gewijzigd door Mijzelf op 19-01-2015 13:19 ]

[HollowGamer]

Mijzelf schreef op maandag 19 januari 2015 @ 13:06:
Een simpel 'openssl speed' command kan je dat vertellen. Op een typische budget nas: (Kirkwood 800MHz):

openssl speed aes
<snip>
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc       9332.33k    11024.10k    11498.76k    11620.74k    11668.81k
aes-192 cbc       8263.59k     9500.21k     9893.33k    10027.30k    10055.82k
aes-256 cbc       7428.04k     8407.84k     8713.02k     8791.62k     8783.80k

Iets duurder (1.3 GHz Comcerto 2000)

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      33606.31k    37787.14k    39182.93k    39527.42k    39819.17k
aes-192 cbc      29163.45k    32217.62k    33353.73k    33664.68k    33614.51k
aes-256 cbc      26271.53k    28623.21k    29557.25k    29754.22k    29837.99k

Lijkt niet vreselijk, niet? Die Kirkwood 800 haalt nog altijd ruim 8MB/sec. Maar vergis je niet. De processor is 100% belast, dus zodra je nog iets anders gaat doen, zakt het allemaal dramatisch in.
Ssh verkeer tussen deze twee systemen:

~$ dd if=/dev/zero bs=16k count=2k | ssh user@nas "dd of=/dev/null"
user@nas's password:
2048+0 records in
2048+0 records out
33554432 bytes (34 MB) copied, 11.3275 s, 3.0 MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 9.082533 seconds, 3.5MB/s

(Het verschil in snelheid komt door de tijd die ik nodig heb om mijn password in te typen) Nog maar 3.5MB/sec over, en de enige overhead is netwerk. (Eerlijk gezegd weet ik niet welke encryptie ssh hier gebruikt, dus mogelijk is het verschil minder dramatisch. Blijft wel dat dit de echte ssh snelheid is.)

Dank voor de benchmarks & informatie.

Ik neem aan dat er tegenwoordig wel wat manieren zijn om het verbruik (zowel in CPU als bandbreedte) te verminderen. Bijvoorbeeld cache, overstappen op een snellere (minder veilige/eenvoudiger) cipher, etc.
Of bijvoorbeeld de encryptie over te laten aan een enkele apparaat die niets anders doet dan dat.
Het blijft natuurlijk wat je ook (terecht) aangeeft, in de praktijk nogal invloed te hebben.

Dat is een afweging. Als jij een mkv van je server wilt trekken zal het je niet veel uitmaken wie er meekijkt. Maar een paar MB/sec extra worden wel belangrijk.

Daar ben ik het mee eens: een goede overweging maken van welk verkeer wel en niet geëncrypt over het LAN/WAN moet gaan.
Maar als het een eis is (of simpelweg 'kan'), prefer ik altijd encryptie van verkeer. Zeker met de huidige upload-snelheden (als je in een data-center zit tenminste ), zou het prima moeten kunnen.

Hè? Waarom zou je VPN verkeer moeilijker kunnen cappen dan platte FTP?

Omdat dit kan 'eenvoudiger' kan worden ingesteld. Ik noem als voorbeeld niewsgroepen die zonder SSL, eenvoudig(er) door UPC worden gecapt.

De router loopt niet vol, omdat hij via ICMP upstream laat weten dat hij minder snel moet gaan zenden. Dezelfde reden dat er nergens een ballonnetje ontstaat als je met een 100Mbit pijp gaat uploaden naar een ADSL verbinding.

Ik bedoelde hierbij niet alleen het verkeer, maar ook de belasting van de router.
Het is natuurlijk wel zo dat je geen budget-ding moet hebben, maar een goede dd-wrt router kan zonder problemen verkeer encrypten/VPN-services opstarten.

[MartijnAbel]

Mijzelf schreef op maandag 19 januari 2015 @ 09:39:
[...]

Bij mijn weten inloggen wel, bestanden niet. FTP maakt gebruik van verschillende verbindingen tegelijkertijd. Eén commando verbinding, en één of meer data verbindingen. Inloggen en initiëren van data transport gaat over de commando verbinding (op poort 21), en de data verbindingen over een van de data poorten. Alleen de commando verbinding is geencrypt. Waarmee je login veilig is.
Overigens is encryptie behoorlijk duur. Als je een budget nas hebt en een dikke internetpijp, wordt de encryptie de beperkende factor in de transport snelheid. Dat geld voor alle vormen van encryptie, dus ook vpn en sftp.


[...]

Die modem en switch hebben geen enkele invloed. Netwerktechnisch zijn ze volkomen transparant.

Ik heb inderdaad een budget nas Ik heb wel de poort aangepast naar iets minder voorkomends, dat zou geen probleem moeten zijn toch?

Ik vind nu wel andere 'vreemde' dingen in de logs, namelijk:

Blocked incoming ICMP error message (ICMP type 3) from 121.151.106.111 to 213.93.13.xxx as there is no UDP session active between 213.93.13.145:38600 and 192.168.0.24:6881

&

Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.154 to 123.222.175.200

dat is net zo goed sniffen en kijken waar een ingang is?
Het lijkt namelijk bij de laatste regel net of is mijn telefoon dingen aan het verzenden naar de meest vreemde IP adressen

[ Voor 21% gewijzigd door MartijnAbel op 19-01-2015 20:18 ]

[HollowGamer]

MartijnAbel schreef op maandag 19 januari 2015 @ 20:15:
[...]


Ik heb inderdaad een budget nas Ik heb wel de poort aangepast naar iets minder voorkomends, dat zou geen probleem moeten zijn toch?

Ik vind nu wel andere 'vreemde' dingen in de logs, namelijk:

Blocked incoming ICMP error message (ICMP type 3) from 121.151.106.111 to 213.93.13.xxx as there is no UDP session active between 213.93.13.145:38600 and 192.168.0.24:6881

&

Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.154 to 123.222.175.200

dat is net zo goed sniffen en kijken waar een ingang is?
Het lijkt namelijk bij de laatste regel net of is mijn telefoon dingen aan het verzenden naar de meest vreemde IP adressen

Je hebt geen Sync/BitTorrent-client runnen?

Er is i.i.d.g.v. iets dat blijft zoeken of er een host bestaat.

[MartijnAbel]

Nope, niks geks draaien... Ik heb wel mijn email, accounts e.d. die synchroniseren etc, maar verder niks. Heb de telefoon laten scannen op gekkigheden, en ook die vind niks