strange nameserver logins from my lappy to lan hosts

slugman · 07-10-2011, 10:25 PM

Good evening dudes (and babes),

Whenever I login from my laptop to other systems in my lan, I notice the following in last -d:

root pts/0 chgooobl01.r2.ch Sun Jul 10 00:23 still logged in
root tty2 0.0.0.0 Fri Jul 8 21:15 still logged in
root tty1 0.0.0.0 Fri Jul 8 21:10 still logged in

I believe the full host in the first line is chgooobl01.r2.ch.cox.cci.

When I do a dig I get:

;; SERVER: 68.105.28.11#53(68.105.28.11)

Which strangely enough is the first nameserver listed in /etc/resolv.conf:

domain ph.cox.net
nameserver 68.105.28.11
nameserver 68.105.29.11
nameserver 68.105.28.12

Why would I see myself logged in as my dns? Is this evidence of some meddlesome activity? Should I be concerned and take further action? When I first looked I thought it was evidence that I was rooted ): . Any advice in this matter is greatly appreciated.

Reuti · 07-11-2011, 12:34 AM

The line with SERVER should show the machine which answered the request. I get a different output for chgooobl01.r2.ch.cox.cci when I try nslookup or host for the address.

this213 · 07-11-2011, 03:40 AM

That is saying that root is logged in from chgooobl01.r2.ch. If this is not you, you have a problem. Where are you running "last". on your laptop or on the remote system? If you're sure this isn't you, you have a lot of work ahead of you in verifying the sanctity of your system(s). Whether that means tracking all of the changes made to your system or reinstalling from scratch depends on how mission critical those systems are.

If those are the only "logged in" entries from last, and you're connecting remotely, and this is output on the remote system, I'd say chgooobl01.r2.ch is you. If any of those conditions are false, you have a problem.

I don't see anything saying you're logged in as your dns. The only thing you posted from dig is which nameserver you were asking. Since it responded with the first nameserver in your list in /etc/resolv.conf, I'd say that's probably a good thing. The only thing you've shown about the remote system is the line saying root is logged in from it. It probably resolves to chgooobl01.r2.ch.cox.cci for you because you're on a Cox cable network and they're blocking it from you. The part of dig output you should be looking at here is "Answer Section".

slugman · 07-12-2011, 12:33 AM

Thank you both kindly for your prompt replies. Sorry for the noob question, I now understand dig should be resolving from my nameserver.

I had no idea what this chgooobl01 is. At first glance it looked like a remote host logged in to my system.

After doing some digging, I discovered that I would only get those notifications when I was logged in--from my laptop--to any of my lan systems. When I disconnect from my laptop, root--from chgooobl01--is no longer logged in.

So to answer your question this213, the last -d output is from my lan systems (not my laptop).

Here is what dig to chgooobl01 shows:

Code:

; <<>> DiG 9.7.3 <<>> chgooobl01.r2.ch.cox.cci
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46103
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;chgooobl01.r2.ch.cox.cci.      IN      A

;; ANSWER SECTION:
chgooobl01.r2.ch.cox.cci. 900   IN      A       172.16.0.54

;; AUTHORITY SECTION:
cox.cci.                31649   IN      NS      ns2.at.cox.net.
cox.cci.                31649   IN      NS      ns1.at.cox.net.

;; ADDITIONAL SECTION:
ns1.at.cox.net.         31688   IN      A       68.1.18.30
ns2.at.cox.net.         32810   IN      A       68.1.18.25

;; Query time: 57 msec
;; SERVER: 68.105.28.11#53(68.105.28.11)
;; WHEN: Mon Jul 11 22:49:33 2011
;; MSG SIZE  rcvd: 136

and nslookup:

Code:

Server:         68.105.28.11
Address:        68.105.28.11#53

Non-authoritative answer:
Name:   chgooobl01.r2.ch.cox.cci
Address: 172.16.0.54

Shouldn't there be a list of more non-authoritative answers below the first non-authoritative answer? I'm still a bit confused--at first I thought chgoobl01 was just a alias/hostname for one of cox's dns servers. Am I correct in this assumption? Or is cox simply blocking the real address and simply resolving at my first nameserver? From the authority output of dig, it looks like this is a legit cox address--I'm just not sure if this is my dns or what. And i'm still confused as to why my systems would show this host as being logged in while i'm ssh'd in my lan systems, and dissapear when i log off. Unless my laptop is royally f***ed.

unSpawn · 07-12-2011, 01:18 AM

First of all you shouldn't be logging in as root over any network period. Secondly, if you list anything with IP addresses, be it tcpdump, netstat, lsof or whatever else, it's often faster to avoid resolution and we get a clean view of addresses used. Usually the "-n" switch does that but for 'last' it's "-i" IIRC. What's your LAN IP range? Did you by mistake choose one that's routable (which it should not be)?

slugman · 07-12-2011, 04:50 AM

Here is my last -d output from my gateway (172.16.0.1):

Code:

root@darkstar:~# last -d 
root     pts/0        chgooobl01.r2.ch Mon Jul 11 07:51   still logged in   
root     pts/0        chgooobl01.r2.ch Sun Jul 10 00:23 - 01:40  (01:16)    
root     tty2         0.0.0.0          Fri Jul  8 21:15   still logged in   
root     tty1         0.0.0.0          Fri Jul  8 21:10   still logged in

... and last -id output from gateway:

Code:

root@darkstar:~# last -id
root     pts/0        172.16.0.54      Mon Jul 11 07:51   still logged in   
root     pts/0        172.16.0.54      Sun Jul 10 00:23 - 01:40  (01:16)    
root     tty2         0.0.0.0          Fri Jul  8 21:15   still logged in   
root     tty1         0.0.0.0          Fri Jul  8 21:10   still logged in

my ip-address range is defined by the bootp dynamic range option in my dhcpd.conf:

Code:

subnet 172.16.0.0 netmask 255.240.0.0 {
    option domain-name "skynet.net";
    option broadcast-address 172.31.255.255;
    option subnet-mask 255.240.0.0;
    option domain-name-servers 68.105.28.11, 68.105.28.12, 68.105.29.11; 
    option domain-search "ph.cox.net";
    option routers 172.16.0.1;
    range dynamic-bootp 172.16.0.50 172.16.0.100;
    use-host-decl-names on;
    if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
      filename "/slackware13.1_x86/pxelinux.0";

The .54 address is me, logged in as root from my laptop.

So, if I understand you correctly, its bad practice logging in as root--even if I am in my own lan? This is not a very complex lan, a single 6 port gigabit switch, with an older 32-bit P4 (Prescott), running slackware as the gateway. I only login to do some administration on my gateway every now and then. I have yet to login as root from outside my lan--not even once.

this213 · 07-12-2011, 05:26 AM

It's bad practice to log in as root in general. You should be logging in as a normal user, then using "su -" (don't forget the hyphen) or sudo to perform administrative functions. The thinking is to only allow the absolute minimum methods for gaining root access on a system - so, to go hand in hand with that, you would also deny root from being able to login through ssh. You can do this by adding "PermitRootLogin no" to /etc/ssh/sshd_config.

Other than root access, I don't see anything from this that should be cause for alarm.

unSpawn · 07-14-2011, 04:51 AM

Your 172.16.0.0/12 is a bogon (see the team CYMRU listings), so that's good. It could be you allow any address to be resolved outside your LAN as per:

Quote:

Originally Posted by slugman

Code:

option domain-search "ph.cox.net";

which returns nfo as your specific provider uses the same /12 IP range for their own purposes.

Quote:

Originally Posted by slugman

So, if I understand you correctly, its bad practice logging in as root--even if I am in my own lan? This is not a very complex lan, a single 6 port gigabit switch, with an older 32-bit P4 (Prescott), running slackware as the gateway. I only login to do some administration on my gateway every now and then. I have yet to login as root from outside my lan--not even once.

While you're certainly free to do so inside, and it's good you never log in as root from outside your LAN for any service, it still isn't a standard procedure or security best practice. Root is the uber-powerful administrative account and exposing that an unnecessary risk.

unSpawn · 07-14-2011, 04:56 AM

Quote:

Originally Posted by this213

Other than root access, I don't see anything from this that should be cause for alarm.

This can really mean a few things about the "evidence" posted or the observer. Being new here, or not having posted in this particular forum much, do realize we like answers such as yours to be supported by evidence, facts, diagnosis, commands or literature so the OP, and anyone who finds the thread later on, has the tools and opportunity to verify things for themselves. Fuzzy human phrasing like "I don't see anything", "I think" or the generic "don't worry" do not belong. TIA.

slugman · 07-15-2011, 01:54 AM

Thank both of you for taking the time to respond to my thread. I understand that logging in directly as root is not considered a security best practice. Going forward, I'll avoid it altogether

Although I was aware I should avoid using private address space,this is the first time the bogon has been brought to my attention. Team Cymru certainly has some good information.

So, you think my option domain search field may be the cause of my issues? I was under the impression I had this set this correctly. Or is it because I sit on the same /12 block a my isp?

Noway2 · 07-15-2011, 05:12 AM

I had to read this one a few times before I was able to make sense of it but I believe what is happening is showing a problem(?) on Cox's end. Let me explain.

Quote:

Although I was aware I should avoid using private address space

In actuality, behind your router, this IS the correct thing to do. Use of the 172.16.0.0/12 is perfectly legitimate, both for you and for Cox. This is spelled out in RFC1918 (link). What is happening is that your private IP is being logged when you access the machine and it is being logged by IP address. The "problem" is when you try to resolve this IP address via reverse lookup which is what happens automatically with the last command and the "problem" is on Cox's end. Cox's name server is resolving RFC1918 addresses associated with their LAN via queries to the public interface on their name servers. While this may be necessary or desirable for their business, I personally don't consider this to be a smart practice. Rather it should resolve from within their LAN only. As unspawn said, this address is a bogon and should not be seen on a public network so why resolve it on a public network DNS? I verified that this is the case by using nslookup and connecting to Cox's server and asking for the IP 172.16.0.54 and received the same name.

While this starts to go beyond the scope of your question, there is nothing that says that you can't run a name server for your local LAN. I personally do this and find it advantageous. This is apparently what Cox has done too and you are using their resolvers, so when given a LAN address, it is happily giving you the host name associated with it from their LAN. If you were to run your own name server and make it authoritative for your LAN, it would return the host name of your machines, rather than theirs.

slugman · 07-21-2011, 04:19 AM

Noway2, thank you for clearing that up. That is what happens when I post late at night, half asleep.

So, the problem here is cox's nameserver is responding to private address space queries on their public interface? So, not really a problem on my end, just bad mojo on theirs?

I appreciate the advice. From what I've read, setting up local caching dns server via BIND does not look too difficult. I'll give this a go and let you chaps now how it went.

Noway2 · 07-21-2011, 09:24 AM

Correct, based upon my own tests, I am certain that the problem is on their end, not yours and that it is caused by your resolver, which is their DNS, returning names for their private IP range.

Setting up you own bind server, and even co-ordiating it with a DHCP is quite easy. Here is a link to a how-to that I used and found quite helpful. Be sure to check the links out on the right hand side of the page for related subjects.