This is the same origin that I reported on earlier. Apparently asking for an explanation of why they were probing our sites only encouraged them to make additional attempts.
sshd: Authentication Failures: unknown (ip-173-201-178-18.ip.secureserver.net): 2 Time(s) unknown (ip-97-74-196-33.ip.secureserver.net): 2 Time(s) unknown (ip-97-74-202-95.ip.secureserver.net): 2 Time(s) root (ip-173-201-252-24.ip.secureserver.net): 1 Time(s) root (ip-72-167-249-196.ip.secureserver.net): 1 Time(s) root (ip-72-167-251-87.ip.secureserver.net): 1 Time(s) root (ip-97-74-121-108.ip.secureserver.net): 1 Time(s) root (ip-97-74-193-219.ip.secureserver.net): 1 Time(s) root (ip-97-74-206-13.ip.secureserver.net): 1 Time(s) unknown (ip-173-201-252-24.ip.secureserver.net): 1 Time(s) unknown (ip-72-167-249-196.ip.secureserver.net): 1 Time(s) unknown (ip-72-167-251-87.ip.secureserver.net): 1 Time(s) unknown (ip-97-74-121-108.ip.secureserver.net): 1 Time(s) unknown (ip-97-74-193-219.ip.secureserver.net): 1 Time(s) unknown (ip-97-74-206-13.ip.secureserver.net): 1 Time(s) Invalid Users: Unknown Account: 12 Time(s)
So, is there any convenient way to construct an IPTables rule to block all IPs associated with a given Domain Name server?
dig -x 173.201.178.18
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> -x 173.201.178.18 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1357 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
;; QUESTION SECTION: ;18.178.201.173.in-addr.arpa. IN PTR
;; ANSWER SECTION: 18.178.201.173.in-addr.arpa. 3600 IN PTR ip-173-201-178-18.ip.secureserver.net.
;; AUTHORITY SECTION: 201.173.in-addr.arpa. 66199 IN NS cns2.secureserver.net. 201.173.in-addr.arpa. 66199 IN NS cns1.secureserver.net.
;; ADDITIONAL SECTION: cns2.secureserver.net. 172800 IN A 216.69.185.100 cns2.secureserver.net. 172800 IN AAAA 2607:f208:303::64 cns1.secureserver.net. 172800 IN A 208.109.255.100 cns1.secureserver.net. 172800 IN AAAA 2607:f208:207::64
Like say, cns{1,2}.secureserver.net. Or an entire domain? Say secureserver.net. ?
--On Monday, October 05, 2015 10:46 AM -0400 "James B. Byrne" byrnejb@harte-lyne.ca wrote:
So, is there any convenient way to construct an IPTables rule to block all IPs associated with a given Domain Name server?
Doing DNS queries within the kernel netfilter path would be bad.
You could run a cron job to update an iptables chain periodically with the results of a dig query. Some Perl could be used to do the query and generate the iptables commands.
--On Monday, October 05, 2015 10:46 AM -0400 "James B. Byrne" byrnejb@harte-lyne.ca wrote:
So, is there any convenient way to construct an IPTables rule to block all IPs associated with a given Domain Name server?
IPs have the reversed lookup "assosiated" with a NS.
What do you mean with "associated"?
Do mean all IPs that this DNS server resolves to (A-Records in zone) (how do know for what zone the NS gives authoritative answers)?
Or just the domain name server IPs of a given domain name (NS records)?
What are you trying to solve?
-- LF
On 10/6/2015 6:34 AM, Leon Fauster wrote:
--On Monday, October 05, 2015 10:46 AM -0400 "James B. Byrne"byrnejb@harte-lyne.ca wrote:
So, is there any convenient way to construct an IPTables rule to block all IPs associated with a given Domain Name server?
IPs have the reversed lookup "assosiated" with a NS.
What do you mean with "associated"?
Do mean all IPs that this DNS server resolves to (A-Records in zone) (how do know for what zone the NS gives authoritative answers)?
Or just the domain name server IPs of a given domain name (NS records)?
What are you trying to solve?
I wondered much the same. most NS servers won't allow you to do a zone transfer to find all the A/AAAA records in a given domain. doing a reverse DNS lookup on every incoming/outgoing socket connection would be beyond painful, it would bring your network to its knees as the reverse DNS zones are often broken.
Taking a stab at you meaning "block all IPs that reverse resolve to a name managed by secureserver.net" because their servers keep scanning you.
You could craft a fail2ban recipe to reverse resolve the IP address (after a some threshold of rejected packets) then block that IP if it ' secureserver.net' is the authority for the PTR record.
K
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd GitHub: @tartansandal
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"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
On 7 October 2015 at 04:36, John R Pierce pierce@hogranch.com wrote:
On 10/6/2015 6:34 AM, Leon Fauster wrote:
--On Monday, October 05, 2015 10:46 AM -0400 "James B. Byrne"< byrnejb@harte-lyne.ca> wrote:
So, is there any convenient way to construct an IPTables rule to block
all IPs associated with a given Domain Name server?
IPs have the reversed lookup "assosiated" with a NS.
What do you mean with "associated"? Do mean all IPs that this DNS server resolves to (A-Records in zone) (how do know for what zone the NS gives authoritative answers)?
Or just the domain name server IPs of a given domain name (NS records)?
What are you trying to solve?
I wondered much the same. most NS servers won't allow you to do a zone transfer to find all the A/AAAA records in a given domain. doing a reverse DNS lookup on every incoming/outgoing socket connection would be beyond painful, it would bring your network to its knees as the reverse DNS zones are often broken.
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 6 October 2015 at 00:46, James B. Byrne byrnejb@harte-lyne.ca wrote:
So, is there any convenient way to construct an IPTables rule to block all IPs associated with a given Domain Name server?
You can use ipsets to block a large collection of IP addresses with netfilter. I block various problematic countries that way.
The problem is getting _all_ the IP addresses associated with a DNS server. I don't think that is going to be easy/possible, unless that DNS sever has been badly misconfigured.
K