{"id":78514,"date":"2020-04-20T01:42:32","date_gmt":"2020-04-19T23:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos"},"modified":"2020-04-20T01:42:32","modified_gmt":"2020-04-19T23:42:32","slug":"kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","title":{"rendered":"Come proteggere i processi e le estensioni del kernel in macOS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr! Oggi vorrei parlare di come si possano proteggere i processi dagli attacchi degli aggressori in macOS. Ad esempio, questo \u00e8 utile per un antivirus o un sistema di backup, soprattutto alla luce del fatto che in macOS esistono diversi modi per \"terminare\" un processo. Di questo e dei metodi di protezione ne parler\u00f2 di seguito.<\/p>\n

\"Come<\/a><\/noindex>
\n<\/a><\/noindex><\/p>\n

Il modo classico per \"terminare\" un processo<\/h3>\n

\nIl modo pi\u00f9 conosciuto per \"terminare\" un processo \u00e8 inviare un segnale SIGKILL al processo. Tramite bash \u00e8 possibile eseguire i classici \"kill -SIGKILL PID\" o \"pkill -9 NAME\" per terminare. Il comando \"kill\" \u00e8 conosciuto fin dai tempi di UNIX ed \u00e8 disponibile non solo in macOS, ma anche in altri sistemi simili a UNIX.<\/p>\n

Come nei sistemi simili a UNIX, macOS consente di intercettare qualsiasi segnale per un processo, tranne due: SIGKILL e SIGSTOP. In questo articolo ci concentreremo principalmente sul segnale SIGKILL, come segnale che provoca l'uccisione del processo.<\/p>\n

Specificit\u00e0 di macOS
\n<\/h3>\n

\nIn macOS, la chiamata di sistema kill nel kernel XNU richiama la funzione psignal(SIGKILL,…). Vediamo quali altre azioni dell'utente nello userspace possono attivare la funzione psignal. Escludiamo le chiamate alla funzione psignal nei meccanismi interni del kernel (anche se esse potrebbero non essere banali, ma le lasceremo per un altro articolo \ud83d\ude42 \u2014 verifica della firma, errori di memoria, gestione exit\/terminate, violazione della protezione dei file, ecc. <\/p>\n

Cominciamo la panoramica con la funzione e la relativa chiamata di sistema terminate_with_payload<\/a><\/noindex>. \u00c8 evidente che, oltre alla chiamata classica kill, esiste un approccio alternativo, specifico per il sistema operativo macOS e non presente in BSD. I principi di funzionamento di entrambe le chiamate di sistema sono similari. Rappresentano chiamate dirette alla funzione del kernel psignal. Notiamo anche che, prima di terminare un processo, viene eseguita una verifica \"cansignal\" - pu\u00f2 il processo inviare un segnale a un altro processo, il sistema non consente a nessuna applicazione di terminare processi di sistema, ad esempio.<\/p>\n

static int\nterminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,\n\t\t\t\tuint64_t reason_code, user_addr_t payload, uint32_t payload_size,\n\t\t\t\tuser_addr_t reason_string, uint64_t reason_flags)\n{\n...\n\ttarget_proc = proc_find(target_pid);\n...\n\tif (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {\n\t\tproc_rele(target_proc);\n\t\treturn EPERM;\n\t}\n...\n\tif (target_pid == cur_proc->p_pid) {\n\t\t\n\t\t\/*\n\t\t * psignal_thread_with_reason() attender\u00e0 un SIGKILL sul thread specificato o\n\t\t * restituir\u00e0 se il thread e\/o il task sono gi\u00e0 in fase di terminazione. In ogni caso,\n\t\t * il thread attuale non torner\u00e0 nello spazio utente.\n\t\t * \/\n\t\tpsignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);\n\t} else {\n\t\tpsignal_with_reason(target_proc, SIGKILL, signal_reason);\n\t}\n...\n}\n<\/code><\/pre>\n
<\/p>\n
launchd<\/h3>\n
\nIl modo standard per creare demoni all'avvio del sistema e controllarne il ciclo di vita \u00e8 launchd. Vorrei sottolineare che i codici sorgente forniti si riferiscono a una versione precedente di launchctl, prima di macOS 10.10, e gli esempi di codice sono forniti solo a scopo illustrativo. La moderna launchctl invia segnali a launchd tramite XPC, e la logica di launchctl \u00e8 stata trasferita in esso.<\/p>\n
Vediamo come viene effettivamente fermata l'applicazione. Prima di inviare il segnale SIGTERM, si cerca di fermare l'applicazione utilizzando la chiamata di sistema \"proc_terminate\".<\/p>\n
...\n\terror = proc_terminate(j->p, &sig);\n\tif (error) {\n\t\tjob_log(j, LOG_ERR | LOG_CONSOLE, \"Impossibile terminare il lavoro: %d: %s\", error, strerror(error));\n\t\tjob_log(j, LOG_NOTICE | LOG_CONSOLE, \"Utilizzando l'opzione di fallback per terminare il lavoro...\");\n\t\terror = kill2(j->p, SIGTERM);\n\t\tif (error) {\n\t\t\tjob_log(j, LOG_ERR, \"Impossibile segnalare il lavoro: %d: %s\", error, strerror(error));\n\t\t} \n...\n<\/code><\/pre>\n
\nSotto il cofano, proc_terminate, nonostante il suo nome, pu\u00f2 inviare non solo psignal con SIGTERM, ma anche SIGKILL.<\/p>\n
Uccisione indiretta \u2014 limitazione delle risorse<\/h3>\n
\nUn caso pi\u00f9 interessante pu\u00f2 essere visto in una diversa chiamata di sistema process_policy<\/a><\/noindex>. L'uso standard di questa chiamata di sistema consiste nel porre limitazioni sulle risorse delle applicazioni, ad esempio per l'indicizzatore una limitazione sulla quota di tempo di CPU e memoria, in modo che il sistema non venga rallentato in modo significativo dalle operazioni di caching dei file. Se un'applicazione supera il limite delle risorse, come si pu\u00f2 vedere dalla funzione proc_apply_resource_actions, al processo viene inviato il segnale SIGKILL.<\/p>\n
Nonostante questa chiamata di sistema possa potenzialmente causare l'uccisione di un processo, il sistema non ha verificato adeguatamente i diritti del processo che invoca la chiamata di sistema. In realt\u00e0, la verifica esisteva<\/a><\/noindex>, ma \u00e8 sufficiente utilizzare l'alternativa del flag PROC_POLICY_ACTION_SET per aggirare questa condizione.<\/p>\n
Da qui, se si \u201climita\u201d la quota di utilizzo della CPU per l'applicazione (ad esempio, consentendo di eseguire solo 1 ns), si pu\u00f2 terminare qualsiasi processo nel sistema. Cos\u00ec, un malware pu\u00f2 terminare qualsiasi processo nel sistema, incluso quello dell'antivirus. Interessante \u00e8 anche l'effetto che si ottiene terminando il processo con pid 1 (launchctl) \u2014 un kernel panic quando si tenta di elaborare il segnale SIGKILL \ud83d\ude42<\/p>\n
\"Come
\n<\/p>\n
Come risolvere il problema?<\/h3>\n
\nIl modo pi\u00f9 diretto per impedire l'uccisione di un processo \u00e8 sostituire il puntatore alla funzione nella tabella delle chiamate di sistema. Sfortunatamente, questo metodo non \u00e8 banale per molte ragioni.<\/p>\n
In primo luogo, il simbolo che rappresenta la posizione di sysent in memoria non \u00e8 solo un simbolo privato del kernel XNU, ma non pu\u00f2 nemmeno essere trovato nei simboli del kernel. Sar\u00e0 necessario utilizzare metodi euristici di ricerca, come la disassemblazione dinamica della funzione e la ricerca del puntatore al suo interno.<\/p>\n
In secondo luogo, la struttura delle voci nella tabella dipende dai flag con cui \u00e8 stato compilato il kernel. Se \u00e8 stato dichiarato il flag CONFIG_REQUIRES_U32_MUNGING, la dimensione della struttura verr\u00e0 modificata: verr\u00e0 aggiunto un campo aggiuntivo. sy_arg_munge32<\/a><\/noindex>. \u00c8 necessaria una verifica aggiuntiva riguardo al flag con cui \u00e8 stato compilato il kernel, ad esempio confrontando i puntatori alle funzioni con quelli noti.<\/p>\n
struct sysent {         \n        \/* tabella delle chiamate di sistema *\/\n        sy_call_t       *sy_call;       \/* funzione di implementazione *\/\n#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))\n        sy_munge_t      *sy_arg_munge32; \/* munger degli argomenti delle chiamate di sistema per processi a 32 bit *\/\n#endif\n        int32_t         sy_return_type; \/* tipi di ritorno delle chiamate di sistema *\/\n        int16_t         sy_narg;        \/* numero di argomenti *\/\n        uint16_t        sy_arg_bytes;   \/* Dimensione totale degli argomenti in byte per\n                                         * chiamate di sistema a 32 bit *\/\n};\n<\/code><\/pre>\n
\nFortunatamente, nelle versioni moderne di macOS, Apple fornisce una nuova API per lavorare con i processi. L'Endpoint Security API consente ai client di autorizzare molte richieste ad altri processi. Cos\u00ec, \u00e8 possibile bloccare qualsiasi segnale ai processi, incluso il segnale SIGKILL, tramite l'API sopra menzionata.<\/p>\n
#include <bsm\/libbsm.h>\n#include <EndpointSecurity\/EndpointSecurity.h>\n#include <unistd.h>\n\nint main(int argc, const char * argv[]) {\n    es_client_t* cli = nullptr;\n    {\n        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {\n            switch (message->event_type) {\n                case ES_EVENT_TYPE_AUTH_SIGNAL:\n                {\n                    auto& msg = message->event.signal;\n                    auto target = msg.target;\n                    auto& token = target->audit_token;\n                    auto pid = audit_token_to_pid(token);\n                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);\n                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);\n                }\n                    break;\n                default:\n                    break;\n            }\n        });\n    }\n\n    {\n        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };\n        es_subscribe(cli, evs, sizeof(evs) \/ sizeof(*evs));\n    }\n\n    printf("%dn", getpid());\n    sleep(60); \/\/ could be replaced with other waiting primitive\n\n    es_unsubscribe_all(cli);\n    es_delete_client(cli);\n\n    return 0;\n}\n<\/code><\/pre>\n
\nAllo stesso modo, nel kernel \u00e8 possibile registrare una MAC Policy, che fornisce un metodo di protezione dai segnali (policy proc_check_signal), ma l'API non \u00e8 ufficialmente supportata.<\/p>\n
Protezione dell'estensione del kernel<\/h3>\n
\nOltre alla protezione dei processi nel sistema, \u00e8 assolutamente necessaria anche la protezione dell'estensione del kernel stesso (kext). macOS fornisce ai desenvolvedores un framework per lo sviluppo di driver di dispositivi IOKit. Oltre a fornire strumenti per lavorare con i dispositivi, IOKit offre metodi per lo stacking dei driver tramite istanze di classi C++. L'applicazione nello userspace sar\u00e0 in grado di \"trovare\" l'istanza registrata della classe per stabilire una connessione kernel-userspace.<\/p>\n
Per rilevare il numero di istanze delle classi nel sistema esiste l'utilit\u00e0 ioclasscount.<\/p>\n
my_kext_ioservice = 1\nmy_kext_iouserclient = 1\n<\/code><\/pre>\n
\nQualsiasi estensione del kernel che desideri registrarsi nello stack dei driver deve dichiarare una classe ereditata da IOService, ad esempio, my_kext_ioservice in questo caso. La connessione delle applicazioni personalizzate causa la creazione di una nuova istanza della classe, che \u00e8 ereditata da IOUserClient, nell'esempio my_kext_iouserclient.<\/p>\n
Quando si tenta di scaricare un driver dal sistema (comando kextunload), viene invocata la funzione virtuale \"bool terminate(IOOptionBits options)\". \u00c8 sufficiente restituire false alla chiamata della funzione terminate in caso di tentativo di scaricamento per impedire kextunload.<\/p>\n
bool Kext::terminate(IOOptionBits options)\n{\n\n  if (!IsUnloadAllowed)\n  {\n    \/\/ Il caricamento non \u00e8 consentito, restituzione false\n    return false;\n  }\n\n  return super::terminate(options);\n}\n\n<\/code><\/pre>\n
\nIl flag IsUnloadAllowed pu\u00f2 essere impostato da IOUserClient durante il caricamento. In caso di limitazione al caricamento, il comando kextunload restituir\u00e0 il seguente output:<\/p>\n
admin@admins-Mac drivermanager % sudo kextunload .\/test.kext\nPassword:\n(kernel) Impossibile rimuovere kext my.kext.test; i servizi non sono riusciti a terminare - 0xe00002c7.\nImpossibile scaricare my.kext.test - (iokit\/common) funzione non supportata.\n<\/code><\/pre>\n
\n\u00c8 necessario fornire una protezione simile anche per IOUserClient. Le istanze delle classi possono essere scaricate tramite la funzione userspace IOKitLib \"IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);\". Puoi restituire false alla chiamata del comando \"terminate\" fino a quando l'applicazione userspace non \"muore\", ovvero non viene chiamata la funzione \"clientDied\".<\/p>\n
Protezione dei file<\/h3>\n
\nPer proteggere i file, \u00e8 sufficiente utilizzare l'API Kauth, che consente di limitare l'accesso ai file. Apple fornisce agli sviluppatori notifiche su vari eventi nel proprio ambito; per noi sono importanti le operazioni KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA e KAUTH_VNODE_DELETE_CHILD. Limitare l'accesso ai file \u00e8 pi\u00f9 semplice tramite il percorso: utilizziamo l'API \u201cvn_getpath\u201d per ottenere il percorso del file e confrontiamo il prefisso del percorso. Si noti che per ottimizzare la ridenominazione dei percorsi delle cartelle con file, il sistema non autorizza l'accesso a ciascun file, ma solo alla cartella stessa che \u00e8 stata rinominata. \u00c8 necessario confrontare il percorso genitore e limitare KAUTH_VNODE_DELETE per essa.<\/p>\n
\"Come
\n
\nUno svantaggio di questo approccio pu\u00f2 essere la bassa prestazione quando aumenta il numero di prefissi. Affinch\u00e9 il confronto non sia pari a O(prefisso*lunghezza), dove prefisso \u00e8 il numero di prefissi e lunghezza \u00e8 la lunghezza della stringa, \u00e8 possibile utilizzare un automa a stati finiti deterministico (DFA) costruito sui prefissi. <\/p>\n
Prendiamo in considerazione il modo di costruire un DFA per questo insieme di prefissi. Iniziamo posizionando i cursori all'inizio di ogni prefisso. Se tutti i cursori puntano allo stesso simbolo, incrementiamo ogni cursore di un simbolo e annotiamo che la lunghezza della stringa identica \u00e8 aumentata di uno. Se ci sono due cursori e i simboli sotto di essi sono diversi, dividiamo i cursori in gruppi in base al simbolo su cui puntano e ripetiamo l'algoritmo per ogni gruppo.<\/p>\n
Nel primo caso (tutti i simboli sotto i cursori sono identici), otteniamo uno stato del DFA con solo una transizione tramite la stringa identica. Nel secondo caso, otteniamo una tabella di transizioni di dimensione 256 (numero di simboli e numero massimo di gruppi) agli stati successivi, ottenuti tramite una chiamata ricorsiva della funzione.<\/p>\n
Consideriamo un esempio. Per l'insieme di prefissi (\u201c\/foo\/bar\/tmp\/\u201d, \u201c\/var\/db\/foo\/\u201d, \u201c\/foo\/bar\/aba\/\u201d, \u201cfoo\/bar\/aac\/\u201d) \u00e8 possibile ottenere il seguente DFA. Nell'immagine sono indicati solo le transizioni che portano ad altri stati; le altre transizioni non saranno finali.<\/p>\n
\"Come
\n
\nDurante il passaggio tra gli stati del DFA, ci possono essere 3 casi.<\/p>\n
    \n
  1. \u00c8 stato raggiunto uno stato finale: il percorso \u00e8 protetto, limitando le operazioni KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA e KAUTH_VNODE_DELETE_CHILD.<\/li>\n
  2. Non \u00e8 stato raggiunto uno stato finale, ma il percorso \u201c\u00e8 terminato\u201d (\u00e8 stato raggiunto il terminatore zero) \u2014 il percorso \u00e8 genitore, \u00e8 necessario limitare KAUTH_VNODE_DELETE. Notiamo che se il vnode \u00e8 una cartella, \u00e8 necessario aggiungere alla fine \u2018\/\u2019, altrimenti pu\u00f2 avvenire una limitazione al file \u201c\/foor\/bar\/t\u201d, il che \u00e8 errato.<\/li>\n
  3. Non \u00e8 stato raggiunto uno stato finale, il percorso non \u00e8 terminato. Nessuno dei prefissi corrisponde a questo, non introduciamo limitazioni.<\/li>\n<\/ol>\n
    <\/p>\n
    Conclusione<\/h3>\n
    \nL'obiettivo delle soluzioni di sicurezza in fase di sviluppo \u00e8 aumentare il livello di sicurezza dell'utente e dei suoi dati. Da un lato, questo obiettivo \u00e8 garantito dallo sviluppo del prodotto software Acronis, che chiude le vulnerabilit\u00e0 dove la stessa operativa \u00e8 \u201cdebole\u201d. Dall'altro lato, non si dovrebbe trascurare il potenziamento degli aspetti di sicurezza che possono essere migliorati anche a livello di OS, tanto pi\u00f9 che la chiusura di tali vulnerabilit\u00e0 aumenta la nostra stessa resilienza come prodotto. La vulnerabilit\u00e0 \u00e8 stata segnalata al Team di Sicurezza dei Prodotti Apple ed \u00e8 stata corretta in macOS 10.14.5 (https:\/\/support.apple.com\/en-gb\/HT210119).<\/p>\n
    \"Come
    \n
    \nTutto ci\u00f2 pu\u00f2 essere fatto solo se la tua utility \u00e8 stata ufficialmente installata nel kernel. Vale a dire che per software esterno e indesiderato non ci sono tali scappatoie. Tuttavia, come vedi, anche per proteggere programmi legittimi, come antivirus e sistema di backup, \u00e8 necessario lavorare sodo. Ma ora i nuovi prodotti Acronis per macOS avranno una protezione aggiuntiva contro il caricamento dal sistema.
    \n
    Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u044d\u0442\u043e \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0434\u043b\u044f \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u0430 \u0438\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0441\u0432\u0435\u0442\u0435 \u0442\u043e\u0433\u043e \u0447\u0442\u043e \u043f\u043e\u0434 macOS \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0437\u0430\u0449\u0438\u0442\u044b \u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u043f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c. \u041a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0412\u0441\u0435\u043c \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":78515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-78514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come proteggere i processi e le estensioni del kernel in macOS | ProHoster","description":"Ciao, Habr! Oggi vorrei parlare di come proteggere i processi contro le intrusioni di malintenzionati in macOS.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u0449\u0438\u0449\u0430\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u0438 \u0440\u0430\u0441\u0448\u0438\u0440\u0435\u043d\u0438\u044f \u044f\u0434\u0440\u0430 \u0432 macOS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-19T23:42:32+00:00","article:modified_time":"2020-04-19T23:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"78514","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:56:36","updated":"2022-09-28 22:19:40","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/78514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=78514"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/78514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/78515"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=78514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=78514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=78514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}