Software de segurança adicional para NAS


A série de artigos é intitulada Construindo um Secure NAS . Portanto, este artigo considerará aumentar o nível de segurança. Além disso, serão descritas as ferramentas que não usei, mas é possível aplicar.


Quem e como


Quem vai atacar o sistema e como ele fará isso?


Geralmente, essa é a primeira pergunta que precisa ser respondida antes de falar sobre segurança.
Pelo menos no caso do NAS, essa resposta já está implícita. Mas, para responder totalmente a essa pergunta, um modelo de ameaça e um intruso estão sendo construídos.


As empresas estão embarcando em uma fase de modelagem de ameaças em seus ciclos de desenvolvimento.
A Microsoft tem um SDL para isso, as pessoas têm outros modelos .


Elas implicam o uso de certas técnicas, como STRIDE ou DREAD (STRIDE é ainda mais geral e tem mais suporte instrumental).


No STRIDE, por exemplo, um modelo é construído em fluxos de dados e geralmente é grande, pesado e mal compreendido. No entanto, a ferramenta fornece uma lista de ameaças em potencial, o que facilita sua consideração.


O modelo de ameaça é uma informação classificada, pois torna mais fácil para um invasor analisar o sistema e encontrar pontos fracos. Se ele receber um modelo, ele não precisará construí-lo por conta própria, porque os analistas já cuidaram de tudo.


Foi um minuto de publicidade.



É assim que as empresas sérias constroem o modelo. E se isso for interessante, posso descrever de alguma forma em um artigo separado.


Aqui, descreverei o que é chamado de "proteção" em inglês e lidarei com as falhas de segurança que foram feitas durante a construção do sistema.


Basicamente, a manutenção da segurança nesse nível é feita fechando as vulnerabilidades conhecidas do sistema, monitorando-as e verificando-as periodicamente.


Literatura Relacionada


O que ler:



Instantâneos e Docker


Anteriormente, o zfs-autosnapshot era instalado. Ele me ajudou repetidamente, porque Eu poderia restaurar configurações corrompidas (para Nextcloud, por exemplo) a partir de instantâneos.
No entanto, com o tempo, o sistema começou a desacelerar e vários milhares de instantâneos se multiplicaram.


Aconteceu que, ao criar o sistema de arquivos pai para contêineres, esqueci de definir o sinalizador com.sun:auto-snapshot=false .


No artigo original, esse problema já foi corrigido. Aqui mostrarei como se livrar de snapshots extras.


Detalhes sobre como corrigir o erro.

Primeiro, desative o zfs-auto-snapshot no sistema de arquivos pai da janela de encaixe:


 zfs set com.sun:auto-snapshot=false tank0/docker/lib 

Agora remova recipientes e imagens não utilizados:


 docker container prune docker image prune 

Excluir instantâneos:


 zfs list -t snapshot -o name -S creation | grep -e ".*docker/lib.*@zfs-auto-snap" | tail -n +1500 | xargs -n 1 zfs destroy -vr 

E desative-os em todos os sistemas de arquivos de imagem:


 zfs list -t filesystem -o name -S creation | grep -e "tank0/docker/lib" | xargs -n 1 zfs set com.sun:auto-snapshot=false 

Mais detalhes podem ser lidos aqui .


LDAP


Na última vez, apenas um usuário LDAP com uma função de administrador foi criado.


Mas a maioria dos serviços não precisa alterar nada no banco de dados do usuário. Portanto, seria bom adicionar um usuário somente leitura. Para não criar funções manualmente, é possível usar um script de inicialização do contêiner.


Primeiro, adicione as configurações no docker-compose.yml para ativar o usuário somente leitura:


 - "LDAP_READONLY_USER=true" - "LDAP_READONLY_USER_USERNAME=readonly" - "LDAP_READONLY_USER_PASSWORD=READONLY_PASSWORD" 

Arquivo completo sob o spoiler.


docker-compose.yml
 version: "2" networks: ldap: docker0: external: name: docker0 services: open-ldap: image: "osixia/openldap" hostname: "open-ldap" restart: always environment: - "LDAP_ORGANISATION=NAS" - "LDAP_DOMAIN=nas.nas" - "LDAP_ADMIN_PASSWORD=ADMIN_PASSWORD" - "LDAP_CONFIG_PASSWORD=CONFIG_PASSWORD" - "LDAP_READONLY_USER=true" - "LDAP_READONLY_USER_USERNAME=readonly" - "LDAP_READONLY_USER_PASSWORD=READONLY_PASSWORD" - "LDAP_TLS=true" - "LDAP_TLS_ENFORCE=false" - "LDAP_TLS_CRT_FILENAME=ldap_server.crt" - "LDAP_TLS_KEY_FILENAME=ldap_server.key" - "LDAP_TLS_CA_CRT_FILENAME=ldap_server.crt" volumes: - ./certs:/container/service/slapd/assets/certs - ./ldap_data/var/lib:/var/lib/ldap - ./ldap_data/etc/ldap/slapd.d:/etc/ldap/slapd.d networks: - ldap ports: - 172.21.0.1:389:389 - 172.21.0.1:636:636 phpldapadmin: image: "osixia/phpldapadmin:0.7.1" hostname: "nas.nas" restart: always networks: - ldap - docker0 expose: - 443 links: - open-ldap:open-ldap-server volumes: - ./certs:/container/service/phpldapadmin/assets/apache2/certs environment: - VIRTUAL_HOST=ldap.* - VIRTUAL_PORT=443 - VIRTUAL_PROTO=https - CERT_NAME=NAS.cloudns.cc - "PHPLDAPADMIN_LDAP_HOSTS=open-ldap-server" #- "PHPLDAPADMIN_HTTPS=false" - "PHPLDAPADMIN_HTTPS_CRT_FILENAME=certs/ldap_server.crt" - "PHPLDAPADMIN_HTTPS_KEY_FILENAME=private/ldap_server.key" - "PHPLDAPADMIN_HTTPS_CA_CRT_FILENAME=certs/ldap_server.crt" - "PHPLDAPADMIN_LDAP_CLIENT_TLS_REQCERT=allow" ldap-ssp: image: openfrontier/ldap-ssp:https volumes: - /etc/ssl/certs/ssl-cert-snakeoil.pem:/etc/ssl/certs/ssl-cert-snakeoil.pem - /etc/ssl/private/ssl-cert-snakeoil.key:/etc/ssl/private/ssl-cert-snakeoil.key restart: always networks: - ldap - docker0 expose: - 80 links: - open-ldap:open-ldap-server environment: - VIRTUAL_HOST=ssp.* - VIRTUAL_PORT=80 - VIRTUAL_PROTO=http - CERT_NAME=NAS.cloudns.cc - "LDAP_URL=ldap://open-ldap-server:389" - "LDAP_BINDDN=cn=admin,dc=nas,dc=nas" - "LDAP_BINDPW=ADMIN_PASSWORD" - "LDAP_BASE=ou=users,dc=nas,dc=nas" - "MAIL_FROM=admin@nas.nas" - "PWD_MIN_LENGTH=8" - "PWD_MIN_LOWER=3" - "PWD_MIN_DIGIT=2" - "SMTP_HOST=" - "SMTP_USER=" - "SMTP_PASS=" 

Em seguida, você precisa despejar e excluir:


 $ cd /tank0/docker/services/ldap $ tar czf ~/ldap_backup.tgz . $ ldapsearch -Wx -D "cn=admin,dc=nas,dc=nas" -b "dc=nas,dc=nas" -H ldap://172.21.0.1 -LLL > ldap_dump.ldif $ docker-compose down $ rm -rf ldap_data $ docker-compose up -d 

Para impedir que o servidor se recupere de um despejo de palavrões em elementos duplicados, exclua as linhas no arquivo:


 dn: dc=nas,dc=nas objectClass: top objectClass: dcObject objectClass: organization o: NAS dc: nas dn: cn=admin,dc=nas,dc=nas objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: PASSWORD_BASE64 

E restaure usuários e grupos:


 $ ldapadd -Wx -D "cn=admin,dc=nas,dc=nas" -H ldap://172.21.0.1 -f ldap_dump.ldif 

Um animal assim aparecerá no banco de dados:


 dn: cn=readonly,dc=nas,dc=nas cn: readonly objectClass: simpleSecurityObject objectClass: organizationalRole userPassword:: PASSWORD_BASE64 description: LDAP read only user 

As funções na configuração do servidor LDAP serão criadas pelo contêiner.
Execute verificações após a recuperação e exclua o backup:


 $ rm ~/ldap_backup.tgz 

Adicionando grupos ao LDAP


Conveniente é a separação de usuários LDAP em grupos semelhantes aos grupos POSIX no Linux.
Por exemplo, é possível criar grupos cujos usuários terão acesso a repositórios, acesso à nuvem ou acesso à biblioteca.


Grupos são facilmente adicionados ao phpLDAPAdmin, e não vou me concentrar nisso.


Observo apenas o seguinte:


  • O grupo é criado a partir do modelo "Padrão". Este não é um grupo POSIX , mas um grupo de nomes.
  • Assim, o grupo possui um atributo objectClass que inclui o valor de groupOfUniqueNames .

Adicionando um grupo ao phpLDAPAdmin


Docker


No Docker, quase tudo foi feito para você.
Por padrão, ele usa a restrição de chamada do sistema , incluída no kernel OMV:


 # grep SECCOMP /boot/config-4.16.0-0.bpo.2-amd64 CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_SECCOMP_FILTER=y CONFIG_SECCOMP=y 

Aqui você pode ler sobre as regras básicas de segurança do Docker com mais detalhes.
Além disso, se o AppArmor estiver ativado, o Docker poderá se integrar a ele e encaminhar seus perfis para o contêiner .


Rede


Eliminar a descoberta do SO


A rede está localizada atrás do roteador, mas é possível fazer um exercício curioso alterando alguns parâmetros da pilha de rede para que o sistema operacional não possa ser identificado pelas respostas.
Há pouco benefício real com isso, porque o invasor estudará os banners de serviço e ainda entenderá o SO que você está usando.


O Nmap mostra qual SO está sendo executado no dispositivo.
 # nmap -O localhost Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-26 14:39 MSK Nmap scan report for localhost (127.0.0.1) Host is up (0.000015s latency). Other addresses for localhost (not scanned): ::1 Not shown: 992 closed ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https 5432/tcp open postgresql Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.8 - 4.6 Network Distance: 0 hops OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 4.07 seconds 

Faça o download das configurações do sysctl.conf:


 # sysctl -p /etc/sysctl.conf net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv4.tcp_rfc1337 = 1 net.ipv4.ip_default_ttl = 128 net.ipv4.icmp_ratelimit = 900 net.ipv4.tcp_synack_retries = 7 net.ipv4.tcp_syn_retries = 7 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 

E assim ...


O Nmap não pode determinar o sistema operacional.
 # nmap -O localhost Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-26 14:40 MSK Nmap scan report for localhost (127.0.0.1) Host is up (0.000026s latency). Other addresses for localhost (not scanned): ::1 Not shown: 992 closed ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https 5432/tcp open postgresql No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.40%E=4%D=8/26%OT=53%CT=1%CU=43022%PV=N%DS=0%DC=L%G=Y%TM=5B8291C OS:3%P=x86_64-pc-linux-gnu)SEQ(SP=FA%GCD=1%ISR=105%TI=Z%CI=I%TS=8)OPS(O1=MF OS:FD7ST11NW7%O2=MFFD7ST11NW7%O3=MFFD7NNT11NW7%O4=MFFD7ST11NW7%O5=MFFD7ST11 OS:NW7%O6=MFFD7ST11)WIN(W1=AAAA%W2=AAAA%W3=AAAA%W4=AAAA%W5=AAAA%W6=AAAA)ECN OS:(R=Y%DF=Y%T=80%W=AAAA%O=MFFD7NNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F= OS:AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=80%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5( OS:R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=Z% OS:F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N OS:%T=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%C OS:D=S) Network Distance: 0 hops OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 19.52 seconds 

Essas configurações precisam ser escritas em /etc/sysctl.conf , e a cada reinicialização elas serão lidas automaticamente.


/Etc/sysctl.conf completo
 ################################################################### # Additional settings - these settings can improve the network # security of the host and prevent against some network attacks # including spoofing attacks and man in the middle attacks through # redirection. Some network environments, however, require that these # settings are disabled so review and enable them as needed. # # Do not accept ICMP redirects (prevent MITM attacks) net.ipv4.conf.default.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 # _or_ # Accept ICMP redirects only for gateways listed in our default # gateway list (enabled by default) # net.ipv4.conf.all.secure_redirects = 1 # # Do not send ICMP redirects (we are not a router) net.ipv4.conf.all.send_redirects = 0 # # Do not accept IP source route packets (we are not a router) net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 ## protect against tcp time-wait assassination hazards ## drop RST packets for sockets in the time-wait state ## (not widely supported outside of linux, but conforms to RFC) net.ipv4.tcp_rfc1337 = 1 # # Log Martian Packets #net.ipv4.conf.all.log_martians = 1 # ################################################################### # Magic system request Key # 0=disable, 1=enable all # Debian kernels have this set to 0 (disable the key) # See https://www.kernel.org/doc/Documentation/sysrq.txt # for what other values do #kernel.sysrq=1 ################################################################### # Protected links # # Protects against creating or following links under certain conditions # Debian kernels have both set to 1 (restricted) # See https://www.kernel.org/doc/Documentation/sysctl/fs.txt #fs.protected_hardlinks=0 #fs.protected_symlinks=0 vm.overcommit_memory = 1 vm.swappiness = 10 ################################################################### # Anti-fingerprinting. # # Def: 64. net.ipv4.ip_default_ttl = 128 #   ICMP  (  1000) net.ipv4.icmp_ratelimit = 900 #    ,     . # Def: 5. net.ipv4.tcp_synack_retries = 7 # Def: 5. net.ipv4.tcp_syn_retries = 7 #   TCP window  timespamp    1323. net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 # Redis requirement. net.core.somaxconn = 511 

A proteção contra a definição de versões de serviço é mais útil, para a qual um invasor também pode usar o Nmap:


 # nmap -sV -sR --allports --version-trace 127.0.0.1 

O resultado não é muito bom para o sistema.
 Not shown: 991 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u3 (protocol 2.0) 25/tcp open smtp Postfix smtpd 80/tcp open http nginx 1.13.12 111/tcp open rpcbind 2-4 (RPC #100000) 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 443/tcp open ssl/http nginx 1.13.12 445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 3493/tcp open nut Network UPS Tools upsd 8000/tcp open http Icecast streaming media server 2.4.2 Service Info: Hosts: nas.localdomain, NAS; OS: Linux; CPE: cpe:/o:linux:linux_kernel Final times for host: srtt: 22 rttvar: 1 to: 100000 

Mas com o disfarce de serviços, nem tudo é tranquilo:


  • Para cada serviço, é necessária uma abordagem individual aqui.
  • A capacidade de remover a versão nem sempre está disponível.

Por exemplo, para SSH, é possível adicionar a opção DebianBanner no a /etc/ssh/sshd_confg .


Como resultado:


 22/tcp open ssh OpenSSH 7.4p1 (protocol 2.0) 

Melhor, infelizmente, não funcionará: a versão é usada pelo SSH para estabelecer quais recursos são suportados, e é possível alterá-lo apenas aplicando patches no servidor .


Porto batendo


Não é a técnica de segurança mais conhecida, permitindo que um usuário remoto que conheça o segredo se conecte a uma porta fechada.
O trabalho se parece com um bloqueio de código : todos sabem que os daemons de serviço estão trabalhando no servidor, mas "eles não estão lá" até que o código seja discado.
Por exemplo, para conectar-se a um servidor SSH, um usuário precisa bater nas portas UDP 7000, TCP 7007 e UDP 7777.
Depois disso, com seu IP, o firewall será iniciado em uma porta TCP 22 fechada .


Você pode ler mais sobre como isso funciona aqui . E no manual para Debian .


Eu não recomendo usar, como fail2ban geralmente é suficiente.


Firewall


Eu configuro o firewall através da GUI da Web OpenMediaVault, que eu recomendo.



Abra as portas necessárias, como 443 e 22, o resto a gosto. Também é aconselhável habilitar o log de pacotes descartados.


Ssh


Se o SSH travar na porta 22, aberta à Internet, você receberá muitas mensagens interessantes ...
 # grep "invalid user" /var/log/auth.log|head Aug 26 00:07:57 nas sshd[29786]: input_userauth_request: invalid user test [preauth] Aug 26 00:07:59 nas sshd[29786]: Failed password for invalid user test from 185.143.160.137 port 51268 ssh2 Aug 26 00:11:01 nas sshd[5641]: input_userauth_request: invalid user 0 [preauth] Aug 26 00:11:01 nas sshd[5641]: Failed none for invalid user 0 from 5.188.10.180 port 49025 ssh2 Aug 26 00:11:04 nas sshd[5644]: input_userauth_request: invalid user 0101 [preauth] Aug 26 00:11:06 nas sshd[5644]: Failed password for invalid user 0101 from 5.188.10.180 port 59867 ssh2 Aug 26 00:32:55 nas sshd[20367]: input_userauth_request: invalid user ftp [preauth] Aug 26 00:32:56 nas sshd[20367]: Failed password for invalid user ftp from 5.188.10.144 port 47981 ssh2 Aug 26 00:32:57 nas sshd[20495]: input_userauth_request: invalid user guest [preauth] Aug 26 00:32:59 nas sshd[20495]: Failed password for invalid user guest from 5.188.10.144 port 34202 ssh2 

Correndo o risco de parecer trivial, ainda me lembro de que é necessário:


  • Proibir estritamente o login root.
  • Limite o login apenas aos usuários especificados.
  • Mude a porta para fora do padrão.
  • É aconselhável desativar a autenticação de senha, deixando apenas a chave.

Leia mais é possível, por exemplo, aqui .


Tudo isso é feito facilmente a partir da interface do OpenMediaVault através do menu "Serviços -> SSH".
Só que eu não mudei a porta para fora do padrão, deixando 22 na rede local e simplesmente substituindo a porta no roteador NAT.


Aqui está uma lista interessante de contas que tentei compilar, até alterar a porta SSHD para outra diferente de 22.
 # grep "invalid user" /var/log/auth.log|sed 's/.*invalid user \([^ ]*\) .*/\1/'|sort|uniq 0 0101 1234 22 admin ADMIN administrateur administrator admins alfred amanda amber Anonymous apache avahi backup@network bcnas benjamin bin cacti callcenter camera cang castis charlotte clamav client cristina cron CSG cvsuser cyrus david db2inst1 debian debug default denis elvira erik fabio fax ftp ftpuser gary gast GEN2 guest I2b2workdata2 incoming jboss john juan matilda max mia miner muhammad mysql nagios nginx noc office oliver operator oracle osmc pavel pi pmd postgres PROCAL prueba RSCS sales sales1 scaner selena student07 sunos support sybase sysadmin teamspeak telecomadmin test test1 test2 test3 test7 tirocu token tomcat tplink ubnt ubuntu user1 vagrant victor volition www-data xghwzp xxx zabbix zimbra 

Feito isso, as tentativas não autorizadas de login serão feitas com muito menos frequência.


Para melhorar ainda mais a situação, é possível bloquear os invasores de determinados IPs após várias tentativas de login.


O que pode ser usado para:


  • Fail2ban . Um utilitário popular que funciona não apenas para SSH, mas também para muitos outros aplicativos.
  • Denyhosts Parece fail2ban.
  • Sshguard , se desejar, você pode tentar usá-lo, mas eu não estava interessado em detalhes.

Estou usando fail2ban. Ele monitorará os logs em busca de várias ações indesejáveis ​​por parte de determinados IPs e os banirá se o número de respostas for excedido:


/var/log/fail2ban.log.
 2018-08-29 21:17:25,351 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.144 2018-08-29 21:17:25,473 fail2ban.actions [8650]: NOTICE [sshd] Ban 5.188.10.144 2018-08-29 21:17:27,359 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.144 2018-08-29 21:28:13,128 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.176 2018-08-29 21:28:13,132 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.176 2018-08-29 21:28:15,137 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.176 2018-08-29 21:28:20,145 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.176 2018-08-29 21:28:25,153 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.176 2018-08-29 21:28:25,421 fail2ban.actions [8650]: NOTICE [sshd] Ban 5.188.10.176 2018-08-29 21:30:05,272 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.180 2018-08-29 21:30:05,274 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.180 2018-08-29 21:30:13,285 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.180 2018-08-29 21:30:13,286 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.180 2018-08-29 21:30:15,289 fail2ban.filter [8650]: INFO [sshd] Found 5.188.10.180 2018-08-29 21:30:15,803 fail2ban.actions [8650]: NOTICE [sshd] Ban 5.188.10.180 

Uma proibição é feita adicionando uma regra de firewall. Após um tempo especificado, a regra é excluída e o usuário pode tentar novamente fazer login.


Inicialmente, apenas o SSH está ativado, mas é possível ativar o controle dos logs do servidor da Web e de outros serviços, pelo menos do mesmo OMV .
Além disso, retire os logs dos contêineres e defina fail2ban neles também.


Eu recomendo adicionar serviços a gosto.
Você pode ler mais sobre a configuração, por exemplo, aqui ou no Wiki nativo .


Logs


Lwatch


Um pequeno utilitário que deve ser instalado por conveniência. Ele destacará os logs e os exibirá de uma forma bonita.
É possível usar qualquer utilitário , o principal é que os erros e as áreas problemáticas dos logs sejam destacados para facilitar a análise visual.


Verificação de log


Vale a pena instalar e configurar a verificação de log simplesmente para que, ao identificar problemas de configuração relatados nos logs, você o veja imediatamente no correio.
Ajuda muito ver o que está errado, embora exija ajuste.


Instalação:


 # apt-get install logcheck 

Imediatamente após a instalação, ele enviará relatórios.


Exemplo de relatório.
 System Events =-=-=-=-=-=-= Oct 2 02:02:15 nas kernel: [793847.981226] [DROPPED] IN=br-ce OUT= PHYSIN=veth6c2a68e MAC=ff:ff:ff:ff:ff:ff: SRC=172.22.0.11 DST=255.255.255.255 LEN=29 TOS=0x00 PREC=0x00 TTL=64 ID=40170 DF PROTO=UDP SPT=35623 DPT=35622 LEN=9 Oct 2 02:02:20 nas hddtemp[13791]: /dev/sdh: Micron_1100 N #020Ђ: 32 C Oct 2 02:02:37 nas kernel: [793869.247128] [DROPPED] IN=br-7ba OUT= MAC= SRC=172.31.0.1 DST=172.31.255.255 LEN=239 TOS=0x00 PREC=0x00 TTL=128 ID=23017 DF PROTO=UDP SPT=138 DPT=138 LEN=219 Oct 2 02:02:37 nas kernel: [793869.247174] [DROPPED] IN=br-7ba OUT= MAC= SRC=172.31.0.1 DST=172.31.255.255 LEN=232 TOS=0x00 PREC=0x00 TTL=128 ID=23018 DF PROTO=UDP SPT=138 DPT=138 LEN=212 Oct 2 02:02:37 nas kernel: [793869.247195] [DROPPED] IN=br-673 OUT= MAC= SRC=192.168.224.1 DST=192.168.239.255 LEN=239 TOS=0x00 PREC=0x00 TTL=128 ID=8959 DF PROTO=UDP SPT=138 DPT=138 LEN=219 Oct 2 02:02:37 nas kernel: [793869.247203] [DROPPED] IN=br-673 OUT= MAC= SRC=192.168.224.1 DST=192.168.239.255 LEN=232 TOS=0x00 PREC=0x00 TTL=128 ID=8960 DF PROTO=UDP SPT=138 DPT=138 LEN=212 Oct 2 02:02:50 nas hddtemp[13791]: /dev/sdh: Micron_1100 N #020Ђ: 32 C 

Pode-se ver que há muito supérfluo, e mais ajustes serão necessários para filtrá-lo.


Primeiro, desative hddtemp, que não funciona corretamente devido a caracteres não ASCII no nome do SSD.
Depois de corrigir o arquivo hddtemp, as mensagens pararam de chegar:


/etc/logcheck/ignore.d.server/hddtemp
 ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ hddtemp\[[0-9]+\]: /dev/([hs]d[az]|sg[0-9]):.*[0-9]+.*[CF] ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ hddtemp\[[0-9]+\]: /dev/([hs]d[az]|sg[0-9]):.*drive is sleeping 

Em seguida, é possível ver o que a verificação de log diz estar bloqueando o tráfego de broadcast pelo firewall:


 [793869.247128] [DROPPED] IN=br-7ba OUT= MAC= SRC=172.31.0.1 DST=172.31.255.255 LEN=239 TOS=0x00 PREC=0x00 TTL=128 ID=23017 DF PROTO=UDP SPT=138 DPT=138 LEN=219 

Portanto, você precisa habilitar o tráfego de broadcast do roteador e dos contêineres:


  • Porta 35622 do contêiner com urbackup.
  • A porta 5678 do roteador é a descoberta do vizinho RouterOS. Pode ser desativado no roteador.
  • A porta 5353 para o endereço 224.0.0.251 é mDNS .

Verifique o logcheck:


 sudo -u logcheck logcheck -t -d 

Finalmente, os problemas se tornam visíveis:


 Oct 21 21:58:18 nas systemd[1]: Removed slice User Slice of user. Oct 21 21:58:31 nas systemd[1]: smbd.service: Unit cannot be reloaded because it is inactive. Oct 21 21:58:31 nas root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1 

Acontece que o SAMBA não inicia. De fato, a análise mostrou que eu o disfarcei através do systemctl, e o OMV estava tentando iniciá-lo.


A verificação de log ainda enviará spam para várias mensagens.
Aqui, por exemplo, o zfs-auto-snapshot passou:


 Oct 21 22:00:57 nas zfs-auto-snap: @zfs-auto-snap_frequent-2018-10-21-1900, 16 created, 16 destroyed, 0 warnings. 

Para ignorar:


/etc/logcheck/ignore.d.server/zfs-auto-snapshot
 ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ zfs-auto-snap: \@zfs-auto-snap_[[:alnum:]-]+, [0-9]+ created, [0-9]+ destroyed, 0 warnings.$ 

O rrdcached também está em ignorar:


/etc/logcheck/ignore.d.server/rrdcached
 ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: flushing old values$ ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: rotating journals$ ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: started new journal [./[:alnum:]]+$ ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: removing old journal [./[:alnum:]]+$ 

Além disso, é recomendável remover o zed se ele ainda não for removido:


/etc/logcheck/ignore.d.server/zed
 ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (/usr/bin/)?zed: .*$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (/usr/bin/)?zed\[[0-9]+\]: .*$ 

Bem e assim por diante. Muitas pessoas pensam que o logcheck é um utilitário bastante inútil.
Isso é verdade se você usá-lo como algo que você define e esquece.


No entanto, se você entender que o logcheck é apenas um filtro de log personalizado, sem heurísticas, algoritmos mágicos e adaptativos, a questão de sua necessidade não surge. Iterativamente, analisando o que ele envia e, adicionando-o para ignorá-lo ou corrigi-lo, é gradualmente possível obter relatórios informativos.


O uso de uma ferramenta automatizada para análise é muito melhor do que executar os logs pelas mesmas expressões regulares com as mãos e, geralmente, melhor do que usar um sistema completo de análise de dados como o Splunk.


O logcheck e sua configuração podem ser lidos no Wiki Gentoo e aqui .


IDS no nível do nó


Aqui vou me referir ao meu próprio artigo "Uma breve análise de soluções no campo do SOC e o desenvolvimento de um detector de anomalia de rede neural em redes de transmissão de dados" , no qual existem vários exemplos.


Você pode ler uma revisão e comparação mais completa de IDS similares no Wiki .


STIG-4


Um script complexo e amplo para análise estática de lacunas conhecidas do RedHat.
Existe uma porta no Debian , que eu recomendo baixar e executar pelo menos uma vez.


Exemplo de Operação STIG-4
 # cd root@nas:~# git clone https://github.com/hardenedlinux/STIG-4-Debian Cloning into 'STIG-4-Debian'... remote: Enumerating objects: 572, done. remote: Total 572 (delta 0), reused 0 (delta 0), pack-reused 572 Receiving objects: 100% (572/572), 634.37 KiB | 0 bytes/s, done. Resolving deltas: 100% (316/316), done. root@nas:~# cd STIG-4-Debian/ root@nas:~/STIG-4-Debian# bash stig-4-debian.sh -H Script Run: Mon Nov 12 23:58:34 MSK 2018 Start checking process... [ FAIL ] The cryptographic hash of system files and commands must match vendor values. ... Pass Count: 54 Failed Count: 137 

O processo de trabalho com esse script é aproximadamente o seguinte:


  • Livre-se do script.
  • Pesquise na Internet todas as linhas com [ FAIL ] .
  • Como regra, será encontrado um link para o banco de dados on-line STIG.
  • Correto, seguindo as instruções no banco de dados, fazendo um desconto no fato de ser o Debian.
  • Execute o script novamente.

Rkhunter


Muito foi escrito sobre o RkHunter .
Usado por muito tempo, amplamente, ainda em desenvolvimento. Existe um repositório Debian.


Tigre


Um script de shell modular que executa auditoria do sistema e detecção de intrusão.
É um pouco semelhante ao STIG-4.
Ele pode usar utilitários de terceiros para analisar logs e detectar violações da soma de verificação.


Consiste em um grande número de módulos diferentes.


Por exemplo, existe um módulo que detecta serviços que usam arquivos excluídos, o que acontece quando as bibliotecas usadas pelo serviço foram alteradas durante o processo de atualização do sistema, mas o serviço não foi reiniciado por algum motivo.


Existem módulos para pesquisar usuários do serviço que não são mais usados, verificar o sistema por falta de patches de segurança, verificar umask etc.


Mais detalhes em man .


Não está em desenvolvimento há 10 anos (sim, não sou o único a abandonar o software).


Samhain


HIDS típicos que podem:


  • Verifique a integridade de todo o sistema usando hashes criptográficos.
  • Procure vários executáveis ​​com o SUID instalado, que não deve ser instalado.
  • Detecte processos ocultos.
  • Assine logs e bancos de dados.

Além disso, possui monitoramento centralizado com uma interface da Web e envio centralizado de logs para o servidor.
, .
.


, , . , , , , .


- HIDS: .
Samhain, .


Tripwire


, Samhain, Tripwire — .
, .


Lynis


RkHunter .


, .
.
Tiger , , .
, . , , Lynix Tripwire.


Chkrootkit


. .
:


  • , .
  • .
  • , latslog, wtmp utmp.
  • , , .

.


Ninja


Linux.


ninja-build.


, . UID/GID, Ninja , , (, , ).
(, su).
, .


Ubuntu , Debian.



. . , , , .
Nmap W3af Web-.



Linux ( ) .
. , .


, , , .


" Linux" IBM .


NAS , AppArmor.
, , .
, , , .


Access Control Lists


, .
, ZFS .


ACL ZFS.
  • Permissão para adicionar um novo arquivo ao diretório.
  • Permissão para criar um subdiretório em um diretório.
  • Permissão para excluir um arquivo.
  • Permissão para excluir um arquivo ou diretório dentro de um diretório.
  • Permissão para executar um arquivo ou pesquisar o conteúdo de um diretório.
  • Permissão para listar o conteúdo do diretório.
  • Permissão para ler ACLs (comando ls).
  • Permissão para ler atributos básicos do arquivo (exceto ACLs, atributos no nível de comando "stat").
  • Permissão para ler o conteúdo do arquivo.
  • Permissão para ler atributos de arquivo estendidos ou procurar no diretório por atributos de arquivo estendidos.
  • .
  • .
  • , , .
  • ACL chmod.
  • . chown chgrp .
  • , . PRIV_FILE_CHOWN.
  • ACL .
  • ACL .
  • ACL , , . ACL file_inherit, dir_inherit .
  • ACL , .

ACL , , , . .


EXT , ZFS ACL setfacl/getfacl , chmod ls .


AppArmor



.


, , exec , , open , exec .
, .
AppArmor , .
, .
capabilites.


, . , , , .


ping.
 #include <tunables/global> profile ping /{usr/,}bin/ping flags=(complain) { #include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice> capability net_raw, capability setuid, network inet raw, network inet6 raw, /{,usr/}bin/ping mixr, /etc/modules.conf r, # Site-specific additions and overrides. See local/README for details. #include <local/bin.ping> } 

, , .. . , , ( local/bin.ping ), , .


deb-based .
firejail , .


, , .


Debian, .


SELinux


Arquitetura SELinux


.
NSA , Debian .


SELinux " " (type enforcement).


, , , SELinux . "".


, , firefox_t .
SELinux , .


Um exemplo:


 allow firefox_t user_home_t : file { read write }; 

, , firefox_t , , user_home_t .


Um exemplo:


 allow user_t user_home_t:file { create read write unlink }; 

user_t , , user_home_t . user_t , , .


, .


AppArmor -, , , .


SELinux .
  • SELinux Linux. su sudo, SELinux . Linux SELinux , 1:1, root.
  • , , . " ", "Web-", " ". , object_r .
    , .
  • . — , .
  • . , , . , user_u:user_r:user_t , user_u:object_r:user_home_t . :

 user:role:type:range 

— SELinux user. — , . — MLS .


, , , user_home_t. user_home_t — , , .


  • , dir file , , . , . , file (create), (read), (write) (unlink), unix_stream_socket object ( UNIX) (create), (connect), (sendto).

, .
. , (, ), .


, AppArmor, permissive , , .
.
, , AppArmor .


SELinux .
.
IBM .


GrSecurity


Debian - . , , .
, ( ), — Gentoo . : hardening .


, .


Debian , GrSecurity PaX.


Tomoyo


Tomoyo Debian .


. AppArmor, . 2003 .
, , .
, AppArmor, .



/etc/securetty , root ( ), .


PAM, /etc/security .


, Samhain Tripwire, debsums , .


Conclusão


. , .


, Github , .

Source: https://habr.com/ru/post/pt421279/


All Articles