I have done that in the past when all else has failed, no calls On Mon, Dec 8, 2014 at 7:13 PM, Ken Hohhof via Af <af@afmug.com> wrote:
> What would be the downside of using a firewall rule to block TCP traffic > where BOTH source and destination port are 1024-65535 or maybe 20000-65535? > Talking about an ordinary subscriber. > > I have a customer with lots of such traffic and not much success convincing > him it's probably bad. If I block the port that gets opened up at his end, > it stops for maybe 2 hours and then it just opens a different port. If I > block the remote IP addresses, they just change. > > The traffic is exactly symmetric, the in and out graphs are so identical > you > can't distinguish the 2 colors of lines they are on top of each other, > except maybe around 8am and 8pm there is some genuine download traffic > probably when he is home. It's not steady streaming, it jumps all around, > with no time-of-day pattern, but it goes as high as 5M x 5M which IMHO is a > lot of bandwidth for something I assume should not be happening. The > traffic seems to come from hosted servers mainly in Germany, and then go > back out to an AWS Cloudfront CDN address. > > So far blocking TCP traffic where both source and destination ports are > 20,000-65,535 seems to stop it dead in its tracks, we'll see if it figures > out to go below 20,000. VoIP could be 10,000-20,000 but should be UDP, I > think maybe Facetime is 5000 but again UDP, so if necessary I can extend it > lower. > > Just wondering what legitimate traffic I might be interfering with. I know > there are applications that use high numbered ports, like routers managed > on > tcp/8080, also passive FTP and stuff like that. > > -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925
