Syspeace 2.7.0 released

Syspeace 2.7.0 is a highly recommended update.

  • It introduces improved support for detecting RDP login failures where the IP addresses are missing in the event log entries. For details, see the separate post A comprehensive approach to detecting RDP login failures.
  • It includes a setting to mitigate repetitive “success” login entries on file servers caused by file server activity instead of authentication.
  • It improves compatibility, including using TLS 1.2 when .NET Framework 4.5 or later is installed – a PCI requirement.
  • It includes the ability to export entries out of and import entries into the local blacklist via copy and paste.
  • Last but not least, it fixes several issues, including an issue that caused the Syspeace database to be larger than it needed to be.

Read the full list of changes or download Syspeace to start a free 30-day trial today or to upgrade.

Syspeace 2.7.0 runs on Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2 and 2016.

A comprehensive approach to detecting RDP login failures

Syspeace’s way of detecting Windows logon failures is based on using the audit events produced by Windows. This is reliable and non-invasive, but in some cases there are oddities.

When a login succeeds or fails during Remote Desktop/Terminal Services authentication during authentication with the TLS/Negotiate layer (a newer way of authenticating), the event is logged, but there is no reference to the IP address of the remote computer. Without this, Syspeace would not know who to block in case the login failure is part of a pattern that would be blocked. There are workarounds like using the RDP Security Layer (an older way of authenticating) to force Windows to use another piece of code that will include the IP address information, but our customers are finding that they don’t wish to use this.

Syspeace 2.7.0, available today, brings a comprehensive solution to this problem.

In Windows Server 2003, only RDP Security Layer (the older way of authenticating) is available, and therefore the problem does not occur. In Windows Server 2016, the oddity has been fixed – the event does include the IP address once again, and therefore the problem does not occur.

In Windows Server 2012 and 2012 R2, the oddity can be fairly easily corrected due to the fact that the missing information is present in different logs. Syspeace has all the information it needs by reading supplemental events. Our algorithm for doing this is improved in Syspeace 2.7.0.

This leaves Windows Server 2008 and 2008 R2, where there are no supplemental events. What are we to do?

There is a solution that is very roundabout, but that nevertheless provides us with the hints we need to be able to supply the IP address. That solution is to open a network socket and literally listen to all the incoming packets, filter down to just the packets on the RDP port and extract the information about the relevant IP address out of the structural header information.

So starting with Syspeace 2.7.0, Syspeace will be capable of using the strategy above with these caveats:

  • You must opt in by turning on a setting called “Traffic-based Remote Desktop/Terminal Services IP detection”. You must turn this level of protection on for yourself. It is not turned on by default.
  • The code that does this runs in another process, Syspeace.SpecialRdpDetector.exe, both for isolation and performance reasons. If you turn off the setting, the process shuts down. If you turn on the setting, it starts back up again. It is there to do this one job. If you so wish or deem necessary, you can delete this executable and prevent it from ever being used. (If you do, the setting will naturally be disabled.)
  • Syspeace.SpecialRdpDetector.exe is not obfuscated. If you so wish or deem necessary, you are able to verify that the code does what we say it does.
  • In fact, the code for Syspeace.SpecialRdpDetector.exe is available upon request.

This is our way of being pragmatic about this issue while tending to the needs of our customers. As a security product, we will need to do things that require administrative privileges and having deep access to our customers’ systems. But we are always careful to be as non-invasive as possible and to never help ourselves to information that does not directly advance the cause of protection. We aim to do the minimum possible work to get the job done and we aim to treat our customers and their servers with respect, and provide the product that behaves in the way that we, as customers, would like it to behave.

Why Syspeace uses SHA-2 and important notes for Windows Server 2003 users

As of today, September 2, 2016, we have switched to using a SHA-2 SSL/TLS certificate for this web site, our Syspeace Licenses site used to manage and purchase licenses, as well as our backend server used by the Syspeace application. The SHA-2 hash algorithm is a newer and more robust hash algorithm than SHA-1, as previously used – SHA-1 has been globally deprecated for years, and since the beginning of 2016, no new SHA-1 certificates are issued by trusted Certificate Authorities.

SHA-2 is unsupported in Windows Server 2003 and 2003 R2, leading to the following:

  • Syspeace users on Windows Server 2003 will have to upgrade to a special Windows Server 2003 variant of Syspeace 2.6 that uses a self-signed, privately issued SHA-1 certificate to maintain the current functionality. This version, along with a special information page, has been available for weeks and we have contacted the affected Syspeace users with this information.
  • Access to any of the affected web sites may be restricted from the versions of Internet Explorer compatible with Windows Server 2003. We recommend using an alternative browser like Chrome or Firefox, or a different computer.

For these reasons, the renewal to the new certificate was done at the last moment (our previous certificate expires on September 3, 2016), to give our customers more time to adjust.

Syspeace now offering discounts for tax-exempt nonprofit organizations

We are proud to announce that we now offer discounts to tax-exempt nonprofit organizations (for example 501(c) organizations in the US). For more information, contact us.

Syspeace Windows Server 2003 Support Policy

The current major release of Syspeace (2.x) will continue to be supported on Windows Server 2003 and Windows Server 2003 R2. We may introduce major new releases of Syspeace that will not run or be supported on Windows Server 2003 and Windows Server 2003 R2.

Microsoft’s extended support for Windows Server 2003 and Windows Server 2003 R2 ended on July 14, 2015. Our recommendation is that you, if possible, run a version of Windows Server currently supported by Microsoft and install all critical security fixes.

Syspeace not starting due to database too large

Update: This problem is fixed as of Syspeace 2.7.0. Please upgrade to the newest version of Syspeace instead of employing the workaround detailed below.

With the current version of Syspeace the error where the Syspeace GUI can’t be started and Syspeace crashes is due to its database sometimes growing too large.

When the database called SCDB1.sdf  (located in the Syspeace installation directory) grows above its built in limit of 4 GB, Syspeace stops working and the GUI can’t be started, nor does Syspeace block any new brute force attacks.
This is due to a limitations of database growth and the way Syspeace stores entries within the database in the current version.

Solution / Workaround

The easiest way to work around this limitation is to stop the Syspeace service and simply delete the database and set up your rules and settings again. This will mean setting up your whitelists, entering license number, rules and so on.

Preparing for this scenario

It is easy to be prepared for this though. Simply export all of the Syspeace settings using the Syspeace GUI (Export settings/ and click the “Check all” in the top right) and keep the DefaultSettings.syspeaceSettings in the Syspeace installation folder. Remember to do this every time you apply changes to your settings.
This will speed up the workaround / fix from the aspect that you only need to stop the Syspeace service, delete the database that and then restart Syspeace thus having it automatically import all of your settings.

There is also the advantage of being able to distribute the DefaultSettings.syspeaceSettings-file to other servers in case you have multiple installations or you’re planning on expanding your Syspeace usage.

Simply install Syspeace on the next server, copy the DefaultSettings.syspeaceSettings to the installation directory and your configuration is set to the same parameters as the first one, including whitelists, license number, email settings and so on.

New resellers in Australia and Germany

Your IT Business Consultants are the newest of our seven resellers.

Your IT Business Consultants Pty Ltd will provide Syspeace licenses in Australia.

See all of our resellers, or read about becoming a reseller yourself.

Felsökning Syspeace

1. Se till att den lokala brandväggen är igång och påsslagen för all profiler enligt manualen.

2. Se till att loggning för in och utloggningar är på enlit manualen.

3. Verfiera att servern kan nå där du du borde få upp ett hälsninsgmeddelande från Stockholm.

4 I visssa fall misslyckas Windows Serevr sjäkvt med att logag IP adressen och då kaninte helelr Syspeace hantera intrångsförösket. Se den här länken för tips på felsökning

5. Trafik till om ni har en annan brandvägg eller antivierus som kan tänkas blockera trafiken. Verifiera genom attstarta en webbläsare och kontrollera ni kommer fram. I vissa vfall måste även Syspeace filerna exkluderas från kontroller.

6. KOntrollera evetneulla proxyinställningar

7. Vissa metoder av Windows inloggningar generar i praktiken flera inloggningar. Två förösk i säkerhetsloggan kan alltså egentlien vara en del av samma inloggning. Syspeace kan inet avgöra hur många förösk som egentöligen avsågs utan kan bara hanetra det fakltiska antalet inloggningar i säkerhetsloggen. P-g-a- detta kan det i särfall hända att en blockering startas till sysnes för snabbt. I de fall rekommenderar vi att ni ser över reelerna i Syspeaace GUI.

8- Ett sätt att snabbt verifera funktionalitet efetr en installation är att medvetet göra en lösenordsatatck från en arbetstation (som inet är vitlistad ) mot servern med net use * \\serevrnamne\c$ /user:syspeacetest “”
Beroende på vilka regler ni satt upp ska arbetstationen blockeras per automatik efter det uppnådda antalet misslyckade försök.

9 Om ni behöver skicka loggar till oss för diagnsotik: Stoppa Syspeace tjänsten, starta Syspeace GUI, klicka på Managamenet, System Settingoch klicka i “Enable Logging” och starta tjänsten igen. Loggar komme skapa i en underkatalog till Syspeace installtiionen.

10. När ni skickar loggar. Skapa en .zip fil av alla kataloger och skicka med relevant information om operativsystem, eventuella fel i Windows loggar och skapa även en .zip fil av databasen scdbf1.mdb. Kontrolelra också att er .NET är korrekt uppdaterad.

11. Om databasen vuxit över 4 GB i storlek komemr Syspeace att stanna i nuvarande version,. Enklaste sättet att lösa detta är stoppa tjänsten, radera databsen och sätta upp Sysoeace på nytt med samma licensnummer. Om ni vid installtionen har exporterat inställningarna för Syspeace är det snabbt gjort att åetrskapa allt. I version 2.8 kommer probelemt med växande datrabaser att vara bättre hanterat.

Felsökning för Syspeace när IP adressen saknas i eventid 4625 och 529

Syspeace är ett HIPS (Host Intrusion Prevention System) som övervakar misslyckade inloggningar bl.a. login event 4625 och 529, på Windows
ufcorp backup disaster recovey kontinuitetsplaner IT säkerhet molntjänster syspeace

Ibland loggas inte IP adressen med i samband med den misslyckade inloggningen ( login event 4625 på Windows 7 och uppåt och Windows Server 2008 och uppåt, eller login event 529 på Windows Server 2003 och några andra säkerhetshändelser som vi övervakar) vilket gör att Syspeace inte kan blockera källan p.g.a IP-adress saknas. Fältet är helt enkelt tomt.
Om det inte finns någon IP-adress för att blockera, kan den inte sättas in de Windows brandväggsregler som Syspeace använder och lösenordsattacken kan fortsätta. (Istället för att blockera automatiskt av Syspeace )

Detta händer när du byter från RDP Layer Security till att använda ett SSL certifikat.

En artikel på Stackoverflow kan peka på en lösning.

I princip är förslaget att ändra denna inställning i Lokal säkerhetsprincip på servern som kör Syspeace.

Computer ConfigurationWindows SettingsSecurity SettingsSecurity Val

– Nätverkssäkerhet: LAN Manager-autentisering nivå – Skicka endast NTLMv2-svar. Vägra LM & NTLM
– Nätsäkerhet: Begränsa NTLM: Revisions Inkommande NTLM Traffic – Aktivera revision för alla konton
– Nätsäkerhet: Begränsa NTLM: Inkommande NTLM trafik – Neka alla konton

En liten varning dock!
Om du använder RD WEB också publicerar Remote Resources till andra operativ än Windows!
Av någon anledning, kommer Mac OS klienter sluta se fjärresurser eftersom de verkar köra på NTLM version 1 (och jag skulle gissa Android och XP)

Även skannrar kan sluta fungera lokalt om de behöver för att skriva filer till en nätverksdelad katalog med NTLM icke tillåtet

Jag testade med att ändra nedanstående och då slutade resuserna att publiceras till just MAC och iPad som kör RD Client och använder Remote Resources
Nätsäkerhet: Begränsa NTLM: Inkommande NTLM trafik – Neka alla konton,

Det finns några varningar vid byte här inställningen och du bör undersöka om det finns program eller tjänster i din servermiljö som är beroende av LM eller NTLM (v1).

Inbyggda metoder att skydda sig mot lösenordsattacker i Windows och varför de inte fungerat

Lösenordsattacker ( eller ordboksattacker , bruteforce attacks och dictionary attacks ) förekommer garanterat på de flesta servrar som är nåbara från Internet, var sig det är Windows, Linux, Netware eller Solaris. Attacker kan också komma inifrån företaget.

Principen bygger på att gissa sig till en användares användarnamn och lösenord genom att helt automatisera försöken med långa listor / ordböcker med variationer på ord .
Skydd mot bruteforce försök specifikt på Windows-servrar har alltid varit en mardröm och skulle fortsätta att vara så om inte det äntligen fanns en kostnadseffektiv och väl fungerande lösning med Syspeace

De flesta systemadministratörer med självrespekt börjar med de bästa avsikter att faktiskt hålla koll på lösenordsattacker och andra larm men så småningom ger de upp på grund av det stora antalet attacker som sker dagligen. Vi kan prata om hundratals attacker. Per dag.

Andra systemadministratörer tror att en brandvägg tar hand om problemet eller att en sk account lockout policy är lösningen.
Ingen av dem är det och jag tänkte belysa varför nedan.

Brandväggen för att spärra attacker
Vad gör en brandvägg egentligen ? Brandväggens roll är att blockera trafik på oönskade portar och att neka portscans och olika SYN flood attacker. I vissa fall kan den även söka efter virus i trafiken så länge trafiken är okrypterad.
Det är ungefär det en brandvägg gör. En brandvägg är i grunden en dörrvakt avgöra vem som får in för att snacka med killarna på insidan och vem som inte får det.
Om en angripare ansluter på en giltig port (t.ex. https på port 443 ) , vidarebefordras det till servern ifråga t.ex webbmail gränssnittet på en Microsoft Exchange Server eller Microsoft Windows Terminal Server eller Citrix-server.
När angriparen kommit fram så inloggningsbegäran lokalt av servern, inte brandväggen. Inloggningsprocessen hanteras av Windows Authentication processen (som i sin tur kan valideras mot Active Directory eller en lokal användardatabas med hjälp SAM).
Brandväggen är redan ute ur bilden verkligen eftersom den inte har något samband med Windows servern förutom TCP-anslutning och hålla den sessionen vid liv egentligen.
De kommunicerar inte resultatet av inloggningsprocessen mellan varandra.

En annan metod man använder ibland är en ändring från standardportar .
Inloggningsprocessen hanteras fortfarande av Windows Server även om du kommer att bli av med många portscans och “lata bakgrundsförsök” om du använder icke-standardportar.
I grund och botten du bli av med script kiddies men problemet är inte löst. Trafiken omdirigeras/port vidarebefordras fortfarande till servern som gör den verkliga autentiseringen och en hacker som vill ta sig in nöjer sig inte med att bara söka efter standardportar utan kommer även hitta de ”dolda” portarna med olika verktyg som telnet , nmap .
De är ju publikt tillgängliga.

Använda Remote desktop gateway elller ett sk DMZ
Använda till exempel en Remote Desktop Gateway kommer inte att hantera problemet heller.
Med hjälp av en RDP Gateway minskas exponeringen för attacker till fler servrar på insidan av brandväggen men det är fortfarande nåbart och användarinloggningar måste valideras fortfarande.
Grundproblemet är att validernigen av inloggningen fortfarande sker lokalt på servern, oavsett på vilka portar och hur de kommer dit. Det gäller Microsoft Windows Server, Exchange Server, Citrix, Sharepoint, CRM, Terminal och RDS Server och så vidare. Listan kan nog gå göras hur lång som helst .

Risker med att ändra standardportar
Det finns också risk för saker slutar fungera när du installerar några uppdateringar eller patchar till dina Windows Servrar om du börjar ändra standardportar eller standardkonfigurationer.
Det har hänt mig några gånger och det är inte så roligt att vara ärlig när man har 1000 användare inte kunna logga in bara för att du gjort det du ska. Tro mig, det är inte en bra måndag morgon.

Att skydda sig med VPN
Ja. Det är en säkrare metod men här finns också några problem.
Först av allt, det är inte så lätt att hålla reda på VPN-certifikat, sätta upp och hantera alla licenskostnader (som kan vara ganska betydande riktigt) och (ibland kostsamma) hårdvara du behöver ha på plats. Historiskt har det också alltid varit prestandaproblem med de flesta VPN-lösningar, eftersom all trafik leds genom en eller ett fåtal VPN servrar.
Några av dem tar betalt även för den bandbredd som du vill att det ska kunna använda för VPN-anslutningar eller ta betalt för antalet samtidiga VPN-anslutningar, kan en VPN-lösning vara ganska dyrt som en nyinvestering och med hänsyn till all administration inblandade i den.
Ett annat problem som kan finnas är att man tillåter all trafik genom en VPN in till företagets nät vilket kan vara riskabelt om arbetsstationen blivit hackad. Den kan då t.ex. genomföra lösenordsattacker från ”insidan” av nätet och det är inte alltid man tänker på att skydda sig även mot inre hot.

VPN och tillgänglighet för webbmail
Du vill kanske inte heller att kräva att dina användare har en VPN-anslutning till Microsoft Exchange OWA eftersom hela idén med OWA är att den ska lätt att nå från var som helst. Även från en flygplats.
Jag vet att det finns några företag som faktiskt kräver VPN även för OWA och det är bara bra antar jag, men ju mer vi flyttar våra data och applikationer till molntjänster, kommer detta krångel med olika VPN och krångligheter så småningom blekna in i de mörka hörnen av Internet (det är min personliga övertygelse ändå).
Saken är den att dina användare inte vill vara bundna av komplicerade VPN-klienter. Användarnas syn är ”det ska bara fungera att arbeta” och det måste vara enkelt och intuitivt för dem. De dagar då “System Administratörer från helvetet” kunde genomföra alla typer av komplexa lösningar för att hålla saker säkra och tvinga användarna att ha mycket specifika och komplexa sätt att komma åt data är över.

Antivirus som skydd
Nej. Ett antivirus söker efter skadlig kod som trojaner och andra virus på servrar och hanterar dem Ett antivirus har inget med inloggningar att göra.

Att skaffa en hårdvarubaserad IDS/IPS eller t.ex. SNORT
Med hjälp av en centraliserad och specialiserad IDS/IPS kan man fånga mycket saker
Detta är en mer effektiv metod, ja.

Nackdelen är, de flesta av dessa system kräver att du ändrar din infrastruktur och får specifik och kostsam hårdvara, licenser och dyra konsulter för att implementera och planera projektet.
Någon måste sen också övervaka det, ta hand om det och så vidare.

Det finns paralleller till VPN metoden här även om en IDS/IPS gör mycket mer eftersom den undersöker all nätverkstrafik till och från företagsnätet, undersöker den för skadlig kod och så vidare.
Jag är inte säker faktiskt om en IDS/IPS per automatik kan kommunicera med Windows Server Authentication Process så jag ska faktiskt inte kommer att säga något om det.
Jag skulle förutsätta att de kan, annars har jag svårt att se poängen (från perspektivet med lösenordsattacker alltså). Om inte så skulle man ju fortfarande behöva hantera attacken på servern på något sätt.

Att låsa ute konton
I Microsoft Windows Server finns egentligen bara en enda inbyggd mekanism för att hantera den här typen av attacker och den kallas för Account Lockout Policy.
Account Lockout Policy metoden är också bristfällig på grund av det faktum att en angripare ganska lätt kan orsaka en DOS (Denial of Service) helt enkelt genom att hamra din server med ogiltiga inloggningar, men med giltiga användarnamn, vilket gör riktiga användarkonton oanvändbara för giltiga användare.
I grunden är allt angriparen behöver veta användarens inloggningsnamn. I många system och företag är det inte svårt att gissa sig till.
Prova t.ex. företagetsnamn\förnamn eller postadressen för användaren eftersom det är ganska ofta också ett giltigt inloggningsnamn.

Om en angripare gör detta från tiotusentals datorer samtidigt kan det effektivt helt lamslå ett företag eller en organisation och ingen kan logga in, varken utifrån eller på kontoret. Som en parantes kan nämnas att administratörskontot i Windows inte går att låsa så en angripare kan försöka hur många gånger som helst mot just det kontot viket de också gör.

Att använda sig av molntjänster
Vi flyttar mer och mer av våra data och applikationer till olika molntjänster. På det sättet blir vi av med några av de här problemen på våra egna servrar och förhoppningsvis, har din leverantör av molntjänster faktiskt en plan för dessa scenarier, rutiner och har den nödvändiga övervakningen och programvaran plats.
Om du använder en Cloud Computing-plattform baserad på Windows-servrar, ska du faktiskt fråga din leverantör hur de hanterar brute force försök på sina servrar. Troligtvis kommer de att ge dig en eller flera av de scenarier som beskrivs ovan och som jag har visat er, är de inte tillräckliga för att hantera uppgiften.
De är sällan förberedda på frågan ens. Fråga gärna din egen leverantör och se vilket svar du får. Min gissning är något svävande svar men i grunden har de inget på plats för att hantera lösenordsattacker.

Du kan även prova att logga in dig eget konto med ditt eget användarnamn, men fel lösenord massor av gånger och se vad som händer. Kommer det bli utelåst? Kommer din maskin låsas ut? Hur kommer din molnleverantör att reagera och kommer du informeras på något sätt att ett intrångsförsök har gjorts med hjälp av ditt konto? Hur många gånger kan någon försöka komma åt ditt konto utan att du blir uppmärksammad på det? Kan din leverantör även snabbt få fram om information om varifrån attacken skedde, hur många tidigare just den IP adressen har försökt ta sig in och liknande information utifall du vill polisanmäla?
Personligen vet jag bara en molntjänstleverantör i Sverige som tänkt på de här sakerna och det är Red Cloud IT.

Att hantera lösenordsattacker automatiskt med hjälp av Syspeace
Även om du väljer att inte använda det jag föreslår så rekommenderar jag ändå starkt att du börjar tänka på de här sakerna på rätt sätt, eftersom de här problemen kommer att eskalera i framtiden.
Ta bara en titt på alla hacktivism med DDOS-attacker som händer där ute. Det är bara en början eftersom Internet fortfarande är relativt ungt.
Först av allt, och det är oerhört viktigt att du förstår att det spelar det ingen roll om du själv driftar dina egna servrar eller om du använder VPS (Virtual Private Servers) någon annanstans eller ens om du är en molntjänstleverantör.
Den grundläggande principen står fast, om du ger någon form av tjänst till användare som använder Windows-autentisering så bör du läsa detta och förhoppningsvis har jag fått fram min poäng

Om du redan har brute force attacker mot dina Windows-system i dag och jag är ganska säker på att du redan har det (bara slå på loggningen i Windows och jag är säker på att du ser att du har mer än du faktiskt trodde, som en fotnot så är den här typen av loggning inte påslaget som standard i Windows.)
När du noterar en attack finns ett antal saker du måste göra

Först av allt. Blockera attacken.
Du behöver blockera attacken. Omedelbart. Detta är naturligtvis din första prioritet. På ena elelr andra sättet ska du blockera det i en brandvägg , antingen i den lokala Windows brandväggen eller i den externa, Välj det som går snabbast och lättast.
Man inte vill att slösa CPU och RAM och bandbredd på dessa människor (eller botnät) och naturligtvis, du inte vill att de ska faktiskt lyckas logga in på era servrar (om du har en usel lösenordspolicy på plats ) Du vill inte heller att man dölja ett riktitg intrångsförsök bakom en DDOS-attack för att fylla dina loggfiler och gömma sig där. (Ja, det är inte en ovanlig metod).
Det finns också en hel del rapporter om DDOS-attacker som används för att dölja den verkliga anledningen vilket är att ta reda på vilka säkerhetsåtgärder som finns på plats för framtida bruk.
Att känna sin fiende

Steg två . Spåra attacken. Varifrån kom den?
För det andra måste du ta reda på varifrån attacken har sitt ursprung och vilka användarnamn som användes. Du vill veta om det är en konkurrent som försöker hacka dig och komma åt dina företagsdata eller om du befinner dig i den lustiga situationen att det är ditt eget användarnamn som försöker logga från soliga Brasilien och du bara inte är i Brasilien (även om du skulle älska att vara). Du är i Bromölla och tittar på vinterslasket. Nånting är på gång.
Du vill också se om det är en tidigare anställd som försöker logga in. Det här är saker du vill veta och hålla koll på eftersom det kan finnas rättsliga frågor längre fram.
Punkterna ett och två, vill att du ska hanteras i realtid. Det finns ingen användning för dig att ta reda på två dagar efter attacken att något faktiskt hände. Du vill ha den stoppad, rapporterad och hanterad när det händer.

De juridiska aspekterna av en attack
Som ett tredje steg måste du bestämma vad du ska göra med vetskapen om attacken. Ska det överlämnas till advokaterna, din chef, polisen eller är det bara “ingenting” och kan kastas?

Att automatisera hanteringen av attacken
Det enklaste och mest kostnadseffektiva sättet att hantera brute force attacker mot Windows-server är att ha en automatiserat system att blockera, spåra och rapportera varje attack och det är där Syspeace kommer in i bilden

Syspeace är en lokalt installerad Windows-tjänst, som drar minst med systemresurser.
Den övervakar servern för oönskade inloggningsförsök och blockerar inkräktare i realtid i den lokala brandväggen utifrån de regler som du konfigurerat. Till exempel “om denna IP-adress har misslyckats med inloggning 20 gånger under de senaste 30 minuterna ska den blockeras helt i 5 timmar och skicka mig ett mail om det”

Detta innebär att du kan till exempel ställa in en blockerande regel som motsvara din Account Lockopu Policy men du höjer Syspeace till att blockera attacken innan din Account Lockout Policy slår till. På det sätet låses inte dina konton utifrån men du har ändå möjligheten att få konton låsta om de beter sig märkligt på insidan av företagets brandvägg.
Eftersom Syspeace övervakar Windows-autentisering och inloggningsprocessen spelar det ingen roll vilken brandvägg du använder eller vilka portar du använder. Övervakning, rapportering och blockering sker där själva inloggningsförsöket görs och därför fångas och hanteras automatiskt.

När en inkräktares IP-adress är blockerad, så blockeras den på alla portar mot den servern, vilket innebär att om du har andra tjänster som också körs på den server (som FTP, RDP, SQL elelr vad som helst) så skyddas också de tjänsterna direkt från angriparen. Angriparen kan alltså inte leta sig vidare till nästa tjänst och försöka hitta sårbarheter där. Det här är ett vanligt tillvägagångssätt utifall att en specifik programvara har skydd mot lösenordsattacker.
Vanligen kan de bara spärra angriparen för sitt eget program men inte för andra program.

Några andra funktioner i Syspeace
Några andra trevliga funktioner med Syspeace är till exempel GBL (Global BlackLlist) där varje Syspeace installation runt om i världen rapporterar varje attack till en central databas där de granskas och om en angripare bedöms ha attackerat tillräckligt många servrar och tillräckligt många kunder så sprids sedan den informationen till alla andra Syspeace installationer i hela världen. På så sätt är du skyddad i förväg när angriparna försöker hacka just din server. De kan helt enkelt inte ens kommunicera med den.
I Syspeace finns naturligtvis finns det vitlistor, vilket ger dig möjlighet att få dina kunder eller interna användare att aldrig blockeras. I sak är det inte så lämpligt kanske eftersom du nog vill veta att något ändå är på gång t.ex. att en av dina kunder eller användare blivit hackade

Det finns också Attack Control och Access Control som ger dig möjlighet att sortera ut information om framgångsrika och misslyckade inloggningar, hitta dem som försökt hålla sig under radarn, visa rapporter, sammanställa inloggningsmönster och platser för användare.
Du får dagliga och veckorapporter till dig per e-post och varje attack som blockera skickas till dig.
Informationen är tillräckligt detaljerad med från där attacken ursprung inklusive land, vilken användarnamn användes och hur många gånger de faktiskt försökt att hacka eller överbelasta dig innan samt när den IP adressen låses upp igen.
Det ger dig möjlighet att snabbt se om det är något du bör ta hand om eller bara fortsätta med din dag och låta det vara med ett leende på läpparna.

Gränssnittet är lätt att använda så det finns ingen anledning att anlita dyra konsulter att komma igång eller börja använda olika skript och ändra parametrar i dem för att passa dig behov och hoppas på bästa och hoppas att de inte hänger dina servrar. Med olika scripts finns också nackdelarna att du sällan har historik eller en Global Blacklist. De hanterar möjligen jus bara attaken men gör det väldigt svårt att få fram information i efterhand,