firehol / blocklist-ipsets

ipsets dynamically updated with firehol's update-ipsets.sh script
https://iplists.firehol.org
3.14k stars 380 forks source link

False Positive in ransomeware_feed #76

Open omeryaron opened 5 years ago

omeryaron commented 5 years ago

The following ip: 185.230.61.161 found in line 3783 of ransomeware_feed.ipset file is a false positive. The IP is part of wix.com sites infrastructure, and only related to randsomware as FP due to hacked sites (in previous hosting) that later were transferred to host at wix (e.g. swordwind.org found in this report: https://malwarebreakdown.com/2016/12/09/payment-receipt-drops-locky-osiris/).

since wix.com is a large scale host, this false positive blocks many trusted sites.

l1kw1d commented 5 years ago

I think you are looking in the right direction when your are talking about the history. But as i do my investigation , and according to the present time period this ip at my regard is still "unsafe". Remember the internet is moving and owned by private compagny now. Let me explain. as you may noticed ISC, IANA, ARIN, are all updating policies , routing table , RFC compliant etc... Getting back to our story ISC F-root answers queries over IPv4 on 192.5.5.241, and over IPv6 on 2001:500:2f::f and using the same old hiarachical structure since 2003 (http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt). So looking at how the peering started , and looking at the history frm the AS attached to this case we noticed the same IP attached to the same AS , but the AS sometimes will report the block IP from israeli, san francisco, brazila, UK . Looking at the peering database we can notice different AS number. If you look directly on the ASN Neighbours History for the AS58182 you can noticed many flag that would help you understand the IP is managed / controlled / routed very poorly. The ip been spotted by a lot of websites, always involve with scam, infection threats, abuses.. That's why i dont want to blame wix in this case, they got a lot of others netblock with a very low score in abuse. When you own a business doing businnes all around the world , you can encounter the local law , or the local administrative rules and business owner are not always aware about that. The internet is evolving and upgrading in so many fields since the few last month.

Just take a look at the story from the AS112, https://www.as112.net/. (rel: https://www.ripe.net/analyse/dns/as112)

And you got an announcement from ICANN Updating of DNS Validating Resolvers with the Latest Trust Anchor, The root KSK rollover is currently planned for 1600 UTC on 11 October 2018.

ISC is testing EDNS compliance because the lack of proper EDNS compliance impacts the deployment of new DNS features. In particular we wish to deploy Domain Name System (DNS) Cookies [RFC 7873] which requires Unknown EDNS Options to be correctly handled by all servers.

The last good internet ip surveys from 1998 (http://ftp.isc.org/www/survey/reports/current/survey.html)

This is why we need good project like firehol or dns sinkhole. We need to be able to build a real trust from dataset that we can collect in that internet jungle !

We can be thankfull , cause the BIND DNS just got a major update last week, (BIND 9 Significant Features Matrix) https://kb.isc.org/docs/aa-01310# . I was the first one using DIG everywhere in all my work, but only few of my coworkers knew that DIG came from BIND. So we been working on many different UTM regarding problems and errors because many of those UTM are supporting very old RFC and even with BIND or any package capture you wont be able to see everything on your network (like the RFC for the FAST TCP). (https://tools.ietf.org/html/rfc7413).

This is why in those case i prefer to look if the problem is just from the netblock, from the hoster, from the owner.