MX Record/DNS help needed
Brad Knowles
brad.knowles at skynet.be
Thu Jun 28 23:45:28 UTC 2001
At 1:38 PM -0700 6/28/01, BCC wrote:
>> hint is: your zone data and delegation is a mess. :)))
Indeed. Here's the results of running the latest version of
"doc" on this zone:
% doc -d nextproteins.com
Doc-2.2.2: doc -d nextproteins.com
Doc-2.2.2: Starting test of nextproteins.com. parent is com.
Doc-2.2.2: Test date - Thu Jun 28 19:19:56 EDT 2001
DEBUG: digging @a.gtld-servers.net. for soa of com.
soa @a.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @b.gtld-servers.net. for soa of com.
soa @b.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @c.gtld-servers.net. for soa of com.
soa @c.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @d.gtld-servers.net. for soa of com.
soa @d.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @e.gtld-servers.net. for soa of com.
soa @e.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @f.gtld-servers.net. for soa of com.
soa @f.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @g.gtld-servers.net. for soa of com.
soa @g.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @h.gtld-servers.net. for soa of com.
soa @h.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @i.gtld-servers.net. for soa of com.
soa @i.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @j.gtld-servers.net. for soa of com.
soa @j.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @k.gtld-servers.net. for soa of com.
soa @k.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @l.gtld-servers.net. for soa of com.
soa @l.gtld-servers.net. for com. has serial: 2001062800
DEBUG: digging @m.gtld-servers.net. for soa of com.
soa @m.gtld-servers.net. for com. has serial: 2001062800
SOA serial #'s agree for com. domain
Found 2 NS and 2 glue records for nextproteins.com.
@a.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@b.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@c.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@d.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@e.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@f.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@g.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@h.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@i.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@j.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@k.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@l.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for nextproteins.com.
@m.gtld-servers.net. (non-AUTH)
DNServers for com.
=== 0 were also authoritatve for nextproteins.com.
=== 13 were non-authoritative for nextproteins.com.
Servers for com. (not also authoritative for nextproteins.com.)
=== agree on NS records for nextproteins.com.
DEBUG: domserv = reap.soulinjection.com. webserver.nextproteins.com.
NS list summary for nextproteins.com. from parent (com.) servers
== reap.soulinjection.com. webserver.nextproteins.com.
digging @reap.soulinjection.com. for soa of nextproteins.com.
soa @reap.soulinjection.com. for nextproteins.com. serial:
ERROR: no SOA record for nextproteins.com. from reap.soulinjection.com.
digging @webserver.nextproteins.com. for soa of nextproteins.com.
soa @webserver.nextproteins.com. for nextproteins.com. serial: 2000110507
ERROR: NS list from nextproteins.com. authoritative servers does not
=== match NS list from parent (com.) servers
NS list summary for nextproteins.com. from authoritative servers
== webserver.nextproteins.com.
Checking 1 potential addresses for hosts at nextproteins.com.
== 204.216.133.114
in-addr PTR record found for 204.216.133.114
Summary:
ERRORS found for nextproteins.com. (count: 2)
Done testing nextproteins.com. Thu Jun 28 19:20:12 EDT 2001
Here's what "dnswalk" has to say:
% dnswalk -alF nextproteins.com.
Checking nextproteins.com.
BAD: nextproteins.com. has only one authoritative nameserver
Getting zone transfer of nextproteins.com. from
webserver.nextproteins.com...done.
SOA=webserver.nextproteins.com contact=webserver.nextproteins.com
WARN: nextproteins.com A 204.216.133.114: no PTR record
WARN: webserver.nextproteins.com A 204.216.133.114: no PTR record
0 failures, 2 warnings, 1 errors.
Finally, here's the output from "DNS Expert" from Men & Mice:
DNS Expert
Detailed Report for nextproteins.com.
6/29/01, 1:23 AM, using the analysis setting "Minimal"
======================================================================
Information
----------------------------------------------------------------------
Serial number: 2000110507
Primary name server: webserver.nextproteins.com.
Primary mail server: exchange.nextproteins.com.
Number of records: 7 (1 NS, 1 MX, 4 A, 1 CNAME, 0 PTR, 0 Other)
Errors
----------------------------------------------------------------------
o The server "reap.soulinjection.com." did not reply
The server "reap.soulinjection.com." did not reply when it was
queried for the name "nextproteins.com.". This indicates that
the server is not running, or it is currently unreachable.
o There is no PTR record for the host "nextproteins.com."
There is no PTR record available for the host "nextproteins.com."
which has the IP address 204.216.133.114.
Warnings
----------------------------------------------------------------------
o There is only one NS record in the zone
The zone contains only one NS record. Every zone should contain
two or more NS records, and the NS records in the zone should
match the delegation data for the domain.
----------------------------------------------------------------------
end of report
IMO, you definitely want to secure the nameserver against having
copies of your zones transferred like this. Just so that you see how
this is done, here's a manual zone transfer operation with the "dig"
utility:
% dig @webserver.nextproteins.com. nextproteins.com. axfr
; <<>> DiG 9.1.2 <<>> @webserver.nextproteins.com. nextproteins.com. axfr
;; global options: printcmd
nextproteins.com. 86400 IN SOA
webserver.nextproteins.com. webserver.nextproteins.com. 2000110507
28800 7200 604800 86400
nextproteins.com. 86400 IN NS webserver.nextproteins.com.
nextproteins.com. 86400 IN MX 0 exchange.nextproteins.com.
nextproteins.com. 86400 IN A 204.216.133.114
webserver.nextproteins.com. 86400 IN A 204.216.133.114
localhost.nextproteins.com. 86400 IN A 127.0.0.1
www.nextproteins.com. 86400 IN CNAME webserver.nextproteins.com.
exchange.nextproteins.com. 86400 IN A 204.216.224.18
nextproteins.com. 86400 IN SOA
webserver.nextproteins.com. webserver.nextproteins.com. 2000110507
28800 7200 604800 86400
;; Query time: 317 msec
;; SERVER: 204.216.133.114#53(webserver.nextproteins.com.)
;; WHEN: Thu Jun 28 19:24:26 2001
;; XFR size: 10 records
> Sounds bad. Well, considering that I am a software engineer and not a
> sysadmin, looks like I need a detailed low level crash course on how to set
> this stuff up. Any suggestions on where to go?
Get fourth edition of _DNS & BIND_ by Paul Albitz & Cricket Liu
(published by O'Reilly & Associates). Do not settle for third
edition, which may still be on the shelves. Either find this book at
a local bookstore tomorrow, or get it shipped from your favourite
online bookstore via FedEx Priority Air for delivery as early
tomorrow morning as possible.
There are some additional books listed at
<http://www.dns.net/dnsrd/books.html>, which you may also be
interested in.
You will also want to use some tools to help you secure your
zones. Take a look at <http://www.dns.net/dnsrd/tools.html> and see
what you find useful.
> 1. On this machine there are two accounts, reap and iago, nobody in the
> nextproteins IS dept knows who they are.
I would not be at all surprised if the machine has been
compromised. Indeed, it may have intentionally been compromised by
the previous admin.
> 2. The old sysadmin apparently went back to canada some time ago, so this
> box has been unadministered until yesterday, when I opened it and started
> poking around.
Bad Juju, Bwana.
> 3. Len's DIG shows reap.soulinjection.com as NS on nextproteins.com (I
> think). The ip address from dig and nslookup is 24.5.172.3.
> 24.5.172.3 was the nameserver address I initially found in /etc/resolv.conf,
> I can't ping it.
>
> 4. Doing dig on reap.soulinjection.com shows NS of tcserver.gibfest.org.
>
> Curious, I went to www.soulinjection.com, and lo and behold on the front
> page is a news post from 'reap' about 'My bud iAgo just finished his hax0r
> project' some webcam. The link to that site is (you guessed it)
> www.gibfest.com.
>
> As if this wasn't strange enough, on www.soulinjection.com, Next Nutrition.
> Inc is listed as a client... and www.nextnutrition.com maps to
> www.nextproteins.com.
>
> Any thoughts besides HACKED! on this? Am I being paranoid?
Nope. You've almost certainly been hacked.
My suggestion is to set up another machine, but do not connect it
to the network (yet). Set it up purely from CD-ROM, and once
everything is installed, use the console to go in and turn
*EVERYTHING* off that it automatically starts up. You don't want X,
any servers in /etc/inetd.conf, or any other server running on that
machine, listening for connections -- not even if they're just from
the local machine itself.
Set this machine up as a pure command-line client. Now you
connect it to the network, and use tools like lynx and ftp (or
whatever) to download the latest security patches for your OS, and
you apply them. You should also download the latest version of BIND
-- preferably 9.1.2-REL or the latest release candidate for 9.1.3.
However, if you're stuck using BIND 8 and can't make the upgrade, at
least get 8.2.4-REL or the 8.2.5 "testing" version that was just
recently announced. Compile and install this version of BIND, and
either remove or rename the binaries provided by your vendor so that
you can ensure that they don't accidentally get started instead.
Copy over just the data files you need from the hacked machine,
using a medium such as tape or floppy disk -- not the network! Make
sure that you're not including any programs (which may have also been
compromised). Read each and every data file very, very carefully to
make sure that it has not been tampered with. When you're confident
that you've done everything, put these data files into their correct
places on the new machine.
Finally, configure the new machine to start up just the services
you actually need. Since this is a nameserver, you should have it
start named and then probably something like ssh (so that you can log
into the machine remotely via a secure encrypted channel). Under no
circumstances whatsoever should you start up any additional
unnecessary services, such as a web server, X, a mail server, etc....
If you need these additional services, then they should be put on
other machines.
Once you've got the new machine working and everything seems to
be correct from all your internal testing and all the external
testing you can do, then you will need to decide whether to take down
the old machine and steal it's IP address or change your delegations
to use the IP address of the new machine as a nameserver.
For help in properly securing your machine, I'd encourage you to
go to <http://www.sans.org/> and read everything on the site. Yes, I
know that this is a lot, but there is a lot you need to do in order
to do the job correctly. I suggest you also take a look at the
Security Focus website at <http://www.security-focus.com/>.
If you want to start with an OS that will give you a head start
at making the system more secure from the beginning, you should look
at either Bastille Linux or OpenBSD (depending on whether you prefer
Linux or BSD for your machines). See
<http://bastille-linux.sourceforge.net> or <http://www.openbsd.org/>,
as appropriate.
Note that I'm not even going to try to address the issue of
setting up a host-level firewall solution to try to help you ensure
that this machine remains secure, or that you set up a network or
host intrusion detection toolkit to help you identify attempted
hacking activity. You don't want to even try to get involved in this
stuff until you have a better understanding of computer security.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list