Thursday, July 06, 2017

997 Hosts Sending Unwanted Traffic

Just as was with spam in Brian Krebs' book Spam Nation it feels like people are simply ignoring the fact that our networks are inundated with noise the same way spam was ignored. "It's just spam. There's nothing we can do."

Now the noise is all kinds of other traffic and it is the precursor to things like Wannacry and Not Petya. Or worse.

What to the book there was a company called Blue Frog that had all its customers return traffic to a host that sent an unwanted email message. The host would get inundated and become unable to function. Perhaps something similar could work. In this case however, it would probably affect individual home users who wouldn't know what to do about it unfortunately. Additionally, the spammers in the book personally went after and threatened the people running Blue Frog. Hackers have also gone after Brian Krebs for his security reporting:

If you own one of the IPs below you might want to take a look at the traffic leaving your host.

If you don't perhaps you'll need to block these IPs if you notice suspicious traffic as I did. localhost. hn.kd.ny.adsl. . hn.kd.ny.adsl. hn.kd.ny.adsl. undefined.hostname.localhost.
MAC-50917:traffic tradichel$ cat 070517badips-rev.txt localhost. hn.kd.ny.adsl. . hn.kd.ny.adsl. hn.kd.ny.adsl. undefined.hostname.localhost.
MAC-50917:traffic tradichel$ cat 070517badips-rev.txt localhost. hn.kd.ny.adsl. . hn.kd.ny.adsl. hn.kd.ny.adsl. undefined.hostname.localhost. hn.kd.jz.adsl. hn.kd.ny.adsl. localhost. localhost. htuidc.bgp.ip. htuidc.bgp.ip. htuidc.bgp.ip. newlifm.

Tuesday, July 04, 2017

What's Up With All the ICMP Traffic

I believe certain brands of wireless routers generate a lot of unnecessary traffic.

I prefer no ICMP:

Friday, June 30, 2017

May be infected with Wannacry or similar: Port 445

Hosts hitting my network on port 445 in the past few minutes - may be infected by WannaCry or?

China and Vietnam

  • inetnum: -
  • netname: CMST-ORENBURG-20130115
  • descr: Orenburg TsuS of Privolzhsky branch of CJS Komstar-Regiony
  • country: RU
  • admin-c: OMZ4-RIPE
  • tech-c: OMZ4-RIPE
  • status: ASSIGNED PA
  • mnt-by: OVERTA-MNT
  • created: 2013-01-15T06:28:42Z
  • last-modified: 2017-06-01T12:12:14Z
  • source: RIPE
  • person: Oleg M Zavalishin
  • address: 14, Karavannaya st., Orenburg
  • phone: +73532372111
  • nic-hdl: OMZ4-RIPE
  • notify:
  • mnt-by: OVERTA-MNT
  • created: 2013-01-15T06:21:59Z
  • last-modified: 2013-01-15T06:21:59Z
  • source: RIPE

inetnum: -
descr:FPT Telecom Company
descr:2nd floor FPT Building, Pham Hung Road, Cau Giay District, Hanoi
remarks:For spamming matters, mail to 20120809
address:Ha Noi, VietNam
auth:# Filtered
mnt-by:MAINT-VN-VNNIC 20101108

Monday, June 26, 2017

DNS traffic, Port 53, AWS

Update: @colmmacc  was kind enough to get back to me with these comments on Twitter if you are looking for AWS DNS CIDRs:

Will look at better JSON description. In the meantime, all of Route 53 is in DNS needs TCP/53 open too for large answers. We'll add more IPs to Route 53 over time too. But unlikely to ever remove.


Taking a look at the IP addresses my EC2 instance attempts to connect to for DNS.

Unfortunately Amazon does not publish which IP ranges are specifically for DNS on this IP ranges list which makes it hard to set specific rules for DNS in NACLs or security groups.

Looks like my EC2 instance attempted to connect to the following IPs. Since this is a WatchGuard Firebox Cloud some of these IPs could be related to WatchGuard however the names are not resolving to WatchGuard DNS entries. So is this AWS DNS traffic or WatchGuard DNS traffic...can explore this further but is making it a bit complicated to create network rules that only allow my instance to go to the desired DNS server. 53 53 53 53 53 53 53 53 53 Comtouch?? India??

What's the problem? If an instance goes to the incorrect DNS server this could pose a serious security problem. If an instance resolves a DNS name to the wrong IP address it could potentially be connecting to a rogue host due to the incorrectly resolved name. Perhaps non-AWS traffic is related to a WatchGuard service. More inspection is needed.

So what to looks like the addresses with awsdns-xx in the name are in this AWS global IP range:

      "ip_prefix": "",
      "region": "GLOBAL",
      "service": "AMAZON"

It looks like the service is using UDP (protocol 17).

So for now will allow egress traffic (initiated from my instance to the Internet) on port 53 to the global AWS range above on protocol 17 and ephemeral ports inbound. We'll see what happens...