search

hardenize / hardenize-public

11 stars 0 forks source link

Feature request: discover further services per RFC6186 #58

Open andreasschulze opened 5 years ago

andreasschulze commented 5 years ago

RFC6186 describe how to announce submission, pop3 and imap services via DNS.

Hardenize could discover and inspect these services for domains implementing the RFC.

ivanr commented 5 years ago

That's a very useful discovery mechanism and I think we should support it in Hardenize. The only thing I am not sure about is whether we should include the discovered services in our report. In other words, we need to determine if the services are public or private. We want to provide a polite service.

andreasschulze commented 5 years ago

everything in DNS is public. If an domainowner setup an SRV under _imap._tcp.example.com, that is public. I may happen, that the Host referenced in SRV is not public accessible (firewalled, private name, private address). This information is also public. If one could establish a TCP connection to the host, that's public.

Your question is whether to show the public gathered data even if there is no TCP connection possible for whatever reasons. I tend to say: yes.

ivanr commented 5 years ago

Sure, but I didn't use the word "public" in the sense "can be observed" or "can be accessed". I used it in the sense "intended for public access". That's the criteria we use to determine if we access services. For example, ports 25, 80, and 443 are clearly public in my opinion, but if I setup an email system (e.g., IMAP) for my family, then it's not so clear.

jani commented 4 years ago

First, thanks for providing a great service!

Port 443 may well be a private NAS or even firewall admin interface, not "clearly public" in any way whatsoever, so I think the public/private argument is pretty weak.

It would be very nice to at least explicitly test ports 993 (imaps, IMAP over TLS) and 995 (pop3s, POP3 over TLS), and preferably also ports 143 and 110 with STARTTLS.

If POP3 and IMAP services are not announced in DNS, they could be implicitly tested for at e.g. imap.mydomain.example and pop.mydomain.example.

Considering that both POP3 and IMAP can be used destructively if there is weak encryption, as well as for extracting weak passwords in transmission, please bump up this on your priority list.