Mit dem folgenden Snippet kann man sich den Status einer gespiegelten MS-SQL-Datenbank und die Rolle des aktuellen Servers anzeigen lassen:
-- Die Abfrage ist für die Serverrolle public möglich. SELECT mirroring_role_desc AS 'Rolle', mirroring_state_desc AS 'Status' FROM sys.database_mirroring WHERE mirroring_guid IS NOT NULL AND database_id=( SELECT dbid FROM master.dbo.sysdatabases WHERE name = '<Datenbankname>' )
Sub doppelteLöschen()
Dim LastC As Long, x As Long
LastC = Range("a65536").End(xlUp).Row
For x = LastC To 1 Step -1
If WorksheetFunction.CountIf(Range("a1:a" & x), Cells(x, 1)) > 1 Then
Cells(x, 1).EntireRow.Delete
End If
Next
End Sub
Die For … Next-Schleife fängt bei der letzten beschriebenen Zelle an. Das wird erreicht durch:
LastC = Range("a65536").End(xlUp).Row
Bei manchen Übernahmen von Texten in eine MySQL-Datenbank mit UTF-8 passiert es, dass die Umlaute nicht korrekt übernommen werden. Durch ein einfaches Suchen/Ersetzen über die entsprechende Spalte ist das aber schnell behoben.
UPDATE <tabelle>
SET <feld>=replace(replace(replace(replace(replace(replace(replace(replace(<feld>,'ß','ß'),'ä','ä'),'ü','ü'),'ö','ö'),'Ä','Ä'),'Ãœ','Ü'),'„','"'),'“','"')
WHERE <feld> LIKE '%ß%' OR <feld> LIKE '%ä%' OR <feld> LIKE '%ü%' OR <feld> LIKE '%ö%' OR <feld> LIKE '%Ä%' OR <feld> LIKE '%Ü%' OR <feld> LIKE '%„%' OR <feld> LIKE '%“%'
Um die Konfiguration sauber trennen zu können, habe ich die Logging-Konfiguration in eine separate Datei aufgeteilt und diese in der named.conf eingebunden.
... // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.log"; // prime the server with knowledge of the root servers ...
logging {
channel bind9log {
file "/var/log/named/bind9.log" versions 3 size 10m;
// syslog info;
// severity debug;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel security {
file "/var/log/named/security.log" versions 2 size 5m;
// syslog warn;
// severity warn;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category resolver {bind9log;};
category default {bind9log;};
category queries {bind9log;};
category client {bind9log;};
category config {bind9log;};
category notify {bind9log;};
category unmatched {bind9log;};
category dispatch {bind9log;};
category dnssec {bind9log;};
category database {bind9log;};
category security {security;};
category lame-servers {null;};
};
Zusätzlich muss das oben angegebene Verzeichnis /var/log/named noch angelegt werden:
mkdir /var/log/named
Danach einen Neustand von bind:
/etc/init.d/bind9 restart
und alles ist erledigt, wie ein ein ls zeigt:
DNS1:/etc/bind# ls -alh /var/log/named/ insgesamt 132K -rw-r--r-- 1 bind bind 126K 24. Nov 16:08 bind9.log -rw-r--r-- 1 bind bind 0 24. Nov 15:41 security.log
Wurde der DNS-Server für automatisch Aktualisierungen durch den DHCP-Server eingerichtet, können die dynamischen Zonnen nicht einfach aktualisiert und neu eingelesen werden. Zuerst muss die Dynamik mit der RNDC-Administration „eingefroren“ werden:
rndc freeze <example.com>
Dann die die Domänen-DB-Datei und die dazugehörige PTR-Datei mit dem Editor der Wahl bearbeiten und !!! die Seriennummer hochzählen !!! Danach kann die Zone neu geladen und wieder „aufgetaut“ werden:
rndc reload <example.com> rndc thaw <example.com>
bind9 ist ja nach der Standard-Installation ein Proxy-DNS, der sich sein Weiterleitungsserver aus der/etc/resolv.conf lädt. Setzt man bind aber auf einem Gateway ein, so kann es ja vorkommen, dass verschiedene Zonen von verschiedenen Servern abgefragt werden sollen. Nichts leichter als das.
Zuerst muss eine Zonenkonfiguration angelegt werden. Je nach Anzahl der Zonen kann man diese in eine Datei schreiben oder ein Zone pro Datei. Da der Rahmen bei mir meist überschaubar ist, schreibe ich eine Datei pro Zone und kann diese dann bei Bedarf einzeln aktivieren und deaktivieren.
// Weiterleitung fuer domain1.tld
zone "domain1.tld" in {
type forward;
forwarders { 192.168.178.1; };
};
// Weiterleitung fuer domain2.tld
zone "domain2.tld" in {
type forward;
forwarders { 10.50.100.1; 10.50.100.2; 10.70.70.3; };
};
Wie zu sehen ist, kann man auch mehrere Weiterleitungsserver eintragen. Alle durch ein Semikolon getrennt.
Bis jetzt verschwenden die Dateien nur Platz auf der Festplatte, weil bind sie nicht kennt. Sie müssen also in der Hauptkonfiguration eingetragen werden. Da bei der Installation bereits eine lokale Version der named.conf angelegt wurde, sollte diese dafür genutzt werden.
Datei: /etc/bind/named.conf.local
// // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; include "/etc/bind/zones.domain1.tld"; include "/etc/bind/zones.domain2.tld"; // Vertrauenswürde Clients (Eigenes LAN) ...
Zum Schluss noch den bind neu starten, damit die Konfigurationen eingelesen werden.
Ab jetzt werden die DNS-Einträge für die explizit konfigurierten Domains bei den expliziten DNS-Servern abgefragt. Alle anderen werden wie bisher bei den Servern aus der /etc/resolv.conf abgefragt.
Jetzt kann man den eigenen Server (127.0.0.1) in der /etc/resolv.conf an die erste Stelle schreiben, damit die expliziten Konfigurationen mit benutzt werden.
Wenn, wie oben angedeutet Acess Listen für den Zugriff definiert sind, muss man prüfen, ob der localhost hier bisher mit bedacht worden ist.
Wie das Anlegen eines Logical Volumes funktioniert, habe ich hier erklärt.
Damit das Verkleinern des Logical Volumes erfolgen kann müssen zuvor einige Schritte durchgeführt werden. Dazu gehören:
Ich erkläre das hier am Beispiel des Samba-Servers unter Debian Lenny. Es gelten folgende Annahmen:
Also los. Dienste stoppen
root# /etc/init.d/samba stop Stopping Samba daemons: nmbd smbd.
Dateisystem aushängen
root# umount /dev/mapper/vg00-srv_samba
Dateisystem überpüfen
root# e2fsck -f /dev/mapper/vg00-srv_samba
Jetzt also zuerst das Dateisystem verkleinern und dann das Logical Volume:
root# resize2fs /dev/mapper/vg00-srv_samba 512000000 root# lvreduce -L -1000G /dev/mapper/vg00-srv_samba
Danach wieder einhängen
root# mount /dev/mapper/vg00-srv_samba
Für die Installation und die Kompilierung der VMWare-Module werden die folgenden Pakete benötigt:
Zusammengefasst, bekommt man die Pakete mit folgendem Befehl installiert:
aptitude install build-essential linux-headers-$(uname -r)
Erstmal über die VMWare-Management-Oberfläche der Link „VMWare-Tools installieren“ anklicken, damit die VMWare-Tools-CD virtuell eingelegt wird. Dann kann man über
mount /dev/cdrom /media/cdrom bzw. mount /dev/sr1
die CD mounten und das entsprechende Tools-Archiv kopieren:
cp /media/cdrom/VMwareTools-X.X.X-XXXXXX.tar.gz /usr/local/src/
Die Xe stehen für die Versionsziffern, die sich bei jedem unterscheiden können.
Die kopierte Datei kann jetzt entpackt werden:
cd /usr/local/src/ tar -xzf VMwareTools-X.X.X-XXXXXX.tar.gz
so dass der Ordner
drwxr-xr-x / root root 4,0K 20. Okt 1009 vmware-tools-distrib
entsteht. Zum Installieren in diesen hineinwechseln und das Installationsscript aufrufen
cd vmware-tools-distrib ./vmware-install.pl
Danach werden alle möglichen Fragen zu Installation gestellt, bei denen man die Defaultwerte übernehmen kann. Abkürzen kann man diese Enter-Klickerei durch den Aufruf
./vmware-install.pl -d
da so alles in den Default-Einstellungen installiert wird. Ggf. sollte man sich die Ausgaben dann aber in eine Datei ausgeben lassen, damit nachträglich diese auf Fehler prüfen kann.
Wenn ein X-Server installiert ist, sollte man die Konfiguration von Hand vornehmen, weil hier auch die Auflösung abgefragt wird.
Damit auch die schnelleren VMWare-Treiber eingebunden werden, müssen die Netzwerk-Module ggf. noch neu geladen werden. Diese Zeilen werden ganz am Ende der Installation angezeigt:
/etc/init.d/networking stop rmmod pcnet32 rmmod vmxnet modprobe vmxnet /etc/init.d/networking start
Hierbei wird das Netzwerk angehalten, so dass eine bestehende SSH-Verbindung unterbrochen wird. Die Befehle können nur über eine lokale oder Fernwartungs-Konsole (IPMI, iLO) ausgeführt werden!
Zur Sicherheit sollte doch noch einmal ein Neustart erfolgen.
Bei der Installation unter Windows muss einfach über die VMWare-Management-Oberfläche der Link „VMWare-Tools installieren“ angeklickt werden. Danach einfach den automatisch startenden Installationsassistenten durchlaufen lassen und neustarten.
Um den Debug-Modus zentral ein- und auszuschalten empfiehlt sich eine Variable:
#!/bin/sh # Variablen DEBUG=0 LAN_IFACE="eth0" ...
welche dann später die Chains bestimmt:
# # Debug-Variable auswerten # if [ $DEBUG == 1 ]; then ACCEPT="OWNACCEPT" DROP="OWNDROP" else ACCEPT="ACCEPT" DROP="DROP" fi
So kann man dann (hier am Beispiel der lokalen Kommunikation) einen Parameter bei der iptables-Konfiguration übergeben:
### Lokale Kommunikation ### iptables -A INPUT -i lo -j $ACCEPT iptables -A OUTPUT -o lo -j $ACCEPT
Die angegebenen Werte sind nur Beispiel-Werte und müssen natürlich angepasst werden.
Hier mal eine Beispiel-Konfiguration:
#!/bin/sh
# Variablen
LAN_IFACE="eth0"
LAN_IP="192.168.XXX.XXX"
LAN_NET="192.168.XXX.0/24"
# Setzen von Kernelparametern
for i in /proc/sys/net/ipv4/conf/*/{accept_source_route,accept_redirects,send_redirects}; do
echo 0 > $i
done
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
### Firewall initialisieren ###
echo "Initialisiere Firewall ..."
iptables -F # Regeln aller Chains löschen
iptables -X # Alle selbst erstellten Chains löschen
iptables -P INPUT DROP # Alles was nicht explizit erlaubt ist ...
iptables -P OUTPUT DROP # ... wird gedroppt.
iptables -P FORWARD DROP #
iptables -Z # Zähler zurücksetzen
iptables -N OWNDROP # Eigene Chain für separate Verarbeitung erstellen
iptables -N OWNACCEPT # ...
iptables -N SYN-FLOOD # DoS-Attacken eingrenzen
### Lokale Kommunikation ###
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
### Stateful Inspection Regeln ###
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j OWNDROP
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
### Eigene Chains OWNDROP und OWNACCEPT konfigurieren (Logging) ###
iptables -A OWNDROP -j LOG --log-prefix "FW-DROP: "
iptables -A OWNDROP -j DROP
iptables -A OWNACCEPT -j LOG --log-prefix "FW-ACCEPT: "
iptables -A OWNACCEPT -j ACCEPT
### Schutz vor Syn-Flooding ###
# limits incoming packets
iptables -A SYN-FLOOD -m limit --limit 10/second --limit-burst 50 -j RETURN
# log attacks
iptables -A SYN-FLOOD -j LOG --log-prefix "SYN flood: "
# silently drop the rest
iptables -A SYN-FLOOD -j DROP
### Ports und Dienste nach aussen freischalten ###
# Eingehende SSH-Verbindungen
iptables -A INPUT -p tcp --dport 22 -j OWNACCEPT
# Ausgehende SSH-Verbindungen
iptables -A OUTPUT -p tcp --dport 22 -j OWNACCEPT
# PING
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
# ausgehende DNS-Anfragen
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
# WWW
iptables -A INPUT -p tcp --dport 80 -j OWNACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j OWNACCEPT
iptables -A INPUT -p tcp --dport 443 -j OWNACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j OWNACCEPT
# Mails
iptables -A OUTPUT -p tcp --dport 25 -j OWNACCEPT
iptables -A OUTPUT -p tcp --dport 110 -j OWNACCEPT
iptables -A OUTPUT -p tcp --dport 143 -j OWNACCEPT
# Samba
iptables -A INPUT -p udp -m multiport --destination-port 137,138 -s $LAN_NET -j ACCEPT
iptables -A INPUT -p tcp -m multiport --destination-port 139,445 -s $LAN_NET -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --destination-port 137,138 -d $LAN_NET -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --destination-port 139,445 -d $LAN_NET -j ACCEPT
iptables -A INPUT -p udp --sport 137 -s $LAN_NET -j OWNACCEPT
# NTP
iptables -A INPUT -p udp --dport 123 -s $LAN_NET -j ACCEPT
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
# SNMP
iptables -A INPUT -p udp --dport 161 -s $LAN_NET -j ACCEPT
iptables -A INPUT -p tcp --dport 161 -s $LAN_NET -j ACCEPT
iptables -A OUTPUT -p udp --dport 161 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 161 -j ACCEPT
# Protokollierung aller übriggebliebenen Pakete, die verworfen werden
iptables -A INPUT -j LOG --log-prefix "FW-LAST-DROP: "
### Fertig ###
echo "Firewall ist konfiguriert und aktiv"
Damit man die Logs, die iptables erzeugt, vom normalen syslog trennen kann, muss man die Logging-Einträge erst einmal eindeutig kennzeichnen. Dazu am besten eigene Ketten erstellen:
# Eigene Chains MYDROP und MYACCEPT konfigurieren (Logging) iptables -A OWNDROP -j LOG --log-prefix "FW-DROP: " iptables -A OWNDROP -j DROP iptables -A OWNACCEPT -j LOG --log-prefix "FW-ACCEPT: " iptables -A OWNACCEPT -j ACCEPT
oder die vorhandenen anpassen:
iptables -A DROP -j LOG --log-prefix "FW-DROP: " iptables -A DROP -j DROP iptables -A ACCEPT -j LOG --log-prefix "FW-ACCEPT: " iptables -A ACCEPT -j ACCEPT
Der entsprechende Präfix ist natürlich frei wählbar.
Jetzt muss man nur noch eine entsprechende Konfigurations-Datei unter /etc/rsyslog.d/iptables.conf anlegen und folgende Zeilen einfügen:
:msg, contains, "FW-ACCEPT: " /var/log/iptables/accept.log & ~ :msg, contains, "FW-DROP: " /var/log/iptables/drop.log :msg, contains, "FW-LAST-DROP: " /var/log/iptables/drop.log & ~
Damit werden alle Einträge die „FW-ACCEPT: „, „FW-DROP: “ oder „FW-LAST-DROP: “ enthalten in separate Logdateien geschrieben. Man muss sich auch keine Gedanken um das Anlegen der Dateien machen. Das erledigt der RSyslog-Daemon bei dem obligatorischen Neustart von alleine:
/etc/init.d/rsyslogd restart
Die letzte Zeile mit dem Inhalt „& ~“ bedeutet, dass diese Nachrichten nicht mehr in das Standard-Log geschrieben werden.
In neueren rsyslog-Versionen ist die Tilde „~“ deprecated, weshalb man sie ersetzen sollte. Die neue Schreibweise sieht so aus:
:msg, contains, "FW-ACCEPT: " /var/log/iptables/accept.log & stop :msg, contains, "FW-DROP: " /var/log/iptables/drop.log :msg, contains, "FW-LAST-DROP: " /var/log/iptables/drop.log & stop
Damit die Logdateien nicht irgendwann die Festplatte zulaufen lassen, sollte auch eine entsprechende logrotate-Konfiguration nicht fehlen. Siehe Logrotate/iptables.