Skocz do zawartości

Jishnu

Użytkownicy
  • Zawartość

    44
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    3

Posty napisane przez Jishnu


  1. Ataki DDoS to problem, nie każda serwerownia sobie potrafi poradzić. Chwali się, że nazwa sobie poradziła ale

    - bez przesady, to nie jest spektakularny sukces tylko zdrowe podejście do tematu,

    - nie trzeba od razu wszystkim rozsyłać maili spamowych z informacją o tym wielkim 'sukcesie',

    - jeśli już podaje się informacje to fajnie by było zobaczyć szczegóły, wykresy, cokolwiek.

     


  2. System płatności Homepay ma problemy. Niektórzy z jego partnerów nie dostają pieniędzy od 2 miesięcy, a część klientów telefonicznie dowiedziała się, że przestój może potrwać kolejne 2 miesiące. Spółka początkowo milczała, po czym dość niespodziewanie ogłosiła przejęcie.

    źródło:

    https://niebezpiecznik.pl/post/problemy-homepay-partnerzy-nie-otrzymuja-pieniedzy-a-spolka-milczy/


  3. Zautomatyzować można cronem

    Przykład dostępny jest TUTAJ

     

    Generalnie w cronie trzeba dodać coś takiego:

    0    0  *  *  * root    /opt/certbot/certbot-auto renew --post-hook "/usr/sbin/apachectl restart" 2>&1
    

    W podanym przeze mnie przykładzie jest "--post-hook "/usr/sbin/apachectl restart"" - aby po wygenerowaniu nowego certyfikatu zrestartować apache / dla nginxa będzie trzeba odpowiednio zmienić


  4. Wygląda na to, że brakuje wpisów ssl dla vhostów z www.

    Dla domeny ssl dla której nie ma wpisu wyświetlana jest pierwsza dostępna a tam nie ma ustawionego odpowiedniego przekierowania

     

    Jest:

    server {
            listen 80;
            listen [::]:80;
    
            server_name www.jenkins.eka.ovh;
            return 301 https://jenkins.eka.ovh$request_uri;
    }
    

    powinno być:

    server {
            listen 80;
            listen [::]:80;
    
            listen 443 ssl; # managed by Certbot
            ssl_certificate /etc/letsencrypt/live/eka.ovh/fullchain.pem; # managed by Certbot
            ssl_certificate_key /etc/letsencrypt/live/eka.ovh/privkey.pem; # managed by Certbot
            include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
            ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    
    
            server_name www.jenkins.eka.ovh;
            return 301 https://jenkins.eka.ovh$request_uri;
    }
    

    i analogicznie dla drugiej domeny..

    • Upvote 2

  5. komenda:

    openssl x509 -noout -text -in certyfikat.crt | grep DNS:
    

    powinna zwrócić cośtakiego:

    DNS:www.example.com, DNS:example.com
    

    w przeciwnym wypadku (jeśli będzie brakowało DNS:www.example.com) będzie błąd certyfikatu.

     

    W pierwszej kolejności następuje połączenie SSL/TLS a dopiero później przekierowania więc jeśli wpiszemy www.example.com a certyfikat mamy wygenerowany tylko na example.com to mamy błąd.

     

    EDIT:

    Dodatkowo dla vhosta www.example.com musisz mieć dodany certyfikat w konfiguracji - tak jak dla example.com

     

    Najprościej będzie zrobić jak zasugerował @GieBe

    • Upvote 1

  6. Nastały ciężkie czasy, albo jesteś rekinem albo zostajesz pożarty przez inne rekiny.

    Dużo firm zostało pożartych przez co ich jakość(support) spadła, cena i oferta upodobniła się do firmy-matki.

    Nawet to forum się ‘zmieniło’ :)

    Inna sprawa, że często moda wygrywa wobec czego firmy korzystają głównie z panelu A bo ludzie są do niego przyzwyczajeni i migracja między tymi panelami jest bezproblemowa.

    W dalszym ciągu jest sporo firm godnych polecenia jednak nie polecę żadnej bo to niezgodne z nowym regulaminem.


  7.  

    Jeśli już to przekierowanie domeny.

     

    Ustawienie cname sprawi tylko to, że domena xyz.pl będzie się rozwiązywała do IP domeny abc.pl. A jak serwer nie jest skonfigurowany żeby obsługiwać domenę xyz.pl to wyświetli się domyślna strona i niekoniecznie będzie to strona abc.pl. To po pierwsze.

     

    A po drugie. W jaki sposób miałby wtedy serwować swoją zawartość z podkatalogów xyz.pl kiedy cały ruch będzie przekierowany na abc.pl?

     

    To też przekierowuje cały ruch. Jeśli koniecznie chcemy .htaccess to wg mnie powinno to wyglądać mniej więcej tak:

    Jeśli wywołanie to XYZ.pl (z i bez www) z dokładnie 0 lub 1 slashem (/) to przekieruj na ABC.pl. W pozostałych przypadkach nie rób nic.

     

    Chcemy przekierować tylko następujące wywołania:

    XYZ.pl, www.XYZ.pl, XYZ.pl/, www.XYZ.pl/ , xyz.pl/index.php itd.

     

    1. Masz rację. Z tą uwagą, że nie powinno się w ogóle robić CNAME czystadomena.pl (bez www) na coś innego.

     

    2. Czytając w pośpiechu nie zwróciłem uwagi na istotę rzeczy - czyli rozwiązanie coś ala proxy wobec czego moje rozwiązanie było błędne

     

    Co do innego rozwiązania to jest jeszcze coś takiego jak mod_proxy tylko nie wiadomo czy na sharedzie będzie działać

     


  8.  

     

    czyli

    "Twoje wszystkie długie i unikalne hasła są tak bezpieczne jak 1 hasło do Windowsa gdzie są zapisane te wszystkie hasła"

     

    Chyba chodziło o dobry manager haseł jak np KeePass, który dodatkowo szyfruje worek z hasłami.

    Aby odszyfrować zapisane hasła potrzeba klucz i hasło klucza.

     

    Nie zmienia to faktu, że jeśli ktoś się włamie na windowsa to ma duże pole do popisu.

     

    Co do tematu to ja "obsługuję strony" jak neandertal - vimem :)


  9. fail2ban - moduł sklepu + usługa

    albo tymczasowo

    Jeśli administrator sklepu łączy się z jednego/dwóch/kilku IP dodać w katalogu admin79 plik .htaccess

    <Files *.php>
    <Limit GET POST>
    Order Deny,Allow
    Deny from all
    Allow from 1.2.3.4
    Allow from 1.2.4.5
    </Limit>
    <LimitExcept GET POST>
    Order Deny,Allow
    Deny from all
    Allow from 1.2.3.4
    Allow from 1.2.4.5
    </LimitExcept>
    </Files>
    ErrorDocument 403 "Hakerom dziękujemy"
    

  10. Ktoś/coś często odwiedza jedną lub kilka stron trzymanych na serwerze.

    Korzystasz pewnie z mod_php i dlatego w procesach widać duże obciążenie generowane przez http - apache.

     

    Musisz zerknąć w logi apache'a i sprawdzić która ze stron generuje takie obciążenie.

    Strzelam, że masz jakąś joomlę i jest dużo 'wejść' na zaplecze /administrator - bo ktoś zgaduje hasło :)

     

    Jak już będzie wiadomo co generuje taki ruch to będzie można coś zaradzić - np fail2ban + joomla

    Gorzej jeśli jest jakaś mocno rozbudowana strona z kiepską optymalizacją i ktoś po prostu ją jakimś skryptem 'odświeża' generując taki ruch

     

×