How come? - FTP brute force attack
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Time to move on
Hi Guys,
A courtesy post to say a final thank you.
So, other than a small number of files (I reacted quickly) which *may* have escaped from my network and which there is no point worrying about (all files were in a private secure area that would have needed hacking in to, it's too late now, and I don't know if the hack actually did anything anyway) I don't think any damage was done.
Time to move on.
Fresh backup to NAS running as I write this.
"Cheers Guys"
A courtesy post to say a final thank you.
- UPnP proven as the cause
- UPnP disabled on both router and NAS (I don't need media streaming internally - it's a backup device)
- Manually initiated Shields Up attack on my own external I.P. address revealed no weaknesses
- Both disks in the NAS "reformatted" to destroy all data (albeit by switching from RAID 1 to RAID 0 and back to RAID 1)
- Wire Shark installed and which confirms nothing trying to report back to base or any other kind of suspicious network activity
- MioNet remote access service now disabled (Not the cause of my troubles but a potential future weak link removed)
- NAS loaded with non-personal files and left running all night; this morning it was in standby mode and the logs show no activity overnight (they can be scrubbed, yes, but given the above I trust them)
So, other than a small number of files (I reacted quickly) which *may* have escaped from my network and which there is no point worrying about (all files were in a private secure area that would have needed hacking in to, it's too late now, and I don't know if the hack actually did anything anyway) I don't think any damage was done.
Time to move on.
Fresh backup to NAS running as I write this.
"Cheers Guys"
Last edited by The late XV105; 9th October 2009 at 09:46. Reason: Clarification
Joined: Aug 2007
Posts: 647
Likes: 0
The BT HH
Good to see a happy ending. I have a MK1 HH - The default security settings are atrocious - It does support AES encryption too by the way.
Somewhere in the advanced setup you can disable Plug and Pray and also disable the acceptance of packet fragments as well. Once set up; AES network encryption (sometimes called WPA2),used on modern kit does not hamper router performance too much.
The bad guys are cunning sods - As I have found out the hard way. It might be a good idea to monitor you network traffic for the future for a while just in case they come back for another go - unlikely but your can never be sure.
Your IP could change your external designated IP address if needed.
CAT III
Somewhere in the advanced setup you can disable Plug and Pray and also disable the acceptance of packet fragments as well. Once set up; AES network encryption (sometimes called WPA2),used on modern kit does not hamper router performance too much.
The bad guys are cunning sods - As I have found out the hard way. It might be a good idea to monitor you network traffic for the future for a while just in case they come back for another go - unlikely but your can never be sure.
Your IP could change your external designated IP address if needed.
CAT III
Joined: Jan 2008
Posts: 1,133
Likes: 0
From: Bracknell, Berks, UK
One thing the majority of HomeHub users may not be aware of, is that the default wifi channel is channel 6.
Now, with only 4 non-blocking channels in 802.11g, and the proliferation of HomeHubs, all on channel 6, if you live in wireless proximity of another HomeHub user the chances are you've got rubbish wifi functionality as a consequence.
In order to fix this, go download a wifi sniffer onto your laptop, such as Airmagnet, and check the channels and their associated strengths. Channels up to 4 channels either side of someone else's channel will interfere, to a greater or lesser degree, so if you choose channels 1,5,9, and 13, and choose one of those which is furthest from the majority of your neighbours, then you should see a corresponding increase in your wireless reliability
Now, with only 4 non-blocking channels in 802.11g, and the proliferation of HomeHubs, all on channel 6, if you live in wireless proximity of another HomeHub user the chances are you've got rubbish wifi functionality as a consequence.
In order to fix this, go download a wifi sniffer onto your laptop, such as Airmagnet, and check the channels and their associated strengths. Channels up to 4 channels either side of someone else's channel will interfere, to a greater or lesser degree, so if you choose channels 1,5,9, and 13, and choose one of those which is furthest from the majority of your neighbours, then you should see a corresponding increase in your wireless reliability
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Absolutely right!
The alternative, if like me you have two neighbours who freely admit they know Jack about what to do, is to set up the wireless routers for them and consider such channel spacing as part of the work.
Shhh. A third house is also within range, but the current elderly owner has no WiFi. The previous owner did, but with a SSID left at the default of NETGEAR I had everything I needed to know to find out what channel they were using without recourse to a sniffer, ahem.
The alternative, if like me you have two neighbours who freely admit they know Jack about what to do, is to set up the wireless routers for them and consider such channel spacing as part of the work.
Shhh. A third house is also within range, but the current elderly owner has no WiFi. The previous owner did, but with a SSID left at the default of NETGEAR I had everything I needed to know to find out what channel they were using without recourse to a sniffer, ahem.
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Your IP could change your external designated IP address if needed.
Joined: Jan 2008
Posts: 1,133
Likes: 0
From: Bracknell, Berks, UK
I switch both the pc and the router of when I go to bed, apart from security, there's the possible fire hazard to be considered, to say nothing of the cost.
- They are designed to run 24x7 without being a fire risk
- There is very little difference to the overall security of your house whether you run them during the day or 24x7 as you will have hacking attempts every 30 seconds or so anyway.
- The cost differential of a 3 watt device over a year is insignificant
...however, the big issue is that the way the Exchange premises equipment monitors and tunes your link speed depends upon you having the device on 24x7. In fact you can lose a significant percentage of your bandwidth purely by adopting a "turn it off at night" attitude.
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
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.
I thought I'd followed the above instructions clearly when running Wireshark, but it would appear not because after resolutely remaining at zero relevant hits since the firewall rule* was defined a few days ago, my HomeHub has today blocked over 10,000 NAS attempts to get outside but Wireshark spotted none of them.
Please will you be kind enough to re-describe?
TVM,
XV
*Custom settings to block all WAN traffic to and from the NAS.
Joined: Aug 2002
Posts: 3,663
Likes: 0
From: Earth
A hub comes in very handy here
As you might have gathered, my pseudonym is not sd..... but I feel I should state here that the chances of you owning or be able to buy a "hub" in 2009 are very, very slim.
Even 8 port boxes these days are switches.
In a day to day environment, hubs are more trouble than they are worth. I would not recommend you go out and buy one if you don't already own one because you will find very little useful use for it, unless you are plannig long term wiresharking ... but even then, you have to be very careful about how the hub is deployed.
What you should be looking to achieve, if you've got an unmanaged switch is either of the following :
(1) Get a managed switch (might be seen as a worthwile longterm investment, you can get small 8 or 12 port ones, no need for office sized ones)
-OR-
(2) Implement an in-line monitoring solution (i.e. two NICs on the PC)
UPDATED TO ADD :
Addmitedly, on a small home network, you probably will not see the difference between hub and switch unless things get really bad or you know what you are looking for. However the point I'm trying to make is hubs are bad feng shui on a network.
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Thanks, mixture; you confirmed what I suspected in that my ancient, decomissioned-until-the-last-few-days, four port ADSL router is a switch not a hub.
Please will you be kind enough to elaborate on your suggestion for an alternative way of me sniffing everything to and from the NAS. As well as the old router I just described I also have a brand new Netgear GS605 gigabit switch but of course it is of unmanaged type.
TVM!
PS - I have two gigabit LAN ports in the PC I will run the sniff from but believe they relate to one physical card. (I need to check since I didn't pay any attention at the time to that part of the spec as having two ports was a Brucie Bonus I didn't need)
Please will you be kind enough to elaborate on your suggestion for an alternative way of me sniffing everything to and from the NAS. As well as the old router I just described I also have a brand new Netgear GS605 gigabit switch but of course it is of unmanaged type.
TVM!
PS - I have two gigabit LAN ports in the PC I will run the sniff from but believe they relate to one physical card. (I need to check since I didn't pay any attention at the time to that part of the spec as having two ports was a Brucie Bonus I didn't need)
Joined: Aug 2002
Posts: 3,663
Likes: 0
From: Earth
Please will you be kind enough to elaborate on your suggestion for an alternative way of me sniffing everything to and from the NAS.
PS - I have two gigabit LAN ports in the PC I will run the sniff from but believe they relate to one physical card.
Joined: Aug 2002
Posts: 3,663
Likes: 0
From: Earth
Which comes from .....
CaptureSetup/Ethernet - The Wireshark Wiki
Which I'm just looking through to see what detail is lacking.....
Administrator
Joined: Mar 2001
Aviation Qualifications: PPL
Posts: 8,121
Likes: 686
From: Twickenham, home of rugby
XV,
An ethernet switch differs from an ethernet hub in that each port on a switch is a separate LAN segment, while each port on a hub is part of the same LAN segment.
All ports on a hub are thus in a single collision domain, whereas each port in a switch is in its own collision domain - which essentially means that frame collisions do not occur with switches. Collisions are bad, btw!
Switches also "learn" the MAC addresses of the connected hosts, so only directed unicast and broadcast frames are forwarded out each switch port. Only where the MAC address of a host is not yet in the switch MAC address table will a switch flood a unicast frame out all its ports.
As mixture rightly states, hubs have been entirely superseded by switches (now that the cost per switch port has reduced to the trivial), and hubs would seriously impact the performance on medium to large networks (due to the collisions described above). In a home network with a handful of devices, frankly, there is little difference in performance.
One of the switch's strengths (only forwarding frames to the necessary port) is also a pain when you actually want to monitor all the traffic between two nodes on the switch (or indeed all the traffic across the switch), as - by definition - the traffic is restricted to the ports that the two nodes are connected on.
There are a number of ways around this, depending on the equipment. "Business class" switches tend to have the ability to configure a monitoring port, that can be used to output all traffic from a selection of other ports - ideal if you happen to have that kind of kit.
Another possibility is to use a hub as described above - place the hub between the switch and the target device so that traffic passing from the switch to the target passes through the hub, and - by definition - is flooded out of all the hub ports. By hooking your sniffer to a hub port you get to see all the traffic.
I'm not sure about the "inline" method mixture refers to. Perhaps he will elaborate for us.
While you may struggle to buy a new ethernet hub, a quick look on ebay suggests that you'll easily pick one up from 99p to a fiver, plus P&P. Just ensure you get an ethernet hub, not a USB hub!
SD
An ethernet switch differs from an ethernet hub in that each port on a switch is a separate LAN segment, while each port on a hub is part of the same LAN segment.
All ports on a hub are thus in a single collision domain, whereas each port in a switch is in its own collision domain - which essentially means that frame collisions do not occur with switches. Collisions are bad, btw!
Switches also "learn" the MAC addresses of the connected hosts, so only directed unicast and broadcast frames are forwarded out each switch port. Only where the MAC address of a host is not yet in the switch MAC address table will a switch flood a unicast frame out all its ports.
As mixture rightly states, hubs have been entirely superseded by switches (now that the cost per switch port has reduced to the trivial), and hubs would seriously impact the performance on medium to large networks (due to the collisions described above). In a home network with a handful of devices, frankly, there is little difference in performance.
One of the switch's strengths (only forwarding frames to the necessary port) is also a pain when you actually want to monitor all the traffic between two nodes on the switch (or indeed all the traffic across the switch), as - by definition - the traffic is restricted to the ports that the two nodes are connected on.
There are a number of ways around this, depending on the equipment. "Business class" switches tend to have the ability to configure a monitoring port, that can be used to output all traffic from a selection of other ports - ideal if you happen to have that kind of kit.
Another possibility is to use a hub as described above - place the hub between the switch and the target device so that traffic passing from the switch to the target passes through the hub, and - by definition - is flooded out of all the hub ports. By hooking your sniffer to a hub port you get to see all the traffic.
I'm not sure about the "inline" method mixture refers to. Perhaps he will elaborate for us.
While you may struggle to buy a new ethernet hub, a quick look on ebay suggests that you'll easily pick one up from 99p to a fiver, plus P&P. Just ensure you get an ethernet hub, not a USB hub!
SD
Joined: Aug 2002
Posts: 3,663
Likes: 0
From: Earth
I'm not sure about the "inline" method mixture refers to. Perhaps he will elaborate for us.
Joined: Aug 2002
Posts: 3,663
Likes: 0
From: Earth
It's been a little while since I've done it inline even more so when using a Windows box to capture, more used to using managed switches and spanning ports.
However, from memory, what needs to be done is as follows :
(1) Bridge your two network cards
If I recall, this is a simple as highlighting them both, right clicking and selecting "bridge interfaces".
(updated -> in the text that was here before I said to configure bridge itself with IP settings.... technically it should work without because most of its magic is at Layer 2 rather than Layer 3 .... so try without extra bridge config work first)
(2) Start a wireshark capture
Hopefully wireshark will let you watch the virtual interface, otherwise you only need to watch one interface, it will pick up on all traffic.
Let me know if you need more detail, although I might pop back an update this post later.
However, from memory, what needs to be done is as follows :
(1) Bridge your two network cards
If I recall, this is a simple as highlighting them both, right clicking and selecting "bridge interfaces".
(updated -> in the text that was here before I said to configure bridge itself with IP settings.... technically it should work without because most of its magic is at Layer 2 rather than Layer 3 .... so try without extra bridge config work first)
(2) Start a wireshark capture
Hopefully wireshark will let you watch the virtual interface, otherwise you only need to watch one interface, it will pick up on all traffic.
Let me know if you need more detail, although I might pop back an update this post later.
Last edited by mixture; 14th October 2009 at 18:28.
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Very helpful, thank you both
Using mixture's schematic, I have the NAS as "Host A" connected to successfully bridged LAN ports in my XP MCE machine that is also runnng Wireshark, and my BT HomeHub as "Host B". WiFi is switched off (adaptor disabled in the PC) for good measure.
Using it's IP address I can browse the NAS from the PC so it's alive and well and I can also reach my Homehub admin page and the internet too.
Homehub still set to block all LAN activity from the NAS' IP address that trys to reach the internet (and viccy verky) so time for some Sharking.
Stay tuned....
Using mixture's schematic, I have the NAS as "Host A" connected to successfully bridged LAN ports in my XP MCE machine that is also runnng Wireshark, and my BT HomeHub as "Host B". WiFi is switched off (adaptor disabled in the PC) for good measure.
Using it's IP address I can browse the NAS from the PC so it's alive and well and I can also reach my Homehub admin page and the internet too.
Homehub still set to block all LAN activity from the NAS' IP address that trys to reach the internet (and viccy verky) so time for some Sharking.
Stay tuned....
Thread Starter
Joined: Feb 2006
Posts: 594
Likes: 0
From: UK
Ok, tuning back in....
That was so easy, ta!
Here's the result, with the total number of records exactly equalling the difference in my firewall rule's "blocked" count when I started and when I finished sniffing.
Any comments on the missing pieces, please?
*WD have acknowledged a bug in response to a support case that I logged whereby it is impossible to fully disable the MioNet service on the NAS. It restarts by itself every half an hour and when the server is booted even if the "do not start MioNet" flag was selected before shutdown. From Wireshark it seems that it's slumbering rather than hibernating when disabled too as the blocked traffic is from when the NAS admin console reports that MioNet is "off"!
That was so easy, ta!
Here's the result, with the total number of records exactly equalling the difference in my firewall rule's "blocked" count when I started and when I finished sniffing.
- "Whois 198.107.148.254" resolves this IP address to Western Digital MioNet despite the fact that I have disabled* this remote access service on the NAS!
- "Whois 224.0.0.22" does not resolve to a domain name but Google returned
The World Knocks at the Door of Your Internet Connection Joejolly’s Weblog ! - "Whois 224.0.0.251" doesn't give any clues.
- "Whois 239.255.255.250" doesn't give any clues.
- "Whois 235.1.1.1" does not resolve to a domain name but Google indicates that it's probably connected to the (Twonky Media) streaming service on the NAS that we use to allow our two WiFi radios to play all music from the NAS; although I wanted to keep it as a backup-only device, the lure of always on music was tempting for the family so I invoked it at the weekend.
Any comments on the missing pieces, please?
*WD have acknowledged a bug in response to a support case that I logged whereby it is impossible to fully disable the MioNet service on the NAS. It restarts by itself every half an hour and when the server is booted even if the "do not start MioNet" flag was selected before shutdown. From Wireshark it seems that it's slumbering rather than hibernating when disabled too as the blocked traffic is from when the NAS admin console reports that MioNet is "off"!
Last edited by The late XV105; 14th October 2009 at 19:16. Reason: Corrected bulleting
Administrator
Joined: Mar 2001
Aviation Qualifications: PPL
Posts: 8,121
Likes: 686
From: Twickenham, home of rugby
These are multicast addresses - 224.0.0.0 through 239.255.255.255.
The range from 224.0.0.0 to 224.0.0.255 (or 224.0.0.0/24) is designated for multicasting on the local LAN only.
224.0.0.251 is the Multicast DNS address.
224.0.0.22 is used by the IGMP Version 3 (Internet Group Management Protocol).
More details here: http://www.iana.org/assignments/multicast-addresses/
SD
The range from 224.0.0.0 to 224.0.0.255 (or 224.0.0.0/24) is designated for multicasting on the local LAN only.
224.0.0.251 is the Multicast DNS address.
224.0.0.22 is used by the IGMP Version 3 (Internet Group Management Protocol).
More details here: http://www.iana.org/assignments/multicast-addresses/
SD