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
(text/plain)