Monthly archives: april, 2017

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



NetScaler user authentication to backend with cookies

A system one of my co-workers are load balancing and configuring AAA/SSO uses cookies for authentication. The username is inserted using a cookie, for example ”username=simon”. It’s very easy to first of all identify this cookie and modify it to another value, which makes it insecure.

The idea we got was to stop exposing the cookie to the user and only add it so that the backend sees it using a rewrite. The second thing we also want to do is remove this cookie so even though the user has the cookie, it will never be sent to the backend.

The solution is quite simple and looks like this:

From my initial tests, this will remove all cookies named ”username” (case insensitive) and add a new one with values from NetScaler AAA. If the user isn’t sending any Cookie-header at all, we’ll add one as well.

Seems to work very well!

Have you done this in any other way? Feel free to post how you did it.



Windows Login prompt with Single Sign-On XenApp

Lately some customers reported they didn’t get Single Sign-On all the way into the desktop when logging in via the browser to StoreFront. Single Sign-On worked partly with automatic login to the StoreFront desktop/application view, but whenever they tried to start a new session the users faced a Windows login prompt. Citrix have released a relatively new article with a variety of things to test when facing problems with Single Sign-On for XenApp/XenDesktop.

Windows Login Prompt

I usually apply settings for Citrix Receiver using GPO and applying them to user level. The problem was immediately solved by applying Citrix Receiver settings to the computer level instead.

Citrix Receiver Authentication Settings



Convert SCCM schedule to readable format

Reading SCCM Maintenance Windows is not an easy thing to do from WMI as they are stored as 16 char hex values

To get the schedule hex values simply run the below line, but the result might not be easy to understand

A server might return the following values.

Now, how do we read this? The easiest thing is to run Convert-CMSchedule but that unfortunately only works if the configuration manager console is installed.
Another way to do is to invoke a wmi method from a site server using the SMS_ScheduleMethods class.

None of these are portable, so I created my own function to decode these. The below function returns the same data as Convert-CMSchedule but is free from any module as it converts the hex to a readable format.

The function also accepts valuefrompipeline

 

The script is reverse engineered from https://msdn.microsoft.com/en-us/library/cc143505.aspx



NetScaler SD-WAN WANOP – Hur initieras en optimerad TCP-session?

NetScaler SD-WAN WANOP Edition försöker optimera all trafik som passerar enhetens interface men det är TCP sessionens Handshake som avgör om en den ska optimeras eller ej. Sessioner som bedöms som icke-otimerbara passerar enhetens interface utan påverkan men sessioner som istället bedöms som optimerabara kommer att dra nytta av den nätverksoptimering som SD-WAN WANOP erbjuder.

När en TCP-handshake initieras (i exemplet ovan från Klient LAN) och en SYN-flagga passerar enheten från Klient LAN försöker enheten påbörja optimeringen. Enheten lägger till sina Identification Options till SYN-paketets header, ändrar MSS till 1380 och ökar winscale men lämnar kvar adresserna för source, destination och portar orörda. När paketet sedan kommer fram till en SD-WAN enhet (i exemplet ovan till Server LAN) identifieras det att det kommer från en annan SD-WAN enhet via de Identification Options som ligger i headern. Den mottagande enheten lyfter bort och sparar undan dessa Identification Options men innan paketet skickas ut på Server LAN justeras paketets Sequence number.

När paketet har tagits emot skickas ett SYN+ACK packet tillbaka som bekräftelse. Samma process med Identification Options, MSS och winscale görs nu på SD-WAN enhet på Server sidan. När SYN+ACK når fram till SD-WAN enheten på Klient sidan sparas Identification Options undan från sin nyblivna SD-WAN partner och markerar anslutningen som optimerad. Även denna gång plockas Identication Options bort från headern och paketets Sequence number justeras. Detta görs på båda sidor så att paket som inte passerar SD-WAN enheterna inte accepteras. Handskakningen slutförs sedan när klienten skickar tillbaka ACK-paketet.

Den här designen medför att alla SD-WAN WANOP enheter är transparanta och kan kommunicera och optimera med alla andra SD-WAN WANOP enheter utan att de behöver paras ihop.



Citrix PVS: UEFI Boot of Targets

If you wish to perform UEFI boot of Targets that are provisioned using Citrix PVS, below are the settings (mainly DHCP) that you need to apply. Majority of the info below was taken from this Citrix PowerPoint presentation.

If using Boot Device Management file (BDM):
With BDM, DHCP options are not needed since everything is in the BDM file. You will need to re-create the BDM file however and check the checkbox ‘Target device is UEFI firmware’.

If using either PXE or TFP to point Target devices to PVS servers:
– You need to specify either DHCP Option 11 or 17. Option 17 is only needed if you are not using port 6910 (which is standard) as the beginning of the PVS Streaming service ports on your PVS servers. For Option 11 you should add the IP address of each PVS server that will provide vDisk streaming (if you are using multiple NICs on your PVS server, specify the IP of the Streaming NIC).

– Option 17 only allows a single value, so in order to get redundancy between multiple PVS servers when using this Option you will need to
1. Specify a FQDN (not IP) as Option 17
2. Enable DHCP Option 6 (DNS server(s) to use)
3. Enable DHCP Option 15 (DNS domain name)
4. Configure Round Robin on the FQDN in step 1 on your DNS servers. It might be possible to load balance this on Netscaler instead, but that is not something I have tried.

The correct syntax for Option 17 is ”pvs:[MyPVSServer.domain.com]:17:6911” (without quotes), where 6911 is the custom PVS Streaming start port being used.

If using PXE to point Target devices to PVS servers:
– You will need to specify Option 60, as usual.

– With Citrix PVS, there is a feature called BOOTPTAB which allows you to specify, for example, that Target Device with MAC address X should be sent the Bootstrap file Y. The GUI for configuring this can be found at ”C:\Program Files\Citrix\Provisioning Services\bpedit.exe”. This feature allows us to support both Legacy and UEFI Targets in a PXE boot Setup (requires PVS 7.7 or higher). If you are using TFTP, then BOOTPTAB cannot be used since the name of the BOOTSTRAP to download will instead be extracted from Option 67.

If using TFTP to point Target devices to PVS servers:
– You need to specify DHCP Option 66, as usual (IP of your TFTP load balancer. If you only have a single PVS server, specify the IP of the PVS server)

– You also need to specify Option 67 (file name of the Bootstrap file that should be downloaded to booting PVS Targets from the TFTP servers). In normal Legacy boot setups, the value is ARDBP32.bin, but for UEFI this should be either PVSNBPX64.efi (for Targets running x64 Operating Systems) or PVSNBPX32.efi (for Targets running X86 Operating Systems).

– If you wish to support both Legacy and UEFI boot Targets in your TFTP setup, you will need to create an isolated DHCP scope for Legacy targets and an isolated DHCP scope for UEFI targets (or for example use BDM instead for Legacy devices) and then have Option 67 be different for each DHCP scope.

– A thing to note is that if you have only UEFI target devices in your setup, any IP address(es) specified for the ARDBP32.BIN file in below screenshot become irrelevant since the ARDPB32.BIN file will not be used in the boot process (the IPs or FQDN specified in Option 11 or 17 will instead dictate which PVS server a Target will stream the vDisk from).

Some additional notes:
– The reason why Option 11 or 17 is needed, instead of regular Option 67, is because the UEFI BOOTSTRAP files PVSNBPX64.efi/PVSNBPX32.efi cannot be edited, unlike the ARDBP32.bin file. And one purpose of the ARDBP32.bin file is to deliver to the booting Target device the IP of the PVS Server it should stream the vDisk from. Since the UEFI files cannot be edited to include the PVS server IPs, the PVS Server IPs must be delivered in some other way, hence Option 11 and 17.

– The ‘Secure Boot’ functionality of UEFI is only supported if the PVS Targets are physical devices. For VMs, the ‘Secure Boot’ feature must be disabled (it is enabled by default for Gen2 VMs on Hyper-V, for example)

– XenServer does not support UEFI boot of VMs hosted on it (as of XS 7.1). Hyper-V supports it but it requires that you use Gen2 VMs and Synthetic NICs on the VMs, and only x64 operating systems on the VMs. VMWare ESX 5.0 and higher support UEFI target boot.

– Citrix PVS 7.7 added support for TFTP/PXE booting of UEFI devices, while PVS 7.9 added support for BDM boot of UEFI devices.

– The boot menu on devices that allows you to choose a specific vDisk, for example, is not available with UEFI boot. A maintenance version of the vDisk will be chosen over a test or production version by default.

If you have any questions or comments about above, feel free to either comment here or email me at Rasmus.Kindberg@xenit.se.



Filtering list in NetScaler and converting to XML using Policy Extension – v2

As I’ve stated, my knowledge of Lua and development is very limited. My good friend Ulrik pointed out to me that the code I was using (in my previous blog post) wasn’t optimized and helped me get it both faster and easier to understand. It’s actually works better and is about 21 times faster (the last one took about 533 437 nanoseconds/0,5ms to process and the new one takes 25 278 nanoseconds/0,025ms in my tests).

The Lua code:

A few things to note:

  • The last one did actually take the input and match it to lower, so if you entered ”Group” instead of ”group”, it didn’t work.
  • The processing used another function, which I’ve removed
  • I’ve tested this one with pattern matching for example ”SG-AD-SAML-User” etc.

If a user is member of the following groups:
Group1, Group2, Grupp1, Grupp2, SG-AD-SAML-User, SG-AD-SAML-User-Office365, SG-AD-SAML-Admin ABC, SG-AD-SAML-Admin-Office365, SG-AD-Role-Employee

And we want to extract everything that contains -AD-SAML-, we’ll use an expression like this:

This will output all the groups containing ”-AD-SAML-” into an XML-list  with the tag ”xmltag” like this:
<xmltag>SG-AD-SAML-User<xmltag></xmltag>SG-AD-SAML-User-Office365<xmltag></xmltag>SG-AD-SAML-Admin ABC<xmltag></xmltag>SG-AD-SAML-Admin-Office365</xmltag>

As always, please leave a comment if you have any feedback!



Filtering list in NetScaler and converting to XML using Policy Extension

UPDATE: Updated the Lua-code, which seems to work better and is about 21 times faster. Big thanks to Ulrik! You can find the updated code here.

There was a question on the Citrix discussion forums where an administrator wants to output the groups a user is member of in a SAML Assertion, but with the caveat that only groups with a specific names should be included.

In this case the following expression is usually used: HTTP.REQ.USER.GROUPS_AS_XML(”xmltag”)

I was thinking about it and couldn’t figure out what the easiest way to do this was, so I started thinking about Lua since it’s extremely flexible and it’s fun learning new stuff. (the NetScaler developers helped me last time with a bug in the JSON-parser – see this post.)

Since I’m no developer myself, and my Lua-knowledge is very limited (at best), I started trying it out using an example Citrix have written.

The result:

When you’ve imported the policy extension, you can use it like this:

In my case, the output for HTTP.REQ.USER.GROUPS would be:
group2,group1,grupp2,grupp1

When using the policy extension, the output is:
<xmltag>group2</xmltag><xmltag>group1</xmltag>

Now remember, the above is an example and should as always be tested (and most likely optimized) before being used in production. But it works (at least in my lab) and it’s really cool to be able to modify the functionality of NetScaler this easliy.

Do you know of any way to do this without policy extensions? Or do you know Lua and there’s a better way of doing the policy extension?



SCCM source cleanup inventory

As applications are retired in SCCM the source tend to build up due to human error or retention policy. Either way admins should perform cleanup of the source directory from time to time.
The below script lists all files and folders in the source directory that does not have any active connection in SCCM.

To run the script first open Configuration Manager Console and press ”Connect via Windows Powershell”