inetd/hostname failures
I've recently started having the following show up in my security run output: lilbuddy.antsclimbtree.com kernel log messages: me: getaddrinfo(adsl-66-122-112-170.dsl.snfc21.pacbell.net, AF_INET) failed I also had failures of the following kind: Nov 7 08:33:34 lilbuddy inetd[68076]: refused connection from 63.202.185.83, service imapd (tcp) Nov 7 12:18:43 lilbuddy inetd[69441]: refused connection from 66.122.112.170, service imapd (tcp) I worked around the inetd issue by commenting out the following in /etc/hosts.allow: #ALL : PARANOID : RFC931 20 : deny The thing is both of the IP's in question (66.122.112.170 and 63.202.185.83) have been connecting daily with no problem whatsoever for over a year. All of a sudden these refusals started, and I haven't changed anything on my end. My questions: 1) What is the best way to troubleshoot the getaddrinfo failure above? What is the failure, exactly? Poking around with nslookup and dig doesn't reveal anything, at least to me. 2) The inetd failure seems related to the IP's in question not having the same reverse/forward DNS entries. However, this has been the case for over a year and I haven't had the failure until recently. What has changed to cause this failure? 3) Is disabling ALL : PARANOID : RFC931 20 : deny a bad idea? One interesting thing is that both of these IP addresses are owned by pacbell.net. My guess is that pacbell messed something up on their end. I run the network at 66.122.112.170, and nothing significant has changed. I tweaked the firewall there, but disabling it doesn't change anything so I don't think it is related to the firewall. I'm not looking forward to trying to explain this to pacbell ... Thanks for any suggestions. Please CC me in any replies, as I'm on the digest. -- Mark Edwards San Francisco, CA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: inetd/hostname failures
From: Mark Edwards [EMAIL PROTECTED] Subject: inetd/hostname failures I've recently started having the following show up in my security run output: lilbuddy.antsclimbtree.com kernel log messages: me: getaddrinfo(adsl-66-122-112-170.dsl.snfc21.pacbell.net, AF_INET) failed I also had failures of the following kind: Nov 7 08:33:34 lilbuddy inetd[68076]: refused connection from 63.202.185.83, service imapd (tcp) Nov 7 12:18:43 lilbuddy inetd[69441]: refused connection from 66.122.112.170, service imapd (tcp) I worked around the inetd issue by commenting out the following in /etc/hosts.allow: #ALL : PARANOID : RFC931 20 : deny The thing is both of the IP's in question (66.122.112.170 and 63.202.185.83) have been connecting daily with no problem whatsoever for over a year. All of a sudden these refusals started, and I haven't changed anything on my end. My questions: 1) What is the best way to troubleshoot the getaddrinfo failure above? What is the failure, exactly? Poking around with nslookup and dig doesn't reveal anything, at least to me. 2) The inetd failure seems related to the IP's in question not having the same reverse/forward DNS entries. However, this has been the case for over a year and I haven't had the failure until recently. What has changed to cause this failure? 3) Is disabling ALL : PARANOID : RFC931 20 : deny a bad idea? One interesting thing is that both of these IP addresses are owned by pacbell.net. My guess is that pacbell messed something up on their end. I run the network at 66.122.112.170, and nothing significant has changed. I tweaked the firewall there, but disabling it doesn't change anything so I don't think it is related to the firewall. I'm not looking forward to trying to explain this to pacbell ... Thanks for any suggestions. Please CC me in any replies, as I'm on the digest. I imagine that the code has been changed in the interest of security. Instead of commenting out the ALL line above, I'd add an allow line just for the service(s) that you are concerned about. Perhaps: imapd: 66.122.112.170 : allow and so on... HTH, Kevin Kinsey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: inetd/hostname failures
I've recently started having the following show up in my security run output: lilbuddy.antsclimbtree.com kernel log messages: me: getaddrinfo(adsl-66-122-112-170.dsl.snfc21.pacbell.net, AF_INET) failed I also had failures of the following kind: Nov 7 08:33:34 lilbuddy inetd[68076]: refused connection from 63.202.185.83, service imapd (tcp) Nov 7 12:18:43 lilbuddy inetd[69441]: refused connection from 66.122.112.170, service imapd (tcp) I worked around the inetd issue by commenting out the following in /etc/hosts.allow: #ALL : PARANOID : RFC931 20 : deny Are you really sure you want to do this? This is some protection against connection from hosts trying to obsure their tracks. It basically means that you can't get a reverse DNS on the host. If it is one of your machines, then you need to fix its DNS info. If it is from somewhere else, you don't want it connecting to your machine - at least not until they get their pile cleaned up. The thing is both of the IP's in question (66.122.112.170 and 63.202.185.83) have been connecting daily with no problem whatsoever for over a year. All of a sudden these refusals started, and I haven't changed anything on my end. Have you done an upgrade? More recent versions of FreeBSD inetd automatically wrap the daemons that it starts. Previously you had to put the wrap in to the inetd.conf file. I don't know just which version started doing it automatically. My questions: 1) What is the best way to troubleshoot the getaddrinfo failure above? What is the failure, exactly? Poking around with nslookup and dig doesn't reveal anything, at least to me. 2) The inetd failure seems related to the IP's in question not having the same reverse/forward DNS entries. Exactly! However, this has been the case for over a year and I haven't had the failure until recently. What has changed to cause this failure? Did you upgrade FreeBSD recently - see above. 3) Is disabling ALL : PARANOID : RFC931 20 : deny a bad idea? Yes. One interesting thing is that both of these IP addresses are owned by pacbell.net. My guess is that pacbell messed something up on their end. Sounds like a good possibility - or someone has not registered a host properly. There are others out there who can explain the details much better than I, but here is the basic think anyway. jerry Thanks for any suggestions. Please CC me in any replies, as I'm on the digest. -- Mark Edwards San Francisco, CA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
