#reverse dns

Hackertarget - Tools And Network Intelligence To Help Organizations With Attack Surface Discovery #network #footprint #hacking

Use open source tools and network intelligence to help organizations with attack surface discovery and identification of security vulnerabilities. Identification of an organizations vulnerabilities is an impossible task without tactical intelligence on the network footprint. By combining open source intelligence with the worlds best open source security scanningtools, we enable your attack…

For some reason I found it exceedingly difficult to find a simple/clear explanation of how SendMail performs reverse DNS lookups. What follows are notes collected from 5+ sources on the interwebs. Hopefully this saves other folks some time (*grumble grumble grumble...).

Short answer: Sendmail does not have a granular setting to disable the lookup for a remote host's name. There are options to REQUIRE reverse DNS results (via the FEATURE(`require_rdns' setting) but nothing that completely turns reverse DNS off while leaving other DNS lookups intact.

Instead, sendmail bundles reverse DNS under a broader question of "should I use DNS at all?". In modern versions, that decision it determined by the hosts: setting in the respective Name Service Switch config file on a system. For Redhat and CentOS, that file is typically /etc/nsswitch.conf

If the hosts: setting has a value of hosts: files dns sendmail will check the local hosts file first for information and then try DNS.

OK. So before we go any further, let's ask an obvious question: Why does sendmail need to perform a reverse dns query at all? In theory, there are a few reasons:

The remote hostname is compared to the local hostname to prevent sendmail from connecting to itself and looping messages.

The remote hostname used in the HELO and EHLO greeting can be compared to the lookup value. If they're different, sendmail can complain.

The hostname value is used for a macro $s which can be used for various programmatic (rules, milter, etc) activity.

The name can be entered into headers and logs for easier tracking.

With me so far? Cool. So now that we have the basics, what is the actual reverse DNS workflow look like for the incoming connection? As per section 21.2.2 of the O'Reilly "bat book":

1) sendmail runs as a daemon, creates (and binds to) a socket, and listens for incoming SMTP traffic. 2) When a remote host connects to the local host, sendmail uses the accept library to accept the connection. 3) As part of the workflow, the accept routine provides the IP address of the remote server to sendmail. 4) sendmail then calls gethostbyaddr to lookup the IP.

Hmm, OK. So, where does this leave us? Well, if the sendmail host is in the middle of mailflow and the count of upstream hosts are relatively small, the easiest option may be to just add those upstream IPs to the /etc/hosts file. That allows the gethostbyaddrfunction to find what it needs locally and avoid using DNS.

Sources:

http://docstore.mik.ua/orelly/networking/sendmail/ch21_02.htm

http://www.sendmail.com/sm/open_source/support/support_faq/faq_ver_8_issues/#3.22

https://lildude.co.uk/howto-prevent-sendmail-from-using-dns

https://www.safaribooksonline.com/library/view/sendmail-4th-edition/9780596510299/ch24s09s108.html

I deal with reverse dns issues so infrequently that I sometimes forget the specifics. Here's a brief summary of the workflow (if for no other reason than to remind myself):

Take the IP of an incoming connection and check the PTR DNS record for it.

Take the value of that PTR record and run a separate DNS query to check the A or AAAA record for it.

Check to see if the two records align with one another.

If there's a "match", then you've "confirmed" that there is a valid relationship between the owner of the DNS zone and the owner of the network that has been given the source IP address.

예를 들어 [email protected] 으로 발송한 메일의 경우, 역DNS를 조회하여 메일 서버의 대표 도메인이 naver.com과 일치하는지 확인 합니다. 만약 일치하지 않으면 사칭 메일이거나, 자동화 서버를 이용한 대량 스팸 폭탄일 가능성이 있죠. 외국 메일 서비스의 경우 이것이 일치하지 않으면 스팸으로 분류해버리는 메일 서비스들이 있습니다.

국내에서는 역DNS에 등록하는 것을 KT에서 대행해주고 있는데, 일반적으로 메일 도메인 주소와 메일 서버의 IP 주소가 다른 경우는 거의 없습니다. 네이버에서 보낸 메일은 당연히 네이버의 메일 서버를 통해 발송됩니다.

다만 이것이 다른 경우가 호스팅 서비스 등에서 많이 발견됩니다. 호스팅 사에서 쇼핑몰을 임대 받아 이용하고 있을 경우 메일 서비스도 호스팅 사에서 제공해주는 서비스를 사용하는 경우가 많은데요, 이런 호스팅사 서비스 중엔 발송자 주소를 고객 도메인에 연결해주는 서비스들이 있습니다.

예를 들어 myhosting.net라는 사이트의 호스팅을 받아 mysite.com이라는 사이트를 운영하고 있다면, 호스팅사에서 제공해주는 서비스에 따라 제 메일 주소를 [email protected] 이라고 만들 수 있습니다. 이 경우 메일 서버는 당연히 호스팅 사에서 보유하고 있습니다. 근데 호스팅 사에서는 메일 서버를 고객 당 한대씩 두는게 아니기 때문에(자원 낭비입니다.) myhosting.net이라는 주소를 메일 서버의 대표 도메인으로 등록합니다.

이 상태에서 [email protected]이라는 발송 주소로 외국에 있는 고객에게 메일을 보내면 해당 고객이 사용하는 메일 수신 서버에서는 역 DNS를 조회합니다. 발송자 메일 서버의 IP로 조회를 해보니 myhosting.net이라는 도메인이 호출됩니다. 발송자와 메일 서버의 도메인이 서로 다르기 때문에 스팸으로 인식하고 고객에게는 최종적으로 수신이 되지 않게 됩니다.

이런 대표적인 서비스가 aol.com입니다. 고객이 aol.com의 메일을 사용하고 있을 경우 저런 케이스엔 100% 스팸으로 처리됩니다. Gmail의 스팸 알고리즘은 그렇게 단순하지 않아서 수신이 되긴 합니다만 스팸 의심 요인 중 하나입니다.(즉 스팸으로 판단될 가능성이 높아집니다.)

이 문제를 해결하려면 사이트를 호스팅에서 임대하고 있다고 하더라도 메일 서버를 자체 도메인으로 해서 따로 구축해서 쓰던지, 아니면 호스팅의 대표 도메인으로 메일을 보내는 방법 밖엔 없습니다만, 전자의 경우 그렇게 구축할 수 있는 여력을 가진 곳이 많지 않고(메일 서버를 따로 둘 정도면 호스팅을 쓸 이유가 없..), 호스팅 사의 도메인으로 메일을 보내면 고객의 신뢰도가 감소합니다.

현재 국내에서는 제가 아는한 역 DNS를 통해 스팸으로 분류하는 곳은 한 곳도 없는 것으로 알고 있습니다. 따라서 이런 문제는 거의 해외에 한정되어 발생하는 문제라고 할 수 있겠죠.

Looking up the PTR resource records / reverses of the /24 neighbourhood of an IP address reveals lots of connections. To do so I use two bash functions. One function for printing all the reverses and one for creating an html file with pointers to more information. I named the first function ptr24 and it looks like that.

g0:~$cat .bashrc | head -14 function ptr24 { CNET=`echo $1|awk -F"." '{print $1"."$2"."$3}'` echo "PTR lookup for $CNET.0/24" for i in `seq 0 255`;do CUR=`dig +short -x $CNET.$i`; if [ -n "$CUR" ]; then echo -n "$CNET.$i -> "; echo $CUR; fi done }

So, if we want to explore the neighbourhood of the gnu.org web server we could do.

g0:~$dig +short gnu.org 140.186.70.148 g0:~$ptr24 140.186.70.148 PTR lookup for 140.186.70.0/24 140.186.70.1 -> ge-core1.qcy.gnu.org. 140.186.70.10 -> fencepost.gnu.org. 140.186.70.11 -> leviathan.gnu.org. ... 140.186.70.154 -> shop-dev.fsf.org. 140.186.70.155 -> testtaranis.gnu.org. 140.186.70.156 -> gplv3.fsf.org. 140.186.70.157 -> audio-video-dev.gnu.org. 140.186.70.253 -> ge-sw1.qcy.gnu.org. g0:~$

I named the second function ptr24htm and it looks like this.

g0:~$cat .bashrc |head -28|tail -15 function ptr24htm { CNET=`echo $1|awk -F"." '{print $1"."$2"."$3}'` echo "PTR lookup for $CNET.0/24<br />" for i in `seq 0 255`;do CUR=`dig +short -x $CNET.$i`; if [ -n "$CUR" ]; then echo -n "$CNET.$i -> "; echo "<a href=http://ipduh.com/dns/?$CUR>$CUR</a><br />"; fi done }

To produce a ptr.html of the gnu.org /24 neighbourhood we can do the following.

g0:~$ptr24htm `dig +short gnu.org` > ptr.html g0:~$