Saltar para o conteúdo 
Direcionado Montagem do sistema de ficheiros-As opções reforçam a segurança do meu servidor Linux ao nível do sistema de ficheiros e bloqueiam ataques típicos através de caminhos temporários, binários setuid e ficheiros de dispositivo. Defino parâmetros de montagem claros, tais como noexec, defina os parâmetros nosuid e nodev para determinar o que é permitido em cada partição e, assim, reduza significativamente o risco de escalada de privilégios.
Pontos centrais
Os pontos-chave que se seguem constituem uma introdução direta à configuração segura das opções de montagem e apresentam medidas concretas para Reforço da segurança do servidor e funcionamento.
- noexec/nosuid/nodev: Opções essenciais contra a execução de código, o uso indevido de SUID/SGID e ficheiros de dispositivo.
- Caminhos temporários: Limitar rigorosamente os diretórios /tmp, /var/tmp e /dev/shm.
- /etc/fstab: Testar e monitorizar de forma rigorosa as entradas persistentes.
- Opções de desempenho: Utilizar de forma específica as opções ro, noatime, sync e Quotas.
- Aditamentos: Combinar ACLs, umask, chattr e encriptação.
Por que razão as opções de montagem contribuem significativamente para o reforço da segurança dos servidores
Através de opções específicas para cada partição, controlo o que pode acontecer nelas e, assim, evito Superfícies de ataque. O apelo mount -o rw,noexec,nosuid,nodev transforma uma montagem padrão numa montagem reforçada, que impede a execução de código e os truques setuid. Especialmente em diretórios de escrita partilhada, isto protege-me contra cadeias de exploits típicas a partir de /tmp. Planeio, para cada partição, quais as ações que são realmente necessárias e restrinjo tudo o resto de forma consistente. Assim, consigo, com pouco esforço, um resultado visivelmente melhor Segurança na vida quotidiana.
noexec, nosuid, nodev: os três pesos pesados do dia-a-dia
Eu fixo noexec em diretórios temporários, para que os ficheiros binários lá guardados não sejam executados diretamente. Com nosuid desativo as vias de escalada SUID/SGID, sobretudo em sistemas de ficheiros externos e em rede. A opção nodev impede que alguém crie e utilize indevidamente ficheiros de dispositivo perigosos. Em conjunto, estas três opções bloqueiam a execução de código, a expansão de privilégios e os acessos de baixo nível. Esta combinação reduz significativamente o risco de escalada de privilégios e reforça a minha Reforço da segurança do servidor mensurável.
Cenários de utilização típicos e opções recomendadas
Por norma, defino para diretórios temporários como /tmp, /var/tmp e /dev/shm noexec, nosuid e nodev. Em /var e /var/log, não utilizo ficheiros de dispositivo nem SUID/SGID, uma vez que nenhum dos dois tem ali uma finalidade legítima. Em /home, permito a execução quando necessário, mas bloqueio SUID/SGID e ficheiros de dispositivo. Para /boot, defino nosuid, nodev, noexec, para que apenas o carregador de arranque leia e nada seja executado nessa partição. Esta separação clara por partição aumenta a Resiliência do meu anfitrião e facilita a resolução de problemas.
| Ponto de montagem | Opções recomendadas | Breve descrição do objetivo |
|---|---|---|
| /tmp, /var/tmp, /dev/shm | noexec, nosuid, nodev | Sem direitos de execução, sem SUID/SGID, sem ficheiros de dispositivo |
| /var, /var/log | nosuid, nodev (opcional: noexec) | Registos e spools sem SUID/SGID e sem ficheiros de dispositivo |
| /home | nosuid, nodev (opcional: noexec) | Ficheiros de utilizador sem SUID/SGID e sem ficheiros de dispositivo |
| /boot | nosuid, nodev, noexec | Acesso apenas de leitura aos ficheiros de arranque |
Utilizar de forma adequada sistemas de ficheiros especiais e opções avançadas
Tenho em conta as particularidades do meu sistema de ficheiros e adapto as opções em conformidade. No caso do ext4, as opções são as seguintes: dados=ordenados (Padrão) e comprometer= um bom equilíbrio entre a consistência dos dados e a frequência de gravação. Para partições particularmente críticas, utilizo errors=remount-ro, para que, em caso de erro, o sistema não continue a funcionar sem que isso seja detetado. No XFS, verifico se inode64 e variantes de quota (usrquota, grpquota, prjquota) estão ativas para gerir de forma organizada grandes árvores de ficheiros. Opções como user_xattr e acl Permito-o de forma seletiva, quando as aplicações necessitam de atributos avançados ou de direitos mais específicos – caso contrário, mantenho a superfície de ataque reduzida e opto por predefinições conservadoras.
No que diz respeito aos volumes SSD e na nuvem, opto deliberadamente entre descartar e execuções regulares do TRIM através do temporizador. TRIM online (descartar) liberta imediatamente os blocos de memória, mas implica um custo em termos de E/S. Em muitas configurações, a libertação periódica fstrim mais eficiente e mais transparente. Escolho a estratégia de timestamp consoante a carga de trabalho: relatime protege a placa e é hoje um bom compromisso, não há tempo reduz ao mínimo os acessos de escrita, mas pode causar problemas a ferramentas que dependem de horários de acesso exatos. hora da preguiça Por sua vez, armazena temporariamente as atualizações de atributos, reduzindo assim a carga de gravação sem perda de semântica – ideal quando pretendo atenuar as operações de E/S de gravação sem abdicar dos metadados.
Evito opções de ajuste arriscadas, se o seu efeito não for absolutamente claro: opções como sem barreiras/writeback podem favorecer a perda de dados em caso de falha de energia. Da mesma forma, só avalio funcionalidades como o DAX se o hardware, o kernel e a versão do sistema de ficheiros forem compatíveis. O lema continua a ser: primeiro testar de forma isolada, depois implementar de forma reproduzível – e sempre com um plano de reversão bem definido.
Equilibrar de forma harmoniosa o desempenho e a segurança
Eu uso ro onde os conteúdos raramente mudam, para que ninguém se inscreva sem dar por isso. Com não há tempo ou com o relatime evito acessos de escrita desnecessários, sem sacrificar cegamente metadados importantes. A opção sincronização salva as operações de gravação imediatamente, o que, embora demore algum tempo, dificulta a perda de dados. As quotas definidas através do usrquota/grpquota mantêm os programas que consomem muito espaço sob controlo e evitam falhas causadas por partições cheias. Para cargas de trabalho com ext4 ou XFS, testo cada opção de forma controlada, para garantir que o funcionamento e Segurança adequados à aplicação.
/etc/fstab: configurar de forma permanente e segura
Vou registar as opções finais em /etc/fstab, para que resistam a cada arranque. Antes de reiniciar, verifico as entradas com mount -a e atualiza os serviços com systemctl daemon-reload, para evitar surpresas. Para a partição raiz, considero as opções mínimas e transfiro as restrições mais rigorosas para montagens dedicadas. Linhas de exemplo como UUID=tmp-uuid /tmp ext4 defaults,nosuid,nodev,noexec 0 2 documento tudo de forma clara, para que as verificações posteriores decorram rapidamente. Com findmnt --real -o TARGET,OPTIONS Comparo a configuração planeada com a que está efetivamente ativa Opções.
Integração com o systemd: montagem automática, robustez do arranque e dependências
Utilizo as extensões do `fstab` do systemd para melhorar a disponibilidade e os tempos de arranque. Com x-systemd.automount Incluo os percursos raramente utilizados logo no primeiro acesso e reduzo os atrasos no arranque. nofail garante que o host continue a arrancar, apesar da ausência de montagens secundárias, enquanto eu, com x-systemd.device-timeout= e x-systemd.mount-timeout= Limitar os bloqueios. Para os serviços, defino as dependências com x-systemd.requires-mounts-for=/caminho, para que as aplicações só sejam iniciadas quando o vosso armazenamento estiver realmente disponível.
Em backends instáveis ou lentos, eu adiciono ainda x-systemd.idle-timeout= para montagens automáticas, de modo a que sejam desmontadas corretamente após um período de inatividade. Desta forma, mantenho baixo o número de descritores abertos, evito montagens «zombie» e garanto um comportamento de execução previsível — essencial em ambientes de grande dimensão com muitas unidades e destinos de armazenamento.
Verificar e monitorizar as opções de montagem durante o funcionamento
Verifico regularmente com findmnt, se todas as partições estão montadas conforme previsto. Deteto imediatamente quaisquer discrepâncias e corrijo-as com remontagens específicas, por exemplo mount -o remount,noexec /tmp. Para hosts em que o tempo é um fator crítico, configuro notificações caso surjam falhas repentinas nas opções ou apareçam novas montagens. Isolamento de contexto através de Espaços de nomes e cgroups complementa eficazmente o reforço da segurança do sistema de ficheiros. Em conjunto, mantenho as vias de ataque curtas, reduzo as falhas de configuração e aumente a Transparência na vida quotidiana.
Proteger os pseudo-sistemas de ficheiros: /proc, /sys, debugfs e devpts
Trato os pseudo-sistemas de ficheiros com o mesmo cuidado que os suportes de dados. Para /proc coloquei ao lado de nosuid, nodev, noexec acima de tudo hidepid=2, para ocultar os detalhes dos processos de outros utilizadores. Caso os administradores precisem de aceder a essa informação, utilizo um grupo dedicado (gid=) e hidepid=1 ou 2, consoante as necessidades de visibilidade. /sys Eu utilizo exclusivamente nodev e sem direitos de escrita desnecessários; debugfs em princípio, permanece sem estar montado, a menos que eu precise dele temporariamente para fins de diagnóstico – nesse caso, exclusivamente por um curto período e em sistemas de teste.
Para devpts controlo o modo e os direitos de grupo, para que os pseudo-terminais fiquem devidamente isolados (por exemplo,. mode=0620,gid=tty). Estes detalhes impedem o acesso cruzado indesejado entre sessões e reduzem o risco de que informações privilegiadas sejam lidas. Especialmente em ambientes multiutilizador ou de alojamento, este ajuste fino é um elemento fundamental da Reforço da segurança do servidor.
Tamanhos e limites do Tmpfs para /tmp e /dev/shm
No caso de sistemas com um elevado volume de E/S ou de compilações, considero /tmp e /dev/shm como tmpfs, com limites bem definidos e fortemente endurecido: tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0. Desta forma, evito que os ficheiros temporários encham os discos e acelero o acesso à memória. No entanto, monitorizo o consumo de RAM e prevejo reservas, para que a pressão na memória não afete outros serviços. Se determinadas ferramentas necessitarem de percursos temporários para ficheiros executáveis, isolo-as através de diretórios de trabalho dedicados e montagens bind, em vez de flexibilizar as regras de segurança globais.
Entre /tmp e /var/tmp Faço uma distinção deliberada entre: /tmp pode ser volátil, /var/tmp deveria resistir aos reinícios. Por isso, escolho tmpfs mais para /tmp e deixe assim /var/tmp em disco – também com noexec, nosuid, nodev. Para cargas pesadas de memória partilhada, dimensiono /dev/shm adequado (size=) e aplico de forma rigorosa os direitos 1777 para garantir a separação entre os utilizadores.
Medidas de reforço de segurança complementares ao nível do sistema de ficheiros
Reduzo SUID/SGID- Reduzo os ficheiros binários ao mínimo e defino o umask de forma conservadora, por exemplo, 027 ou 077, para que os novos ficheiros sejam criados com proteção. Ativo as ACLs de forma seletiva, quando as aplicações necessitam de direitos mais específicos, e documento as regras com getfacl limpo. As configurações particularmente sensíveis, selo-as com chattr +i, para evitar alterações. As quotas impedem o uso excessivo de espaço de armazenamento numa fase inicial, antes que isso comprometa o desempenho dos serviços. Para um isolamento rigoroso dos processos, remeto também para Comparação do isolamento de processos, para reduzir os riscos para além do sistema de ficheiros.
Utilizar conceitos de isolamento de forma combinada
Complemento o reforço da segurança do sistema de ficheiros através de Isolamento do sistema de ficheiros ao nível do utilizador, para que as aplicações não tenham acesso para além dos seus limites. Em configurações de alojamento, um ambiente isolado compensa, porque os efeitos colaterais causam menos danos. Aqui, vale a pena dar uma vista de olhos a Isolamento do sistema de ficheiros CageFS, que separa rigorosamente os ambientes dos utilizadores. Os contentores e as «jails» também trazem vantagens quando os associo a opções de montagem restritivas. Esta combinação colmata lacunas que a mera Opções de montagem não cobrir por si só.
Obstáculos frequentes e medidas de correção
Eu testo noexec cuidadosamente, porque algumas ferramentas pretendem executar temporariamente ficheiros binários em /tmp. Nesses casos, recorro a diretórios de trabalho dedicados onde a execução é permitida. Para scripts de shell, utilizo chamadas explícitas ao interpretador, como /bin/bash script.sh, para que o noexec não seja um obstáculo. Se houver subdiretórios específicos que necessitem de exceções, utilizo montagens Bind e opções específicas. Desta forma, mantenho a fortificação básica intacta e permito apenas o que uma aplicação realmente necessário.
Montagens «bind», subdiretórios e propagação de montagens
Eu uso mount --bind, para incluir apenas as subárvores necessárias nos ambientes de destino, restringindo assim os direitos. Com mount -o bind,ro coloco-os em modo de só leitura e, em seguida, através de um mount -o remount,nosuid,nodev,noexec,bind reforço ainda mais os limites de segurança. Para subárvores inteiras, utilizo --rbind, para incluir todas as sub-montagens. É importante ter em conta a regra de propagação: com mount --make-private Separo os eventos de montagem entre o anfitrião e os chroots/contentores, para que nenhuma montagem indesejada „passe“.
Quando a orquestração de contentores está ativa, mantenho os caminhos centrais por predefinição privado e abrir apenas o que as cargas de trabalho necessitam. Nas fases de depuração, é possível partilhado pode ser útil; no funcionamento normal, é privado/escravo A escolha segura. Desta forma, as topologias de montagem permanecem previsíveis e evito que caminhos privilegiados surjam acidentalmente em ambientes convidados.
Endurecer suportes remotos e removíveis
Por norma, monto unidades externas e recursos partilhados na rede com nosuid,nodev e, na maioria das vezes, também noexec. Para VFAT/NTFS, defino os proprietários e as máscaras (por exemplo,. uid=1000,gid=1000,umask=027,fmask=137,dmask=027), para que os bits executáveis não se tornem uma porta de entrada. Em suportes removíveis, não há qualquer necessidade legítima de SUID/SGID ou ficheiros de dispositivo – desativo sistematicamente estas funcionalidades. Se pretender apenas ler, é necessário adicionalmente ro é utilizada. Desta forma, o código malicioso fica inoperante e não pode ser carregado posteriormente de forma inadvertida.
No caso do NFS/SMB, também limito rigorosamente os privilégios. nosuid, nodev, noexec são padrão; defino deliberadamente os tempos limite e as repetições (hard/soft,timeo=), para que as falhas não bloqueiem todo o sistema. No caso de dados sensíveis, prevejo medidas de integridade e encriptação ao nível do protocolo e certifico-me de que o cliente e o servidor seguem políticas consistentes. Quanto menos a outra parte puder decidir sobre o anfitrião local, mais estável e previsível será o funcionamento.
Passo a passo: implementar com segurança uma configuração de exemplo
Começo por fazer um inventário através de findmnt --real -o TARGET,OPTIONS e registo todos os ativos Montarias. Depois disso, eu adapto-me /etc/fstab por exemplo, com linhas para /tmp e /dev/shm, incluindo noexec, nosuid e nodev. Em seguida, testo com mount -a e verifico novamente o resultado com o comando `findmnt`. Se tudo correr bem, defino quotas nas áreas onde as contas de utilizador estão a crescer e ativo o `relatime` ou o `noatime`, conforme necessário. Por fim, registo as alterações no meu registo de alterações e planeio Controlos.
Controlo de desvios, auditorias e reversão segura
Defino as minhas políticas de montagem como o „estado desejado“ e verifico regularmente se existem desvios. Além disso, findmnt e /proc/mounts Utilizo verificações simples em scripts de monitorização que emitem um alarme quando os caminhos críticos ficam sem noexec, nosuid ou nodev em execução. Alterações a /etc/fstab Ou, no caso das unidades do systemd, documento-as com numeração de versão; antes de efetuar ajustes arriscados, crio instantâneos (por exemplo, através do LVM/btrfs), para poder reverter rapidamente em caso de emergência. Para sistemas particularmente sensíveis, planeio janelas de manutenção e testo previamente as remontagens em hosts de teste com a mesma configuração.
Há sempre uma solução prática à mão: com mount -o remount,defaults ou, no caso de contra-flags específicas, revertei temporariamente as opções restritivas quando um serviço falha de forma imprevista. Em seguida, isolo a causa, ajusto as exceções de montagem do Bind e reintroduzo o reforço de segurança de forma controlada. Desta forma, o equilíbrio entre políticas rigorosas e elevada disponibilidade mantém-se controlável – mesmo sob pressão de tempo.
Resumo: Utilizar as opções de montagem de forma inteligente
Protejo eficazmente os servidores Linux ao noexec, coloco «nosuid» e «nodev» de forma seletiva nas partições adequadas. Isolamos rigorosamente os caminhos temporários, e as áreas de dados produtivas recebem apenas os direitos de que realmente necessitam. Defino opções de desempenho, como relatime, ro e quotas, de acordo com a situação, para garantir o bom funcionamento e a segurança. Entradas persistentes em /etc/fstab e verificações regulares com o findmnt mantêm a configuração fiável. Complementado com ACLs, umask, chattr e boas técnicas de isolamento, o Superfície de ataque pequena e com custos administrativos previsíveis.
