Of course I should be worried about an attack, we are actually working to increase our protection but...

I was going through the message log this morning and found the following entries... should I be worried?


There are lots of these at various times:
Jun 19 22:08:06 company named[5291]: client 80.117.199.251#15326: update 'company.com/IN' denied

A billion of these for various IPs:
Jun 19 22:25:02 company named[5291]: lame server resolving '193.229.142.80.in-addr.arpa' (in '229.142.80.in-addr.arpa'?): 194.25.0.125#53

Only saw this once:
Jun 19 23:55:39 compnay xinetd[30332]: warning: /etc/hosts.allow, line 8: can't verify hostname: getaddrinfo(gbrdialin, AF_INET) failed

And what is this trying to tell me?
Jun 20 00:18:03 company pam_timestamp_check: pam_timestamp: `/var/' permissions are lax


Thanks for your help.

The "update" could be some MICROS~1 client trying to do dynamic updates and if so it could be totally unrelated to the domain you're authoritative for.
The "lame server" you can forget about, this is a message of the "informational" level.
The Xinetd/"getaddrinfo" I don't know if this can be contributed to someone mucking remotely with faking authoritative DNS, plain IPv* weirdness or what. Is this the latest Xinted version? Earlier versions had a bug wrt getaddrinfo.
The "pam_timestamp_check" is the easiest: check out if permissions are lax, like octal 0775 permissions. (you could have told you that yourself :-] ).

Thanks UnSpawn...

As far as I know the xinetd is the newest version. The install is fresh and up to date using redhat up2date.

The question with the permissions on VAR was more along the lines of... why is it telling me that? What is pam_time_stamp doing? and why does it know my permissions are lax?

Are you configured to be a slave DNS for at least one domain? Is company.com ( or whatever appears there, in case it has been hidden for privacy reasons ) the name of _your_ domain?

You get these when an application sends a Name lookup request for a certain name and the daemon finds during resolution that the NS to which it is redirected by the higher level domain is not configured to authoritative for that zone. Completely Harmless.

For instance if you were trying to lookup foo.bar.com and the bar.com zone points you to the NS entry for foo, but that server is not configured to be authoritative for foo, you will see error 'lame server reolving foo.bar.com'. Same for in-addr.arpa domains. They facilitate reverse DNS lookups ( address to name )


Not sure why xinetd is complaing this way, this doesn't appear to be dangerous.

pam_timestamp.so has functions that authenticate users based on a sufficiently recent successfull auth. I'm not sure how exactly, but it is know to cache some information in timestamp files and these files need to be properly secured in terms of permissions. It is warning now that the current permissions for the timestamp directory are too lax.

nxny: Not sure why xinetd is complaing this way, this doesn't appear to be dangerous., just for my curiosity, how did you determine this is not dangerous?

nxny - we are not a slave we are the primary...

So at this point I have already tightened up VAR and I am watching to see if my xinetd issue is dangerous or not... I'll wait and see what unSpawn says.

I didn't say I 'determined'. Said it didn't appear to be dangerous. Saw your take on it, makes sense.

I was only asking Nxny how he could assess the situation from one message, literally one string submitted to syslog, because I couldn't without more info (I should have done the obvious and that is first ask you to post /etc/hosts.allow). Maybe he had info I hadn't.

Wrt to getaddrinfo, Solar Designer did an audit of Xinetd a while ago and found some "irregularities". I know xinetd dev released proper after the audit so you should be "safe".

Thank you...

I appreciate the help...

This is caused from what I see here by a domain connecting with out reverse DNS. I get these all day on my server and doing a host on the culprit domain always returns null.

"hostname: getaddrinfo(gbrdialin"

"gbrdialin" definately does not resolve. (but maybe I'm reading this wrong.)