ESX:n hallintaa yli SSH:n

Joskus tarve säätää iskee silloin kun omaa laitteistoa ei ole sopivasti käsillä tai käsillä oleva laitteisto on isommalla näytöllä varustettu kuin mitä puhelimeni. Tällöin on olisi näppärää vetäistä minimityökaluilla säätö käyntiin. Ehkäpä minua ei huvita jättää jälkeeni ohjelmistoa ja avaimia millä saa VPN yhteyden kotiini, kun todellisuudessa tarvin vain vSphere yhteyden ESX serverille. Silloin tehdään seuraavaa

1) Putty:lla SSH yhteys reitittimelle, portti ohjaukset ESX serverin portteihin 443 ja 902

2) Lisätään hosts tiedostoon (C:\WINDOWS\system32\drivers\etc\hosts) TUPESXP00? missä ? on joko 1 tai 2, riippuen kummalle koneelle menen.

tämän jälkeen kaikki toimii kuin olisi kotona. \o/

Physical security

All digital security is meaningless if the physical security is lacking. There for getting this right is one of the key things. I’m not going into the details of cooling or fire alarms or any such thing, but do note that these have effect on the security when implemented without care. Example when fire extinguisher is activated doors open so that everyone can exit and firemen and easily enter. The way the doors open should always be out of the main space. Emergency opening mechanisms should not leave the door open, they should unlock it only temporarily, this of course is again subject to local laws. No server room should have windows.

I would divide server hosting to three different security levels.

  • normal
  • secure
  • high secure

At normal level access to server facility should be limited to authorized personnel only, noting that not all servers should be accessible by all admins. Normal level security for financial servers and normal level security for example web servers should be implemented so that these servers are in different rooms with different accesses. Of course, now I’m assuming that one has sufficient staff for this kind of separation. Practicalities must be taken in to account, could be that all standard security servers are accessible by all three administrators that the company has. Normal level must of course log all entering the space, with video camera being the preferable way. The loading bay and the way to get the servers in needs to be protected at least at the same level than any other entry to these rooms.

Secure level is a bit upwards from normal level. These servers could be located in the same place as normal level servers, but physical access to these is limited little bit more. The rack they are located in must be locked and monitored with a camera from front and back. At the very basic level at least network equipment should be security classified devices, but network HSM’s or servers with card readers, internal HSM or anything that needs to be physically activated should generally be located here. Major mistake with these racks is pointing the cameras so that the passwords of the administrators can be read when they use the console for these servers. Cameras should never point so that passwords could be read from the recording. Keys to the rack should be somewhere else, perhaps with a guard or receptionist or monitoring, somewhere where human interaction is required to get those keys to the racks. Naturally here we need process so that people can’t go willi-nilly getting the keys. – A valid reason is needed, such could be an approved work order or a production incident.

High security, now we are talking guards, dual access, sealed walls, full blown “nuclear bomb level” protection copied from military practices. Designer needs to be bat-crap insane and really sure others are out to get him or his computers. This deservers a good, deep explanation of the security requirements, so I’ll safe it to the next post.

How to do security stuff in company settings?

A friend, who’s opinion I do value, told me that the previous texts regarding building a CA was too simple, stuff that could easily be figured out and that stuff just was nothing to talk about. Granted, all that could be figured out from the web. Apparently dual control, split roles and such would be things that would be interesting and not enough is written about it. So, here goes.

I’ll take the goal of building a serious CA in a company environment where one would have resources at their disposal. These settings could be generalized to any security server and I, by far, am not a specialist on all the stuff I cover, I try to point out where my knowledge gets thin.

Lets get to basics and build up from there. This section of my blogs will be a mixture of physical, technical and process in an order that I feel writing about.

Reittisuunnitelma

2013-01-26 12.40.26Makuuhuoneen ovessa on ollut pitkään tuloste Pohjois- ja Etelä-Amerikasta, johon on saanut piirtää ja merkata haluamiaan kohteita.

Vuodenvaihteen jälkeen aloimme Kristan johdolla työstämään halutuista kaupungeista reittiä kasaan. Torstai 24.01. tilasimme liput ja näin ollen runko on lyötynä lukkoon. Allaoleva kuva on suunnittelustamme. Liitutaulu on lyömätön suunnittelutyökalu Smile

Liikkelle 24.08.2013 Helsingistä kohti New Yorkia. Washingtonin kautta Buffaloon, josta matka vie meidät Los Angelesiin, missä teemme pienen reissun kohti Grand Canyonia tämän jälkeen matkustellaan Chileen moikkaamaan tuttuja ja sieltä palataan Rio De Janeiron (sweeeeeet) kautta Suomeen niin että 11.10. 2013 olemme Helsingissä taas.

Lähtösuunnitelma

CRL

Viimeinen palanen mikä tarvitaan toimivan PKI rakenteen ylläpitämiseen on varmenteiden hylkäyslista (CRL) tai OCSP, joka puolestaan vastaa reaaliajassa varmenteen tilan.

CRL on vanha tuttu, joten aloitin sen kanssa. Itseasiassa CRL:n liittyvät asiat olin päättänyt jo juuri CA:ta tehdessä. CRL tulee löytyä osoitteesta crl.leivo.org. Jotta varmenteet toimivat ulkopuolellekin oikein on tuo crl.leivo.org julkisesti saavutettavissa. Se on itseasiassa tämä web palvelin. Toinen tärkeä huomioitava asia on, että sisäverkossa homman on toimittava myös, joten sisäverkossani crl.leivo.org onkin minun Microsoft Home server. Näinollen WLAN tunnistus, kun sinne saakka päästään, tulee toimivaan vaikka nettiyhteys olisikin kentässä jostain syystä.

OpenSSL on helppo virittää sylkemään pihalle CRL:ää. Minulla palvelin on viritetty sylkemään 30 minuutin välein uusi CRL. Tämä tarkoittaa sitä että varastettu/menetetty varmenne on käyttökelpoinen noin 30 minuuttia sen hylkäämisenkin jälkeen. OpenSSL luo normaalisti PEM muotoisia CRL:iä. Windows käyttäytyy kauniisti DER muotoisten CRL:n kanssa, joten valitse oma myrkkysi.

PEM: openssl ca -config testca.cnf -gencrl -out crl/Rootca-crl.pem
DER: openssl ca -config testca.cnf -gencrl -outform DER -out crl/LeivoI-CA.crl

kuten konfiguraatioista huomaa, minä sotkin PEM ja DER muotoja keskenään. Tämä siksi, että huomasin Windowsin ominaisuuden vasta myöhemmin Smile.

Tämän jälkeen skriptejä päivittämään CRL pitkin eri web palvelimia ja homma on kunnossa.

Kevyen taisteluväsymyksen vuoksi, en tässä vaiheessa konffaa OCSP:tä käyttöön. Se tulkoon myöhemmin.