![]() |
How come? - FTP brute force attack
As you may have read, yesterday I commissioned my RAID1 NAS and it's working great. Very, very slick and a number of the features have brought a smile to my face! I actually got to bed at 3:00am as I couldn't stop playing, ahem.
Browsing the log file just now however I found that for 30 minutes not long after I went to bed it was subjected every two seconds to a brute force FTP attack: 2009/10/07 04:05:32 [admin] FAIL LOGIN: Client "60.217.229.222" Google revealed the I.P. address to likely be in China and that it has been blacklisted by some ISPs for exactly what caused me to research it. I'm not an I.T. numpty but I certainly don't know it "all", so my question is "How was my NAS found?". I could understand my firewall repelling an intruder since it's knowingly exposed to the outside world but the fact that the NAS log shows the attack implies the firewall was breached. I'm running a BT HomeHub with (checked and confirmed just now) default firewall and the only intentional way to reach my NAS from the outside world is via the secure MioNet web-based remote access account that I have created. If that's the weakness it gets deactivated right away; I have chosen a long and meaningless username and password but if that's breached I can't imagine it's rocket science to trawl even the "unshared" parts of my network. TVM, XV |
I may be wrong but if your NAS has uPNP activated and so does the router then your NAS could be visible to the outside world.....
|
I don't know the HomeHub, but can I assume it has Network Address Translation (NAT)? Most home gateways do, and if so, then devices behind it are not actually on the Internet, they are on a private network with a different IP address range. The typical private range of 192.168.xxx.xxx is one of several that are not actually valid on the Internet, and routers will not forward them.
So, behind NAT, nothing gets through unless an outgoing port is opened on it, and that happens in two ways: explicitly by a Port Forwarding setting on the gateway, or by some application that has a persistent attachment to the Internet. In your case, in my opinion, that points the finger directly at the MioNet function on the NAS box. I would disable it, and also check the HomeHub for any Port Forwarding settings. (The only ones there should be ones that you know you need - if in doubt, make a note of them, then remove them and see if anything breaks.) A friend of mine has a WD NAS box that he uses behind his home hub. When I visited him back in August he was annoyed that MioNet was asking him to pay for an account, but when I read about it, I learned that MioNet is specifically for getting to your files from outside, from the Internet, If you don't need to do that, you don't need MioNet - full stop. We stripped it off all the PCs in my friend's house (he has a lot), and set the WD box as a plain SMB share on Windows (\\wdstorage). Sorted. :ok: |
Thanks, bnt.
I'm familiar with the principles of NAT, thanks, and yes, my internal addresses are along the lines you describe (and fixed per MAC address to make network maintenance easier and short cuts more reliable to use). Unfortunately you confirm my fear that it's MioNet that's the likely catalyst.I say unfortunately because this service (in my case free for the basic option for the life of the unit it came bundled with) is something I do actually want to use.
All this only applies though if security is not unduly compromised... Cheers, XV |
I'd second that uPNP is the cause. If it wasn't negotiated between the NAS and the router then there would be no open tcp port 20/21 through which the Chinese script kiddie could attempt hacking (unless you've inadvertently manually opened those ports and forwarded them on to the NAS's LAN IP).
|
I'd second that uPNP is the cause. However.... there would be no open tcp port 20/21 through which If you've got any inbound services open on perimeter devices then you are at risk if vulnerabilities exist in their implementation (or your configuration thereof) and you have failed to keep your patches up to date (assuming patches exist of course). There are some very innovative attack strategies out there that can make use of what might look to the lay-person as innocent services.... for example ICMP (a.k.a PING / TRACEROUTE etc.)..... the average Joe might not know what can be done these days with such an innocent sounding service allowed through firewalls..... :cool: |
I also work from home P.S. Just noticed it's you XV105...... so how about making a VPN your next pet project... :ok: |
Well, gentlemen, I think you are collectively in with a very good chance of being correct...
I just took a look at my HomeHub settings and found "allow UPnP" enabled. I don't recall doing it, but I must have as I can't believe it'd be the default setting. Needless to say it's now disabled but in the mean time someone (ostensibly an IT services provider in California according to whois!) has successfully connected via FTP according to the log. Damn. They were connected for about half an hour before I realised and hit the "off" switch supplying the Home Hub. I now have a new external I.P address (confirmed) as well as having switched off external UPnP but now need to think what to check for malicious intent. |
Ask your company if they will pay for an DSL service upgrade to one with a static IP.... then you can have your very own VPN and do things properly ! P.S. Just noticed it's you XV105...... so how about making a VPN your next pet project... Don't tempt me! Seriously, I already have a dyndns account but unfortunately company policy is (a) that they will pay for domestic ADSL and (b) mandatory use only of Cisco VPN and associated company-supplied certificates. |
I just took a look at my HomeHub settings and found "allow UPnP" enabled. I don't recall doing it, but I must have as I can't believe it'd be the default setting. |
That's bizarre - but it still has me wondering how the FTP traffic got in, through NAT. If they weren't on the correct FTP port (21) the login attempts would not have registered at all. So I don't think uPNP is the final answer here, and would still check for any Port Forwarding settings on the HomeHub.
I'm a bit rusty on the issues, but I'm reading about some of the problems with uPNP, and they include security holes in its Internet Gateway Device spec. According to a report on Wikipedia, a Flash applet on a website can get a uPNP-enabled router to set up port forwarding, exposing a computer to internet attacks. |
That's bizarre - but it still has me wondering how the FTP traffic got in, through NAT. If they weren't on the correct FTP port (21) the login attempts would not have registered at all. So I don't think uPNP is the final answer here, and would still check for any Port Forwarding settings on the HomeHub. I'm a bit rusty on the issues, but I'm reading about some of the problems with uPNP, and they include security holes in its Internet Gateway Device spec. According to a report on Wikipedia, a Flash applet on a website can get a uPNP-enabled router to set up port forwarding, exposing a computer to internet attacks. Hence, the NAS firmware's uPNP has told the HomeHub that it wants to open 20/21 and the HomeHub has duly obliged.....leaving an FTP service open on the internet, which has subsequently been found by script kiddies with probes looking at 20/21 on a range of IP addresses. |
You don't need the port under attack to be open. If you've got any inbound services open on perimeter devices then you are at risk if vulnerabilities exist in their implementation (or your configuration thereof) and you have failed to keep your patches up to date (assuming patches exist of course). There are some very innovative attack strategies out there that can make use of what might look to the lay-person as innocent services.... for example ICMP (a.k.a PING / TRACEROUTE etc.)..... the average Joe might not know what can be done these days with such an innocent sounding service allowed through firewalls..... http://images.ibsrv.net/ibsrv/res/sr...ilies/cool.gif |
Thanks for all that; very interesting to read.
The questions now are:
I guess the real answer is "who knows?", so having plugged the hole (switched off UPnP) I need to stop worrying, reconfigure the NAS from factory defaults, and for my sanity, also forget about going anywhere near MioNet or any other service that gives remote access! ;) |
There is a great tool ShieldsUp which is available free to check open ports on your network.
|
Did anything get transferred even though the FTP logs only show a connection, not any activity, and the two "public" folders were empty at the time? (The private folders were chokka with files) Has anything been silently installed on the (Flavour of Linux) NAS and should I therefore reset it to as-delivered defaults and start again? |
In this instance, the edge device was his HomeHub, and without the HomeHub ports open his SPF and NAT in the HomeHub would have denied all access to the NAS located on his LAN, irrespective of the ports on the NAS being open. The concept of UPnP doesn't even exist on the routers and firewalls I use at home .... let alone any that I might have come across elsewhere :ok: |
Thanks very much, srobarts.
No vulnerabilities were found. I know that's not to say my setup is perfect and cannot be exploited, but at least none of the obvious things tested showed a weakness. Thanks for your help, too, mixture. The problem I have is that the NAS doesn't ship to be "consumer rebuilt" by doing anything other than pressing the reset pip (only resets the network and admin password) or by using the option in the admin console that deletes all user data and reverts to factory defaults*. It does not reformat and reading "how to hack your NAS" and "Linux for newbies" (you get my drift) puts the fear of God in me that I will end up with a nice white brick. :) *Added later via edit: I have now done a reset via the Admin console and as you imply, it doesn't reset to factory defaults, despite what the manual says; the firmware is still at the version I upgraded to via download from WD, not the version that came installed. |
It does not reformat and reading "how to hack your NAS" and "Linux for newbies" (you get my drift) puts the fear of God in me that I will end up with a nice white brick Anyhow.... I understand your point of view, so I'll leave it as "your call". |
Yes, that was my point; it's obvious from what I have seen that I don't have a NAS that's truly back to "as delivered" and therefore anything installed (and I assume it was) is probably still there.
The NAS is now unplugged whilst I pause and think rationally what to do. |
The NAS is now unplugged whilst I pause and think rationally what to do. Theoretically, if you were very careful and your router/firewall provides a way to block outbound as well as inbound traffic from its IP address you could reduce the risk of data leakage. Maybe the manufacturer will let you send it back to them under warranty and format it... unless they'll send you some tools on a CD. |
What I would suggest is to download ethereal or some other free network analyzer and see what, if anything, is going on on the network between your NAS and other devices / internet.
A hub comes in very handy here - especially if you can't set up a switchport as a monitoring port. just use a x-over cable to connect the hub to the switch, then attach the NAS and the PC you are running your sniffer on to the hub. Now you will see all traffic between the NAS and everything else. SD |
Originally Posted by Mike-Bracknell
(Post 5239122)
Hence, the NAS firmware's uPNP has told the HomeHub that it wants to open 20/21 and the HomeHub has duly obliged.....leaving an FTP service open on the internet, which has subsequently been found by script kiddies with probes looking at 20/21 on a range of IP addresses.
What? :8 |
What I would suggest is to download ethereal |
Thanks for that; I'll give Wireshark ago with the config suggested.
As an aside, as a way of junking all the data I thought of rebuilding the NAS from RAID1 to RAID0 using the Admin Console, and then reverting to RAID1 but I guess (a) this doesn't necessarily reformat (so data still "exists") and (b) the RAID controller / MoBo is probably flashable and therefore could have been exposed to a hack anyway? |
Wireshark Wireshark easily produces a whole ton of data which can be confusing and difficult to interpret if you don't know what you're looking for or how to configure it. |
as a way of junking all the data I thought of rebuilding the NAS from RAID1 to RAID0 using the Admin Console, and then reverting to RAID1 but I guess (a) this doesn't necessarily reformat (so data still "exists") and (b) the RAID controller / MoBo is probably flashable and therefore could have been exposed to a hack anyway? I think the chances of the Motherboard being targetted are fairly slim in this scenario .... more likely is that the OS was targetted in order to attempt to ensure a backdoor remained available. |
Thanks again mixture. I take it then that if Wireshark doesn't show something dodgy (it doesn't so far*, amongst the tons and tons of data yuo correctly predicted!) then a RAID rebuild could be a sensible thing to do before forgetting the affair and moving on? Remember I have now verified that UPnP is "off" and that ShieldsUp found no weaknesses so it's only something already inside trying to get out that I think I need to consider.
*I let it capture for a while and then sorted the records alphabetically by source column so I could quickly scan I.P. addresses and names outside those I know. I then did likewise for destination. Nothing found. I'll let it run for a couple of hours more and then look again. |
then a RAID rebuild could be a sensible thing to do before forgetting the affair and moving on? What you could do is leave the RAID as RAID1, but just reformat it (or even better do a quick one pass zero overwrite) ....you might as well keep the benefit of RAID1. Then, you might want to consider making use of TrueCrypt (or other tool of your choice) to create encrypted disks (not "whole disk" encryption, just little disk images of manageable sizes - or larger sizes if you know you're never going to be doing remote access)..... so then at least your data is encrypted at rest and "they" can copy it as much as they want but would be able to see :mad: all. :ok: |
By the way, I forgot to say ...
Congratulations on you for being security aware and actually keeping an eye on your logs etc. So don't feel too bad about this whole lesson ! You did well to pick up on it so quickly. |
XV105 there must be a utility to securely erase the data on the drive and reset to the factory condition They must have thought of the end of life or moving locations. Look at the manufacturers web site and search the knowledge base. If no answer pose the question to them. They should have phone support available.
|
Thanks (again!), and for the comment. It still hurts though as I try to be absolutely as security aware as I am backup plan conscious, and something got past me. Grrrr!
Regarding encryption I have been using Memeo Backup for some time now but whilst I have elected to continue using it with the NAS I have likewise elected to continue using it without invoking the encryption option. My thinking here was that the benefit of being able to manually restore if the auto restore was ever needed but failed [the backup follows the same logical structure and is viewable (but must not be edited!) via Windows Explorer] outweighed the encryption benefit of a device on an internal network with strong firewall and which is unlikely to be stolen. Perhaps time to have a rethink. Regarding the RAID "reformat" I have successfully gone from RAID 1 to RAID 0, rebooted the NAS, and then gone back from RAID 0 to RAID 1. All is well and the free byte count is correct. The next job? To work out how the hell to remove (a) MioNet, (b) the Public Folder, and (c) the Download Folder without resorting to SSH and a hack. I have decided to live without MioNet and use web-hosted file sharing on demand instead and I don't need the two described folders that are a CIFS standard. |
resorting to SSH and a hack Post the commands they've told you to type on SSH and I'll soon tell you how likely they are to trash your box assuming they are standard Linux commands and not some proprietary NAS box commands ! :cool: |
Perhaps time to have a rethink. |
Can I just point out the following little-known facts:
1) the number of script kiddy attacks is inversely proportionate to their effectiveness. i.e. - there's thousands of teenage students out there, using P2P software and have probably downloaded a generic script which wants to replicate itself and does so via scanning IPs and trying basic exploits 2) another reason there are lots of attacks are because not everyone understands the benefits of keeping systems up to date regarding security exploit fixes etc 3) the VAST majority of script kiddy attacks are automated, basic, and targeted towards the exploits not patched in #2 above. 4) the VAST majority of exploits are for Windows systems, which make up a VAST majority of internet-connected computers 5) the VAST majority of exploits are done for commercial gain in some shape or form ... Hence, unless you are convinced that you had a manually initiated attack, onto your IP address, using exploits which were sufficient to compromise your own specific embedded Linux variant, and the operator was skilled enough to be able to install a trojan as a result, and they had something significant to gain from doing so on your NAS box (versus the time they would have had to do so, in a time and motion study sorta thing)......then i'd suggest you can sleep safe in your bed. FWIW, I have LOTS of devices on the internet, and attempted attacks are a regular occurrence. Granted you can't be 100% sure that someone's not smarter than you are, but on the law of averages and looking at the reasons behind the exploits, you really need to chill about this IMHO. (besides, the NAS specifically included uPNP in order to configure itself to do this very task on the internet - if you were a product designer, would you do this as standard if you weren't very confident about it's security?) |
5) the VAST majority of exploits are done for commercial gain in some shape or form Zombie nets Somewhere to host questionable content to share amongst "friends" etc. etc. (besides, the NAS specifically included uPNP in order to configure itself to do this very task on the internet - if you were a product designer, would you do this as standard if you weren't very confident about it's security?) Lets face it .... product design for residential products is NOT security lead. That includes residential firewalls embedded on cheapo routers, which don't compare in the least with their commercial variants. |
using exploits which were sufficient to compromise your own specific embedded Linux variant, But just to make my point of view clear... I think XV should take a little time to make sure his house is in order and then move on. I don't think he should spend days or weeks on it. |
But just to make my point of view clear... I think XV should take a little time to make sure his house is in order and then move on. I don't think he should spend days or weeks on it. |
Mike,
It does indeed seem we have the same end goal in mind even if certain methods of achieving it are up for debate, however now is not the time and PPRuNe is not the place. In the end, I think it has been correctly identified that UPNP was to blame here which, like WiFi and all the other residential technologies sold as a way to make your life easier, are so easily abused and mis-configured due to the manufacturers and resellers focus on marketing and sales rather than product development and user education/support. As for pointing fingers at BT and Homehub .... I will leave that one as an exercise for the reader..... :ok: |
The security of the BT hub leaves a lot to be desired, I got mine because I they offered me the Voip service for free. When I came to set it up I looked at the manual and could find no mention of WPA encryption at all, the only security mentioned was to enter the serial number of the router into the WEP box.
So I rang the help desk and the person I spoke to didn't even know what I was talking about. :ugh: I found WPA eventually. But it's a bloody awful setup menu, very difficult to find your way through (or at least it was 2 years ago when I got mine). |
| All times are GMT. The time now is 14:33. |
Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.