Infrastruktur och serverdrift

Att sÀtta upp ett SPF record för att minska SPAM och bedrÀgerier

Vad Àr ett SPF record och hur kan det minska SPAM ?

JufCorp AB hjÀlper företag och föreningar med frÄgor inom backup / restore , Disaster Recovery, IT sÀkerhet, molntjÀnster och Syspeace SPF recordI princip fungerar SPF record  sÄ att nÀr ni skickar ett mejl sÄ kontrollerar den mottagande mejlservern huruvida mejladressen eller rÀttare sagt den mejldomÀn ni skickar frÄn, i mitt fall alltsÄ @jufcorp.com, verkligen fÄr komma frÄn den IP adressen den ska.

Ett inte ovanligt problem i vÀrlden Àr att det Àr vÀldigt, vÀldigt lÀtt att utge sig för att skicka ett mejl som nÄgon annan.
Det finna massvis med hemsidor som beskriver hur det gÄr till och de anvÀnder s.k. Open Relay servrar ute pÄ nÀtet och helt enkelt utger sig för att vara dig. Det stÄr alltsÄ era mejladresser som avsÀndare.

En varningsklocka för att det hÀnder er kan vara t.ex. att det helt plötsligt börjar trilla in en massa mejl med felmeddelanden om att mejl inte gick att leverera och ni vet att ni inte skickat dem.
Om man granskar mejlhuvudet lite nÀrmare sÄ inser man att nÄgon har anvÀnt era mejladresser som avsÀndare men IP adressen dÀr mejlet har skickats frÄn (d.v.s mejlservern) Àr nÄgot helt annat Àn den ni anvÀnder.

Ett problem som kan dyka upp nÀr sÄnt hÀnder Àr att t.ex. er ISP tycker att det har skickats alldeles för mÄnga konstiga mejl med domÀn som avsÀndare och bestÀmmer sig för att helt sonika stÀnga av er frÄn att mejla ut överhuvudtaget.

Att sÀtta upp ett SPF record för att undvika s.k. spoofade adresser och minska mÀngden SPAM och bedrÀgerier Àr oftast en bra idé alltsÄ.

NÀr en mottagande mejlserver fÄr ett mejl sÄ kontrollerar den huruvida avsÀndardomÀnen verkligen kommer frÄn den mejlserver som Àr ansvarig för mejl genom att kontrollera SPF record.
Om det inte gör det sÄ skickas ett felsvar tillbaka och mejlet tas helt enkelt inte emot (OBS , alla mejlservrar Àr inte instÀllda pÄ att kontrollera det hÀr, det Àr upp till serveradministratören att sÀtta upp kontrollen).

Det hÀr Àr dock ÀndÄ en finurlig mekanism som minskar mÀngden SPAM och att folk skickar mejl i ert namn (det kan ju som sagt vara rena bedrÀgerier det handlar om)

Att sÀtta upp SPF record och saker att tÀnka pÄ

SPF record sÀtts upp i din publika DNS servern d.v.s den Àr en del av din DNS domÀn som finns publikt tillgÀnglig.
Det Àr ett s.k TXT record och kan se ut sÄ hÀr

“v=spf1 mx a ip4:164.40.177.83 a:ch-p-mailout01.sth.basefarm.net”

I det hÀr fallet sÄ betyder det att alla servrar som Àr uppsatta som MX pekare (dvs mejlservrar) för den hÀr domÀnen fÄr mejla i domÀnens namn.
Den har Ă€ven tillĂ€gget att IP adress “164.40.177.83” samt hostname “ch-p-mailout01.sth.basefarm.net” ocksĂ„ fĂ„r skicka mejl med den hĂ€r domĂ€nen som avsĂ€ndare.

De flesta ISPr tillÄter inte att man skickar ut mejltrafik pÄ port 25 direkt utan man mÄste anvÀnda deras relay servrar . Anledning torde vara att minska mÀngden SPAM frÄn datorer med virus, hackers o.s.v. Port 25 Àr helt enkelt lÄst om den inte gÄr via ISPns relay servrar

Jag anvÀnder Com Hem som leverantör och de i sin tur anvÀnder sig av Basefarm.
För att mejla ut frĂ„n Com Hem sĂ„ anger man next hop server (d.v.s relay server ) “mailout.comhem.se” som egentligen bara Ă€r ett alias för “smtp.comhem.basefarm.net” med IP adress “164.40.177.47”.

Det som hĂ€nder efter det Ă€r att Basefarm i sin tur skickar den hĂ€r trafiken vidare till ytterligare en server dvs till “ch-p-mailout01.sth.basefarm.net” med IP adress “164.40.177.83” och det Ă€r den adressen som kommer att synas för den mottagande mejlservern.

AlltsÄ, nÀr man sÀtter upp ett SPF record mÄste man ha koll pÄ hur kedjan ser ut d.v.s vilken IP adress kommer mottagande mejlserver att se som avsÀndande mejlserver.
TÀnk pÄ att det kan vara en pool av IP adresser det handlar om (för redundans t.ex. )

Mm ni sitter pÄ t.ex. Com Hems nÀt sÄ Àr det ovanstÄende saker som ska in i DNS medans t.ex Telia och TDC och andra har andra IP adresser. Enklast Àr att ringa dem och frÄga vilken IP adress som Àr den sista i kedjan för utgÄende SMTP.

Ytterligare en sak att tÀnka pÄ kan vara att om ni har t.ex. ett webbformulÀr nÄnstans som mejlar saker till er (t.ex. ett kontaktformulÀr) sÄ mÄste den IP adressen eller hostname ocksÄ vara tillÄten att skicka mejl eller ni mÄste Àndra avsÀndande mejldomÀn till nÄgot annat.

Kontrollera att ert SPF record fungerar

Ett sÀtt att kontrollera om ditt SPF record Àr korrekt uppsatt eller om ni ens har Àr t.ex. att surfa till http://www.kitterman.com/spf/validate.html och skriva in ert domÀnnamn.
Den hÀr kontrollen kan dock inte veta vad som Àr den sista i kedjan utan slÄr bara upp huruvida det finns ett SPF record och om det ser korrekt ut vad gÀller syntaxen.
Ni kan ocksÄ testa hur det fungerar med raderna lÀngst ner i formulÀret genom att ange rÀtt IP adress och fel IP adress som avÀsandande mailserver för att se hur en mottagande mailserver skulle reagera.

Vill ni ha hjÀlp med dessa frÄgor eller andra inom mina omrÄden sÄ vÀlkommen att kontakta mig hÀr

Securing Windows Server with a baseline security

JufCorp AB hjÀlper företag och föreningar med frÄgor inom backup / restore , Disaster Recovery, IT sÀkerhet, molntjÀnster och Syspeace

Securing Windows Server with a baseline security

In short, to have an acceptable baseline security for any Windows server you need to think all of the things below in this list.
Sadly enough, even if you follow all of these steps, you’re still not secured forever and ever. There’s no such thing as absolute security.  That’s just the way it is but you might use this as some kind of checklist and also the links provided in this post.

 

Securing Windows Server with an acceptable baseline security

  • 1. Make sure all of your software is updated with all security patches. This includes the Windows operating system but also Adobe, Java,Office and any software really. This reduces the risk for so called 0day attacks or your server being compromised by software bugs.
  • 2. Make sure you have a good and not too resource intensive antivirus running on everything. Personally I’m a fan of F Secure PSB for Servers and Workstations for lots of reasons. It’s not just a pretty logo. If you need licenses or assistance, please feel free to contact me here
  • 3. Verify you have thought your file and directory access structure and that users and groups are only allowed to use and see what they’re supposed to. Setting file permissions is a very powerful tool to secure your server and crucial.
  • 4. Always make sure to read best practices for securing applications and servers and Google for other ideas also. No manual is the entire gospel.
  • 5. Enable logging. If you don’t know what’s happeing, you can’t really react to it can you ? It also makes any troubleshooting hopeless in restrospect.
  • 7. Have a good monitoring and inventory system in place such as the free SpiceWorks and I also recently discovered Sitemonitoring at Sourceforge that I liked. Unfortunately Sitemonitoring only works for HTTP responses , I’d love to also have it work for pure port monitoring.
  • 8. If your server has any monitoring agents from the manufacturer such as HP Server Agents, then install them and set them up with notifications for any hardware events to be prepared incas of hardware failures. If possible, also have spare parts readu for the common failures such as hard drives and PSu (Power Supply Units)
  • 9. Use Group Policies. It’s an extermely powerful tool once you start using it and it will make you day to day operations much easier.
  • 10. If your server is reachable from the Internet, use valid SSL certificates. They’re not that expensive and any communications should be encrypted and secured as fa as we’re able.
    Yes, think Mr. Snowden.Think NSA. There’s a few more things to consider when installing SSL on servers such as disabling weak cryptos and testing youÂŽv done so correctly. I like using SSL Labs free test.
  • 11. Disable any unused services and network protocols. They can be a point of entry and for the unused network protocols, you bascially fill your local network with useless chatter that comsume bandwidth. This also goes for workstations and printers and so on.
  • 12. Enforce complex password policies! You won’t be well-liked but that’s not what you get paid for.
    If people are having trouble remembering passwords the have all over the world, maybe you could have them read this blog post I wrote about rememebering complex passwords
    and on the topic of online passwords and identities, they migh also want to read this post about protecting your online identity  also.
  • 13. Use a good naming standard for user logins. Not just their first name as login or something too obvious. Here’s an old blog post (still on the Syspeace Blog site though )  on why
  • 14. Backups! Backups! and again. BACKUPS!!
    Make sure you have good backups (and test them at least once a year for a complete disaster revovery scenario) and make sure you have multiple generations of them in case any of them is corrupted, preferrably stored offsite in some manner in case of a fire, theft or anything really.For day to day operations and generation management I highly recommend using the builtin VSS snapshot method but never ever have it instead of backups.
    You can also use the built in Windows Server backup for DR as described here
  • 15. You need to have an automatic intrusion protection against brute force and dictionary attacks with Syspeace since the “classic” methods do not get the job done. Here’s an older blog post on why . I you don’t have the time to read the article then simply download the free Syspeace trial or contact me for licenses and consulting regarding Brute force prevention

If you’re up for it, I’ve written a few other related posts here:

Securing your datacenter part 1 – Physical aspects
and
Securing your datacenter part II – Networking

There’s also a third one but to be honest , I can’t remember where I published it. This is one of the reasons I’m moving basically everyting I’ve written to my own website instead . Easier to maintain .
Keep it simple and easy is alway a good approach. 🙂

By Juha Jurvanen @ JufCorp

Securing your datacenter – Physical aspects

Securing your datacenter - Juha Jurvanen JufCorp AB

A basic guide to securing your datacenter- part 1

This blog post is intended only as a basic guide to securing your datacenter and it’s a repost with some new stuff added into it. I also wrote a couple of follow ups to it that I will repost later.

It is not intended to be the gospel of security since, well.. let’s be honest, there is no such thing as absolute security.

As an example, in Sweden there was a case where a computer was locked in a vault, with no network access whatsoever and only a few people had access to it and still, it leaked information to foreign countries. Yes . a computer controlled by the military.

Absolute computer security is a myth and a beautiful dream. With that said, system administrators can still do a lot to make more difficult to access data and prevent attacks and sabotage to their systems.
Let’s start off with physical aspects .

The actual georgraphic location

Where is your server actually located and who has physical access to it?

Resetting administrator passwords or root passwords

Once you gain physical access to a sever, there are numerous way of accessing the data. The root password or Active Directory Domain Administrator password or NDS Admin password can be easily reset (yes, the sentence “easily reset” is used loosely) with a USB stick and booting the server. Have look a at for instance HIren’s Boot CD, Burglar for NDS or just play around with Google and search for terms such as “Reset administrator password”, “decrypt password” and so on .
You’ll be amazed when you realize how easy it actually is. Personally, I always carry with me some USB stick that enables me to boot up any system and “have my way with it”
So, we need to secure the server from outside access. The data center must be protected with card keys, cameras and access control. We need to who and why they are in the data center in the first place.For instance, a janitor or cleaning staff tends to have complete access due to what they do. Many companies hire outside help to get these kinds of jobs done.

Sabotage and disrupted data services

If I wanted to gain access to server, I would try to infiltrate one of those subcontractors to get a job as a let’s say janitor, and try to gain access to the data center somehow and from there, I can basically do what ever I wanted with the servers.
Maybe my goal wouldn’t be to steal data but to kill the data operations by corrupting the filesystems on the servers (for instance just “piping” data into various files from command prompt or hding files behind other files ), randomly switch disks on RAID systems or just put small holes in network cables to cause network errors, trigger an EMP in the data center and so on .
There would be numerous ways to disrupt the data operations, once i gained access to the data center or servers room.

Information theft

If I’m out to steal data, I would probably not target the servers themselves but instead I’d start looking for backup tapes or backup disks. Far too many companies have their backups in the same location as the servers themselves and since the backups usually are not encrypted , I’d go for stealing a complete backup set, go home and start doing a scan of the tapes to figure out what backup software was used and then do a complete restore of it all.
The backups are most likely to contain the data I’m after, although probably a maximum of 24 hours old but from them I can gain access to all kinds of information about the operations and crack administrative passwords for the server systems and so on . In the comfort of my own data center. or my couch.
This way would of require some skill of Disaster Recovery scenarios and how to get data back from backups but I’m fairly sure I’m not he only one in the world who has the expertise in those matters.

Backups are always a weak point from several aspects.

You need to know who has access to them , at all times.
If you are company that for instance have your backups shipped to another location on a daily basis or weekly, you need to know that people handling them haven’t been compromised. It wouldn’t take that long for anyone with the proper skills do clone your tapes or disks en route to their destination and you would have no way of telling they’d been cloned. In that scenario, all of your critical data would be in the wild, without you actually knowing it.

If you are using any kind of online backup service, remember to choose your encryption password wisely and be extremely restrictive with who has the password. A lot of backup software do not let you change the encryption password without doing the first backup all over again, thus doubling your usage of space and your costs.
Still , I highly recommend you use an encryption password for several reasons.
If you don’t use it, it’s just pure laziness and fear of administrative hassle and that’s just not an excuse. The risk of people at your online backup provider being able to access your data is of course also an obvious risk. Do you know these people and how could you be absolutely certain that they aren’t poking around in your data and maybe giving it to your competitors?

If you are thinking about online backups there are a few very essential questions you should ask yourself but we’ll get back to that later in another post.
Do not use the same encryption password as you have for Root / Administrator / Admin . ThatÂŽs just crazy talk. Use a password generator to create a unique password. This is also very much valid for tape backups or backups on NAS / disk. Always encrypt your backups with password and be very, very restrictive with who has the password.

If an employee quits your company or an outside consultant quits his project and he / she has had knowledge of the password, change it.

If you’re doing a planned Disaster Recovery test for instance, change the administrative passwords right after the DR test , thus not enabling anyone to reuse what they’ve found out during the test
During the actual DR test, you should be there and be the one that actually types in the encryption password for the backups, not any outside technicians or consultants , not even the online backup service provider or your Disaster Recovery Service Provider. You , and you alone should be the one that has those passwords.
I’ll will return to backup questions and stuff regarding DR plans and so further down the line in some upcoming blog post
So, the conclusion is, always know who and why people are in proximity of your servers and NEVER let anyone be there alone without supervision and here’s a few more pointers.

A short cheatsheet for datacenters

  1. Always have you data center locked and secured from unauthorized access, If you have the means, also have it secured against an EMP attack from the outside. Of course, I haven’t even touched the subjects but be sure your data center has all the necessary fire prevention/extinction equipment in place, UPS backups and , if possible, also an outside source for generating current in case the UPS or battery runs out of current. There should also be a system in place for protecting you servers against spikes in current.
    Be sure to know where water pipes are running in the building so you don’t place your server directly underneath one.
  2. Don’t keep cardboard or any other kind of flammable materials in the data center. Be sure to take them with you when you’ve set up a new server or switched disks. Don’t be lazy. The cost of laziness can be extreme.
  3. In the data center, always have your servers locked in cabinets that requires keys and access card to gain physical access to keyboards and stuff. Also remember to protect the cabling and the back of the servers! Never have a server logged on the console. Be sure to have all cabling to the and from the firewall and the internet access secured.
  4. If you’re “expecting company” i.e. external consultant and so on, be sure to think abut NOT having different kinds of network maps, administrative passwords and different kinds of information in plain sight for anyone to see. I’ve seen it hundreds of times, the IT department having their entire IT operations and information of their systems on white boards or on print on documents next to their workstations. It’s very quick and easy to take a picture of it with a cell phone and once you understand the infrastructure you can also start exploring weak points in it.
    Sure , it makes their lives easier but as one might gather, it also makes the life of the attacker easier. Knowledge is a powerful weapon, especially when it comes to data protection
  5. Don’t have software laying around in the data center with software keys and stuff on them . All it takes is a mobile phone for someone to coy your license keys thus possibly putting you in an awkard situation having to explain to Microsoft for instance how come that your Volume License keys are a bit too easy to find on Piratebay, thus putting you n the risk of your licenses becoming invalid and bringing your server operations to a halt , or at least a shoer disruption.
  6. Know where your backups are, at all times. Have them encrypted. If using online backup services, be sure to use an encryption key and , if possible, be sure to have restrictions on the online backup service providers end on to and from where backups and restores are allowed
  7. Do not allow mobile phones in the data center due to the risk of people photographing your equipment or software license keys or using the mobile phones to copy data via USB cables and stuff.
  8. If possible, disable any USB ports on your servers. This can be done in the BIOS (and of course also have a sysmtem password for accessing the BIOS, a unique one for each server ) or you can physically kill it by putting glue or semothing in there (I haven’t tried that myself so do try at your own risk .. )
  9. If you are sharing a data center with others, there is no need for you to have your company logo or anything revealing the servers are yours. Keep it as anonymous as possible. There is also no need for you to tell anyone where your servers are physically located (although it can be fairly easy for anyone to fin out using traceroute commands and so on ),
  10. Be sure to have a Disaster Recover Plan (DRP ) / Business Continuity Plan (BCP) if your site is compromised or an accident should occur. Also in this case, treat the secondary DR location as mission critical data. Far too often, the secondary site is forgotten and poorly updated.
  11. Once again, do not underestimate the powers of social engineering. Although it’s not hacking in the usual sense, it’s merely good acting but it can still be as harmful as I’m trying to point out here

So, there’s a few tips anyway and that’s just the start really. It’s not a complete recipe for securing your physical environment and I’m sure I’ve missed out loads of stuff but it’s a start anyways.

I hope you you liked this post and I’d love to hear you thoughts on it and if you want me to write a few others on the matters of securing your server operations, I was thinking in the lines of brute force protection, change management, 0day attacks, certificate management , password policies, protecting web servers and so on , You get the picture 🙂

// Juha Jurvanen

Contact me

Senior consultant in backup, IT security, server operations and cloud

Svenskt sjukhus förlorade data om 5000 patienter pga bristande backuper och övervakning 

backup Äterstartsplanering IT IT konsult IT sÀkerhet

De flesta företag och föreningar vet redan att backuper Àr viktiga att ha. I mÄnga avtal med externa leverantörer stÄr det ocksÄ att backuper ingÄr i deras tjÀnster.

Det som ofta inte stÄr och inte heller görs Àr faktiska Äterstartstester och kvalitetskontroller pÄ de backuper som tas.SÀrskilt inte av en oberoende tredje part. Det handlar sÄklart om att hÄlla kostnaderna nere.

Konsekvenserna dock av det kan ibland bli katastrofala pga detta. Vid ett haveri finns det flera aspekter att tĂ€nka pĂ„ som t.ex hur man ska meddela sina kunder, vart ska backupen Ă„terlĂ€sas, hur och vilken ordning och hur lĂ„ng tid fĂ„r det egentligen ta? Hur stor dataförlust, om nĂ„gon alls,  Ă€r acceptabel?

Dessa frĂ„gor och andra frĂ„gor kring  IT drift  Ă€r sĂ„nt jag hjĂ€lper företag och organisationer med.

Ett olyckligt exempel pĂ„ hur man misslyckats med sin Ă„terstartsplaner och backupövervakning finns hĂ€r i Computer Sweden nyligen. (exemplen Ă€r tyvĂ€rr vĂ€ldigt mĂ„nga men majoriteten kommer aldrig fram i dagsljuset)

Ett sĂ€tt att i vart fall minimera risken Ă€r att anlita en tredje part som hjĂ€lper till att hĂ„lla ett öga pĂ„ backuperna och Ă€ven hjĂ€lper till att planera och genomföra Ă„terstartstester för Ă¶vning och kvalitetskontroll.

Ny version av Wordfence för WordPress slÀppt idag

konsult inom backup It sÀkerhet molntjÀnster Ätersartsplaner för IT

SĂ€kerhet och WordPress

WordPress Àr en av de absolut största plattformarna idag för websidor och CMS. FramgÄngen ligger i enkelheten att sÀtta upp och alla tillÀgg och teman som finns till WordPress.

MÄnga installerar mÄnga olika tillÀgg och fÄr till sina sidor precis som de vill ha dem och tÀnker inte mer pÄ det.

I det hÀr sammanhanget kommer Wordfence tillÀgget in i bilden som ett verktyg för att fÄ larm och övervakning pÄ hur olika sÀkerhetsaspekter av ens WordPress mÄr.

Att installera Wordfence Àr enkelt och mÄnga av standardinstÀllningarna Àr bra. Det finns dock en hel del jag brukar Àndra pÄ nÀr jag installerat Wordfence.

En av de stora nyheterna i den nya versionen Àr Web Application Firewall som aktivt lyssnar efter olika typer av hacking attacker som SQL injection, XSS scripting o.s.v

Wordfence 6.11 finns att hÀmta hÀr

För de kunder jag övervakar och hanterar WordPress sÄ sköter jag sÄklart allt det dÀr.

Kontakta mig hÀr för frÄgor

NTLM settings and other fun labs searching for missing IP adresses in eventid 4625 or trying to get RemoteAPP to work well with RD Client on iPad, Android and even Windows!

konsult inom backup It sÀkerhet molntjÀnster Ätersartsplaner för IT

Using SSL causes mssing IP adresses in eventid 4625 and to get them back .. disable NTLM ? Nope. Not really an option

Today I took me a lab day to actually sit down and spend time with the NTLM settings and the RDWEB and try it out on various platforms and do some more or less scientific testing.
In short, I’Ă€m not impressed by how Micropsoft has actually implemented parts of ther stuff..

I used Windows 10, RD Client for IOS and RD Client for Android. The server infrastructure was a Windows Server 2008 R2 with valid SSL certficates for all services.

The underlying problem is basiaclly that if you use an SSL certificate for your RDP connections , failed logins aren’t correctly dispalyd , i.e. your missing IP adresses in eventid 4625. (When not using an SSL certficate , it is recorded but then your users and customers get a lot of warnings when connecting to your servers and some things just donĂ€t work very well sucha as the Webfeed for RD Web)

Syspeace is a Host Intrusion Prevention Software that uses this inormation about the source IP address to block brute force attacks against Windows Servers.

One way around this is to disable incoming NTLM traffic and sure enought , all IP addresses are recorded.

The downside is .. only “full” RDP connections will work meaning that for instance connections to a server desktop works fine but if you’re really into RemoteAPP (and that’s the way I want to go and a lot of tekkies with me) you’ll be running into problems.
And, by th way.. frankly, full desktop session don’t work either from IOS (at least remote Desktop Client 8.1.13 and my iPad, they do from Android though, same server, same username and so on)

Not even Windows really working correctly when disabling NTLM ?

I also did some testing for fun by creating a .wcx file and oddly enough. In order to get that to actually work with Windows 10 (and I’m guessing it’s the same for Windows 7 and so on ) , It just refuses to connect to the RemoteApp service if incoming NTLM is disabled.
I can howerver start a normal Desktop Session against the server so, what I would claim is that the fault is actually within RD Web and the way it handles authentication, requiring some parts to be using NTLM.
The usual RD Web login interface works so far that I can login and see the resources but I can’t start any applications from it. No errors, nothing.
If enabling NTLM, I can start the applications just fine. Once again. NTLM has to be enabled in order for full functionality 🙁

So, basically, if I change the policy settings for the RD Server not to allow incoming NTLM traffic in order to be able to actually handle a bruteforce attack and also keep track of failed logins with informaion that’s actually useful for me as a sysadmin and CSO

These are by the way the settings I’m referring to

Computer Configuration\Windows Settings\Security Settings\Security 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

Regardless of how I try, I can’t get it to work to actually add remoteapp resources (or Remote Resource Feed) neither Windows 10, nor IOS, nor Android.

So, what are the implications of this ? Does it matter ? Do we need the source IP address in 4625?

First of all, the way this is handled within Windows Server is an absolut nightmare and frankly, just usesless and I can’t see any reason for Microsoft developers to leave the IP address out when using SSL certificates or at least have another entry in the eventlog for it containg useful information.
It’s not possible to handle brute force attacks natievly within Windows Server as I’ve written about many times earlier.

The biggest problem is of course that if someone tries to bruteforce your server, then how will you stop the attack ? How do you gather evidence ?
If your’e running a larger server environment and hosting customers and so on , you’ll have no way of knowing what attempts are legitimate customers and user and which ones aren’t really.
You can hardly shut down your services can you ?

At the moment , I don’t have a good solution to this problem. Syspeace catches lots and lots of bruteforce attacks for me but these ones it can’t since it doesn’t have any IP address to block.
I’m just hoping for Microsft to actually solve this on the server side since that would be the easiest fix for them I’d say.
Of course they also neeed to get the RDP clients working for all platforms but basically it should be working with NTLM2 at least and also to log the failed logon request correctly if using an SSL certficate. Anthing else is just pure madness and stupidity to be honest and someone should get fired for not thinking ahead.

By Juha Jurvanen @ JufCorp

End of life för Windows Server 2003 – Dags att migrera till nytt OS eller flytta till Molnet ?

End of life för Windows Server 2003 imorgon

konsult inom backup It sÀkerhet molntjÀnster Ätersartsplaner för IT

Imorgon Àr det sk Patch Tuesday dvs den dagen varje mÄnad dÄ Microsoft slÀpper olika uppdateringar för sina operativsystem.

Morgondagen Àr dock lite speciell dÄ det Àr sista gÄngen Microsoft slÀpper uppdateringar för just Windows Server 2003 familjen. Efter det kommer alltsÄ inga nya sÀkerhetsuppdateringar att slÀppas och det Àr vÀldigt viktigt att vara medveten om.

För företag och föreningar som fortfarande anvÀnder nÄgon variant av Windows Server 2003 familjen finns alltsÄ en del saker att tÀnka pÄ efter det.

Valen man stÄr inför Àr att migrera till ett nyare operativsystem med allt vad det kan innebÀra som t.ex. inkompabiliktet med programvaror man kör. Oftast gÄr det att lösa men krÀver en del testande och tid att lÀgga ner pÄ projektet för att vara sÀker pÄ att verksamheten kan fortsÀtta utan överraskningar. Saker som lÀnkar hos anvÀndare och olika pekar i filsystemen kan ocksÄ stÀlla till en del trassel om man bara installerar upp en ny server i miljön.

Flytta till en plattformsoberoende molntjÀnst som Red Cloud ITs rCloud Office?

Ett annat alternativ Àr att t.ex. börja undersöka molntjÀnster dit man kan flytta sina applikationer som t.ex. Red Cloud ITs rCloud Office. Fördelar hÀr Àr t.ex. att flytta sin Visma eller Pyramid och i ett slag göra den Àven Ätkomlig frÄn iPad, Android o.s.v men ÀndÄ ha sÀkerheten, backuper och generationshanteringar inbyggd till en fast kostnad per anvÀndare och mÄnad.
MÄnga CRM och affÀrssystem finns helt enkelt inte för MAC, Android , iPad osv men utvecklingen gÄr alltmer Ät BYOD dvs lÄt anvÀndarna sjÀlva bestÀmma vilket operativ eller plattform de vill anvÀnda. DÄ behövs lösningar som stöder att de kan komma Ät affÀrssystemet o.s.v.

Oavsett bör man som företag se över sin IT miljö eftersom det helt enkelt över tid kommer bli alltmer osÀkert att köra ett operativ som inte lÀngre stöds. Hackers kommer att utnyttja vetskapen att ett tidigare oupptÀckt sÀkerhetshÄl helt enkelt inte kommer att ÄtgÀrdas.

Det finns en del saker att göra under en övergÄngsperiod dock eftersom det ju kommer nya patchar imorgon.

Nedan Àr nÄgra punkter att tÀnka pÄ

1. Se till at ha fungerande certifikat pÄ all kommunkation till och frÄn servern för att skydda er mot eventuell avlyssning och sk Man in the Middle attacker. Kom ihÄg dock att bara installera ett SSL certifikat inte rÀcker, det behövs fler ingrepp i servern för att sÀkra upo den. Certifikatet i sig skyddar inte heller mot t.ex. skadlig kod eller intrÄngsförsök.

2. Se till att ha ett vÀl fungerande antivirus, t.ex. F Secures PSB lösning dÀr man kan ta hjÀlp av tredje part att övervaka eventuella larm och anvÀnda dess Software Updater.

3. Ett automatiserat intrÄngsskydd för lösenorsdattacker med Syspeace. Det pÄgÄr vÀldigt mycket intrÄngsförsök i bakgruinden som man ofta Àr helt omedveten om.

4. GÄ igenom vilka portar i brandvÀggar som Àr öppna och tÀnk igenom dem noggrannt. Vad behöver egentligen vara öppet ? StÀn allt som inte uttryckligen mÄste vara öppet. Styr trafik korrekt.

5. En stark, tvingande lösenordspolicy för alla anvÀndare. MINST 8 tecken o.s.v.

6. Se till att alla program Àr uppdaterade, Àven Java och Flash o.s.v. om de körs pÄ servern och den anvÀnds som Terminal Server. Generellt sett sÄ ska programvaror alltid vara uppdatrade till senaste versioner. Har ni en lite större miljö finns lösningar för att distribuera ut programvaror frÄn centralt hÄll , Àven till era arbetsstationer, t.ex med PDQ Deploy eller via Group Policies.

7. GÄ igenom alla fil och katalogrÀttigheter pÄ servern och följ de rekommendationer som finns. Googla pÄ uttryck som 2003 Server Hardening och lÀs igenom och testa att ni satt upp sakerna efter bÀsta rekommendationer.

8. Om ni kör t.ex. Windows Server 2003 SBS behövs en del eftertanke med hur er mail ska hanteras framöver. Det kan handla om stora mÀngder datat i en Exchange Server och krÀva en del eftertanke med hur det ska migreras pÄ bÀsta sett , antingen till en extern leverantör elelr till en ny mailserver,

9. TĂ€nk igenom om servern behöver vara nĂ„bar frĂ„n Internet egentligen ? Finns det möjlighet att flytta Internet acessen till ett nyare operativ och lĂ„ta Ă„tkomst hanteras av den istĂ€llet ? Är en VPN lösning smidigare eller finns det andra sĂ€tt att sköta extern Ă„tkomst ? Det fĂ„r ju inte vara för krĂ„ngligt för anvĂ€ndarna.

10. I sak har inte den hÀr punkten med migrering av Windows Server 2003 att göra men kolla igenom backuperna kontinuerligt och tÀnk igenom hur ni kanske vill ha en arkivkopia av den gamla servern efter en migrering ? Hur ska den ÄterlÀsas om det behövs ?

11. Fundera pÄ vilken vÀg ni vill gÄ vad gÀller er IT miljö. Till en extern molntjÀnst eller kanske dags bygga ett eget privat moln eller en hybrid ? Att flytta sina saker till en molntjÀnst krÀver en del eftertanke och Àr kanske inte alls rÀtt vÀg för er.

ÅteranvĂ€nda serverparken ?

Att uppgradera den befintliga serverparken kan vara den bÀsta lösningen för just er verksamhet. Troligen Àr det Àldre servrar som körs om ni fortfarande anvÀnder Windows Server 2003 men de maskinerna kanske gÄr att ÄteranvÀnda till andra saker (dvs först installera om / uppgradera dem till nyare operativ och sedan ÄteranvÀnda för t.ex. fillagring för arkivering , backup server, Terminal Server Access o.s.v.). I sammahanget ska naturligvis Àven virualisering av serverparken nÀmnas och Àven hÀr finns flera vÀgar att gÄ t.ex. VMWare eller Hyper-V eller Xenserver.

Det finns inget sjÀlvÀndamÄl i att kasta hÄrdvara bara för den Àr lite till Ären och avskriven men ÀndÄ fungerar. Ofta kan den hÄrdvaran rÀcka till att byga en egen, intern molntjÀnst om man Àr orolig för att flytta sitt data till en molnleverantör.

Det finns mÄnga olika vÀgar att gÄ och det gÀller tÀnka igenom att det blir rÀtt för just er verksamhet.

Oavsett vÀg ni vÀljer kan jag hjÀlpa er planera och implementera. För mer information, kontakta mig hÀr

GrundlĂ€ggande sĂ€kerhet pĂ„ Windows Server – uppdaterad

GrundlÀggande sÀkerhet pÄ Windows server

backup disaster recovey kontinuitetsplaner IT sÀkerhet molntjÀnster syspeace

Jag skrev den hÀr saken för ett tag sen men har lagt till lite nya lÀnkar till programvaror o.s.v.

Kortfattat behlövs minst samtliga saker i den hÀr listan för att uppnÄ i vart fall en grundlÀggande sÀkerhet pÄ Windows server.
TyvÀrr kommer servern ÀndÄ inte vara fullstÀndigt skyddad Àven om du följer alla steg. Absolut sÀkerhet finns helt enkelt inte men det hÀr Àr i vart fall en lista för att göra ett antal grundlÀggande instÀllningar och steg.

Installerade program

1. Se till att alla progranvaraor Àr uppdaterade med senaste sÀkerhetsuppdateringarna. Det hÀr gÀller operativsystemet, Exchange, SQL men Àven Adobe, Java och allt annat som finns installerat. Det hÀr minskar risken för att rÄka ut för s.k. exploits som utnyttjkar sÄrbarheter i programvaror. Kika pÄ t.ex. PDQeploy som jag tycker funkat bra i större miljöer för distribution.
Det skyddar dock inte mot en riktig Zero Day attack dvs nÀr en sÄrbarhet blivit publikt kÀnd men leverantören av programmet Ànnu inte slÀppt en uppdatering som avhjÀlper felet.

Antivirus

2. Se til att ha ett vÀl fungerande men inte för resusrkrÀvande antiviruws pÄ samtliga system. SjÀlv tycker jag om F Secures PSB lösning trots en del brister i software updater Àmen den fungerar ÀndÄ vÀldigt vÀl för systemadministratör. SÀtt upp larm pÄ virusangrepp!

Katalog och filrÀttigheter

3. Se till att gĂ„ igenom alla katalog och filrĂ€ttighter ordentligt och vilka anvĂ€ndare och grupepr som har tillgĂ„ng till vad. TĂ€nk pĂ„ att se till att anvĂ€ndare , bĂ„de interna och externa , endast ska kunna se det som de uttryckligen ska ha tillĂ„ng till. Inget annat. Ett exempel Ă€r t.ex. att begrĂ€nsa Ă„tkomst till diskar och dölja diskar pĂ„ Terminal Server (kolla t.ex. TS Hide Drives). Att sĂ€ttw upp rĂ€ttigheter pĂ„ fil och katalognivĂ„ Ă€r oerhört kraftfullt sĂ€tt att begrĂ€nsa tillgĂ„ngen till data. Testa innan du tillĂ„ter anvĂ€ndare att nĂ„ servern. Det Ă€r alltid svĂ„rare att och jobbigare att fixa till saker i eftehand nĂ€r servern Ă€r i drift. “Better to be denied than sorry”

Best practices

4. Se till att följa “best practices” för alla applikationer och tjĂ€nster du sĂ€tter upp. Googla. Ingen manual Ă€r komplett och programvarutillverkare tĂ€nker inte alltid pĂ„ kringliggande saker som kan pĂ„verka sĂ€kerhet och kompabilitet.

Loggning

5. Se till att ha loggning pÄslaget dÀr det gÄr. MÄnga program och funktioner har inte det pÄslaget som standard men du kan inte felsöka det du inte ser och att försöka hitat ett intrÄng eller annat fel i efterhand kan vara hopplöst om inte omöjligt.

Övervakning

6. Se till att ha en vÀl fungerande övervakning och inventering pÄ hela ditt nÀt. SjÀlv Àr jag en föresprÄkare för Spiceworks som Àr gratis som man kan göra vÀldigt mycket med.

SNMP och serveragenter

7. Om din server har olika typer av övervakningsagenter som kommer frÄn tillverkaren (vilket de flesta har) se till att installera dem. De ger dig information om hur hÄrdvaran mÄr och larmar om olika typer av incidentter. Se till att ocksÄ sÀtta upp larm frÄn dem via mail till en funktionsbaserad maillÄda dvs inte till en person. Se ocksÄ till att ha en plan för incidenthantering pÄ plats och utpekade ansvarig för olika typer av fel.

Group Policies

8. Group policies dvs grupp principer. Oerhört kraftfullt verktyg om du sÀtter dig in i det och kommer att underlÀtta administration, sÀkerhetshantering och anvÀndarhantering vÀldigt mycket.

SSL TLS och Internet

9. Om servern Àr nÄbar frÄn Intern, se till att ha giltiga SSL certifkat för alla tjÀnster so ska kommuniceras med. Det Àr inte sÄ dyrt man kan tro och kommer underlÀtta ocksÄ att fÄ en del funktioner att fungera smÀrtfritt. TÀnk dock pÄ att bara installera ett SSL certifikat inte rÀcker, du mÄste ocksÄ slÄ av en del svaga krypton o.s.v.

Onödiga tjÀnster och nÀtverksprotokoll

10. Stoppa tjÀnster, funktioner och nÀtverksprotokoll som inte anvÀnds. Minimiera attackytan för hackers, bÄde interna och externa, men spara Àven prestanda i serven. Du slipper ocksÄ onödigt tjattrig nÀtverkstrafik pÄ nÀtet . Behöver t.ex. DHCP Client vara igÄng pÄ en server ? Samma princip gÀller för skrivare och arbetsstattioner.

Lösenordspolicy

11 Tvinga komplexa lösenord för alla anvÀndare. Ett av de vanligaste sÀtten för hackers att ta sig in i system beror just pÄ svaga lösenord som enkelt gÄr att gissa sig till. Byt namn pÄ administratören dÄ kontot inte gÄr att lÄsa i Windows. HÀr Àr det ocksÄ viktigt att ha et fungerande intrÄngsskydd mot lösenordsattacker med Syspeace.

Namnstandard för inloggningar

12. AnvĂ€nd en bra namnstandard för inloggningar. AnvĂ€nd inte bara t.ex. förnamnn@ertföretag.se eller nĂ„got annat som Ă€r för uppenbart och enkelt. Ju svĂ„rare det Ă€r för en hacker att gissa sig till ett anvĂ€ndarnamn desto fler försök komemr behövas för att ta sig in i systemet. Även hĂ€r Ă€r Syspeace en viktigt nyckel för hanteringen.

Backuper

13. Backuper, backuper och BACKUPER! Se till att ha fungerande backuper och rutiner för dem. Testa dem regelbundet , minst en gÄng om Äret. Att ÄterlÀsa enskilda filer ur en backup Àr inte en Äterstartstest! Se Àven till att ha flera generationer av backuper och en IT policy som styr detta. Att bara ha en eller tvÄ generationer att kunna falla tillbaka pÄ vid ett haveri kan vara katastrof t.ex. om backupen av nÄgion anledning Àr korrupt och inte gÄr att anvÀnda eller om ni blivit hackade och nmÄste fÄ tillbaka systemet till ett tillfÀlle ni vet med sÀkerhet Àr OK innan intrÄnget skedde.
Se till att ha MINST en fungerande enreation av backupern anÄgon annastans Àn i samma lokaler dÀr servern Àr utifall det brinner eller blir inbrott.

Att ha disksystem som RAID och andra failolver-lösningar kmemr aldrig att ersÀtta backuper. All hÄrdvara kan falera, bÄde fysiskt och logiskt som korrupta filsystem.
Ett tips hĂ€r Ă€r ocksĂ„ att slĂ„ pĂ„ regelbundna VSS snapshots pĂ„ alla diskar . Enkelt, stabilt och billigt sĂ€tt att ha flera generationer av data att tillgĂ„ –

Scanna , hacka , sök aktivt efter brister

14. Scanna din server med olika verktyg efter sÄrbarheter och tips för att öka sÀkerheten.

BrandvÀggar och kommunikationer

15. TÀnk igenom hur serven kommunicerar med omvÀrlden vad gÀller brandvÀggar och routing i nÀtet. Ha Àven den lokala brandvÀggen pÄslagen i Windows, trots att den stÄr bakom en extern brandvÀgg.

Lösenordsattacker

16. Automatisk intrÄngshantering med Syspeace. I Windows gÄr det inte att automatiskt hantera lösenordsattacker pÄ ett vettigt sÀtt. De inbyggda mekanismerna kan t.o.m. göra mer skada Àn nytta. Att installera Syspeace löser mycket av problematiken direkt och Àr oerhört enkelt att installera och konfigurera.

Återstartsplaner för IT

17. Det hÀr hör pÄ sÀtt och vis ihop med punk 13 om backuper men se till att ha en vettig Äterstartsplan om nÄgot hÀnder.

Microsoft Baseline Security Analyzer

18. Kolla med Microsoft Baseline Security Analyzer sÄ du ocksÄ följer deras rekommenadtioner. Den Àr inte heltÀckande men anvÀndar för att ge en fingervisning

Kontakta mig för möte eller frÄgor

Återstartsplaner för IT – Disaster Recovery pĂ„ svenska

konsult inom backup It sÀkerhet molntjÀnster Ätersartsplaner för IT

Efter 20 Är som IT konsult inom mÄnga olika omrÄden Àr min erfarenhet att backuper oc Äterstartsplaner för IT fortfarande Àr en eftersatt frÄga. I sak har det inte förÀndrats mycket , trots molntjÀnster och förenklade metoder och hur mÄnga gÄnger det Àn diskuteras pÄ möten blir det ÀndÄ eftersatt och uppskjutet.

Ända till den dagen nĂ„got verkligen hĂ€nder och de dĂ€r backuperna behövs.

Backuper Àr för de flesta ett trÄkigt Àmne och sÀllan nÄgot som prioriteras, varken av IT avdelningen eller av ledningen men, tyvÀrr Àr ÀndÄ den krassa verkligheten att backuperna Àr nÄgot av det viktigaste ett företag eller organisation har.

En av de mest grundlĂ€ggande frĂ„gorna varje IT chef och VD mĂ„ste sĂ€lla sig Ă€r “Hur lĂ€nge kan vi klara oss utan vĂ„r IT? Timmar ? Dagar ? MĂ„nader ?
Utan den tankegÄngen kommer teknikerna och IT avdelning aldrig att ha ett mÄl att jobba mot för att skapa en anvÀndbar Äterstartsplan som följer den riktlinjen. Backuper och riktlinjer för Äterstartsplaner Àr alltid ledningens ansvar.

Förarbetet under den normala driften Àr vÀldigt viktig att tÀnka pÄ .
Att inte kontinuerligt övervaka backuperna, testa att de innehÄller vad de ska och ha ett öga pÄ eventuella fel kan fÄ vÀldiga konsekvenser.

Att inte ha planerat igenom hur en stor ÄterstÀllning av hela IT systemet ska gÄ till i förvÀg kan leda till en onödigt lÄng Äterstartsprocess i sökande efter dokumentation, backuper, hÄrdvara och kompetenta tekniker.

Att ÄterstÀlla enskilda filer pÄ en server Àr inte en test av backuperna , det Àr i bÀsta fall bara ett test av lÀsbarheten pÄ backuperna. Ett riktigt Äterstartstest (Disaster Recovery Test )  ska utgÄ frÄn scenariot att hela servern eller hela servermiljön helt enkelt inte lÀngre finns att tillgÄ.

Tekniker som skall ÄterstÀlla ska ha tillgÄng till backuperna, dokumentationen och hÄrdvara att ÄterstÀlla till. Det Àr allt. Ingen att ringa. Ingen att frÄga. Syftet skall vara att ha en tillrÀckligt bra teknisk Äterstartsplan och kunna följa den sÄ att företaget eller organisationen har tillgÄng till sina IT system inom den tid som krÀvs enligt IT policyn och företagets BCP (Business Continuity Plan ) och DRP (Disaster Recovery Plan) .

HÀr kommer mÄnga frÄgor in per automatik att tÀnka pÄ.
Alla de hÀr frÄgorna förutsÀtter att det redan Àr konstaterat att det Àr just backuperna som mÄste tas till .
För att komma fram till det beslutet krÀvs ocksÄ en del planering innan och beslut att fatta baserat pÄ vad som hÀnt (virusattack, brand, stöld, översvÀmning, terrorhot o.s.v. ) 

  1. Var finns backuperna? Är de pĂ„ tape? -Var finns banden? Är de krypterade och vem har lösnorden?
    PÄ disk?  I princip Àr frÄgestÀllningarna de samma som pÄ tape.
    Är det onlinebackuper? – Är de krypterade ? Hur mycket data Ă€r det totalt och hur mycket bandbredd har vi att tillgĂ„ ? Kommer sjĂ€lva Ă„terlĂ€sningen av data att ta för lĂ„ng tid för allt data över den hĂ€r bandbredden t.ex. 10 Mbits eller 100 Mbits ?
  2. Hur har backuperna tagits ?  Vilken backup programvara ha anvÀnts och hur fÄr vi tag pÄ den ? Hur ÄterstÀller man backupservern i t.ex. Legato Networker eller Tivoli TSM för att ens kunna börja ÄterlÀsa nÄgot frÄn backuperna? Hur lÄng tid tar den initiala ÄterstÀllningen och har vi rÀknat in den tiden i vÄr DRP ? För t.ex. Legato kan en sÄn ÄterstÀllning handla om mÄnga, mÄnga timmar för man kanske mÄste scanna igenom varje tape och fÄ in dem i databasen och i TSM Àr databasen kritisk för att kunna fÄ tillbaka nÄgot alls frÄn backuperna.
  3. Hur ser systemdokumentationen ut ?
    Hur var servrarna uppsatta med volymstorlekar, programvaror, operativsystem med service packs o.s.v. ? MÄnga företag missar den hÀr delen i sin Äterstartplan och det kan leda till ett alldeles onödigt tidsspill under ÄterstÀllningen . Dokumentationen Àr gammal eller direkt felaktig . HÀr behövs enkla och automatiserade system som uppdaterar systeminformationen dagligen. Administrativa lösenord behöver ocksÄ finnas tillgÀngliga, i Wndows server vÀrlden Àven de lokala administrativa lösenorden och en uppdaterad IP plan kommer behövas.
  4. Till vad ska vi ÄterlÀsa backuperna?De flesta företag organisationer har inte en dubblerad serverpark som bara stÄr och vÀntar en katastrof och att veta till vilken hÄrdvara det faktiskt ska ÄterlÀsas till Àr en viktigt frÄga att tÀnka pÄ alltsÄ, hur fÄr vi tag pÄ reserv hÄrdvara eller ska vi ÄterlÀsa allt till en virtuell miljö? Hur fÄr vi tag  pÄ en server som kan husera t.ex. 25 servrar med 4 GB RAM vardera minst och 50 GB disk utrymme?
  5. Vart ska vi göra den faktiska ÄterlÀsningen? Om företaget eller organisationen drabbats av en större olycka kommer det troligen inte att gÄ att ÄterstÀlla miljön pÄ samma stÀlle. Det mÄste finnas en plan för vart bÄde personal och IT personal ska ta vÀgen för att ens kunna pÄbörja en ÄterlÀsning och Äteruppbyggnad av IT miljön. Oavsett hur sÄ mÄste förmodligen verksamheten ÄteruppstÄ förr eller senare.
  6. Vem ska göra vad? Och i vilken ordning?Det hĂ€r Ă€r ocksĂ„ hemskt viktiga frĂ„gor. Vem eller vilka ska göra det rent praktiska med Ă„terlĂ€sningen ? Vem ska t.ex. meddela pĂ„ hemsidan / twitter / press att ni rĂ„kat ut för ett haveri och meddela nĂ€r ni berĂ€knas vara i full drift igen ? PĂ„ vilka siffror baseras den informationen dvs frĂ„n tidigare krascher eller tidigare Ă„terstartstester eller bara en “allmĂ€n kĂ€nsla” dvs mer eller mindre baserat pĂ„ gissningar ?

    Finns det redan utsett i vilken ordning olika system och funktioner ska upp och vilka som Àr mest kritiska och viktigast att fÄ upp först ? Vad IT avdelningen tycker Àr viktigt kanske inte alls Àr det viktigaste för företaget sett ur affÀrssynpunkt. Att förstÄ samspelet mellan olika system Àr kritiskt.

    Om ingen med kunskap om hur miljön var uppbyggd finns tillgÀnglig, kommer dokumentationen att vara en hjÀlp eller ett hinder för den externe konsulten som skall hjÀlpa till ? Att ÄterlÀsa t.ex. en kraschad Microsoft Exchange Server med tillhörande Active Directory eller en komplicerad Oracle installation Àr inte alldeles sjÀlvförklarande för den som aldrig gjort det innan. Allt gÄr sÄklart att göra om backupen Àr korrekt taen men det kan ta mÄnga gÄnger lÀngre tid Àn nödvÀndigt att vara igÄng igen. Jag har sett exempel dÀr det handlat om veckoer innan systemn Àr uppe igen.

  7. ÅterstĂ€llningen i sig – Ă€r den permanent eller tillfĂ€llig? Om Ă„terstĂ€llningen gĂ„tt bra sĂ„ mĂ„ste man Ă€ndĂ„ ha klart för sig om det Ă€r en tillfĂ€llig lösning man Ă„terstĂ€llt sin miljö till och sĂ„ fort man Ă€r i normal drift igen mĂ„ste man börja planera för Ă„tergĂ„ng till den riktiga miljön igen .

Det hÀr Àr egentligen bara nÄgra av saker som jag vet man mÄste tÀnka pÄ för sin verksamhet och framförallt, man mÄste ta sig tiden att göra det hÀr jobbet , antingen internt eller att anlita en extern konsult som hjÀlper till med att strukturera upp arbetet och planeringen med nya ögon.

Kommentera gÀrna eller kom med synpunkter eller kontakta mig för vidare funderingar kring de hÀr frÄgorna.

Ett möte kostar bara lite tid men kan ge sÄ mycket mer

Juha Jurvanen – Senior IT konsult inom backup, IT sĂ€kerhet, servedrift och molntjĂ€nster .

TLS 1.1, TLS 1.2 och SSL certifikat pÄ Microsoft IIS Server och Exchange Server

Vad Àr ett SSL certifikat ?

konsult inom backup It sÀkerhet molntjÀnster SSL

Ett SSL certifikat anvÀnds för att kryptera trafiken mellan en klientenhet (PC, MAC, Android , iPhone o.s.v. ) och en server. Det hÀr Àr en vÀldigt viktig funktion bÄde ur sÀkerhetsaspekter men Àven ur funktionalitet dÄ mÄnga system idag krÀver krypterad kommunikation för att fungera fullt ut som t.ex. Microsoft Exchange och Microsoft RDS Servers (Remote Desktop servers) .
TLS Àr egentligen en vidareutveckling av just SSL Àven om man i dagligt tal pratar om just SSL certifikat.

SSL / TLS anvÀnds ocksÄ för att validera att servern Àr den som den utger sig för att vara genom att din enhet kontrollerar med en tredje part att det hÀr certifikatet Àr giltigt och att det Àr den serven som faktiskt har det installerat.
Enklast ser du att allt stÄr rÀtt till om det stÄr https i adressfÀltet i din webblÀsare och att du inte har felmeddelanden kring certifikatet.

SSL Àr dock inget skydd mot t.ex. lösenordsattacker mot Windows Server. För den typen av skydd behövs Syspeace

RÀcker det att ha SSL installerat pÄ servern ?

MÄnga företag tror tyvÀrr att det rÀcker men det gör det inte. I den hÀr korta artikeln ska jag fokusera pÄ Microsoft IIS Server d.v.s deras webbserver som finns inbyggd i Microsoft Windows Server.I en del fall nöjer man sig Àven med att ha bara egenutfÀrdade certifikat dvs dessa valideras inte av en tredje part.
Det hÀr Àr absiolut inte att rekommendera i en driftsmiljö. Knappt ens i testmiljö eftersom det Àr en del manuell hantering och det Àr ofta svÄrt att helt efterlikna driftsmiljön.

Kontrollera er SSL installation gratis

Det finns gratis verktyg pÄ nÀtet för att kontrollera status och hur ni satt upp SSL pÄ just er IIS server.
Sök pÄ t.ex. SSL Check pÄ Google och ni kommer hitta mÄnga bra verktyg för detta. Personligen gillade jag https://sslcheck.globalsign.com/en_US eftersom den hade ett enkelt grÀnssnitt och bra förklaringar till de olika delarna och Àven https://www.ssllabs.com/ssltest/analyze.html?d=jufcorp.com&latest som Àven undersöker för sÄrbarheter mot t.ex. POODLE.

SSL och IIS server i standardinstallation

En standardinstallerad Windows server ger vanligen betyg F dvs underkÀnt, Àven om man installerat ett godkÀnt SSL certifikat.

MÄnga av standardvÀrdena i Microsoft IIS tillÄter svaga krypteringar och SSLv2 och SSLv3, och dessa borde inte tillÄtas p..g.a. risken att de kan utnyttjas till olika saker (t.ex. datastöld, s.k. Man in the Middle attacker dvs nÄgon annan utger sig för att vara den servern som du tror att du kommunicerar med men man avlyssnar egentligen all trafik) .
Det saknas Àven en del viktiga instÀllningar i registret för Forward Secrecy o.s.v

Det behövs alltsÄ fler ingrepp i servern och hÀr gÀller det att göra rÀtt och tÀnka pÄ t.ex. kompabilitet mot Activesync om det t.ex. Àr en Microsoft Exchange server men Àven för Remote Desktop Server.
Det krÀvs helt enkelt en del ingrepp i serverns registry vilket i vÀrsta fall kan leda till att servern slutar fungera.

Kontakta mig för hjÀlp och frÄgor

%d bloggers like this: