Patrick Braun IT-Security Blogalles rund um IT-Security – Clearswift – Cisco – Microsoft ISA Server – Microsoft ForeFront u.v.m.

Hallo zusammen,

wieder bin ich auch ein Problem gestoßen, dass mit Sicherheit mehrere Menschen da draussen haben:

Kaum will man per http/https etwas hochladen bricht der Upload nach geschätzen 1-2 Minuten ab bei größeren Dateien.
Die Fehlermeldung ist auch wenig aussagekräftig: ‘No response from server HTTP status code:504′
Diesem Problem bin ich nachgegangen und habe folgende Infos dazu gefunden:
http://kb.clearswift.com/article.aspx?article=2625&p=13

Leider, warum auch immer, muss man diesen Hack beim Support anfragen.
Um das Problem in den Griff zu bekommen muss man folgende Schritte durchführen:

1. SSH freischalten und per SSH auf die Konsole und mit dem System User anmelden
2. mit “sudo su -” Adminrechte übernehmen
3. die Datei proxy-template.xml in /opt/msw/cfg/ui/websettings vorsichtshalber sichern
4. die Datei mit vi proxy-template.xml öffnen
5. nun lokalisieren wir den Wert: “Propertyname=”RequestTimeout” und überprüfen ob der Wert hier auf 60 steht.
6. den Wert auf 600 ändern, was 10 minuten entspricht
7. das ganze mit “:wq!” speichern und raus aus der Shell
8. in der WebGUI müssen wir nun einmal die Konfuiguration applien und fertig.

Danach sollte alles funktionieren – in seltenen Fällen kann es sein, dass der Server einen reboot benötigt.

Um die ASA’s oder PIXen per SSH zu administrieren muss man zuerst einmal ein wenig konfigurieren:

Zuerst legen wir nach Grundinstallation der ASA einen Benutzer an:

• username admin password Passw0r7 privilege 15

Nun lassen wir die lokale Authentifizierzung per shh zu:

• aaa authentication ssh console LOCAL

  (Optional wenn https auch freigeschalten werden soll)
aaa authentication http console LOCAL


Nun müssen wir noch einen RSA Key auf der Firewall erzeugen:

• crypto key generate rsa

Zum schluss müssen wir noch eine Zugriffsregel in der Konfiguration anlegen.

In unserem Bsp. lassen wir SSH Zugriff vom Netz 172.16.50.0/16 auf das Management Interface zu

• ssh 172.16.50.0 255.255.0.0 management

Und das war es auch schon – nun kann man sich per SSH auf die Firewall einloggen.

Wer kennt dieses Problem nicht? Immer mal wieder kommt es im SGMG vor das diverse Mails nicht verarbeitet werden können.
Um die Mails zu verarbeiten gibt es einen kleinen Trick um diese aus “Bad Mails” rauszuholen.

Wir loggen uns per SSH auf der Konsole mit “root” ein.

• wir gehen ins Verzeichnis der bad mails /chroot/esmtp/bad

• und schieben diese mit mv dateiname nach /chroot/esmtp/proccessing
  
• kurz warten und die Mails sollten verarbeitet werden.

Sollte trotz dessen die Mails nicht verarbeitet werden kann man noch folgendes probieren:

< 5.50: "sendmail -q"
> 5.60: "postfix flush"

Sicherlich ist diesr kleine trick nicht oft nötig, für viele soll das auch keine Anleitung sein die Appliances zu tweaken.. aber hin und wieder braucht man einfach einen root Zugang auf die Appliances.
Kennt man sich nun mit Linux nicht wirklich aus kann man lange probieren, einloggen als “root” gibt es so nicht.
Eigentlich ist es aber doch ganz einfach! Hier die zwei kleinen Schritte:

Loggen Sie sich per SSH auf der Appliance ein.
Per “sudo su -” übernehmen Sie Root Rechte.

Das wars schon

In diesem Template beschreibe ich wie mit Postfix ein relativ guter Schutz vor Spam erzielt werden kann.
Ich habe mit exakt diesem Template ca. 95% weniger Spam bekommen.

Für Verbesserungsvorschläge stehe ich jederzeit gerne bereit.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

smtpd_banner = $myhostname ESMTP-YOUR SERVER $mail_name (Debian/GNU)
biff = no

append_dot_mydomain = no

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/YOURCERT.cert
smtpd_tls_key_file = /etc/postfix/YOURKEY.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = YOURSERVER.tld
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydomain = YOURDOMAIN.tld
mydestination = domain, servername etc. , $myhostname, localhost.$mydomain, $mydomain
smtpd_helo_required = yes
message_size_limit = 102400000
#smtpd_helo_restrictions = reject_invalid_hostname
smtpd_helo_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_rhsbl_client rhsbl.sorbs.net,
reject_rhsbl_sender rhsbl.sorbs.net,
reject_rbl_client opm.blitzed.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client dialup.blacklist.jippg.org,
reject_rbl_client opm.blitzed.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client zen.spamhaus.org,
reject_unauth_pipelining

smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
reject_unauth_destination,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client opm.blitzed.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl,
reject_rbl_client dialup.blacklist.jippg.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client zen.spamhaus.org,
permit

smtpd_sender_restrictions = reject_unknown_address
smtpd_client_restrictions = reject_invalid_hostname
strict_rfc821_envelopes = yes
home_mailbox = mails/
relayhost =
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# SASL parameters

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtp_sasl_auth_enable = no
broken_sasl_auth_clients = yes

#Virtual Host parameters
#virtual_alias_domains = YOURALIAS DOMAINS
virtual_alias_maps = hash:/etc/postfix/virtual_domains
virtual_mailbox_limit = 102400000

Wie updated man eigentlich ein Failover ASA Cluster richtig?

Zuerst einmal müssen auf beiden(!) Firewalls die gewünschten neuen Versionen hochgeladen werden.
Dies kann man per ASDM oder per tftp, http oder ftp tun wenn man eher der Command Line Fan ist.

Wichtig ist, dass die Images auch in der Konfiguration gesetzt werden, wir müssen also in der Config das BOOT und ASDM Image anpassen:

boot system disk0:/asa822-k9.bin
asdm image disk0:/asdm-6.2.5.bin

Wichtig! Nicht vergessen das ganze zu speichern mit:

wr mem

Nun wechseln wir auf die Primary Firewall und führen folgenden Befehl aus:
sh failover state mit diesem Befehl fragen wir den Failover Status der Firewall ab.
Wir sollten folgendes zu sehen bekommen:

Firewall# sh failov state
State Last Failure Reason Date/Time
This host – Primary
Active None
Other host – Secondary
Standby Ready None
====Configuration State===
Sync Done – STANDBY

This host – Primary! Wir sind also richtig.

Wir starten nun die Standby Firewall einmal durch mit dem Befehl:

failover reload-standby

Wir warten kurz nach absetzen des Befehls und geben zum checken ob der Failover geklappt hat einmal:

sh failover state

ein.

Nun können wir das ganze auf der primary Firewall durchführen indem wir auf der aktuellen Firewall den Primary Status abgeben mit:

no failover active

und starten diese auch neu mit:

failover reload-standby

Jetzt kann man wieder zurückschwenken wenn gewünscht oder es so belassen, prinzipell ist beides dasselbe!

… Das wars schon!

Das ganze gibts auch im Zero Downtime HowTo von Cisco zu finden:

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/mswlicfg.html#wpxref39028

Was tun wenn man sich auf dem Webinterface nicht mehr einloggen kann? Bzw. das Adminpasswort einfach vergessen hat.

Zuerst schnapp man sich Monitor und Tastatur um sich per Konsole am Server anzumelden, Intelligenter, und das empfehle ich jedem der mit den Appliances arbeitet definiert sich eine Adminmaschine die IMMER via SSH auf den Server zugreifen darf.

ToDo:

• Wir loggen uns am System mit dem User “Console” ein
• Wir gehen zum Punkt “Password and account management”
  
• Wir wählen “Reset admin Reset UI administrator account”
  
• Wir bestätigen das zurücksetzen des Accounts mit “Yes”
  

Nachdem das Passwort zurückgesetzt wurde, ist das default Passwort “password” schade, das DIES nirgends in der Dokumentation zu finden ist

*UPDATE*
Danke Andreas, dass Du in der Knowledgebase das Standardpasswort ergänzt hast
http://kb.clearswift.com/display/2n/kb/article.aspx?aid=1985&n=1&s=

Gerade eben habe ich folgende E-Mail erhalten:

Dear Patrick,

I am pleased to announce that we have launched two new Cloud-based email filtering products – GFI MAX MailProtection and GFI MAX MailEdge – in the USA, UK and APAC. In 2010, we will also continue developing our on-premise products with significant enhancements to GFI MailEssentials and GFI MailSecurity.

If you have any questions or feedback do email us on WECARE@gfi.com

… Ich bin zwar kein Freund von GFi Software, besser gesagt nicht mehr, aber das schau ich mir doch vielleicht an, sollte Interesse von eurer Seite aus bestehen lasst es mich wissen und ich werde ein Review dazu schreiben.

Wer kennt diese Problem nicht? Neue Mailbox, neuer User… und die LDAP Sync auf der Appliance ist einfach noch nicht durch! Gut man könnte ja von Hand Updaten… aber wieso nicht einfach wie früher bei der guten alten Software alle 15 min oder jede Stunde?

Eigentlich auch gar kein Problem! In diesem kleinen Tutorial will ich zeigen wie es geht:

• Zuerst loggen wir uns auf die Appliance per SSH ein, übernehmen root Rechte, wer nicht weiß wie, ein Tutorial findet man auf dieser Seite.
• Wir kopieren nun die Datei /opt/msw/data/ldapagent/schedule.properties zu /var/msw/ldap/  – Wer nicht so gerne mit der Konsole arbeitet kann hierzu auch WinSCP oder ähnliches nehmen.
• Diese Datei dann einfach so anpassen wie in Zukunft die LDAP Liste Synchronisiert werden soll.
• Nach der änderrung einmal über das WebInterface die Sync starten und schauen ob noch alles geht. Alternativ wieder über die Konsole mit dem Befehl: uiservicecontrol restart ldap

Anbei ein Beispiel wie die Datei aussieht mit einer frequenz von 15 Minuten:

#
# Schedule for LDAP agent
#
# Copy this file to /var/msw/ldap/ to change the default schedule
# Use an absolute time of day or a frequency

absolute=false

# Time of day to refresh LDAP address lists (if absolute=true)

time=02:30

# Frequency (in minutes) to refresh LDAP address lists (if absolute=false)

# (1 hour)

frequency=15

Und es ist mal wieder soweit, ein Exploit für den Internet Explorer in der Version 6.x oder drunter! Leider noch immer ein viel zu genutzter Browser. Microsoft selbst hat diese Sicherheitslücke bereits in Version 7.0 geschlossen.

Wer genau Verwundbar ist kann man im Security Blog von Microsoft anhand einer Grafik super sehen: http://blogs.technet.com/srd/

Aber nun zum HowTo – Ziel ist es alte Browser zu sperren.

• - Wir erstellen eine “Block Page” mit dem Namen “Alter Browser erkannt”
  - hier am besten die Beschreibung das der Explorer Sicherheitslücken hat und upgedatet werden soll als Information  angeben.

• - Wir erstellen eine lexical Expression List und fügen folgende Stichwörter ein:
  MSIE 6.0
  MSIE 6.0b
  MSIE 5.5
  MSIE 5.01
  MSIE 5.0
  MSIE 5.0b1
  MSIE 4.01

• - Route erstellen und einfügen

Tada.. alle Anfragen von den alten Browsern werden gesperrt.
Selbiges funktioniert auch mit ISA/TMG.