Category: Övrigt

HOW TO: Configure BGP between Arista and Palo Alto using loopback-interfaces

In this example I will be showing you how you can configure BGP between Arista and Palo Alto. The setup has two Arista COR-switches which is configured with MLAG and a Palo Alto Networks firewall.

The goal is to use iBGP between the Arista-switches and eBGP between the Arista-switches and Palo Alto.

We will also be using a specific VRF in this example, if you have more than one VRF the same configuration-method can be applied again.

We will also assume that all linknet-interfaces are already configured on each device.

The topology is shown below.

Start by adding your route distinguisher and activate routing on your VRF on the Arista-switches.

Configure the loopback-interfaces and create static routes between them.

Next we will configure BGP on both Arista-switches. Both Arista-switches will have the same router BGP-ID but will be distinguished by ”local-as”. Also in this example we will redistribute connected and static routes, these can be changed depending on your needs.

Verify that that the neighbor Arista-switch is in established state with the below command.

Next we will configure the Palo Alto-firewall with BGP. For simplicity we will call the Virtual Router ”vrf-01” here as well.

Start by creating your loopback-interface.

Then create your static-routes and enable ECMP to be able to use both paths.

Next we will create a redistribution profile to decide what routes will be redistributed. As on the Arista-switches we will redistribute connected and static routes.

As a final step we will configure BGP on the VR. This can be configured in several different ways depending on your needs and this example is kind of slim but enough to distribute the routes.

Verify that BGP is established to both arista-core1 & arista-core2 by going to:

You should see that both ”peer-arista-core1” and ”peer-arista-core2” is established.

Also verify the established neighbors (should be two) on the Arista-switches with the below command:

At this point the only routes that should be added by BGP is the linknets that is not directly connected.

For example on arista-cor1:

As seen in the topology 10.0.0.2/31 is between arista-core2<->pa-fw01 and arista-core1 routes this traffic via the linknet ip on arista-core2.

Feel free to send me any questions to petter.vikstrom@xenit.se or add your question in the comments.



Palo Alto introduces new feature to support Terminal Service (TS) Agent on Windows Server 2016

In the latest release of Palo Alto Networks Terminal Service Agent 8.1.1, we were introduced to a new feature where it is now supported to install the agent on Windows Server 2016.

This is a very welcome feature that a lot of us have been waiting for. There are no other features added to this version or the one before.

This release is also compatible with all the PAN-OS versions that Palo Alto Networks still support.

For more information see:

Where Can I Install the Terminal Service (TS) Agent?

Release Notes – Terminal Service Agent 8.1



Chrome – Certificate warning – Invalid Common Name

Users of Google Chrome version 58 (released March 2017) and later will receive a certificate alert when browsing to HTTPS-sites if the certificate only uses Common Name and does not use any Subject Alternative Name (SAN) values. This has been ignored and for many years the Common Name field was exclusively used. The Chrome developers finally had enough with the field that refuses to die. In Chrome 58 and later, the Common Name field is now ignored entirely.

Chrome - Certificate warning - Invalid commonName

Chrome – Certificate warning – NET::ERR_CERT_COMMON_NAME_INVALID

The reason for this is to prevent homograph attack – which exploits characters which are different but look similar. The lookalike characters can be used for phishing and other malicious purposes. For instance, the English letter “a” looks identical to the Cyrillic “a”, but from a computers point of view these are encoded as two entirely different letters. This allows domains to be registered that look just like legitimate domains.

Some organizations with an internal or private PKI have been issuing certificates with only the Common Name field. Many often do not know that the “Common Name” field of an SSL certificate, which contains the domain name the certificate is valid for, was phased-out via RFC nearly two decades ago (RFC 2818 was published in 2000). Instead the SAN (Subject Alternative Name) field is the proper place to list the domain(s), which all publicly trusted certificate authorities must abide by, has required the presence of a SAN (Subject Alternative Name) since 2012.

Publicly-trusted SSL certificates have been supporting both fields for years, ensuring maximum compatibility with all software – so you have nothing to worry about if your certificate came from a trusted CA like Digicert.

Below is an example of a correctly issued certificate with Common Name and Subject Alternative Name.

tech.xenit.se - Common Name

tech.xenit.se – Common Name

tech.xenit.se - Certificate Subject Alternative name

tech.xenit.se – Subject Alternative Name

RFC 2818 – Common Name deprecated by Google Chrome 58 and later

”RFC 2818 describes two methods to match a domain name against a certificate: using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName.

/…

The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. However, the commonName is ambiguous, and because of this, support for it has been a source of security bugs in Chrome, the libraries it uses, and within the TLS ecosystem at large.

Source: https://developers.google.com/web/updates/2017/03/chrome-58-deprecations



Outlook Search index med FSLogix

Något som upptäckts snabbt efter uppsättningen av sin ”FSlogix Office 365 Containers”-lösning i en fleranvändarmiljö är att sök-indexeringen för Outlook i vissa miljöer görs om vid varje ny inloggning, det gäller miljöer där man har flera Session Hostar användarna kan logga in på.

Sök-funktionen i Outlook använder sig av ”Windows Search” vilket är en databas över indexeringarna på hela Operativsystemet, det är alltså inget som lagras för varje enskild användare. Det innebär t.ex.  att en Citrix miljö med flera servrar kommer en användares Outlook indexera om hela Outlook vid varje ny server man loggar in på. Detta medför en långsam sökning (tills indexeringen är klar) och en onödigt belastning på CPU som i sin tur kan påverka hela miljön negativt. Det kan bli ännu värre i de fall man använder Citrix Provisioning Services (PVS) då den uppdaterade indexeringen försvinner vid varje omstart av servern.

FSLogix to the rescue

För att komma runt detta problem finns en funktion i FSLogix som tar med din Outlook indexering i VHD-filen, på så vis har du alltid din uppdaterade indexeringsdata med dig på vilken server du än hamnar på. Du behöver ändra på två stycken registervärden för att aktivera detta, jag själv föredrar att skapa/editera en GPO för detta.

Följande två registervärden ska justeras:

HKLM\Software\FSLogix\Apps

Type:                      DWORD

Value Name:          RoamSearch

Value Data:            2

 

HKLM\Software\Policies\FSLogix\ODFC

Type:                      DWORD

Value Name:          RoamSearch

Value Data:            2

 

Hör gärna av er om ni skulle vara intresserade av eller vill veta mer om produkter från FSLogix, se gärna våra tidigare blogginlägg om FSLogix nedan:

FSLogix Profile Containers – Enkel och snabb Profilhantering

Office365 med FSLogix i en fleranvändarmiljö

OneDrive with simulated Single Sign-On

 

 



Print drivers and Microsoft Update KB3170455

Typically users get their printers mapped by Group Policies or Group Policy Preferences. Especially in Citrix environments, users should not have the right to add their own printers or drivers that are not approved for multi-user environments. On July 12th 2016, Microsoft released a security update (KB3170455) to safeguard Man-in-the-Middle (MITM) attacks for clients and print servers. Then an updated version was released again September 12th 2017.

Users could encounter the dialog boxes below if the driver did not meet the requirements of Microsoft where the driver would be packaged and signed with a certificate:

Scenario 1

For non-package-aware v3 printer drivers, the following warning message may be displayed when users try to connect to point-and-print printers:

Do-you-trust-this-printer

Do you trust this printer?

Scenario 2

Package-aware drivers must be signed with a trusted certificate. The verification process checks whether all the files that are included in the driver are hashed in the catalog. If that verification fails, the driver is deemed untrustworthy. In this situation, driver installation is blocked, and the following warning message is displayed:

Connect-to-printer

Connect to Printer

Even if you enabled Point and Print restrictions in GPO and specified which server’s clients could get drivers from, users could encounter an installation prompt and request administrator privileges to install.

For most printers this is not an issue if there is an up-to-date driver which is compliant. Some manufacturers do not always provide printers drivers that is both packaged and signed. The first thing you should do is update the driver to one that both is signed and packaged. Usually the drivers from the manufacturer are signed according to Microsoft Windows Hardware Quality Labs (WHQL) but may not be packaged correctly and the users get prompted for administrator credentials when the printer is being added to the client computer or in the remote desktop session.

Since KB3170455 we need to enable point and print restrictions and specify our print servers in the GPO. For most printers there is no issues, however a couple of printers will not be pushed out by Group Policy Preferences since the update. Even though the print server was listed in the point and print GPO. Browsing the print share and trying to connect the printer manually would result in the ”Do you trust this printer” pop up which will then prompt for administrator credentials to install the driver. Looking at Print Management on the server in question shows that the problem printer drivers have a ”Packaged” status of false.

Workaround:

If you are pushing out printers via Group Policy or Group Policy Preferences and they are of Non-Packaged type you will always get a prompt to install, ignoring the point and print GPO, which will cause the install to fail. A workaround to this is a registry edit on the print server – test and verify this first before putting it into production:

  • HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\<…>\<Driver name>\PrinterDriverAttributes

Change the value from 0 to 1 and reboot the printspool service or/and server. The value for other print drivers may not be 1, but to make this work the value needs to be set to an odd number. For example, if the value is 4 change it to 5. Only do these changes if you have no other means of getting a valid driver or printer swapped. In RDS/Citrix environments you could pre-install the printer driver on the host if viable and you only have a few session-hosts.

Back in Print Management you will see the Packaged status is now changed to true, and the printer should deploy. If you can find packaged print drivers then use those, but some manufacturers have not bothered supplying them.

PrintManagement-packaged-true

PrintManagement – Packaged True

Source: https://support.microsoft.com/en-us/help/3170005/ms16-087-security-update-for-windows-print-spooler-components-july-12



Palo Alto Networks: Command-And-Control (C2) category has been added to URL-Filtering

A new category has been added to Palo Alto Networks URL-filtering. The category is ”Command and Control” or ”C2” and the recommendation is to immediately set the action to BLOCK in your security profiles.

C2 was previously included in the Malware category but has now been separated to get more effective management. For the malware-category you will normally recognize that the threat was stopped by your Palo Alto Networks Firewall and no further compromises has been made. When C2 is logged an endpoint has likely been compromised, this happens when an compromised endpoint attempts to communicate with an attackers remote server to receive malicious commands or extract information.

The default URL-profile should automatically have C2 action to BLOCK if you are using PAN-OS version 8.0.2 or later. If you are using customized profiles or other versions you need to set it manually.

These are the steps required:

  1. Go to Objects > Security Profiles > URL Filtering

 

 

 

 

 

 

 

 

2. Click on your URL-profile and find ”command-and-control” in the list. Set the action to BLOCK and press OK.

Also make sure the URL-profile are applied to your security-profiles.

Press commit and you are done!

More information can be found on https://live.paloaltonetworks.com/t5/Management-Articles/Command-and-Control-C2-FAQ/ta-p/178617

 



Uppsättning av accesspunkter med hjälp av Device Profile

Device Profile är en funktion som finns på de senare ArubaOS switchar. Funktionen förenklar uppsättningen av accesspunkter, genom att autokonfigurera portarna som accesspunkterna kopplas in i.

För att konfigurera detta så skall först en profil skapas på switchen, där konfigurationen som ska gälla på porten som APn kopplas in i ställs in. Detta görs med nedan kommando:

Switch# device-profile name "AccessPoint"
untagged-vlan 100
tagged-vlan 150,200,212
exit

En profil är nu skapad. Det som konfigureras där ska gälla på de portar som en viss typ av accesspunkter kopplas in i.
Associera sedan profilen till en enhetstyp, i detta fallet Aruba accesspunkter:

Switch# device-profile type "aruba-AccessPoint"
associate "AccessPoint"
enable
exit

När en Aruba AP sedan kopplas in i valfri port på switchen, så kommer konfigurationen ovan att automatiskt appliceras på porten.
I nedan exempel har en Aruba accesspunkt kopplats in i port 1 på switchen. Tittar vi på konfigurationen som ligger på porten just nu:

Switch# show running-config interface 1
Running configuration:
interface 1
untagged vlan 112
exit

Tittar vi dock närmre så ser vi att det är nedan konfiguration som automatiskt lagt sig på port 1, enligt konfigurationen i device profile:

Switch# show vlans port 1 detail
Status and Counters - VLAN Information - for ports 1
VLAN ID Name | Status Voice Jumbo Mode
------- -------------------- + ---------- ----- ----- --------
150 Business | Port-based No No Tagged
200 Client | Port-based No No Tagged
212 Public | Port-based No No Tagged
100 Management | Port-based No No Untagged

Skulle accesspunkten kopplas ur, så går konfigurationen på porten tillbaka till hur den var innan.

Nedan commando visar vilka portar där device-profile är aktiverat och om en Aruba accesspunkt är inkopplad:

Switch# show device-profile status
Device Profile Status
Port Device-type Applied device profile
------------- -------------------- ----------------------
1 aruba-AccessPoint AccessPoint
2 aruba-AccessPoint AccessPoint
3 aruba-AccessPoint AccessPoint
4 aruba-AccessPoint AccessPoint
5 aruba-AccessPoint AccessPoint
6 aruba-AccessPoint AccessPoint
7 aruba-AccessPoint AccessPoint
8 aruba-AccessPoint AccessPoint
10 aruba-AccessPoint AccessPoint

Med hjälp av device-profiles är det mycket enklare och tidssparande att koppla in access-punkter, eftersom man slipper att manuellt konfigurera varje port.



Skapa SpamAssassin-signaturer för blockering av ransomeware-kampanjen Torrentlocker/Crypt0l0cker

Just nu pågår en ransomware-kampanj som försöker infektera privatpersoner och företag genom bluff-mail (spam). Myndigheten för samhällsskydd och beredskap har gått ut med signaturer som kan användas för att identifiera och blockera kampanjen på följande länk: Signaturer för pågående ransomware-kampanj.

Signaturerna innehåller tre länkar till ZIP-filer som ligger hos Dropbox, men även ämnesraden för bluff-mailen:

Dropbox URL:er
hxxps://dl.dropboxusercontent.com/s/5h76l6uqdp7vtvk/753941.zip?dl=0
hxxps://dl.dropboxusercontent.com/s/h8jyb5xkh6dqoyf/197067.zip?dl=0
hxxps://dl.dropboxusercontent.com/s/jv3vtf14gxgz6sa/394216.zip?dl=0

Två exempel på phishing-mailen:

”Från: Skickat: den 16 mars 2017 11:06
Till: förnamn.efternamn@domän.se
Ämne: Faktura / Betala din faktura / Se din faktura / Detta är din faktura

Hallå
Info: hxxps://dl.dropboxusercontent[.]com/s/snzrpnvtd1fchxi/862751.zip?dl=0
(+ flertalet andra Dropbox länkar)


Från: ” Datum: 16 mars 2017 11:08:23 GMT
Till: Ämne: Faktura

Betala din faktura: hxxps://dl.dropboxusercontent.com/s/jv3vtf14gxgz6sa/394216.zip?dl=0

Vänliga Hälsningar
Namn

Med hjälp av denna informationen kan man skapa en regel i SpamAssassin:

Man kan göra regeln enklare att läsa genom att skapa en kontroll per ämnesrad och länk:

Den officiella dokumentationen för hur man skriver SpamAssassin-regler återfinns här: https://wiki.apache.org/spamassassin/WritingRules