Att skapa en #molntjänst för era tjänster och applikationer #rCloud Office

Red Cloud IT logo
Red Cloud IT logo

Ett problemställning som många programföretag står inför är Molnet och hur de ska förhålla sig till det.

Att skriva om sin kod för att kunna stödja fler plattformar än den ursprungliga Windowsplattformen är oerhört kostsamt och komplicerat. I värsta fall måste precis all kod skrivas om, alla funktioner och allt tänkas om från grunden för varje plattform.

I praktiken har man fått börja om från noll.

Ett annat alternativ är att göra om sina applikationer till rena webapplikationer (tyvärr ofta med minskad funktionalitet) men kostnaderna för detta är också mycket höga och säkerhetsaspekterna är väldigt lätta att förbise.
Vem ska drifta sajten ?
Hur ser t.ex. övervakning och logghantering ut ? Backuphanteringen? Vet man att den man lagt sitt data hos är tillräckligt kunnig imon områådet ? Hur ser support och SLA ut ?

Tittar man på de SLA som finns på många ställen som erbjuder t.ex. virtuella servrar så inser man snabbt att deras anvsvar endast är att tillhandahålla en server-plattform och därefter är det kundens eget ansrvar att ta hand om drift, backuper, uppgraderingar, intrångsskydd o.s.v.

Att bara flytta ut sin applikation till en virtuell server eller ett webhostingföretag löser således inte problemet utan kan t.o.m. skapa nya och oväntade problem och frågeställningar kring drift och ansvar.
En incident som pekar på riskerna är naturligtvis det stora datahaveriet som inträffade för ett tag sedan och drabbade t.ex. Apoteket, Bilprovningen med flera.

”Portade” applikationer till web brukar också generellt innebära att man får göra avkall på väldigt mycket funktionalitet i sina program.

En annan fråga som inställer sig är också rent matematisk och ekonomisk. Kommer man få fler användare bara för man stöder fler plattformar som t.ex. MAC, iPad o.s.v. ? Eller har man redan uppnått det maximala antalet användare man kommer nå överhuvudtaget med sin produkt?

Är den marknaden mycket större tack vare fler plattformar?

I den andra vågskålen står att användare av ett program börjar leta efter alternativ eller tycker det börjar kännas förlegat med programmet som inte utvecklats på 10 år, även om det innehåller bra funktioner som är únika. Användarna käner sig bekväma med gränssnittet men kanske ändå börjar fundera över saker som plattformsoberoende.

Licensieringen är ett ytterligare problem.

Hur ska man kunna ta betalt för sin programvara mer än på det traditionella sättet? Kunderna är knappast intresserade av att stå för utvecklings och migreringskostander för att man behöver modernisera en produkt man använt i flera år men det måste ändå göras på det ena eller andra sättet om man tänker finnas kvar.

Kort sagt , man sitter lite i en rävsax.

Här kommer PaaS, SaaS och Red Cloud IT in i  bilden.

Genom att samarbeta med Red Cloud IT kan ett programvaruföretag flytta sina applikationer till en beprövad molntjänst med en minimal arbetsinstats.
Per automatik har man nu stöd för Windows, MAC, Android, iPad, Linux o.s.v. och licensieringsmodellen kan fortsätta vara densamma eller man tänker igenom sina modeller och moderniserar genom att börja ta betalt per användare och månad eller ännu mer granulärt om det finns behov. Programvaran behöver inte installeras lokalt på datorerna för användaran och finns således tillgängliga från varsomhelst.

Ni ger era kunder och användare omedelbar tillgång till era program.

Den ofta bristande kontrollen över antalet användare som använder programmen och licensfusk kan förebyggas enkelt.

Det här är en utveckling vi tror kommer att synas allt mer. Vi har redan idag ett antal programvaruföretag som ligger i vårt moln rCloud Office för att på ett enkelt och smart sätt kunna tillhandahålla sina applikationer till både befintliga och nya kunder.

Vi tror att de företag som inte börjar reflektera över de här frågorna kommer få problem inom några år och även i förlängningen kommer att tappa kunder.

Kontakta oss för att diskutera lösningen på just era funderingar

#infosec Troubleshooting #Syspeace and why source IP addresses aren’t always resolved by #Windowsserver in eventid 4625

Syspeace is a HIPS (Host Intrusion Prevention System) that monitors failed logins attempts on for instance Remote Desktop Servers, Exchange Server, SQL Servers, Winlogon events on Windows Servers from Windows Server 2003 and more and blocks, tracks and reports the attacker based on customazible rules

Sometimes though, the event (Eventid 4625 or eventid 529 and a few other security events we monitor) doesn’t actually contain the source IP address thus leaving Syspeace with nothing to block.
If there’s no IP address to block, it can’t be put into to the Windows Frewall Syspeace rules and the bruteforce attack can continue.

This essentially happens when you switch from RDP layer security to using a certificate.

An article on Stackoverflow might be pointing to a solution though

http://stackoverflow.com/questions/1734635/event-logging-ipaddress-does-not-always-resolve

Essentially, the suggestion is to change this setting in the Local Security Policy of the server running Syspeace.

Computer ConfigurationWindows SettingsSecurity SettingsSecurity Options

– Network security: LAN Manager authentication level — Send NTLMv2 response only. Refuse LM & NTLM
– Network security: Restrict NTLM: Audit Incoming NTLM Traffic — Enable auditing for all accounts
– Network security: Restrict NTLM: Incoming NTLM traffic — Deny all accounts

Here’s a warning though!
If you’re using the RD WEB also to publish Remote Resources.
For some reason , your MAC OS clients will stop recieving Remote Resources since it seems to run on NTLM version 1 (and I would guess Android and XP too )
Also scanners may stop working locally if they need to write files to a newtorks share
I tried a lab with this and when seting the – Network security: Restrict NTLM: Incoming NTLM traffic — Deny all accounts , the remote resources can’t be refreshed.

There are a few warnings when changing this setting and you should investigate if there are applications or services in your server environment that are dependent on LM or NTLM (v1).

I’ve changed the setting on a number of servers and haven’t seen anything stop working but still you should investigate before changing.

Syspeace - intrusion prevention for Windows servers
Syspeace website

Troubleshooting Syspeace

An interesting support case came to our attention recently.

A customer claimed that Syspeace wouldn’t block according to the rules.

The bruteforce attacks would continue , even after they should have been blocked.

We checked the ususal culprits (verify that the .Net is fully patched, that the customer is running the latest Syspeace version, verify that logging is enabled and that the firewall is turned on )

The rules were added as expected in the firewall but they didn’t have any effect.

After a lot of troubleshooting the root-cause was found.

The customers server did indeed have the firewall enabled but only in one of the firewall profiles (public, private, domain) and unfortuantely, the network used was not the one the firewall was enabled for, hence, nothing was blocked as expected. The rules were added but did not take effect in the expected amount of time

So, as a general troubleshooting tip , check how your firewall is enabled and verify that it indeed is the correct network profile in there, or, enable the firewall for all three profiles.

The usual troubleshooting tips we give are described in the manual in the troubleshooting section

1. Make sure you’ve enabled the firewall (as described in Firewall), firewall enabled, prefferably on all profiles.

2. Make sure you’ve enabled the auditing (as described in Windows login detection prerequisites).

3. Verify that the server can reach https://s.syspeace.com/ping . (You should see a message saying Hello from Stockholm. and the local time of the server and recommended Syspeace version)

4. In some instances, when running Terminal Server or Remote Desktop Services there’s actually the scenario where the Windows server itself fails to obtain the source IP address of the login attempt (you can verify this by checking the Windows event log and look for Source Network Address: ) Sometimes, that entry is empty, thus disabling Syspeace from actually having anything to block. Syspeace will attempt to corroborate the IP address from some other logs. If it doesn’t find any, there is not much that Syspeace can do.

5. In any applicable firewall or antivirus software, allow Syspeace access to https://s.syspeace.com/ (port 443).

6. Verify any proxy settings, if applicable.

7. Some methods of Windows authentication actually attempts to log in several times. Two failures may be part of one log in attempt. Syspeace has no way of knowing how many attempts were intended and has to work with the actual failures. Due to counting failures instead of attempts, rules may be triggered seemingly ahead of time.

8. One way of quickly verifying functionality is to use a workstation (not whitelisted) and attack your server with the net use command from the command prompt. After the number of tries defined in the current rules, the workstation should be blocked from communicating with the server. Example of the command: net use * \server name or server IP addressanyshare /user:syspeacetester ”anypassword”

9. If you want to submit logs to us, start Syspeace, go to Management → System settings, enable logging and start the service. The log file is created in a subfolder of the Syspeace installation folder.

10. When submitting logs,
Please create a .zip file of the logfiles, include any relevant information from Windows Eventlogs (application, system and security and when applicapble, the Syspeace eventlog ) and also create a .Zip-file of the database and email them directly to the devteam . The email address can be found in the manual

11. If your server doesn’t pick up the source IP address in your eventlog , please have a look a this blog article

12. If your database has grown above the size limit of 4 GB, in the current version ( 2.5.2) you will have to manually delete the database and set up your Syspeace again. in the upcoming version this has been fixed.

by Juha Jurvanen

#msexchange Brute force attacks prevention on #Webmail #OWA with #Syspeace #hacking #security

Syspeace icon
Syspeace icon

Preventing brute force attacks against Microsoft Exchange Server and OWA Webmail

If you’re running Microsoft Exchange Server your also quite likely to have the Microsoft Exchange OWA (Webmail)
interface up & running to enable your users to use Activesync and access their email, calendars and contacts
over an easy-to-use web interface accessible over the Internet. This is just as relevant if you’re managing your
own Exchange Server or if it is a hosted Exchange at a service provider. If your provider doesn’t have a
solution for this, you may find yourself in a very difficult situation one day as explained further down.
Since the Exchange Webmail (OWA) is reachable and visible over the Internet, this of course also means that
anyone is able to try to log in to your Exchange server over the same OWA interface. They may not succeed to
login but they may try to overload your server by sending lots of login request or have your users undergo a
Denial of Service attack (a DoS attack).

Brute force attacks used as Denial of Service attacks

The OWA in itself (or does Windows Server for that matter) doesn’t have any brute force prevention mechanisms
built into it but the actual user validation is done within the Active Directory infrastructure by your domain
controller(s). Within the Microsoft line of products this is actually true for most of them such as Terminal
Server (RDS, Remote Desktop), Sharepoint, SQL Server and so on and also for Citrix since user validation is done
in the same way.
If you have for instance set up Account Lockout Policies to disable a user account after 5 failed attempts ,
anyone with knowledge of your name standards (email addrees, AD login) can basically run a script against the
server using a specicif username (or hundreds of them) and deliberatley usoing wrong passwords, thus locking the
legitimate users account and disabling them from loging in at all (in essence, they can’t even login to anything
that uses the Active Directory validation, not even their own workstations in the Office)
If such an attack is made from a single IP address, it is fairly easy to block it manually (simply block the
attack in either the external firewall or the local firewall of the Exchange server).
In reality though, this is not how such an attack occurs. Should someone really want to disrupt ypur services,
they will do this from hundreds or thousands computers at the same time and making it impossible to block
manually.

Using Syspeace as a countermeasure

With Syspeace , this is all taken care of automatically. Syspeace monitors the Windows Serevr logs for failed
login requests and if an IP address tries to login against your servers ( Exchange, Terminals Server and so on)
and fails for instance 5 times within half an hour, the IP address is automatically blocked from communicating
at all with the affected server on any level (so if you’re also running other services , they will not be able
to target them either once blocked).
Each attack is blocked, traced and reported via email that contains the source IP address, the username used,
country of origin and previous attacks from the same IP address.

Here is actually an example of how the email notification looks like (with IP address and domain name intentionally removed)
Blocked address *.*.*.* (ip-*-*-*-*.*.secureserver.net) [United States] 2015-01-14 18:45:00 Rule used (Winlogon):
Name: Catch All Login
Trigger window: 4.00:30:00
Occurrences: 5
Lockout time: 02:00:00
Previous observations of this IP address:
2015-01-14 16:44:50 ****lab
2015-01-14 16:44:52 ****labroator
2015-01-14 12:53:44 ****ron
2015-01-14 12:53:46 ****demo
2015-01-14 12:53:48 ****canon

Syspeace also delivers daily and weekly reports of blocked threats.

Within Syspeace, there is also reporting tools for access reports, a Global Blacklist for infamous offenders and
much more.

Installing and setting ups Syspeace

Setting up Syspeace is very easy and only takes a couple of minutes, without the need for changing your
infrastructure or bying very expensive dedicated hardware. Most likely , you will not even need to hire a
consultant for it.

Syspeace runs as Windows Service and support a variety of Windows Servers such as Terminal Server, Exchange Server, Sharepointm Windows Serevr 2003 to Windows Serevr 2012 R2 and more and it starts detecting brute force attacks immediately after you set it up and press the start button.

Please download a free, fully functional 30 trial from http://www.syspeace.com/free-download/download-plus-
getting-started-with-syspeace/
and see for yourself how a very big problem can be very easily solved.
Should you decide to keep using Syspeace, the licensing cost is equivalent to an antivirus product and the
licensing model is highly flexible, enabling you to decide for yourself ofor how long you wish to run Syspeace.

Syspeace - intrusion prevention for Windows servers
Syspeace website