| Keith C. Perry on 29 Mar 2018 21:38:57 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Verizon router's security log fills up too frequently |
George, 224.0.0.22 is a multicast address (IGMP) so its weird for the typical network to pass that traffic automatically but if you're not using it maybe VZ is (173.49.200.99 is your FIOS address). Its probably something upstream from your local FIOS network since its inbound to you. I would just drop that traffic so your logs don't fill up. The second block... sounds like it is working for Missus computer though so maybe the first packet is triggering a rule that finds the packet invalid before it gets translated? Seems benign. The third block... probably more of the same. The way this router logs things appears to be on the noisier side of things. I know you are saying you can't just run out and get another router but I would strongly suggest eventually putting in your own router even if its and old computer that you add another NIC to (I know... now I'm saying get another NIC). One should should never trust the edge of their network to your upstream provider. The additional advantage of doing this is that you can put in the type of router you want with the resources you need. You can remove or dumb down the VZ router filter rules and move the bulk of your work to your device. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Keith C. Perry, MS E.E. Managing Member, DAO Tecrhnologies LLC (O) +1.215.525.4165 x2033 (M) +1.215.432.5167 www.daotechnologies.com ----- Original Message ----- From: george@georgesbasement.com To: plug@lists.phillylinux.org Cc: "George Langford" <george@georgesbasement.com> Sent: Thursday, March 29, 2018 7:07:44 PM Subject: [PLUG] Verizon router's security log fills up too frequently Today I discovered rather belatedly that there is far too much activity happening in the Security Log of my ActionTec Wireless Router, courtesy Verizon FIOS. I've had it for a number of years, and in the past I've never seen the activity that surfaced today when I checked it for no good reason. The Log File had filled up and stopped recording all the craziness that has been happening since the Russians started messing around with our 'Net. Start rant: Here's what's been eating up several hours a day for the past few months: http://www.pinthetaleonthedonkey.com. The Russians are working toward a granddaddy DOS attack. One set of brute force hits on WordPress weaknesses escalated from 22 in a row in December to 44 in January to 89 in February; I'm expecting much worse in the March raw access log ... They are perfecting the timing of HEAD / HTTP requests to get to MyDomain.com at the same second on the clock, with a view towards overwhelming some unsuspecting Windows users when the Czar hacker activates Port 3389 on the participating servers. Back to the router: So I saved what there was and restarted the log ... only to be greeted with another filled-up log in a couple of hours ... and again ... and again, just today. Something has got to be changed. And it's not the Russians who are leaving their tracks all over my router; OK, maybe a few CloudFlare hits, a couple from Germany, one from Israel,one from France, one Chinese, but the rest are from Google, Amazon, Akamai, Adobe and lesser known US folks. But the most hits are nuisance procedural hits purportedly having something to do with the non-existent domain, 224.0.0.22. A Google search reveals that it's the result of some programmers not coordinating their efforts between competing applications. That glitch accounts for about 90% of the entries in the Security Log, and they need to get dropped if we can't make them go away in a less crude fashion. The ActionTect router gets nice reviews for wireless FIOS, but there is nowhere near enough storage for the Security Log. I can't just trot down to MicroCenter and get a better one ... Here's a snippet for a good 224.0.0.22 example: Mar 29 16:19:33 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1[repeated 31 times, last time on Mar 29 16:20:03 2018] Mar 29 16:07:46 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 16:07:45 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 16:07:45 2018 Firewall Info Rate Limit 2 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 16:07:13 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1[repeated 31 times, last time on Mar 29 16:07:44 2018] Mar 29 15:37:14 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 15:37:13 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 15:37:13 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 15:37:11 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 15:37:11 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Here's a snippet of some different activity: Mar 29 17:53:10 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 65.222.200.75:80->173.49.200.99:64642 on eth1 Mar 29 17:53:06 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64636->23.52.143.66:443 on eth1 Mar 29 17:52:57 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64635->23.52.143.66:443 on eth1 Mar 29 17:52:51 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 23.52.143.66:443->173.49.200.99:64635 on eth1 Mar 29 17:52:01 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64579->104.25.226.100:443 on eth1 Mar 29 17:45:52 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 13.33.74.8:80->173.49.200.99:64560 on eth1[repeated 2 times, last time on Mar 29 17:45:54 2018] Mar 29 17:42:39 2018 Firewall Info Rate Limit 1 messages of type [65] First packet is Invalid suppressed in 1 second(s) Mar 29 17:42:38 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64492->104.100.132.85:443 on eth1 The LAN address in the second snippet above is the Missus' laptop. Here's a short snippet with a CloudFlare connection: Mar 29 16:56:35 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 104.16.50.134:443->173.49.200.99:64263 on eth1 Mar 29 16:56:14 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64254->104.16.51.134:443 on eth1 where 104.16.50.134 and 104.16.51.134 is a typical CloudFlare domain IPv4 address pairing; but I didn't know the domain name until Google revealed through Hurricane Electric that the pair represents two of the five IPv4 addresses assigned to peapod.com by the CloudFlare service ... and Mrs. L just made an order through PeaPod for delivery of groceries ... so that's clearly an innocent Firewall Security Log occurrence. Is the Actiontec router just being paranoid ? Thanks, George Langford ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug