named responding to port 80

Barry Margolin barmar at genuity.net
Mon Mar 25 18:43:23 UTC 2002


In article <a7nno9$j4s at pub3.rc.vix.com>,
Steven Parsons <sparsons at columbus.rr.com> wrote:
>I have  been stumped with this for a couple days now so whoever can provide
>insight it is going to be greatly appreciated.
>
>I have a bind server 8.2.3-REL running on Sun OS which for some reason
>unknown to me at times answer's DNS requests to port 80.  This is causing
>a small amount (one right now that im aware) of users to assume they are
>code red probe's and myNewWatchman is sending alerts to my ISP.
>
>I feel very confident the server is secured - is only running Bind & SSH.
>I fell this is just something bind does at time's (port forwarding ?) but that I
>can not find documented or in the news group's.
>
>Below you can see some snip's of a couple snoop sessions and one more
>verbose showing the originating port being 53.  

A server should send a reply to the port that the query came from.  If
someone sends a query with source port 80, the reply will have destination
port 80.  There's nothing wrong or insecure about the server's behavior.

The question is why these queries are coming from port 80 in the first
place.  It could be a kind of spoofing attack; someone sends a query with
spoofed source address and port, and your server will dutifully send the
response back to that address/port.

It's also interesting that this is a TCP RST packet; although DNS can use
TCP, it normally uses UDP.  I think that supports my spoofing theory.

>
>Any additional information will be very much appreciated.
>
>Thanks
>
>Steven B. Parsons
>
>
>my.dns.server.com -> 192.116.207.178 HTTP C port=17601
>my.dns.server.com -> belly.worldaccessnet.com HTTP C port=49476
>my.dns.server.com -> cisco-gw.worldaccessnet.com HTTP C port=49476
>my.dns.server.com -> 12.39.160.31 HTTP C port=49476
>my.dns.server.com -> 63.149.183.31 HTTP C port=49476
>my.dns.server.com -> 192.116.207.178 HTTP C port=17601
>my.dns.server.com -> 203.196.69.64 DNS R port=80
>
>
>ETHER:  ----- Ether Header -----
>ETHER:
>ETHER:  Packet 1 arrived at 12:09:0.09
>ETHER:  Packet size = 54 bytes
>ETHER:  Destination = 0:0:c:7:ac:a, Cisco
>ETHER:  Source      = 8:0:20:9a:2e:f2, Sun
>ETHER:  Ethertype = 0800 (IP)
>ETHER:
>IP:   ----- IP Header -----
>IP:
>IP:   Version = 4
>IP:   Header length = 20 bytes
>IP:   Type of service = 0x00
>IP:         xxx. .... = 0 (precedence)
>IP:         ...0 .... = normal delay
>IP:         .... 0... = normal throughput
>IP:         .... .0.. = normal reliability
>IP:   Total length = 40 bytes
>IP:   Identification = 14581
>IP:   Flags = 0x4
>IP:         .1.. .... = do not fragment
>IP:         ..0. .... = last fragment
>IP:   Fragment offset = 0 bytes
>IP:   Time to live = 52 seconds/hops
>IP:   Protocol = 6 (TCP)
>IP:   Header checksum = 90f8
>IP:   Source address = 65.X.X.X, my.dns.server.com
>IP:   Destination address = 168.215.146.79, 168-215-146-79.gen.twtelecom.net
>IP:   No options
>IP:
>TCP:  ----- TCP Header -----
>TCP:
>TCP:  Source port = 53
>TCP:  Destination port = 80 (HTTP)
>TCP:  Sequence number = 0
>TCP:  Acknowledgement number = 0
>TCP:  Data offset = 20 bytes
>TCP:  Flags = 0x04
>TCP:        ..0. .... = No urgent pointer
>TCP:        ...0 .... = No acknowledgement
>TCP:        .... 0... = No push
>TCP:        .... .1.. = Reset
>TCP:        .... ..0. = No Syn
>TCP:        .... ...0 = No Fin
>TCP:  Window = 0
>TCP:  Checksum = 0x3279
>TCP:  Urgent pointer = 0
>TCP:  No options
>TCP:
>DNS:  ----- DNS:   -----
>DNS:
>DNS:  ""
>DNS:
>
>
>
>
>
>


-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


More information about the bind-users mailing list