Today I had the phantom data-loss issue -- with my "Anytime Data" tracker going to ZERO while my Bonus Tracker was at 82% -- which is odd. So I started testing, calling, and came-up with this:
I cranked-up my alternate router I had before I subscribed with Hughesnet thinking it had to provide better protection from DDoS (Denial of Service) attacks / hacking, and my "hunch" paid-off.
My Hughesnet router's firewall is set to "on," and the usual intrusion prevention and stateful inspection all configured to the correct default settings, but still something got through...
[DoS attack: Smurf] attack packets in last 20 sec from ip [192.168.xx.xxx], Sunday, Oct 14,2018 19:38:07
The IP address listed above is the HUGHESNET router allowing these IP packets through even though its firewall is set to the default "on" settings. So apparently it's not stopping these DDoS SMURF packets from going across the NAT (modem / router interface,) and could be why some folks are having issues...
A Smurf amplifier is a computer network that lends itself to being used in a Smurf attack. Smurf amplifiers act to worsen the severity of a Smurf attack because they are configured in such a way that they generate a large number of ICMP replies to the victim at the spoofed source IP address.
Please fix this pronto!
I notice that the default setting for ICMP is set to "respond or reply to" my Hughesnet modem / router was set to "discard ICMP requests," and those SMURF packets still got through. That creates bottlenecks with all those modem / routers set to reply and respond to ICMP -- these should be set to OFF or not to reply to lower the attack surface of any internet-facing device...
Had assumed it may be something like that, but considered it might be torrent-related from an external user repeatedly trying to latch onto a newly-obtained IP (after modem reboot).
Somewhat similar premise, different port. Nice detective work.
Thank you Mark, I checked my log today and found that was the only entry -- so far no SMURF DoS except the one listed above.
Combined with data-use -- anytime data mysteriously going into a black-hole -- and dropped calls on the Voice Service -- something is going-on that makes me very uneasy. 644 Mb does not equal 1 Gb. Where did the rest of the data go?
I've never seen a subnetted network (192.168.42.1 - LAN) behind another network (192.168.0.1 - WAN) configured like this before.
And you cannot change the subnetted network's IP address. I figured it was due to limit users IP's they could add but seeing as the 192.168.42.1 subnet can have 150 IP addresses, this is not the reason it's subnetted - So there is another reason. Could it be to seperate the Gen 4 and Gen 5 systems? Provisioning? But the data-loss? That data tracker lives on the 192.168.0.1 - WAN and counts data on the WAN and also the LAN IP addresses 192.168.42.1 subnet. It's counting more data than I'm using that's for sure. If I had done the configuration for the LAN / NAT subnet, I'd have put the data tracker on so it would only count the data a user actually used.
The WAN subnet of 192.168.0.1 is also where DNS lives and any traffic traveling across that network gets counted, and Hughesnet has no sponsored data with Microsoft or Apple so that when user's Windows or iOS updates it wouldn't cost them data... I suggested this to Hughesnet and the chat rep said that was a good idea. Not a great idea is when they won't listen to user's remarks like mine, because I KNOW what I'm talking about -- because I have a degree in Networking and have done this for almost 20 years -- I think I have a good eye as to what their problems are...
The DoS SMURF packets came from somewhere -- my modem (behind Hughesnet router / modem) shows it came-from 192.168.42.1 IP address, and since the modem / router's firewall and intrustion detection didn't see the packets, that tells me there's some kind of mis-configuration -- it should have kicked those packets and not have passed them thru it. So the firewall and settings are useless on the Hughesnet modem / router. This is why the default settings are set to OFF. ICMP is also passing-through that modem, which it's not supposed to be doing. I've got it set to not reply to ICMP requests, but my modem is set not to either -- on the log it says it dropped the ICMP requests and didn't reply, but these are not even showing-up on the log on the Hughesnet modem / router. Something isn't right. And I'm not interested in getting my devices hacked due to that mis-configuration on the Hughesnet devices.
[DoS attack: Smurf] attack packets in last 20 sec from ip [192.168.42.101], Sunday, Oct 14,2018 19:38:07
192.168.0.1 assigns IP addresses via DHCP to router / modem of 192.168.42.1 and the LAN side IP address of the router / modem is 192.168.42.101 which is also my Netgear modem / router's IP address. But it's not my Netgear sending those DoS SMURF packets -- it received them, hence showing-up on the Netgear's log. There is nothing on the Hughesnet router / modem log so that makes me think there is some kind of transitive or other trust arrangement configured between the two subnets -- but you cannot change the 192.168.42.1 subnet so there is no way you can limit the range of IP addresses or even change them. Those packets are coming from somewhere and it's obvious that some kind of reconfiguration is needed or nothing is as secure as it COULD be made. And this is not good policy -- it wastes bandwidth and also opens doors that need to be shut completely and jeopardizes the security and puts users in a situation where they are not being protected as well as they should be...
Notice these transactions from Hughesnet Router / Modem to Netgear Modem / Router as indicated on the log from Netgear.
Notice the NPT - internet time server -- internet disconnected -- AFTER it gets an ICMP request from the WAN IP Address of the Hughesnet Modem / Router -- this proves it's coming from OUTSIDE -- then immediately reconnects.
[Time synchronized with NTP server] Sunday, Oct 14,2018 19:44:25
[Internet connected] IP address: 192.168.42.101, Sunday, Oct 14,2018 19:44:24
[Service blocked: ICMP_echo_req] from source 192.168.42.1, Sunday, Oct 14,2018 19:44:21
[Internet disconnected] Sunday, Oct 14,2018 19:44:20
[Time synchronized with NTP server] Sunday, Oct 14,2018 19:42:09
[Internet connected] IP address: 192.168.42.101, Sunday, Oct 14,2018 19:41:31
[Internet disconnected] Sunday, Oct 14,2018 19:41:29
Something is going-on that makes me nervous.
Just think, on the IP address leases -- normally I set mine to PER DAY -- expires every day -- but I noticed that Hughesnet has IP addresses set to expire every 30 minutes. Why? I think they know. And I know.
Spoofed IP addresses for 192.168.42.1 or 192.168.42.101 -- how many modems / routers are configured in this way? And the only way to work-around this is for you to ADD your router (that you might put behind Hughesnet's modem / router) and configure it to only ALLOW MAC addresses from YOUR individual Hughesnet modem / router -- not every darned modem / router on the network with that same IP address -- How does the Hughesnet 192.168.0.1 network tell who's is whose? It can't unless they have the MAC addresses filtered to NOT ALLOW. But I'm going to configure my Hughesnet modem / router to NOT ALLOW any MAC except the modem / router I have. See if that helps.
On the Hughesnet modem / router the subnet IP is 192.168.42.1, but what is this other network?
What does this belong to? It's on my LAN and none of my devices HAVE AN IP address like this one.
Anyone have any ideas? I should not be anything as this on my LAN. How can you have two LANs? You cannot.
I bet that data tracker tracks data coming and going on this LAN subnet as well. This is ridiculous.