R33NET BLOG Rotating Header Image

Firewall

CheckPoint: Managing ADQuery Suspected Service Account List

Solltet Ihr Identity Awareness [IA] mit ADQuery im Einsatz haben könnt Ihr die Option „Automtically exclude users wich are logged into more than X machines simultaneously“ aktivieren. Oder ihr müsst eure Windows Admins oder Servicedesk Mitarbeiter manuell vom ADQuery ausschließen [Excluded Users/Networks]. Warum ?
Sobald ein Benutzer ein „AD Security Login Event“  auslöst lernt die Firewall die IP Adresse des Benutzers und weist die entsprechende FW-Freischaltung die an dem AD-Konto gebunden ist dem System zu. Das kann durch die Anmeldung an einem System einer RDP Session, Zugriff auf Netzlaufwerke, Exchange oder sonstige Authentifizierung an der Domäne geschehen. Ein Admin loggt sich auf einer Vielzahl von Systemen ein und hat meistens andere Firewallfreischaltungen als ein normaler Anwender. Durch die Anmeldung auf einem System zu Support zwecken greifen jetzt also auch die FW-Freischaltunen des Admins. Um dieses zu verhindern solltet ihr die Service Accounts vom ADQuery ausschließen. Wird doch mal von einem Admin die Freischaltungen auf einem der Systeme benötigt kann dieser ich sich über das Captive Portal authentifizieren.
Solltet Ihr die Option „automatically exclude users“ aktiviert haben sucht IA alle 10min nach „service accounts“.  Die vermutlichen „service accounts“ werden in einer persistenten Datenbank gespeichert die auch einen Reboot überlebt.  Es ist es auf jeden Fall sehr hilfreich sehen zu können welche Benutzer auf dieser Liste stehen ggf. sobald mal einen von dieser Liste zu entfernen. Um die „service account“ Datenbank einsehen und verwalten zu können stehen euch folgende Befehle im Expert-Mode zur Verfügung.

adlog a control srv_accounts show Alle erkannten „service account“ anzeigen lassen
adlog a control srv_accounts find Den „service account“ Scan sofort starten
Adlog a control srv_accounts unmark <account name> Einen „service account“ aus der Datenbank löschen
adlog a conrol srv_accounts clear Alle „service account“ aus der Datenbank löschen
adlog a control reconf Wenn adlog a conrol ausgeführt wurde muss „reconf“ ausgeführt werden um die Änderungen zu speichern.

 

 

PaloAlto: PAN-OS 8.0 Session End Reason

PaloAlto zeigt in PAN-OS 8 die Informationen an warum eine Verbindung beendet wurde. Mir ist es bei der aktuellen Version 8 aufgefallen. Laut Dokumentation steht dieses Feature bereits seit PAN-OS 7.1 zur Verfügung. Wenn Ihr auf der Palo die SSL/TLS decryption macht um den Traffic nach Schadcode untersuchen zu können bekommt ihr jetzt genauere Informationen warum eine Verbindung nicht entschlüsselt werden kann.

decrypt-cert-validation wenn ein Serverzertifikat ausgelaufen, nicht vertrauenswürdig ist
decrypt-unsupport-param bei nicht unterstützten Protokoll Versionen, Cipher oder SSH Algorithmen
decrypt-error bei allen anderen Fehlern

Hier die komplette Liste (Nach Priorität sortiert) der Session End Reason. Sollte eine Verbindung aus mehreren Gründen beendet werden wird immer der höchst priorisierte Grund angezeigt.

threat

The firewall detected a threat associated with a reset, drop, or block (IP address) action.

policy-deny

The session matched a security rule with a deny or drop action.

decrypt-cert-validation

The session terminated because you configured the firewall to block SSL forward proxy decryption or SSL inbound inspection when the session uses client authentication or when the session uses a server certificate with any of the following conditions: expired, untrusted issuer, unknown status, or status verification time-out. This session end reason also displays when the server certificate produces a fatal error alert of type bad_certificate, unsupported_certificate, certificate_revoked, access_denied, or no_certificate_RESERVED (SSLv3 only).

decrypt-unsupport-param

The session terminated because you configured the firewall to block SSL forward proxy decryption or SSL inbound inspection when the session uses an unsupported protocol version, cipher, or SSH algorithm. This session end reason is displays when the session produces a fatal error alert of type unsupported_extension, unexpected_message, or handshake_failure.

decrypt-error

The session terminated because you configured the firewall to block SSL forward proxy decryption or SSL inbound inspection when firewall resources or the hardware security module (HSM) were unavailable. This session end reason is also displayed when you configured the firewall to block SSL traffic that has SSH errors or that produced any fatal error alert other than those listed for the decrypt-cert-validation and decrypt-unsupport-param end reasons.

tcp-rst-from-client

The client sent a TCP reset to the server.

tcp-rst-from-server

The server sent a TCP reset to the client.

resources-unavailable

The session dropped because of a system resource limitation. For example, the session could have exceeded the number of out-of-order packets allowed per flow or the global out-of-order packet queue.

tcp-fin

One host or both hosts in the connection sent a TCP FIN message to close the session.

tcp-reuse

A session is reused and the firewall closes the previous session.

decoder

The decoder detects a new connection within the protocol (such as HTTP-Proxy) and ends the previous connection.

aged-out

The session aged out.

Unknown

This value applies in the following situations:

-Session terminations that the preceding reasons do not cover (for example, a clear session all command)

-For logs generated in a PAN-OS release that does not support the session end reason field (releases older than PAN-OS 6.1), the value will be unknown after an upgrade to the current PAN-OS release or after the logs are loaded onto the firewall.

-In Panorama, logs received from firewalls for which the PAN-OS version does not support session end reasons will have a value of unknown

n/a

This value applies when the traffic log type is not end

PaloAlto Dokumentation PAN-OS 8: syslog field descriptions 

CheckPoint: Löschen alle Identity Awareness Sessions und Identitäten

Aus den verschiedensten Gründen kann es mal vorkommen da alle Identity Awareness Verbindungen und gelernte Identitäten aus der Datenbank gelöscht werden müssen.
ACHTUNG:
-In ClusterXL Umgebungen müssen die Befehle auf beiden Cluster-Geräten zeitgleich ausgeführt werden da diese zwischen den ClusterXL nodes synchronisiert werden.
-Da eine erneute „Authentifizierung“ der Clients erforderlich ist sollte das selbstverständlich nur in einem Wartungsfenster durchgeführt werden.

Clearing all Identity Awareness kernel tables:

[Expert@hostname]# fw tab -t pdp_sessions -t pdp_super_sessions -t pdp_encryption_keys -t pdp_whitelist -t pdp_timers -t pdp_expired_timers -t pdp_ip -t pdp_net_reg -t pdp_net_db -t pdp_cluster_stat -t pep_pdp_db -t pep_networks_to_pdp_db -t pep_net_reg -t pep_reported_network_masks_db -t pep_port_range_db -t pep_async_id_calls -t pep_client_db -t pep_identity_index -t pep_revoked_key_clients -t pep_src_mapping_db -t pep_log_completion -x -y

[Expert@hostname]# fw kill pdpd
[Expert@hostname]# fw kill pepd

CheckPoint: Logical Volume resize

Um die Festplatten in eurer Firewall zu vergrößern oder zu erweitern geht Ihr wie folgt vor. In diesem Fall habe ich das LV (Logical Volume) lv_current mit vorhandenen freien Speicher vergrößert. Falls Ihr eine weitere Festplatte eingebaut habt müsst Ihr das PV (Physical Volume) mit „pvcreate“ initialisieren. Danach einer VG (Volume Group) zuweisen mit „vgextend“

[Expert@fw-mgmt:0]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current
30G 25G 3.4G 88% /
/dev/sda1 145M 19M 118M 14% /boot
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/mapper/vg_splat-lv_log
97G 51G 42G 56% /var/log
tmpfs 10G 0 10G 0% /ramdisk

[Expert@fw-mgmt:0]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 231.81G 91.81G

[Expert@fw-mgmt:0]# vgs
VG #PV #LV #SN Attr VSize VFree
vg_splat 1 3 0 wz–n- 231.81G 62.88G

[Expert@fw-mgmt:0]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
lv_current vg_splat -wi-ao 40.00G
lv_log vg_splat -wi-ao 100.00G

[Expert@fw-mgmt:0]# lvextend -L +10G /dev/vg_splat/lv_current
Extending logical volume lv_current to 40.00 GB
Logical volume lv_current successfully resized

[Expert@fw-mgmt:0]# resize2fs /dev/vg_splat/lv_current
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/vg_splat/lv_current is mounted on /; on-line resizing required
Performing an on-line resize of /dev/vg_splat/lv_current to 10485760 (4k) blocks.
The filesystem on /dev/vg_splat/lv_current is now 10485760 blocks long.

[Expert@fw-mgmt:0]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current
39G 25G 13G 66% /
/dev/sda1 145M 19M 118M 14% /boot
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/mapper/vg_splat-lv_log
97G 51G 42G 56% /var/log
tmpfs 10G 0 10G 0% /ramdisk

CheckPoint Security Gateway Backup/Restore

cp1Hier möchte ich kurz die unterschiedlichen Backup/Restore Möglichkeiten auf einem Check Point Security Gateway beschreiben. Die Backups zu erstellen über WebGui oder CLI ist relativ einfach und gut beschrieben: CP_R77_Gaia_Installation_and_Upgrade_Guide – Backing Up

upgrade_export (restore)
-Es werden keine OS (SPLAT) Einstellungen gesichert. Es werden nur die Check Point Einstellungen gesichert.
Da hier keine OS Daten gesichert werden kann es z.B auf einen anderen OS importierte werden.
Ein upgrade_import auf einer anderen Hardware ist möglich, sowie der Import auf eine neue OS Version (Achtung der upgrade_export muss mit der neueren Version ausgeführt werden.)

backup (restore)
-Ein SPLAT Backup sichert sowohl die SPLAT OS Einstellungen als auch die Check Point Einstellungen. Kurz gesagt ein upgrade_export mit OS Einstellungen.
Der Restore setzt die gleiche Softwareversion und Hardware voraus.

snapshot (revert)
-Ein Snapshot ist meistens die besser Wahl als ein Backup. Es enthält neben den OS und CP Einstellungen zusätzlich auch die binary-files. Kurz gesagt es wird ein Image erstellt. Hier ist eine Wiederherstellung zwischen unterschiedlichen Versionen möglich.
Z.B. kann ich einen Snapshot auf R77.10 machen, dann das Upgrade auf R77.30 durchführen. Auf R77.30 kann ich ebenfalls ein Snapshot machen. Dies erlaubt mir jederzeit zwischen den Versionen zu wechseln.
Ein Revert ist nur auf derselben Hardware möglich. Versucht man ein Snapshot auf einer anderen Hardware wieder her zu stellen muss man die /etc/sysconfig/hwconf und /etc/modules.conf löschen (Werden automatisch bei Reboot erstellt) sowie die „hwaddr“ Zeilen aus der /etc/sysconfig/netconf.C
Achtung: Ihr benötigt genug freien Plattenplatz auf der Backup Partition, mein letzter Snapshot war 5,4 Gb groß. (Root Partition * 1,15)

CheckPoint failover commands

cp-clusterDie wichtigsten CheckPoint Befehle zum Thema Cluster „failover“.

cphaprob stat

Listet den Clusterstatus

cphaprob -a if

Status der Interface

cphaprob syncstat

Zeigt den Sync Status

cphaprob -reset syncstat

Sync Status zurücksetzen

cphastart/stop

Stopt den Cluster auf dem jeweiligen Gerät

Etherchannel, PagP & LACP

image

Ales Etherchannel bezeichnet man ein Verfahren zur Bündelung mehrerer physikalischer Ethernet-Schnittstellen zu einem logischen Kanal. Etherchannel hat sich teilweise als alltäglicher Ausdruck für die Ethernet-Kanal-Bündelung etabliert und wird umgangssprachlich nicht nur für Cisco-Produkte benutzt. He nach Hersteller werden für die Bündelung andere Synonyme benutzt:
    -Bonding, im Linux Umfeld.
    -Etherchannel, bei Cisco.
    -Link Aggregation, bei IEEE
    -Port Aggregation, bei Hewlett-Packard.
    -Trunking, bei Sun Microsystems

Richtlinien für die Konfiguration:
-Bis zu 8 Ethernet Interfaces des selben Typs (nicht den GigaStack GBIC nutzen)
-Geschwindigkeit und Duplex Mode müssen gleich sein.
-"enable" alle Interfaces
-Ein Interface das als SPAN-Port (Switched Port Analyzer) oder 802.1X konfiguriert ist, wird nicht im Etherchannel unterstützt.
-Alle Interfaces müssen sich im selben VLAN befinden oder als Trunk gesetzt sein.
-Bei Trunking bitte den Mode beachtetn ISL oder 802.1Q müssen identisch sein

Port Aggregation Protocol (PagP)image
Vom Funktionsprinzip ähnelt das proprietäre PAgP (CISCO) dem offenen LACP. Das PAgP erkennt, durch das Aussenden sogenannter Hello-Pakete, ob zwei Switches über mehr als eine physikalische Verbindung direkt verbunden sind. Das senden der Hello-Pakete findet nur im "desirable" Modus statt, während im "auto" Modus nur auf diese Pakete geantwortet wird.

Link Aggregation Control Protocol (LACP) IEEE 802.1AX-2008 (früher IEEE 802.3ad)
LACP hat den Vorteil das es Herstellerübergreifend arbeitet. Bei LACP kann jeder einzelne Port als Active LACP oder Passive LACP konfiguriert werden:
Passive LACP: der Port bevorzugt von sich aus keine LACPDUs zu übertragen. Nur wenn die Gegenstelle Active LACP hat, überträgt der Port LACPDUs (preference not to speak unless spoken to).
Active LACP: der Port bevorzugt LACPDUs zu übertragen und somit das Protokoll zu sprechen unabhängig davon ob die Gegenstelle Passive LACP hat oder nicht (a preference to speak regardless).

Cisco: Configuring EtherChannels

Befehle:
Das Konfigurationsbeispiel erstellt einen Etherchannel aus den Interfaces Gigabit Ethernet 0/4 und 0/5 als static-acces Ports in VLAN 10 zu Channel 5 mit PAgP-Modus “desirable”

Switch# configure terminal
Switch(config)# interface range gigabitethernet0/4 -5
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# channel-group 5 mode desirable
Switch(config-if-range)# end