hemi

Może pokaż wynik? Jeśli nie chcesz pokazywać nazwy domeny to zrób screen całego wyniku i w jakims programie graficznym wymaż nazwę domeny.

Wybacz, nie doczytałem dobrze Twojej odpowiedzi ("Strona w stopce")... . Generalnie nie widze powodu aby Ci to nie działało na XP w FF. Na IE owszem może nie działać bo IE6 nie obsługuje SNI.

Niekoniecznie certyfikat od home jest tu problemem. konfiguracja serwera http także ma tu spore znaczenie. Zrób sobie test na https://www.ssllabs.com/ssltest/ i zobacz co zwraca. Test ten sprawdza między innymi jakie opcje masz włączone, jakie przeglądarki (lub inne klienty typu java, android etc) są obsługiwane i jakie opcje są zalecane. Można home nie lubic ale pierwsze słyszę aby ich certyfikaty nie obsługiwały ff czy chrome.

Postfix nie przesyła żadnego rekordu SPF bo SPF jest definiowane na poziomie domeny;). Problemem jest to, że forwardowane maile mają w nagłówkach adres oryginalnego nadawcy. Domena oryginalnego nadawcy może mieć własne rekordy SPF, które na 100% nie będą wskazywać Twojego serwera jako "uprawnionego" do wysyłania poczty z danej domeny.

Forwardowanie maili to ogolnie w moim przeświadczeniu zło i gdyby nie to, że wielu klientów z tego korzysta całkowicie zablokowałbym możliwość korzystania z tej funkcjonalności. W tej chwili zdecydowana większość providerów oferuje zaciąganie poczty z jednego konta na drugie za pomocą POP3 lub IMAP.

W przypadku, gdy forwardowani jest nieuniknione to polecałbym zainteresować się tematem SRS - Sender Rewrite Framework -> https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

Na sieci znajdziesz trochę informacji i tutoriali jak to zaimplementować, niektóre popularne panele hostingowe (np directadmin poprzez custombuild) ma to także zaimplementowane lepiej lub gorzej.

Nie wiem jak jest teraz ale rejestratory Dahua miały/mają dziurę w oprogramowaniu. Ostatnio znajomemu włąscicielowi pubu w mieście robiłem proste testy zabezpieczenia sieci w lokalu, 1.5 roczny (nowy w momencie zakupu rejestrator Dahua) udało mi się złamać w ciągu 20 min na zwyklym, 2 rocznym laptopie. Wystarczy, że ma wystawiony port 37777 na świat i każdy z odrobiną wiedzy to zrobi. Bez VPN tutaj nie obejdzie się.

https://github.com/depthsecurity/dahua_dvr_auth_bypass - moduł metasploita wyciągający praktycznie cały konfig z dahua (łacznie z hashami haseł), do tego w miare aktualny john the ripper z obsługą hashy dahua

Jedyny "problem" jaki widzę to każde zmiany DNS wykonywane przez panel Vesta będziesz musiał ręcznie ustawiać w CloudFlare -ale to na upartego dałoby się napisać plugin łączący się po API do CloudFlare i robiący to za Ciebie.

Generalnie przy konfiguracji bridge w ogole nie konfigurujesz interfejsu eth0. Całą konfigurację zawierasz w vmbr0. Konfig podany przez Ciebie powyzej powinien działać. Upewnij się, że nie masz odpalonego żadnego firewalla. Ewentualnie odpal maszyne w trybie vKVM - w hetznerze po odpaleniu trybu vKVM maszyna ma normalny dostep do sieci. Będziesz mógł na bierzaco zmieniać ustawienia sieci i testowac czy połączenie działa.

Czemu routing dodałeś do fizycznego urządzenia eth0 zamiast do vmbr0?

Ups, nie zauważyłem, że jednak routing jest dodany do vmbr0.

A czemu nie chcesz skorzystać z trybu bridged? Poza tym, że trzeba utworzyć wirtualny mac dla danego adresu IP w panelu Hetznera to wydaje mi się, że konfiguracja Bridged jest prostsza i mniej problemowa.

Skryptu nie kojarze ale jeśli sie sprawdzi to ok. Osobiscie uzywam zwyklego rsynca + na serwerze backupowym mam doinstalowaną paczkę skryptów zfstools, która zawiera miedzy innymi skrypt zfs-auto-snapshot. Ten skrypt konfigurujesz w ten sposob, że dodajesz go do crona z odpowiednimi parametrami i zapominasz. On automatycznie tworzy nowe snapshoty i wykonuje autorotacje snapshotow (usuwanie starych snapshotow). Potem dla każdego datasetu zfs, który chcesz miec automatycznie snapshotowany ustawiasz parametr zfs i tyle.

zfs set com.sun:auto-snapshot=true nazwa/datasetu/zfs

Generalnie w tym przypadku najlepiej sprawdziłby się ZFS + rsync z opcją --inplace jak ktoś wyżej sugerował. Snapshoty w ZFS działają bardzo dobrze (w zasadzie nie znam innego systemu plików z tak dobrą obsługą snapshotów), żeby się dostać do kopii z danego dnia wystarczy jedno polecenie zfs, znapshoty działają przyrostowo a więc trzymają tylko deltę zmian między kolejnymi dniami. ZFS obsługuje deduplikację choć w jej przypadku trzeba serwera z dość dużą ilością pamięci RAM. Do tego masz sprawdzanie poprawności danych w czasie rzeczywistym, możesz w każdym momencie uruchomić też scruba, który sprawdzi na żądanie poprawnośc danych blok po bloku (w tym momencie nadal możesz komfortowo korzystać z systemu bez zauważalnego spadku wydajności) etc etc etc.

Generalnie FreeBSD obsługuje natywnie ZFSa, na linuksa istnieje projekt ZfsOnLinux (używam go w takiej konfiguracji na proxmoxie i nie odnotowałem na razie żadnych problemów aczkolwiek nie zalecałbym go jeszcze w przypadku bardzo wrażliwych danych).

Mając dane na zfs'ie lokalnie + zfs na serwerach zdalnych możesz również przesyłać całe datasety danych (lub ich snapshoty przyrostowo) zamiast kopiować rsynciem plik po pliku przez sieć co też w jakiś sposób przyspieszy przesył danych.

Może coś z online.net? https://www.online.net/en/dedicated-server/dedibox-sc

Niskie ceny, łacze 1Gbps (co prawda nie gwarantowane ale z doswiadczenia wiem, że poniżej 700Mbps nie spada), procki Atom w zupelnosci Ci starczą. Z minusów to tylko 1 dysk a więc brak RAID, czyli w przypadku padu dysku tracisz to, co na nim było, ale wg tego co piszesz to i tak ma byc taki serwer pośredni do pchania plików dalej w świat wiec nie powinno Ci to robić róznicy.

 

adminer jest dzięki wielkie, podczyściłem 24k śmieci ;p

przydałby się jednak bardziej automatyczny sposób, czyszczący co tydzien

Mysql posiada cos takiego jak eventy (choc defaultowo wyłaczone). To jest coś a'la cron ale działający bezposrednio w bazie danych. Łap parę linków na ten temat:

http://blog.ksiazek.info/2011/09/29/events-cron-wewnatrz-mysql/

http://www.mysqltutorial.org/mysql-triggers/working-mysql-scheduled-event/

Generalnie zasada jest prosta. Piszesz sobie zapytanie DELETE, które ma Ci usuwać konkretne dane. Ten DELETE wpisujesz w eventa, którego z kolei konfigurujesz zeby odpalal sie np raz dziennie w nocy (lub co godzine, nie ma znaczenia, to już Twoj wybór).

A, no i event_scheduler z defaultu jest wyłaczony w mysql.

Najprosciej bedzie Ci wrzucic PMA albo adminera (jednoplikowy skrypcior z podstawową funkcjonalnością, na pewno mniejsze niż PMA).

Jeśli chcesz to zrobic z poziomu shella to:

[root@host ~]# mysql -u root -p 
mysql> show databases;
mysql> use nazwa_bazy
mysql> show tables;
mysql> describe nazwa_tabelki;

Możesz pominąć polecenia "show" jesli dokladnie wiesz jaką baze i tabelke potrzebujesz.

'describe' pokazuje strukture tabeli w bazie danych. Inny sposob na poznanie struktury to:

mysql> show create table nazwa_tabelki;

Aby łatwiej komukolwiek było Ci pomóc możesz też wkleić wynik zapytania (z ewentualną zamianą wrażliwych danych na XXXXX):

mysql> SELECT * FROM nazwa_tabelki LIMIT 1 \G

Polecenie \G wyświetli dane w bardziej przejrzysty sposób - działa tylko w mysql clilencie.

  SLAVE_ZONES_LIST=`ls -1 * | sed 's/.signed//g'`
  for zone in $SLAVE_ZONES_LIST; do
    echo $zone
  done

W tym kodzie w pierwszej linijce zamień '*' na '*.cos'

find /path/to/gdziestam -type f -name "*.txt" | cut -d '.' -f 1 > wynik.txt

find /path/to/gdziestam -type f -name "*.txt" | rev | cut -d '.' -f 2- | rev > wynik.txt

Tutaj dodaj '-exec basename', czyli:

find /path/to/gdziestam -type f -exec basename -name "*.txt" | cut -d '.' -f 1 > wynik.txt

find /path/to/gdziestam -type f -exec basename -name "*.txt" | rev | cut -d '.' -f 2- | rev > wynik.txt

 

Spójrz na timery w systemd: https://wiki.archlinux.org/index.php/Systemd/Timers
Osobiście nie miałem nigdy potrzeby pisać usługi z delayem ale myślę, że pod tym linkiem znajdziesz podpowiedź lub rozwiązanie

Może hosting dedykowany? W sensie dostajesz dedyka wstepnie skonfigurowanego z panelem (DA, CPanel). Do tego w zależności od ilosci danych bierzesz kilka dyskow i mirrorujesz wszystkie w raidzie (jesli nie zalezy Ci az tak bardzo na ilosci dostepnego miejsca) wtedy tak naprawde moze Ci pasc N-1 dysków (gdzie N to calkowita ilosc dyskow) i nadal wszystko bedzie smigac.

Do tego osobny serwer tylko pod backup offsite. Najlepiej w innej lokalizacji niz serwer glowny.

Sprawdz access logi. Jeśli to atak na xmlrpc to bedziesz mial spoooooro requestów na ten plik. Sprawdz także w jaki sposob ten xmlrpc jest blokowany. Jak po stronie php (jakies IFy etc) to nie wiem czy to pomoze duzo. Sprawdz czy masz to blokowane np na poziomie htaccess.

Sprawdz tez w netstacie czy jakis adres się nie "wybija" ponad inne w ilości połączeń do serwera:

netstat -plan|grep :80|awk '{print $5}'|cut -d: -f 1|sort|uniq -c|sort -n

Czemu mialyby nie dzialac? NAT działa na innym poziomie stacka TCP, NAT routuje Ci calutki ruch tak, jak sobie to skonfigurujesz przez iptables. Co innego jak byś się bawił w np proxowanie ruchu przez nginxa, squida czy inne aplikacje, które wtedy już działają na innym poziomie .

Znalazłem jeszcze coś takiego (problem wydaje sie taki sam, jak Twój): http://serverfault.com/questions/452183/keep-source-ip-after-nat

Kurcze, nie mam akurat pod ręką żadnej matki z kontenerami lxc więc ciężko mi samemu sprawdzić Twój problem, ogólnie jednak pamiętam, że konfigurując kiedyś dla jednego klienta serwer (aczkolwiek bez CSF na matce) nie miałem takiego problemu, tzn adres źródłowy połączenia był poprawnie widziany przez np apache w kontenerze po utworzeniu odpowiedniej reguły iptables.

Wg dokumentacji CSF:

 

 

All redirections to another IP address will always appear on the destination
server with the source of this server, not the originating IP address.

W samej dokumentacji csf także nie ma jako tako opcji NATowania portu (a o to Ci w tym momencie chodzi).

Spróbuj zrobić to wg tej instrukcji: https://blackonsole.org/how-to-add-nat-iptables-rules-with-csf/

Możesz jeszcze dodatkowo skonfigurować rekordy SRV tak, aby po wpisaniu w kliencie jabbera loginu np login@domena.pl klient od razu "wiedzial" (oraz inne serwery, które będą łączyć się z Twoim serwerem) , ze ma się faktycznie łączyć na xmpp.domena.pl

I analogicznie drugi podobny rekord ale z wartosciami:
Service name: _xmpp-server

Port: 5269

Bez logów apache i php to możemy co najwyżej powróżyć ze szklanej kuli .

Przecież równie dobrze można skonfigurować proxy dla requestów z określonym URI, niepotrzebny tu sieciowy system plikow... O ile potrzebny jest tylko odczyt tych plików, z uploadem jest trochę więcej roboty.

Zależy co masz na mysli "podpis cyfrowy".

DKIM to standard uzywany do zapobiegania podszywaniu się pod serwer poczty, tzn w DNS definiujesz publiczny klucz, z którym porównywany jest klucz, którym podpisany został dany email. Jeśli klucze się zgadzają oznacza to, że mail został wysłany z autoryzowanego przez Ciebie serwera pocztowego.

Możesz także podpisać każdą wysłaną wiadomość podpisem kwalifikowanym (wydanym przez urząd certyfikacji) - w tym wypadku certyfikat potwierdza, że został wysłany przez Ciebie, odbiorca może podejrzeć zawartość certyfikatu tak, jakbyś podglądał certyfikat w przeglądarce.

Jest jeszcze opcja podpisywania lub szyfrowania poczty np za pomocą PGP ale tu już trzeba się wymienić kluczami z odbiorcą maila.

http://www.pcworld.pl/news/393866/Poczta.e.mail.pewna.i.bezpieczna.html

CloneZilla z darmowych -> https://www.thomas-krenn.com/pl/wiki/Klonowanie_programem_Clonezilla_dysku_z_systemem_Windows

Używam w firmie (2 różne konfiguracje komputerów biurowych, 2 osobne obrazy dysków) + udział smb na serwerze współdzielonym i śmiga bezproblemowo.

No dobra, ale w tym wypadku ovh ma dwie opcje żeby legalnie i bez płacenia udostępniać dalej ubuntu do instalacji na serwerach:

1. udostępnić czystego ubuntu, bez zmian i poprawek ovh + osobna paczka własnych zmian, które użytkownik może na własną rękę doinstalować - wtedy nie będą w żaden sposób łamać licencji ubuntu.
2. zrekompilować całe ubuntu wywalając wszelkie znaki towarowe Canonicala i nazwać to np Ovh OS + dopisek, że jest to na bazie systemu Ubuntu.

Canonical w tym przypadku przyczepił się do tego, że ovh udostępnia zmodyfikowany system podpisany jako Ubuntu, czyli wlasny kernel, wlasne poprawki pod infrastrukturę ovh.