George: What I reported below about libwrap was the result of a couple searches on Google; in short, I am not smart enough to know how many things work: The reason why I post questions to the group :-) I am curious as to know whether my hosts file theory is why the wildcard 'LOCAL' did not work for you? -Mike On Wed, Oct 16, 2002 at 01:17:00AM -0400, George Toft wrote: # ldd /usr/lib/openldap/slapd libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x40027000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40053000) libdb-3.1.so => /usr/lib/libdb-3.1.so (0x4005d000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x400da000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400e5000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40113000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401dc000) libnsl.so.1 => /lib/libnsl.so.1 (0x4020a000) libresolv.so.2 => /lib/libresolv.so.2 (0x40220000) libdl.so.2 => /lib/libdl.so.2 (0x40232000) libpthread.so.0 => /lib/libpthread.so.0 (0x40236000) libc.so.6 => /lib/libc.so.6 (0x4024c000) libpam.so.0 => /lib/libpam.so.0 (0x40372000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) No libwrap :( George Mike Starke wrote: > > I am assuming you mean the /etc/hosts.allow file that you had > to add an entry? If so, here is what I have learned: > > 1. If slapd has been compiled against libwrap, then it will be under > tcpwrapper control and does not have to run under inetd. > > ldd `which slapd`|grep libwrap > libwrap.so.0 => /lib/libwrap.so.0 (0x4016f000) > > I assume this explains why some services from some distros > react differantly. > > 2. As the hosts_access man page reports: > LOCAL Matches any host whose name does not contain a dot > character. > > Therefore, I would check your /etc/hosts file. I haven't tested this theory, > but I wonder if you had an entry(s) such as > > 127.0.0.1 localhost localhost.mydomain.com > 192.168.1.1 myhost myhost.mydomain.com > 192.168.1.2 anotherhost > > Perhaps, the 'dots' in the first two entries exclude you from > using the LOCAL wildcard, whereas the third entry would work > as expected? > > HTH > > v/r > -Mike > > On Tue, Oct 15, 2002 at 10:35:20PM -0400, George Toft wrote: > You bring up a good point. LDAP is not under inetd control, but I had > to add 127.0.0.1 (LOCAL wasn't good enough) to connect to my local LDAP > server. > > What's the explanation for this? > > George > > > Mike Starke wrote: > > > > No need to eat crow......I think this was the point I > > was trying to make. Some services are (undr wrapper control), > > some are not, some used to be and no longer are, and then > > some behave just as I expect, those that are only run > > under inetd. It is the inconsistencies from service to > > service, and from year to year (your case) that I find > > confusing. I think you mentioned chasing down an issue > > with SNMP and I with ldap; seems to me one should just > > 'know' what's under wrapper control and what is not. > > > > v/r > > Mike > > > > On Tue, Oct 15, 2002 at 12:18:04AM -0400, George Toft wrote: > > Crow chomp chomp > > > > I do not understand . . . > > > > I have tested your theory and your are right (as of 2002). I know for a > > fact that in 2000, what I described worked as described. I have seen it > > in action - I tossed IP's into /etc/hosts.deny because they were abusing > > our machines an as soon as I did so, the abuse stopped. We did not have > > Apache under inetd control. > > > > I stand corrected. > > > > George > > > > > > Digital Wokan wrote: > > > > > > Apache is only under the control of /etc/hosts.allow|deny when you set it up > > > to start as an inetd service instead of in standalone mode. For a low use or > > > testing site, this may be okay, but it is a large bottleneck to high-usage > > > sites, where a firewall-based blocking solution would make more sense to use > > > against abusers. > > > > > > On Thursday 10 October 2002 20:40, George Toft wrote: > > > > What makes you think Apache is not? Whe I was at the .com in LA, we had > > > > a script that analyzed Apache log files, and dropped the abuser's IP > > > > netowrk into /etc/host.deny for 48 hours. That locked him (and a chunk > > > > of his ISP) out so he couldn't redial and continue the attack. > > > > > > > > I know for a fact that SNMP is under tpc wrapper control - that was one > > > > of the biggest bitches to solve. > > > > > > > > SSH is also controlled by TCP wrappers - I use it as redundancy in case > > > > I make stupid typos and open SSH to my $EXTIF instead of my $INTIF. I > > > > did this, and I discovered it through looking at my logs. > > > > > > > > What I discovered two weeks ago about OpenLDAP was that LOCAL is not the > > > > same as 127.0.0.1. To every other service I have used in the last 6 > > > > years it was, but noooo - not OpenLDAP. > > > > > > > > Anyway, it's called TCP wrappers, not inet wrappers, because it affects > > > > all TCP services. My hosts.allow file looks like this: > > > > ALL: LOCAL, 127.0.0.1, 192.168.55. > > > > which supports my LDAP, MySQL, Apache and DNS servers. The 192.196.55 > > > > LAN is another interface that needs DNS and HTTP services. > > > > > > > > George > > > > > > > > Mike Starke wrote: > > > > > Years ago, I seem to recall that the only services > > > > > under control of hosts.allow & hosts.deny were those > > > > > under inetd (/etc/inetd.conf). > > > > > > > > > > I just spent the past hour trying to figure out why I couldn't > > > > > connect to my new ldap server from a remote site; come to find > > > > > out all I needed was a simple entry in /etc/hosts.allow Being that > > > > > slapd runs as a deamon, I stared at my slapd.conf file and couldn't > > > > > find any reason why a connection was denied. > > > > > > > > > > Simple question: How does one know when a service is under > > > > > tcpwrappers? Apache & Bind are not, what should have made > > > > > me think slapd was? > > > > > > > > > > v/r > > > > > Mike > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > > > > To subscribe, unsubscribe, or to change you mail settings: > > > > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > > > To subscribe, unsubscribe, or to change you mail settings: > > > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > > To subscribe, unsubscribe, or to change you mail settings: > > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > To subscribe, unsubscribe, or to change you mail settings: > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > To subscribe, unsubscribe, or to change you mail settings: > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change you mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss