LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 07-10-2011, 10:25 PM   #1
slugman
Member
 
Registered: Jun 2010
Location: Los Estados No Estan Unidos
Distribution: Slackware
Posts: 58

Rep: Reputation: 1
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.
 
Old 07-11-2011, 12:34 AM   #2
Reuti
Senior Member
 
Registered: Dec 2004
Location: Marburg, Germany
Distribution: openSUSE 11.4
Posts: 1,319

Rep: Reputation: 252Reputation: 252Reputation: 252
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.
 
Old 07-11-2011, 03:40 AM   #3
this213
Member
 
Registered: Dec 2001
Location: ./
Distribution: Fedora, CentOS, RHEL, Gentoo
Posts: 167

Rep: Reputation: 34
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".
 
Old 07-12-2011, 12:33 AM   #4
slugman
Member
 
Registered: Jun 2010
Location: Los Estados No Estan Unidos
Distribution: Slackware
Posts: 58

Original Poster
Rep: Reputation: 1
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.
 
Old 07-12-2011, 01:18 AM   #5
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
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)?
 
Old 07-12-2011, 04:50 AM   #6
slugman
Member
 
Registered: Jun 2010
Location: Los Estados No Estan Unidos
Distribution: Slackware
Posts: 58

Original Poster
Rep: Reputation: 1
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.
 
Old 07-12-2011, 05:26 AM   #7
this213
Member
 
Registered: Dec 2001
Location: ./
Distribution: Fedora, CentOS, RHEL, Gentoo
Posts: 167

Rep: Reputation: 34
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.
 
Old 07-14-2011, 04:51 AM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
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 View Post
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 View Post
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.
 
Old 07-14-2011, 04:56 AM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
Quote:
Originally Posted by this213 View Post
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.
 
Old 07-15-2011, 01:54 AM   #10
slugman
Member
 
Registered: Jun 2010
Location: Los Estados No Estan Unidos
Distribution: Slackware
Posts: 58

Original Poster
Rep: Reputation: 1
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?
 
Old 07-15-2011, 05:12 AM   #11
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
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.
 
Old 07-21-2011, 04:19 AM   #12
slugman
Member
 
Registered: Jun 2010
Location: Los Estados No Estan Unidos
Distribution: Slackware
Posts: 58

Original Poster
Rep: Reputation: 1
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.
 
Old 07-21-2011, 09:24 AM   #13
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
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.
 
  


Reply

Tags
dns, hacked, nameserver


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange problem with connection between two hosts pgrd Linux - Networking 6 06-21-2009 05:22 AM
Strange remote logins after starting a gnome session Clemente Linux - Desktop 2 11-11-2008 02:14 PM
Strange loopback entries in /etc/hosts Passions Linux - Networking 1 04-13-2007 08:37 PM
Trouble with LAN nameserver... sorenp Linux - Networking 1 12-18-2006 02:03 AM
Build Nameserver and Virtual Hosts bytebrowser Linux - Networking 5 04-30-2004 09:02 AM


All times are GMT -5. The time now is 09:33 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration