On Thu, Aug 03, 2000 at 02:14:08PM -0400, marek@foundmoney.com wrote:
> I have tried two other mailing(like linux-net, etc) lists with this
> question and no luck, so I thought I will try it here.
Did you try on the bind list?
> One of our systems was compromised with t666.c I believe, there was a
> directory called AMDROCKS in /var/named
Yeah, ok... You got burned by ADMROCKS. Well known bind hole.
Very well known bind whole. The script kiddies are scanning for bind
servers using massively parallel scanners.
> (RH6.2 2.2.14)So I upgraded to named, and few other things. Named was
> and is running under its own username, etc.
> This is what I have gathered from the named debug file. The domain name
> here in question is not ours, nor we have anything to do with it. Can
> someone please translate into english the following lines. ????
Ok... I'm not quite sure what you are after (I know what you
are literally asking and it's probably why no one has answered you).
Is this from the failure when they broke in or are you having problems
NOW after the upgrade. What was this trace from?
> datagram from [210.113.231.145].1668, fd 22, len 35
> req: nlookup(v.scenewhores.com) id 53786 type=1 class=1
> req: found 'v.scenewhores.com' as 'com' (cname=0)
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197248.000000000, inter 0.000000000)
> forw: forw -> [198.41.0.4].53 ds=5 nsid=15407 id=53786 79ms retry 4sec
> datagram from [198.41.0.4].53, fd 5, len 130
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15407
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
> ;; v.scenewhores.com, type = A, class = IN
> SCENEWHORES.COM. 2D IN NS NS1.SUIDREWT.ORG.
> SCENEWHORES.COM. 2D IN NS NS2.SUIDREWT.ORG.
> NS1.SUIDREWT.ORG. 2D IN A 195.13.119.253
> NS2.SUIDREWT.ORG. 2D IN A 195.13.119.254
> resp: nlookup(v.scenewhores.com) qtype=1
> resp: found 'v.scenewhores.com' as 'scenewhores.com' (cname=0)
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197248.000000000, inter 0.000000000)
> sysquery: send -> [198.41.0.4].53 dfd=5 nsid=2176 id=0 retry=965197248
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197248.000000000, inter 0.000000000)
> sysquery: send -> [198.41.0.4].53 dfd=5 nsid=25109 id=0 retry=965197248
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197248.000000000, inter 0.000000000)
> datagram from [198.41.0.4].53, fd 5, len 180
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197248.000000000, inter 0.000000000)
> datagram from [198.41.0.4].53, fd 5, len 180
> datagram from [210.113.231.145].1668, fd 22, len 35
> req: nlookup(v.scenewhores.com) id 53786 type=1 class=1
> req: found 'v.scenewhores.com' as 'scenewhores.com' (cname=0)
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197253.000000000, inter 0.000000000)
> forw: forw -> [195.13.119.253].53 ds=5 nsid=43213 id=53786 3ms retry
> 4sec
> evSelectFD(ctx 0x80d2740, fd 7, mask 0x1, func 0x8086e98, uap
> 0x4013004c)
> IP/TCP connection from [216.208.41.78].4355 (fd 7)
> datagram from [195.13.119.253].53, fd 5, len 84
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43213
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; v.scenewhores.com, type = A, class = IN
> v.scenewhores.com. 1W IN NS doh.scenewhores.com.
> doh.scenewhores.com. 1W IN A 216.224.8.100
> resp: nlookup(v.scenewhores.com) qtype=1
> resp: found 'v.scenewhores.com' as 'v.scenewhores.com' (cname=0)
> evSetTimer(ctx 0x80d2740, func 0x805aed8, uap 0, due
> 965197254.000000000, inter 0.000000000)
> resp: forw -> [216.224.8.100].53 ds=5 nsid=28566 id=53786 19ms
> evSelectFD(ctx 0x80d2740, fd 8, mask 0x1, func 0x8086e98, uap
> 0x40130008)
> IP/TCP connection from [216.224.8.100].1466 (fd 8)
> evDeselectFD(fd 8, mask 0x1)
> evSelectFD(ctx 0x80d2740, fd 8, mask 0x1, func 0x8086e98, uap0x40130090)
> evDeselectFD(fd 8, mask 0x1)
> update type 30: 6507 bytes is too much data
> And this is when the DNS server went down. Any idea on what was the
> purpose of this ?
I don't know. It could be the trace from the IXFR buffer overflow
that ADMROCKS takes advange of. Was this from the logs during the breakin?
If you are trying to get help getting your bind server up or
analyzing an ongoing breakin attempt, say so. Just asking us to translate
a trace into a form you can understand is not going to get you very far.
Asking for us to translate a trace with no information about when and
where it came from and what was happening at the time is going to get
you even less.
> BTW: Can anyone explain why does bind 2.5pre9 listen on a high udp port
> ?
Bind WHAT? I know of bind 4.x (old) and bind 8.x (current) and
bind 9.x (up and coming) but I know of no bind 2.x.
> Thank you
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:13 EST