Re: [users@httpd] better configtest
Hi, Marc wrote: > With the forced upon us 90 day certificate renewal crap, my httpd > was down today although I have a 'restart procedure' that verifies > a bit for errors with apachectl configtest. Regardless of the certificate duration I would recommend to use some monitoring tool to check on the status of the web service and get an alert when the certificate is close from its expiration date. I personally use Monit [1], but there is probably plenty of other tools that could fullfill the same purpose. Sincerely, 1: https://mmonit.com/monit/ -- Xavier Belanger - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: newbie question: Allowing recursion
Hi,
David Newman via Unbound-users wrote:
> (...) if anyone here has examples of how to run an authoritative
> and recursive server on the same box using unbound and NSD please
> let me know.
Not exactly what you're looking for, and probably not best practice,
but this should be close enough: I'm running both Unbound and BIND
on the same machine, the first one only on IPv4 and the second
one on IPv6.
Then Unbound is configured to use BIND in the IPv6 loopback
interface to get the data for the local zones:
# unbound.conf
interface: 127.0.0.1
interface: 192.168.1.50
stub-zone:
name: "home.arpa"
stub-addr: ::1@53
stub-zone:
name: "168.192.in-addr.arpa"
stub-addr: ::1@53
# named.conf
options {
version "restricted";
directory "/srv/named";
recursion no;
listen-on { none; };
listen-on-v6 { any; };
};
I'm assuming that you could get something similar with NSD.
Sincerely,
--
Xavier Belanger
Re: Group-based SASL Auth
Hi, After reading the documentation more closely and testing in a more organized fashion, it's working. Here is the proper saslauthd.conf configuration file: ldap_servers: ldaps://ldaps.example.net ldap_tls_check_peer: yes ldap_version: 3 ldap_search_base: DC=example,DC=net ldap_scope: sub ldap_filter: (sAMAccountName=%u) ldap_group_match_method: filter ldap_group_filter:(&(sAMAccountName=%u)(memberOf=CN=SMTP-Auth,OU=Groups,DC=example,DC=net)) ldap_group_search_base: DC=example,DC=net ldap_auth_method: bind ldap_bind_dn: CN=saslauthd,OU=Special Accounts,DC=example,DC=net ldap_bind_pw: REDACTED Sincerely, -- Xavier Belanger
Re: Group-based SASL Auth
Hi, Demi Marie Obenour wrote: > Have you considered using Kerberos + channel binding instead of > LDAP authentication? Thank you for your response. Unfortunately, my only option right now is to use LDAP (LDAPS in fact). Sincerely, -- Xavier Belanger
Group-based SASL Auth
Hi, My question is not directly related to Postfix, but hopefully someone could point me in the right direction. I am building a SMTP relay server with SASL authentication, using LDAP (Active Directory) as a backend and it does work. Regular users can send emails after being authenticated. My goal is to restrict access based on a group from the directory. This is what I am using for my saslauthd.conf: ldap_servers: ldaps://ldaps.example.net ldap_tls_check_peer: yes ldap_version: 3 ldap_search_base: DC=example,DC=net ldap_scope: sub ldap_filter: (&(sAMAccountName=%u)(memberOf=CN=SMTP-Auth,OU=Groups,DC=example,DC=net)) ldap_group_attr: sAMAccountName ldap_group_match_method: filter ldap_group_dn: CN=SMTP-Auth,OU=Groups,DC=example,DC=net ldap_group_search_base: DC=example,DC=net ldap_auth_method: bind ldap_debug: 6 ldap_bind_dn: CN=saslauthd,OU=Special Accounts,DC=example,DC=net ldap_bind_pw: REDACTED I have tried few variants (using ldap_group_filter instead of ldap_filter for instance) without any luck. And I didn't find much examples or documentation about this. Any help would be appreciated. Thanks. Sincerely, -- Xavier Belanger
Re: UNBOUND AXFR
Hi, On Tue, 13 Jul 2021 15:15:20 -0400 Luiz Fernando Softov via Unbound-users wrote: > If I understand right and want to be fully authoritative I need NSD or > BIND9? (...) Very likely. You can use Unbound as an authoritative server for some types of records (A, , PTR) but not all (CNAME). For that reason I'm using Unbound on the local network for all my clients, but the authority for the local zone home.arpa is managed with a BIND server (using it with the 'stub-zone' configuration in the unbound.conf file). Sincerely, -- Xavier Belanger
Re: OpenDMARC 1.4.1 Released
Hi, John Levine wrote: > I cloned the github repo which contains no zip files, so no I don't know that. Cloning the repository will indeed not create a zip file, you must use the GitHub web interface to get access to it. Click on the green 'code' button on the right, then on the "Download ZIP" entry". This direct link should work the same: [ https://github.com/trusteddomainproject/OpenDMARC/archive/refs/heads/master.zip ] Sincerely, -- Xavier Belanger
Re: Unbound 1.13.0
Hi,
"Herbert J. Skuhra via Unbound-users" wrote:
> after upgrading unbound to version 1.13.0 (from 1.12.0) on FreeBSD running
> 'unbound-anchor' shows the following errors on IPv4-only hosts:
> (...)
If your server is IPv4 only, using the following configuration
should solve that issue:
# Enable IPv6, "yes" or "no".
do-ip6: no
Sincerely,
--
Xavier Belanger
Re: postfix 3.5.4 centos 8 hardcoded crypto settings?
Hi, Kris Deugau wrote: > It should be possible to set options like this in /etc somewhere, which > shouldn't be overwritten on package upgrades. I'm not sure where > CentOS/RHEL/Fedora have put the relevant OpenSSL configuration recently, > but on Debian and derivatives this can be set in /etc/ssl/openssl.cnf. It is, the idea is to define exception in the system crypto policy used by the system. There is multiple ways to do this: [ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening ] See sections: - 3.5. Excluding an application from following system-wide crypto policies - 3.6. Customizing system-wide cryptographic policies with policy modifiers - 3.7. Creating and setting a custom system-wide cryptographic policy It's not as quick and simple as editing one configuration file, but this should not be too difficult to implement. The issue here is that this mechanism is new in Red Hat/CentOS 8 and some people may not be aware of it. Sincerely, -- Xavier Belanger
Re: postfix 3.5.4 centos 8 hardcoded crypto settings?
Hi, Leonardo Rodrigues wrote: > You nailed it, Viktor and Xavier, it was the default system-wide > setup on the CentOS 8 OS from file > > /usr/share/crypto-policies/DEFAULT/opensslcnf.txt > > setting MinProtocol to TLSv1 there did the trick. > > Thank you guys! You're welcome. One piece of advice: that file may be considered as a "system file" and could be overwritten in the future by some CentOS update. Make sure to document that change and to keep an eye of that file; or to define your own policy (custom policies are not overwritten). Sincerely, -- Xavier Belanger
Re: postfix 3.5.4 centos 8 hardcoded crypto settings?
Hi, > I'm setting up a new postfix 3.5.4 server on a Centos 8 box and, > no matter what config i make, i can't get TLSv1 (yes, sorry, need to > support some old clients until the end of the year) support to work. I have been working with Red Hat Enterprise Linux 8 and very likely CentOS is using the same new "Systeme-wide crypo policies" mechanism that may interfere with your configuration. Details here: [ https://access.redhat.com/articles/3666211 ] [ https://access.redhat.com/articles/3642912 ] There is a way to change a different system policy; or you can keep it and only tweak what you need (I did something like that for OpenSSH). Hope this help. Sincerely, -- Xavier Belanger
No 'ad' bit from a stub zone
Hi,
Unbound 1.10.0 runs on my home server and it is configured
with a stub zone:
-- unbound.conf --
stub-zone:
name: "home.arpa"
stub-addr: ::1@53
--
That stub zone is managed by a ISC BIND server running
on the same host, using inline-signing:
-- named.conf --
zone "home.arpa" IN {
type master;
file "home.arpa/zone.home.arpa";
# DNSSEC keys
key-directory "/srv/named/keys";
# automate DNSSEC
auto-dnssec maintain;
inline-signing yes;
};
When I use dig to check a DNSSEC record in that zone,
I do not obtain the 'ad' bit.
>From the 'unbound' manual page I can read that my configuration
is probably incomplete:
> This setup allows DNSSEC signed zones to be served by that
> authoritative server, in which case a trusted key entry with
> the public key can be put in config, so that unbound can
> validate the data and set the AD bit on replies for
> the private zone
Here are my questions:
- Does that kind of setup would work with BIND inline-signing?
If not I can switch to some kind of manual signing.
- How can I add the zone public key in the configuration
to restore the trust chain?
Thanks for your help.
Sincerely.
--
Xavier Belanger
Re: Unbound 1.9.6 release
Hi, Ralph Dolmans via Unbound-users wrote: > Unbound 1.9.6 release is available: > https://nlnetlabs.nl/downloads/unbound/unbound-1.9.6.tar.gz > sha256 1d98fc6ea99197a20b4a0e540e87022cf523085786e0fc26de6ebb2720f5aaf0 > pgp https://nlnetlabs.nl/downloads/unbound/unbound-1.9.6.tar.gz.asc Ralph, should we assume that you will be the one to sign the future Unbound releases from now on? It's just for me to make sure to have your key available. > xavier@slack-ssh:~/unbound$ gpg2 --search > 21615A7F2478EA8C27DD26B830918D8275724222 > gpg: data source: http://82.148.229.254:11371 > (1) Ralph Dolmans > 2048 bit RSA key 30918D8275724222, created: 2014-01-07, expires: > 2023-12-09 > Keys 1-1 of 1 for "21615A7F2478EA8C27DD26B830918D8275724222". Enter > number(s), N)ext, or Q)uit > 1 > key 30918D8275724222: > 5 signatures not checked due to missing keys > gpg: key 30918D8275724222: public key "Ralph Dolmans " > imported > gpg: no ultimately trusted keys found > gpg: Total number processed: 1 > gpg: imported: 1 > xavier@slack-ssh:~/unbound$ gpg2 --verify unbound-1.9.6.tar.gz.asc > unbound-1.9.6.tar.gz > gpg: Signature made Thu 12 Dec 2019 05:09:40 AM EST > gpg:using RSA key 21615A7F2478EA8C27DD26B830918D8275724222 > gpg: Good signature from "Ralph Dolmans " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 2161 5A7F 2478 EA8C 27DD 26B8 3091 8D82 7572 4222 > xavier@slack-ssh:~/unbound$ On another note, Unbound 1.9.6 complies and runs just fine on my Slackware 14.2 (as usual, no surprises). Thanks! Sincerely. -- Xavier Belanger ___ unbound-users mailing list unbound-users@lists.nlnetlabs.nl https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
Re: unbound logging on Archlinux
Hi, > Archlinux current amd64 > Unbound 1.71 > > Try as I might Unbound is not writing to logfile: "/var/log/unbound.log" > and use-syslog: no. > > Would appreciate if someone could let me know. Is unbound chrooted? If so, that would probably prevent it to access to the /var/log directory. Look for the 'chroot' configuration option in your unbound.conf file. Sincerely. -- Xavier Belanger
Re: [Dnssec-trigger] dhclient-exit-hooks support
Hi, > Has anyone created /etc/dhclient-exit-hooks support for > dnssec-trigger? One of my desktops isn't using NetworkManager because > it is doing bridging, bonding, VLANs, and all sorts of other fancy > stuff via the Fedora network scripts that NetworkManager didn't > support until recently. I don't need VPN support, just a way to > inject DHCP provided DNS forwarders (and maybe domain as well). Sort of. Long time ago I have wrote a couple of scripts to use unbound and dnssec-trigger on Slackware (before NetworkManager get included in that distro). Here are the steps: - modify dhcpcd.conf to add the option 'resolv.conf' to the 'nohook' command. That way dhcpcd will not try to change /etc/resolv.conf. - add a dhcpcd hook script to send the DNS servers provided by the local DHCP server to Unbound or (especially during the system boot) store the DNS servers into a temporary file. - in the dnssec-trigger startup script look for the temporary file and load the DNS servers into the Unbound configuration. It's far from perfect or even reliable, not heavily tested, but it works. Files are here: http://www.ellendhel.net/fichiers/dnssec-slackware.zip The most useful to you should be '25-dnssec-trigger'. And there is a more detailled blog post, but in French: [ http://www.ellendhel.net/article.php?ref=2011+12+24-0 ] I don't have any experience with Fedora so you will probably need to adjust the files locations. Sincerely. -- Xavier Belanger ___ dnssec-trigger mailing list dnssec-trigger@NLnetLabs.nl http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
Re: [Unbound-users] Unbound Logging
Hi, > On BSD I'd say use a pf rule to block the IP for a time period if X > many concurrent states to port 53. Is something like that possible with > iptables on Linux? Like a rate-limit for incoming connections? Yes, it's possible: iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 --rttl --name DNS -j DROP iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNS -j ACCEPT The first rule block every tentative above 10 each minute, but it's a quick'n dirty example, it's possible to have something better. [ http://www.debian-administration.org/articles/187 ] Bye. -- Xavier Belanger ___ Unbound-users mailing list Unbound-users@unbound.net http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
