openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
openssl req -noout -modulus -in server.csr | openssl md5
niedziela, 23 listopada 2014
Weryfikcja zgodności certyifkatu i klucz prywatnego
Certyfikat self-signed
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout cert.pem -out cert.pem
więcej: http://www.madboa.com/geek/openssl/
Wersja offline
czwartek, 2 października 2014
BSD vs GPL
Cytat:
> BSD: "If you love something, set it free. If it comes back to you,
> it was meant to be."
>
> GPL: "If you love something, set if free, but put a chain around
> it's neck to make sure it doesn't get out of sight."
Natrafienie na ten cytat związany jest z bardzo, bardzo, bardzo wątpliwą zawartością strony: http://aboutthebsds.wordpress.com/ (adresu celowo nie linkuję).
Nie pamiętam bym przez ostanie dwie dekady miał możliwość zapoznania z takim poziomem treści.
Niewątpliwie zawartość strony rozbawiła mnie ale zapoznanie się z treściami zawartymi w powyższym blogu byłoby niesamowitą stratą czasu gdyby nie powyższy cytat.
Cytat nie pojawił się oczywiście na stronie. Napotkałem go na liście dyskusyjnej FreeBSD gdzie był poruszony temat tej nieszczęsnej strony.
> BSD: "If you love something, set it free. If it comes back to you,
> it was meant to be."
>
> GPL: "If you love something, set if free, but put a chain around
> it's neck to make sure it doesn't get out of sight."
Natrafienie na ten cytat związany jest z bardzo, bardzo, bardzo wątpliwą zawartością strony: http://aboutthebsds.wordpress.com/ (adresu celowo nie linkuję).
Nie pamiętam bym przez ostanie dwie dekady miał możliwość zapoznania z takim poziomem treści.
Niewątpliwie zawartość strony rozbawiła mnie ale zapoznanie się z treściami zawartymi w powyższym blogu byłoby niesamowitą stratą czasu gdyby nie powyższy cytat.
Cytat nie pojawił się oczywiście na stronie. Napotkałem go na liście dyskusyjnej FreeBSD gdzie był poruszony temat tej nieszczęsnej strony.
środa, 24 września 2014
nginx + node.js (proxy)
Konfiguracja serwera nginx jako serwera proxy dla aplikacji node.js (do zastosowań developerskich).
Poniższa konfiguracja umożliwia:
Obsługa websocket po stronie nginx-a jest możliwa (z pamięci) od wersji 1.4.x (na pewno działa w wersji 1.6.x).
app.0.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10000
app.1.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10001
app.99.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10099
app.999.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10999
itd...
Adresy typu app.0, app.00 czy app.000 są tożsame (tj. mapowane do adresu 10000). Tak samo jak np. app.5, app.05 czy app.005 (port 10005).
Obsługa plików statycznych odbywa się poprzez utworzenie katalogu:
W pierwszej kolejności w powyższym katalogu sprawdzana jest obecność pliku i jeśli jest on dostępny jest serwowany przez nginx-a. Jeśli plik nie zostanie odnaleziony wywoływana jest aplikacja node.js (na wybranym porcie), która może obsłużyć dane wywołanie. (powyższy mechanizm sprawdził się w jednym z moich projektów gdzie służył do generacji miniaturek obrazków - jeśli miniaturka nie istniała aplikacja node.js generowała plik, który przy następnym wywołaniu był już bezpośrednio serwowany przez nginx-a). Dodatkowo dla adresu / obsługiwane jest statyczny plik index.html. Łatwo to rozszerzyć o obsługę pliku index.html (lub dowolnej innej nazwy) dla pozostałych katalogów:
PS: Ostrożnie z dyrektywą If
http://wiki.nginx.org/IfIsEvil
http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
- dynamiczne tworzenie adresu dla aplikacji node.js nasłuchującej na partach od 10000 do 10999 (na adresie localhost)
- serwowanie plików statycznych poprzez serwer Nginx zamiast poprzez aplikację node.js
- obsługę websocket (upgrade połączenia)
Obsługa websocket po stronie nginx-a jest możliwa (z pamięci) od wersji 1.4.x (na pewno działa w wersji 1.6.x).
# Kontekst http{} map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 80; listen [::]:80; server_name ~^app.([0-9]?[0-9]?[0-9])\.socha\.it$; set $url_node_port $1; if ($url_node_port ~* "^[0-9]$") { set $app_node_port 1000$url_node_port; } if ($url_node_port ~* "^[0-9][0-9]$") { set $app_node_port 100$url_node_port; } if ($url_node_port ~* "^[0-9][0-9][0-9]$") { set $app_node_port 10$url_node_port; } root /storage/web/node/app/$app_node_port; location /system-problem/ { root /storage/web/default; } location = / { try_files /index.html @application; } location / { try_files $uri @application; } location @application { error_page 502 =404 /system-problem/error.html; proxy_pass http://127.0.0.1:$app_node_port; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } }Adres wywołania wygląd tak:
app.0.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10000
app.1.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10001
app.99.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10099
app.999.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10999
itd...
Adresy typu app.0, app.00 czy app.000 są tożsame (tj. mapowane do adresu 10000). Tak samo jak np. app.5, app.05 czy app.005 (port 10005).
Obsługa plików statycznych odbywa się poprzez utworzenie katalogu:
np. katalog /storage/web/node/app/10000./storage/web/node/app/<PORT>
W pierwszej kolejności w powyższym katalogu sprawdzana jest obecność pliku i jeśli jest on dostępny jest serwowany przez nginx-a. Jeśli plik nie zostanie odnaleziony wywoływana jest aplikacja node.js (na wybranym porcie), która może obsłużyć dane wywołanie. (powyższy mechanizm sprawdził się w jednym z moich projektów gdzie służył do generacji miniaturek obrazków - jeśli miniaturka nie istniała aplikacja node.js generowała plik, który przy następnym wywołaniu był już bezpośrednio serwowany przez nginx-a). Dodatkowo dla adresu / obsługiwane jest statyczny plik index.html. Łatwo to rozszerzyć o obsługę pliku index.html (lub dowolnej innej nazwy) dla pozostałych katalogów:
location / { try_files $uri $uri/index.html @application; }W przypadku braku możliwości połączenia z aplikacją node.js (502 - Bad Gateway) zwracany jest błąd 404 i zawartość pliku /storage/web/default/system-problem/error.html.
PS: Ostrożnie z dyrektywą If
http://wiki.nginx.org/IfIsEvil
http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
środa, 13 sierpnia 2014
IPXE XenServer 6.2 Boot
Konfiguracja dla iPXE ładująca instalator XenServer 6.2
imgfree
kernel -n xen.gz boot/ipxe/xen dom0_max_vcpus=2 dom0_mem=752M com1=115200,8n1 console=com1,vga
module -n vmlinuz osboot/ipxe/vmlinux xencons=hvc console=hvc0 console=tty0 install
module install.img
boot
Tworzenie plików xen i vmlinux:
cd boot
mkdir ipxe
cp xen.gz ipxe/
cp vmlinuz ipxe/vmlinux.gz
cd ipxe
gzip -d xen.gz
gzip -d vmlinux.gz
sobota, 7 czerwca 2014
Jedna instancja cronjob-a
Problem stary jak świat...
Proste rozwiązanie: http://timkay.com/solo/
Proste rozwiązanie: http://timkay.com/solo/
#!/usr/bin/perl -s # # solo v1.6 # Prevents multiple cron instances from running simultaneously. # # Copyright 2007-2013 Timothy Kay # http://timkay.com/solo/ # # It is free software; you can redistribute it and/or modify it under the terms of either: # # a) the GNU General Public License as published by the Free Software Foundation; # either version 1 (http://dev.perl.org/licenses/gpl1.html), or (at your option) # any later version (http://www.fsf.org/licenses/licenses.html#GNUGPL), or # # b) the "Artistic License" (http://dev.perl.org/licenses/artistic.html), or # # c) the MIT License (http://opensource.org/licenses/MIT) # use Socket; alarm $timeout if $timeout; $port =~ /^\d+$/ or $noport or die "Usage: $0 -port=PORT COMMAND\n"; if ($port) { $addr = pack(CnC, 127, $<, 1); print "solo: bind ", join(".", unpack(C4, $addr)), ":$port\n" if $verbose; $^F = 10; # unset close-on-exec socket(SOLO, PF_INET, SOCK_STREAM, getprotobyname('tcp')) or die "socket: $!"; bind(SOLO, sockaddr_in($port, $addr)) or $silent? exit: die "solo($port): $!\n"; } sleep $sleep if $sleep; exec @ARGV;
sobota, 22 lutego 2014
Terminacja SSL/TLS i Apache (przekierowania na katalogi)
Co się stanie gdy wywołamy taki adres?
http://adres.pl/katalogObsługując taki adres serwer Apache spróbuję udostępnić plik o nazwie /katalog (względem DocumentRoot). Gdy się okaże, że pod tą nazwą w systemie plików znajduję się katalog serwer wykona przekierowanie (HTTP 301) na adres:
http://adres.pl/katalog/W przekierowaniu jest podany adres bezwzględny (pełny URL). Przy tworzeniu pełnego adresu Apache ustawia rodzaj protokołu (scheme). Domyślna wartość dla scheme to http. Gdy aktywny jest jakiś moduł SSL/TLS (np. mod_ssl) dla vhostów z obsługą SSL-a zwracana jest wartość https.
Na problem możemy natrafić gdy terminacja SSL/TLS obywa się w innym miejscu niż Apache (przykład terminacji na serwerze Nginx). W takiej sytuacji komunikacja serwera proxy z serwerem Apache odbywa się najczęściej po "czystym" protokole HTTP i Apache wygeneruję przekierowanie bezwzględne zawierające http://.
Najprostszym rozwiązaniem tego problemu w przypadku Nginx jest wykorzystanie dyrektywy proxy_redirect. Pozwala ona na podmianę w odpowiedzi z backendu np. http:// na https://. Wykorzystując to rozwiązanie może być trudno wykonać celowe przekierowanie z poziomu backendu (np. aplikacji php) na adres http:// - może ono zostać zamienione na https://.
Poniższy bardzo prosty moduł dla Apache (dla wersji 2.2.x) rozwiązuję ten problem. Rozwiązanie opiera się na przekazaniu przez serwer proxy nagłówka (X-Forwarded-Proto) informującego jaki protokół został użyty przy połączeniu. Poniższy moduł po wykryciu takiego nagłówka "informuję" serwer Apache o odpowiednim typie protokołu (zmienia nazwę dla scheme) dla danego requesta.
Moduł jest bardzo prosty. Posiada zaszyte informacje o nazwie nagłówka i dopuszcza tylko zmianę jeśli request został wywołany z adresu 127.0.0.1. Moduł celowo nie obsługuję żadnych parametrów konfiguracyjnych - jeśli moduł zostanie wyłączony konfiguracja serwera Apache będzie dalej prawidłowa (nie będzie nieznanych dyrektyw konfiguracyjnych).
Poniżej kod źródłowy modułu (w języku C) i pakiety RPM.
Pakiet RPM dla CentOS 6.x x86_64
Pakiet SRPMS
/* * mod_rpsm.c (Reverse Proxy Scheme Module) * Version: 1.0 * License: Public Domain * * Author: Robert Socha * EMail: socha@socha.it * * Simple module to set Apache scheme (https or http) when request are coming from * reverse proxy/ssl terminator (eg. Nginx) * No configuration directives - pass X-Forwarded-Proto header from proxy * (and set it to https) * * Compile: apxs -c mod_rpsm.c * */ #include "httpd.h" #include "http_config.h" #include "http_protocol.h" #include "ap_config.h" module AP_MODULE_DECLARE_DATA rpsm_module; static const char *rpsm_http_scheme(const request_rec *r) { const char *xfproto; if( (strcmp(r->connection->remote_ip,"127.0.0.1")==0) && (xfproto = apr_table_get(r->headers_in, "X-Forwarded-Proto")) && (strcmp(xfproto,"https") == 0)) { return "https"; } return NULL; } static void rpsm_register_hooks(apr_pool_t *p) { ap_hook_http_scheme(rpsm_http_scheme, NULL, NULL, APR_HOOK_MIDDLE); } module AP_MODULE_DECLARE_DATA rpsm_module = { STANDARD20_MODULE_STUFF, NULL, /* dir config creater */ NULL, /* dir merger --- default is to override */ NULL, /* server config */ NULL, /* merge server configs */ NULL, /* command apr_table_t */ rpsm_register_hooks, /* register hooks */ };
środa, 19 lutego 2014
Nginx TLS Proxy do backendu na HTTPD Apache
Przykładowa konfiguracja terminacji SSL/TLS po stronie Nginx.
Konfiguracja po stronie Nginx
Konfiguracja po stronie Nginx
server { listen 443 default_server ssl; server_name servername; ssl_certificate /etc/pki/tls/custom/server.pem; ssl_certificate_key /etc/pki/tls/custom/server.key; ssl_session_timeout 5m; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/pki/tls/dh/dh.pem; ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/pki/tls/certs/custom/oscp-bundle.pem; resolver 8.8.8.8 valid=300s; resolver_timeout 10s; location / { proxy_pass http://127.0.0.1; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-SSL-Protocol $ssl_protocol; proxy_set_header X-SSL-Cipher $ssl_cipher; proxy_set_header Host $host; proxy_max_temp_file_size 0; } }Konfiguracja po stronie Apache
LogFormat "%V %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vcombined LogFormat "%V %{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{X-SSL-Protocol}i %{X-SSL-Cipher}i" vproxy SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on CustomLog "access.log" vcombined env=!forwarded CustomLog "access.log" vproxy env=forwarded
Wersja BIND
dig @nameserver version.bind txt chaos
nslookup -type=txt -class=chaos version.bind nameserver
czwartek, 30 stycznia 2014
Konfiguracja TLS - ocena SSL Labs
Uzyskanie wysokiej oceny w teście SSL Labs nie jest sztuką dla sztuki.Prawidłowa konfiguracja TLS zwiększa bezpieczeństwo jaki i aspekt wizerunkowy naszej strony.
Niestety uzyskanie poniższej oceny w chwili pisania tych słów nie jest praktyczne.
https://www.ssllabs.com/ssltest/analyze.html?d=monitor.socha.it
Wersja offline
Ze stroną o tym adresie https://monitor.socha.it aktualnie można połączyć się wyłącznie za pomocą przeglądarek takich jak Chrome, Internet Explorer 11 czy wybranych wersji Safari (zarówno OSX jak i iOS). Nie uda się nam to za pomocą Firefoxa. Jego stabilna wersja o numerze 26 obsługuję tylko połączenia TLS 1.0 lub SSLv3. Wersja Firefox 27 (BETA) posiada już wsparcie dla TLS 1.2. Poważnym problem może być też googlebot, który również nie będzie w stanie nawiązać połączenia. Taka sytuacja może być bardzo niekorzystna dla naszej strony.
Uzyskanie punktacji na poziomie 100 w każdym z czterech testów może wydawać się wyzwaniem czysto akademickim. W przypadku mojej strony jest to świadomie podjęta decyzją i zaakceptowanie konsekwencji wynikających z zmniejszonej niedostępności strony.
Bardziej praktyczna konfiguracja TLS dostępna jest na stronie https://www.robi-net.it/
https://www.ssllabs.com/ssltest/analyze.html?d=www.robi-net.it
Wersja offline
Konfiguracja dla tej strony pozwala na znacznie szerszy dostęp poprzez większość aktualnych przeglądarek.
Jak uzyskać wysoki wynik, a co za tym idzie bezpieczniejszą konfigurację? Dokładny opis co jest testowane i jak ważone dostępny jest pod adresem https://www.ssllabs.com/projects/rating-guide/index.html. Skrótowo opiszę wymagania dla uzyskania wyniku 100 w każdym z testów.
Jako ciekawostkę zamieszczam skan strony Ministerstwa Administracji i Cyfryzacji.
https://www.ssllabs.com/ssltest/analyze.html?d=mac.gov.pl
Wersja offline
Wynik skanu jest dość niepokojący. Protokół TLS 1.2 został zdefiniowany w sierpniu 2008. Natomiast obsługa TLS 1.2 w popularnej bibliotece openssl jest od marca 2012 (wersja 1.0.1).
Brak obsługi Forward Secrecy można być "ryzykowany" w czasach gdy głowy państw są podsłuchiwane :)
Testy innych stron w domenie gov.pl. Oceny pozostawiam bez komentarza.
Strona logowania do systemu EPUAP
https://www.ssllabs.com/ssltest/analyze.html?d=hetman.epuap.gov.pl
Wersja offline
https://www.ssllabs.com/ssltest/analyze.html?d=epuap.gov.pl
Wersja offline
Strona Ministerstwa Infrastruktury i Rozwoju
https://www.ssllabs.com/ssltest/analyze.html?d=mir.gov.pl
Wersja offline
Strona Ministerstwa Edukacji Narodowej
https://www.ssllabs.com/ssltest/analyze.html?d=men.gov.pl
Wersja offline
Strona e-GIODO
https://www.ssllabs.com/ssltest/analyze.html?d=egiodo.giodo.gov.pl
Wersja offline
Strona Ministerstwa Transport (może niedługo przestać działać)
https://www.ssllabs.com/ssltest/analyze.html?d=transport.gov.pl
Wersja offline
Niestety uzyskanie poniższej oceny w chwili pisania tych słów nie jest praktyczne.
Wersja offline
Ze stroną o tym adresie https://monitor.socha.it aktualnie można połączyć się wyłącznie za pomocą przeglądarek takich jak Chrome, Internet Explorer 11 czy wybranych wersji Safari (zarówno OSX jak i iOS). Nie uda się nam to za pomocą Firefoxa. Jego stabilna wersja o numerze 26 obsługuję tylko połączenia TLS 1.0 lub SSLv3. Wersja Firefox 27 (BETA) posiada już wsparcie dla TLS 1.2. Poważnym problem może być też googlebot, który również nie będzie w stanie nawiązać połączenia. Taka sytuacja może być bardzo niekorzystna dla naszej strony.
Uzyskanie punktacji na poziomie 100 w każdym z czterech testów może wydawać się wyzwaniem czysto akademickim. W przypadku mojej strony jest to świadomie podjęta decyzją i zaakceptowanie konsekwencji wynikających z zmniejszonej niedostępności strony.
Bardziej praktyczna konfiguracja TLS dostępna jest na stronie https://www.robi-net.it/
https://www.ssllabs.com/ssltest/analyze.html?d=www.robi-net.it
Wersja offline
Jak uzyskać wysoki wynik, a co za tym idzie bezpieczniejszą konfigurację? Dokładny opis co jest testowane i jak ważone dostępny jest pod adresem https://www.ssllabs.com/projects/rating-guide/index.html. Skrótowo opiszę wymagania dla uzyskania wyniku 100 w każdym z testów.
- Certificate
Każdy certyfikat wystawiony przez "zaufane" centrum certyfikacji. Nawet podstawowy certyfikat typu "domain-validated" będzie wystarczający.
- Protocol Support
Ocena zależy od protokołów obsługiwanych przez serwer. Wynik 95 uzyskamy udostępniając TLS 1.0, TLS 1.1 i TLS 1.2. Obecność protokołu SSLv3 obniży wynik. Aby uzyskać wynik 100 musimy oferować wyłącznie TLS 1.2.
- Key Exchange
Aby uzyskać wynik na poziomie 100 nasz klucz prywatny RSA musi mieć długość przynajmniej 4096 bitów.
Jeśli używamy algorytmów EDH/DHE lub ECDHE wymagane jest użycie wspólnego klucza/parametru DH o długości minimum 4096 bitów. Użycie klucza RSA krótszego niż 2048 bitów obniża ocenę (analogicznie dla DH).
- Cipher Strenght
Najwyższy wynik zapewnia użycie algorytmów szyfrujących posiadających długość klucza przynajmniej na poziomie 256 bitów (np. AES 256).
Jako ciekawostkę zamieszczam skan strony Ministerstwa Administracji i Cyfryzacji.
Skan wykonany 2014.01.30 |
Wersja offline
Wynik skanu jest dość niepokojący. Protokół TLS 1.2 został zdefiniowany w sierpniu 2008. Natomiast obsługa TLS 1.2 w popularnej bibliotece openssl jest od marca 2012 (wersja 1.0.1).
Brak obsługi Forward Secrecy można być "ryzykowany" w czasach gdy głowy państw są podsłuchiwane :)
Testy innych stron w domenie gov.pl. Oceny pozostawiam bez komentarza.
Strona logowania do systemu EPUAP
https://www.ssllabs.com/ssltest/analyze.html?d=hetman.epuap.gov.pl
Wersja offline
https://www.ssllabs.com/ssltest/analyze.html?d=epuap.gov.pl
Wersja offline
Strona Ministerstwa Infrastruktury i Rozwoju
https://www.ssllabs.com/ssltest/analyze.html?d=mir.gov.pl
Wersja offline
Strona Ministerstwa Edukacji Narodowej
https://www.ssllabs.com/ssltest/analyze.html?d=men.gov.pl
Wersja offline
Strona e-GIODO
https://www.ssllabs.com/ssltest/analyze.html?d=egiodo.giodo.gov.pl
Wersja offline
Strona Ministerstwa Transport (może niedługo przestać działać)
https://www.ssllabs.com/ssltest/analyze.html?d=transport.gov.pl
Wersja offline
poniedziałek, 13 stycznia 2014
Supermicro BIOS/IPMI Update
Przykład dla platformy Supermicro X9SCL(+)/X9SCM.
Pobranie aktualizacji BIOS i IPMI
Pobranie Rufs-a do tworzenia bootowalnych napędów USB.
Sesję IPMI należy uruchomić z uprawnieniami ADMINISTRATORA w celu podłączenia wirtualnego napędu USB.
Pobranie aktualizacji BIOS i IPMI
Pobranie Rufs-a do tworzenia bootowalnych napędów USB.
Sesję IPMI należy uruchomić z uprawnieniami ADMINISTRATORA w celu podłączenia wirtualnego napędu USB.
Subskrybuj:
Posty (Atom)