Archiv der Kategorie: Linux

freeswitch / fusionpbx, VoIP

freeSwitch – versatel.sip

As known, Versatel needs „versatel.sip“ as REALM. This is not an fqdn and there for we run in some little possible config trouble.

Basic example for connection freeswith pbx to (1&1) Versatel public phone service

This example contains an example phone number and password – please change it!

<include>
  <gateway name="versatel">
    <param name="username" value="0049301234567"/>
    <param name="password" value="bu!Msuf5"/>
 
    <!--/// proxy /realm host: Versatel Name! ///-->
    <param name="proxy" value="versatel.sip"/>
    <param name="realm" value="versatel.sip"/>
 
    <!--/// send register to this proxy: correct DNS Name! ///-->
    <param name="register-proxy" value="wia-sip-proxy.ngn.versatel.de"/>
    <param name="outbound-proxy" value="wia-sip-proxy.ngn.versatel.de"/>
 
    <!--/// expire in seconds: *optional* 3600, if blank ///-->
    <!--<param name="expire-seconds" value="60"/>-->
 
    <!--/// do not register => false ///-->
    <param name="register" value="true"/>
    <param name="register-transport" value="udp"/>
 
    <!--<param name="retry-seconds" value="30"/>-->
    <!--Use the callerid of an inbound call in the from field on outbound calls via this gateway, imported to versatel -->
    <param name="caller-id-in-from" value="true"/>
 
    <!--extra sip params to send in the contact-->
    <!--<param name="contact-params" value="tport=tcp"/>-->
    <!--send an options ping every x seconds, failure will unregister and/or mark it down-->
    <!--<param name="ping" value="25"/>-->
  </gateway>
  <!--rfc5626 : Abilitazione rfc5626 ///-->
  <!--<param name="rfc-5626" value="true"/>-->
  <!--rfc5626 : extra sip params to send in the contact-->
  <!--<param name="reg-id" value="1"/>-->
</include>
asterisk, VoIP

Asterisk – versatel.sip

Die Versatel wünscht sich als REALM „versatel.sip“ in der Registrierung. Mit der folgenden Konfiguration funktioniert die Registrierung mit einer Asterisk PBX.

Telefonnummer und Kennwort sind natürlich der individuellen Konfiguration anzupassen…

/etc/asterisk/sip.conf:

register => 0049301234567:bu!Msuf5@versatel.sip/0049301234567
 
[0049301234567]
type=peer
host=62.214.36.241
outboundproxy=versatel.sip
realm=versatel.sip
proxy=versatel.sip
registrar=versatel.sip
port=5060
context=isdn-incoming
defaultuser=0049301234567
fromuser=0049301234567
username=0049301234567
secret=bu!Msuf5
dtmfmode=rfc2833
insecure=port,invite
canreinvite=no
registertimeout=600
disallow=all
allow=alaw
allow=ulaw

ggf. ist noch in der /etc/hosts der folgende Eintrag sinnvoll hinzuzufügen:

62.214.36.241   versatel.sip
Allgemein, DBMS, freeRADIUS, Linux, MySQL/MariaDB

Updating freeradius 2.2.5 to 3

After a Debian Update to Stretch the freeradius Server with mysql database stopped working!
A short investigation I saw that the config structure change and there was no update script provided. – Ok. No Problem: Old config on the left hand – new Config on the rigth hand and after a few minutes the radius server was talking to the mysqldb/mariadb server, again. But looking to the debug log, I found some mysql insert errors.
An other a short comparission I found the changes in the database schema, especially in the accounting table (radacct), but there was als no Update script 🙁
So. here is my SQL Update for the radius database:

ALTER TABLE radacct
ADD COLUMN `acctupdatetime` datetime NULL default NULL AFTER `acctstarttime`,
ADD COLUMN `acctinterval` int(12) default NULL AFTER `acctstoptime`,
DROP COLUMN `acctstartdelay`,
DROP COLUMN `acctstopdelay`,
DROP COLUMN `xascendsessionsvrkey`,
ADD KEY `acctinterval` (acctinterval);
 
GRANT ALL PRIVILEGES ON radius.radpostauth to 'radius'@'localhost';
Linux, Postfix

Spaß mit TLSA Records

Bei dem Erzeugen des Hash für einen TLSA Record kann mensch plötzlich sehr viel „Spaß“ haben.

Die geläufigste, beim Suchen zu findende Anleitung ist ja die folgende:

openssl x509 -in example.com.crt -outform DER | openssl sha256
(stdin)= 46fc14a051629364fc0bedafd87b74731c7e63af4d772127871b0bd9f2bbd29c

soweit so gut. Also einen ensprechden Hashwert erzeugt und per DNS publiziert. Im nächsten Schritt versuchen wir mal den Eintrag zu validieren unter Verwendung von z.B.: https://www.huque.com/bin/danecheck oder https://dane.sys4.de/

Und was müssen wir feststellen: Der Hashwert ist ungültig! – aber warum?

Ok, also auf ein Webseiten gegangen um einen TLSA Hash zu erstellen (z.B.: https://de.ssl-tools.net/tlsa-generator)

Hups, warum kommt die Webseite auf ein anderes Ergebnis als openssl in der Shell?

Möglicherweise ein openssl Problem? – Probieren wir mal einen anderen Rechner aus – das gleiche Ergebnis wie vorher – ist ja auf der einen Seite gut und sollte auch so sein – aber warum kommt die Webseite auf ein anderes Ergebnis als ich?

Beim Suchen bin ich nun über den einen Blogeintrag gestolpert:
Hier gibt es einen Codeschnipsel zum erzeugen des TLSA Records … Probieren wir den doch mal aus – und? – das gleiche Ergebnis wie die Webseiten ….

Hier der besagte Codeschnipsel als bash script:

#!/bin/bash
server=`hostname -f`
tlsa=$(openssl x509 -in $1 -noout -pubkey |
 openssl pkey -pubin -outform DER |
 openssl dgst -sha256 -binary |
 hexdump -ve '/1 "%02x"')
echo -e "_25._tcp.$server. IN TLSA 3 1 1 $tlsa\n"

Ist ein wenig aufwendiger – führt aber zu einem offensichtlich „schönerem“ Ergebnis.

Und für’s nächste mal:

posttls-finger -t30 -T180 -c -L verbose,summary gruppe04.de

und selber überprüfen …

Linux

fqdn setzen bzw. anpassen

Um die .local, .lan, .intern Sünden zu beheben und vor allem spätestens, wenn es notwendig wird, einem internen Dienst ein „ordentlich“, soll heißen öffentlichen CA, signierten Zertifikat auszustatten ist sinnvoll und notwendig den Maschinen einen Fully Qualified Name mit gültiger tld.

Also passen wir hier in unseren vorhandenen Debian Systemen mal fleißig die Namen an:

  1. /etc/init.d/hostname.sh stop
  2. echo fliege.home.example.org > /etc/mailname
  3. echo fliege > /etc/hostname
  4. in der /etc/hosts „192.168.102.12   fliege.home.example.org fliege“
  5. /etc/init.d/hostname.sh start

Danach sollte sich die Maschine wie folgt verhalten:

fliege:~# hostname
fliege
fliege:~# hostname -f
fliege.home.example.org

Wirklich ausschlaggebend ist eigentlich nur die /etc/hosts

127.0.0.1       localhost.localdomain localhost
192.168.102.12   fliege.home.example.org fliege

Die Datei /etc/hostname ist eigentlich nur anzupassen, wenn sich der Hostname selber ändert

Die Datei /etc/mailname ist nur vorhanden, wenn auch ein MTA installiert ist – hier sollte der gleiche fqdn gesetzt sein, wie in der /etc/hosts

Exchange Server, LDAP, Linux, Microsoft, MSAD, Postfix

LDAP Abfrage für einen vorgelagerten Postfix

Wie so schon in Beiträgen wie diesen beschrieben, kann ein Postfix wunderbar dem Netzwerkinternen Exchange Server vorgeschaltet werden. Bei der LDAP Abfrage gegenüber dem AD möchte mensch natürlich nur gültige eMailadressen annehmen und dem Exchange Server weiter leiten. Dafür reicht der folgende LDAP Query Filter prinzipiell aus:

query_filter = (|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))
result_attribute = mail

Allerdings kann es in einer Domainumgebung vorkommen, daß Menschen eine Organisation verlassen und der Account z.B. zu einem Bestimmten Zeitpunkt auslaufen / gesperrt werden. Diese Information wird im AD bei dem Benutzer in dem Attribut „accountExpires“ gespeichert. Der Defaultwert ist dabei in Dezimal: 9223372036854775807 oder auch 0x7FFFFFFFFFFFFFFF als Hexadezimalwert. Die entsprechende Dokumentation des Attributes kann bei Microsoft im Artikel ms675098 gefunden werden.

Darüber hinaus ist es möglicherweise nicht gewünscht, daß für deaktivierte Accounts / gesperrte Accounts überhaupt eMails angenommen werden. Ob ein Account gesperrt ist oder welchen zustand dieser so gerade hat, wird im AD bei dem Benutzer im Attribut „userAccountControl“ abgespeichert.

Ein aktivierter Account hat den Dezimalwert 512, ein aktivierter Account ohne ablaufenden Kennwort wird Dezimal als 66048 repräsentiert. Beide werte sind also für aktive Accounts

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(&(accountExpires=9223372036854775807)(|(userAccountControl=512)(userAccountControl=66048))))

Diese Abfrage filtert demnach a) die gültige eMailadresse, b) ob der Account nicht Abgelaufen ist und c) ob der Account aktiviert ist.

Bei der Abfrage ob ein Account aktiviert ist, stellt sich hier das Problem, daß ein Account gerade deaktiviert wurde oder in Zukunft deaktiviert, eMails aber noch angenommen werden sollen (z.B.: um per auto-replay mitzuteilen, daß mensch nicht mehr dabei ist und zukünftig andere Personen zuständig sind)

Mit Hilfe der Powershell lässt sich die aktuelle Zeit einfach in einen entsprechenden Zeitstempel umrechnen und ausgeben

PS> (Get-Date).ToFileTime()

Der Filter lässt sich wie folgt anpassen:

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(&(accountExpires>=130954282658740101)(|(userAccountControl=512)(userAccountControl=66048))))

somit werden eMails an einen Account, der eine kleinen kleineren Zeitstempel, als der in der Abfrage, hat, nicht mehr zugestellt. Diesen Zeitstempel muß mensch ggf. regelmäßig im Filter der LDAP Abfrage anpassen.

Mit dem bisher gebauten filter sind leider keine Exchange eMail Gruppen berücksichtigt. Um diese zu berücksichtigen erweitern wir den Filter um die Frage nach der „objectClass„.

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(|(&(accountExpires>=130954282658740101)(|(userAccountControl=512)(userAccountControl=66048))(objectClass=person))(objectClass=group)))

Was genau macht dieser Filter jetzt?

  1. gibt es die eMailadresse: ja
  2. ist das Object eine Gruppe: ja
    => alles schick: gibt die eMailadresse zurück
  1. gibt es die eMailadresse; ja
  2. ist das Object ein Benutzer: ja
  3. ist der Benutzer weder gesperrt noch abgelaufen?: ja
    => alles schick: gibt die eMailadresse zurück