LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   strange nameserver logins from my lappy to lan hosts (http://www.linuxquestions.org/questions/linux-security-4/strange-nameserver-logins-from-my-lappy-to-lan-hosts-891005/)

slugman 07-10-2011 10:25 PM

strange nameserver logins from my lappy to lan hosts
 
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

re: unSpawn
 
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 (Post 4412469)
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 (Post 4412469)
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 (Post 4412489)
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.


All times are GMT -5. The time now is 11:10 PM.