: () { : | : & } ; :

Epoptes é uma ferramenta de gerenciamento e monitoramento de laboratório de informática. 

O site ofiicial do Epoptes possui mais informações e detalhes.

Neste artigo será mostrado simplesmente um script de configuração final da estação que possui o lado client da aplicação, o "epoptes client".

O script serve para as tarefas básicas de pós instalação do versão cliente da aplicação, como padronizar o hostname da estação para as definições que cada unidade/laboratório/escola e etc definirem. Especificar IP do servidor Epoptes, porta de acesso e seu protocolo. Basicamente é isso.

Ela precisa se comunicar com protocolo e porta próprio com o "Epoptes Server". Configurar uma máquina só, pode ser até razoável fazer manualmente, mas quando se possui diversas máquinas, o melhor e tentar automatizar máximo possível.

Funções do script:

1 - Verifica se o usuário está como root (sudo), se não for, avisa e sai; se for root (ou sudo) avisa que o usuário está como root e prossegue.

2 - Ajusta o hostname da estação. Normalmente se tem um padrão de nome como "nome-do-lab-nome-da-estacao", onde o prefixo "nome-do-lab" é estático, ou seja não muda no hostname das estações, somente o sufixo "nome-da-estacao". Este prefixo está pré-definido no script e que pode ser mudado cada vez que for utilizar em laboratórios diferentes. Deixando a ação de "nomear" a máquina mais simples, atribuindo somente o sufixo. Atente a isso.

3 - Depois o script rescreve com as informações do arquivo /etc/hosts. Não precisa mexer nesta parte, porque é o definido previamente.

4 - É solicitado então o IP do servidor. Foneça o IP no formato de exemplo: 172.16.6.6.

5 - Finalizando, o script grava as informações passadas e "restarta" os serviços e a estação de trabalho, estando pronto para uso em seguida.

Baixe o Script AQUI.

Altere conforme sua necessidade.

Quando eu trabalhava com redes windows, que são as mais comuns (infelizmente) em ambientes corporativos, tive algumas situações interessantes e outras bem incômodas.

Mesmo o ambiente tendo um AD (o famigerado Active Directory da MS) muitas vezes pode não ser possível (por N razões e motivos diversos) trabalhar com as GPOs para gerenciar alguns pormenores e com isso usamos técnicas diversas.

Uma delas é instalar aplicações em rede em N máquinas simultaneamente, ou em lote.

Existem diversas ferramentas pagas e não pagas para esta tarefa.

Nos testes eu utilizei uma ferramenta do pacote PSTOOLS da Winternals/Sysinternals (uma subisidiária da Miscrosoft) o PSEXEC. (https://docs.microsoft.com/en-us/sysinternals/downloads/pstools)

Este aplicativo do pacote/suite PSTOOLS executa processos remotamente e com isso poderemos instalar e executar aplicativos em estações de trabalho da rede.

Nos meus testes encontrei alguns contratempos, sendo necessário utilizar outros métodos para contornar. Mas penso que uma leitura mais detalhada da documentação e demais sites, possa resolver. No meu caso funcionou como eu precisava, então mantive meu método.

Procedimentos que executei

Baixei o psexec.exe do seguinte link: PSTOOLS

Descompactei num diretório e copiei somente o psexec.exe para o diretório c:\windows\system32 para ser chamado de qualquer local pelo CMD (prompt do DOS).

Sim sim. Terá que utilizar o DOS.

Obs 0: Quem tiver “medo do escuro” deverá perder esse medo ou então ficará limitado demais. Mas isso é uma conversa para um outro momento. Venha para o Lado Negro da Força!

Baixei o Notepad++ aqui.

Copiei o arquivo para o diretório C:\teste\ e mudei o nome para npp.exe, simplificando a digitação.

Este é o diretório que deve estar compartilhado com todas as permissões de acesso possíveis.

Na máquina em que será "disparado" o comando, deve ser feito com o usuário Administrador ou outro com privilégios de Admin logado.

Ao invés de utilizar um Windows Server, utilizei um Windows 10 estação de trabalho com o usuário Administrador para poder fazer todos os procedimentos. Isso facilita o processo e não interfere no ambiente de rede nem nos possíveis Servidores Windows que possa ter na rede.

Compartilhe o diretório e de preferência deixe o mesmo com permissões totais de acesso.
 

Exemplo:
C:\teste>psexec ip-destino -c "\\ip-origem\pasta\arquivo.exe” cmd /S

Para uma máquina somente:

"C:\teste>psexec \\172.16.1.2 -c "\\172.16.1.1\teste\npp.exe" cmd /S"

Para N máquinas utilizando um arquivo lista com os Ips destino:

C:\teste>psexec @lista-carrocas.txt -c "\\172.16.1.1\teste\npp.exe" cmd /S

O parâmetro -c copia, instala e remove o instalador
O comando cmd é o prompt de comando que vai chamar o instalador (npp.exe)
O pârâmetro /S faz o instalador do Notepad++ executar de forma "silenciosa" não dando nenhum alerta ou aviso para o usuário logado, não interferindo e/ou interagindo com o usuário.

Nos testes as duas máquinas (origem e destino) possuem o mesmo usuário Administrador local com a mesma senha.
Existe a limitação de passar usuário e senha junto ao comando.
Diversos modos de execução e todos retornaram com erro de logon ou autenticação.
Com isso, os comandos funcionam quando as "máquinas destino" possuem o mesmo usuário local Administrador/Senha.

Caso tenha mais de uma máquina destino, pode-se adicionar uma lista de máquinas num arquivo texto e fazer o apontamento.

Nos testes criei um arquivo com o nome lista-carrocas.txt.
Inclui dois IPs de destino. Destalhe: é somente adicionar os IPs, um por linha.

Lembrando que nos testes funcionou sem problemas.

Mas cada ambiente pode responder de forma diferente com possíveis erros diversos.

Nestes casos é interessante pesquisar a documentação e sites especializados, que pode ajudar e muito.

Fiz um arquivo batch e dei o nome de joga-lixo.bat (mas pode dar o nome que preferir). Coloque no diretório onde está o arquivo npp.exe pelo gerenciador de arquivo, execute o bat. O conteúdo do arquivo ficou da seguinte forma:

rem Copia e inicia instalador dos aplicativos remotamente em rede ruwindows

rem Nome do Arquivo: Joga Lixo

rem Arquivo: joga-lixo.bat

rem Autor: Mario Medeiros

rem Data: 2022-05-25 - 27

rem Versao: 0.2

psexec @lista-carrocas.txt -c "\\172.16.1.1\teste\npp.exe" cmd /S

pause

Mario Medeiros
Versão: 0.2.0
Data: 2022-05-27

Shell Script que move N arquivos de um diretório para subdiretórios

Problema inicial:
Ter milhares de arquivos (algo como 50 mil arquivos) em um único diretório e ter a necessidade de mover/separar em subdiretórios com quantidades menores, por exemplo, mil arquivos em cada diretório.

Uma solução que encontrei foi gerar um shell script que gere os subdiretorios e mova os arquivos com limites de mil arquivos em cada diretório destino.

Obs 0: O script deve estar no mesmo diretório dos N arquivos que serão movidos.
Obs 1: O diretório de destino onde serão criados os subdiretórios deve estar fora da estrutura onde estão os arquivos originais, parar não haver erros nas buscas do comando find ou outros erros.

Link para o vídeo descritivo
Link para o GitHub

A onda de pseudociências, negacionismo e a tal da pós-verdade, tem alcançado cada vez mais pessoas. Trazendo cada vez mais adeptos em grande quantidade e muito rápido.

Chegou no ponto em que grupos conseguem se organizar, com dinheiro, influência e até um certo grau de poder político.

O que antes era em parte uma mera piada (ainda é sim uma piada) está se tornando um grave problema cognitivo e social.

Estão atacando mais e mais as bases científicas e a técnica é simples: dizer sempre a mesma coisa inúmeras vezes, tornando assim para os “desavisados”, a nova verdade.

A palavra da vez para bater de frente com a Ciência é “Refutar”. Mas como todo bom pseudo-sei-la-o-que, é claro que distorcem o conceito da palavra.

O pouco que observo, me mostra que esses picaretas (sim, são picaretas e charlatões sim) estão ocupando os espaços como se não houvesse nenhuma resistência. O que por enquanto existe muito pouca por sinal.

Um dos efeitos de se atacar picaretas e charlatões é o de promovê-los, porque eles conseguem utilizar muito bem aquele ditado antigo e batido, mas que ainda funciona: falem mal, mas falem de mim.

Já havia mencionado sobre esse tipo de situação anteriormente, que é como combater a picaretagem. E sinceramente eu não vejo muitas alternativas racionais para tal.

Talvez, e somente talvez, num futuro não tão distante assim, poderia haver políticas ou ações da seguinte ordem:

Quem não aceitar as premissas da Ciência, estará automaticamente excluído dos acessos a seus benefícios. Alguns dirão que isso vai contra a liberdade de expressão e bla bla bla.

Existem limites para tolerâncias e pseudociência é uma das coisas que não deveriam ser toleradas. Atualmente pode soar como radicalismo, ou como alguns adoram usar, “fascismo”, mas para quem sabe fazer ao menos a tabuada do Zero, tente fazer uma projeção a longo prazo, de forma estatística de como as pseudagens estarão ocupando o dia-a-dia das pessoas.

Claro que sem efeitos práticos com benefícios reais. Vão manter as Ciências reais somente naquilo que não poderão substituir, mas atacarão e chegarão até mesmo proibir aquelas que acharem desnecessárias.

É um exagero isso? Talvez não seja, mas quem quer pagar para ver?

LowCypher Augur

2019-05-09 – 18:29h.

Link Vídeo

Linux, Vírus e RootKits

Uma das questões em que muitas pessoas ainda tem conceitos com base em desinformação é sobre os vírus para Linux. Tentarei ser breve e rápido em descrever e desmitificar isso.
Tem um sistema operacional (hahahahahahaha. Não ria, é feio!) de tela azul que atualmente deve estar na versão 10 ou 10.x, que é o mais suscetível a ser infectado por vírus. Esse sistema, é especialista nisso. Mas vamos discorrer um pouco sobre isso.
Primeiro dizem que só porque ele é o mais utilizado e por isso é mais “visado”. Segundo dizem que é uma forma de garantir o mercado de anti-virus, uma vez que o desenvolvedor proprietário desse sistema tem acordos de longa data com os desenvolvedores dessas ferramentas.
Vamos falar então sobre esses dois pontos.
Ser o mais “visado” não é necessariamente o motivo principal, mas é uma variável a ser considerada. No real é a estrutura básica do sistema que permite ser exploradas suas vulnerabilidades (um detalhe: não existe sistema cem por cento invulnerável).
A forma de lidar como o modo multiusuário é meio porco (tá bom, tá bom. É muito porco), permitindo que o usuário principal do sistema tenha os privilégios (na nomenclatura dele) de administrador para todas as tarefas, desde as corriqueiras até as realmente administrativas.
Aliado a isso, a forma como o mesmo instala programas é bem simplória: o famoso NNF, ou Next Next Finish.
Sobre o mercado de anti-virus, foi feito com o decorrer dos anos um monte de acordos para que os desenvolvedores dessas ferramentas fizessem o trabalho de fornecer o melhor possível, em matéria de software, para proteção do sistema operacional em questão. Até agora estão conseguindo até que mais ou menos bem, cumprir essa missão. Muitas vezes não conseguem mesmo, mas aí é outra estória.
Mas vamos deixar de lado esse sistema que é um pool, um repositório infinito, um “buraco negro” de coleta e uso de vírus.
É sobre vírus para Linux que pretendo falar rapidamente. O assunto é bem mais complexo, portanto deixarei algumas fontes/links no final para referências e melhores estudos.

Mitos E Verdades sobre Linux Ter Vírus

 Existem vários mitos sobre Linux ter ou não vírus e se ele é infectado ou não. 

Obs: uma falácia ou mito, é que uma vez que o Linux não tem tantos usuários assim, então não tem vírus para ele.

Primeiro: sim existem vírus para Linux
Segundo: não é assim tão simples uma infecção em Linux.

Pronto, resolvido.
Ah, não? Ah tá!! Vamos descrever então, um pouco sobre cada um dos pontos acima.

Primeiro item: existem vírus para Linux sim. Não tenho os dados de quantidade, mas existem sim. E parece não ser poucos. Mas tem alguns detalhes a serem considerados (sempre tem). A probabilidade de um sistema Linux ser infectado por vírus são muito baixas.
Segundo item: você teria que facilitar muito e até mesmo permitir algo do tipo: vírus, pode entrar no sistema e infectar o que der!!

O sistema é multiusuário, mas a forma como lida com seus usuários é bem mais criteriosa. Na instalação do sistema, é solicitado que crie um usuário padrão, com poucos privilégios sobre o sistema, para que possa trabalhar sem permissões de administrador, ops, ou melhor, Root. Com isso, o local de acesso desse usuário fica restrito ao seu próprio diretório “home’. Ex: /home/usuario
Quanto necessitar instalar ou fazer alterações no sistema, haverá uma solicitação de senha do usuário root, que é gerada no processo da instalação.
Com isso, a instalação de novas aplicações/programas e alterações nas configurações do sistema, ficam um pouco mais restritas. Diminuindo a possibilidade de falhas e/ou instalação de softwares maliciosos.
Em Linux existem várias formas de se instalar programas: os repositórios de softwares das distribuições, pacotes pré-compilados e os sources ou códigos fontes, para compilação na máquina local. O mais comum atualmente são os repositórios de softwares.
Um exemplo de repositório Debian:

deb http://ftp.br.debian.org/debian stable main contrib non-free

O repositório normalmente, estão alocados nos servidores da distribuição (mas pode ser local também, mas aí é uma outra estória, mas segue a mesa lógica). São mantidos pelos desenvolvedores, que também são tanto do projeto Debian, quanto desenvolvedores voluntários, que participam do projeto.
Esse modelo é muito utilizado em quase todas as distros (distribuições Linux) que existem. Isso também permite um controle mais apurado da qualidade e segurança dos pacotes de softwares. Claro que já houve situações em que, devido a alguma invasão ou até mesmo brechas de seguranças, os repositórios ficaram comprometidos com software malicioso. Um evento desse tipo que me lembro foi com o pessoal do Linux Mint, uma distribuição baseada em Debian e Ubuntu. Mas o que ficou comprometido foram as imagens ISO de instalação do sistema e não o repositório dos softwares. Mesmo assim foi complicado para o pessoal do Linux Mint, mas também foi relativamente rápido e eficiente a solução. Coisa que acontece quase nunca com o sistema de tela azul.
Nesse caso não foram vírus e sim invasão dos servidores, inclusão de códigos/softwares maliciosos nos arquivos de imagem ISO de instalação do sistema. O que pode ser algo similar.
Mas vamos então falar um pouco sobre algo que realmente é grave em Linux, os tais rootkits.
Não é tão diferente de se “infectar” com um rootkit. 

Rootkit:
é um software malicioso que permite o acesso a um computador enquanto oculta a sua atividade. Originalmente o rootkit era uma coleção de ferramentas que habilitavam acesso a nível de administrador para um computador ou uma rede. Uma das propostas desse programa é o uso para ocultar específicos processos e arquivos para algumas partes do sistema.
Comportamento:
O malware se integra a partes do sistema operacional para que não seja possível fazer a leitura do mesmo no disco rígido do computador. Assim dando a impressão que o mesmo não existe. Desta forma, sistema de segurança e proteção do computador, por exemplo, antivirus, não conseguem ler o código do software malicioso para efetuar testes de detecção e identificar ameaças. Outra função comum é camuflar seu processo de execução fazendo rodar como uma thread em algum processo essencial do sistema, como comando ls ou ps do Linux, não podendo ser visualizado como um arquivo ou processo do sistema.
Detalhe. Uma das formas de se infectar com rootkit, pode ser por algum programa pré-compilado fora dos repositórios ou pelos sources. Não é assim algo muito comum. Outra forma, seria por alguma via de invasão do sistema. Distros desatualizadas com falhas de segurança e/ou com configuração padrão, são propícias a “infecções”.

 Nestes casos, uma das ferramentas mais utilizadas para detecção de rootkits é o chkrootkit.
Pode-se instalar tanto pelo source (código fonte) ou pelo repositório.
Por exemplo, no Debian, como root: apt-get install chkrootkit
No site do desenvolvedor do chkrookit, tem a documentação de instalação e utilização do programa.

Testando Alguns Scripts

Então vamos fazer alguns experimentos simples para ver quanto de estrago poderemos causar.
Reforçando que a idéia aqui é fazer alguns testes e com isso ter o hábito de se ter alguns cuidados simples ao lidar com scripts e/ou pacotes de aplicativos/programas de terceiros.
Fiz alguns scripts pequenos que causam um certo contratempo na utilização do sistema. Não são nada de mais, mas que podem ser problemáticos se utilizados com objetivo de causar danos reais. Portanto use com cautela e de forma alguma utilize para prejudicar pessoas. Não é esse o objetivo desse texto/artigo.

Ferramentas utilizadas:
Primeiro Script:
Sistema Operacional: Linux Ubuntu Mate 18.10 x64, rodando no VirtualBox. Pode ser utilizado via Live/DVD ou pendrive bootavel.
Alertando: Não utilize os scripts em ambientes de produção. Somente em ambientes de teste.
Aplicações adicionais: fortune e xcowsay – instaladas via apt-get, pelo script “pseudo-virus”.

Procedimento: o script “libera-a-vaca”, trava com mensagens do fortune e xcowsay no ambiente gráfico - usa root na instalação e rodando em background pra ferrar de vez com tudo. Esse script grava o comando de repetição em loop no arquivo .bashrc do usuário comum e do root. Com isso, toda vez que o terminal for aberto, ele chama novamente o fortune e xcowsay, gerando mais um processo em background. A reação normal é tentar abrir um terminal, chamar o sudo su para tentar parar os processo. Mas como a linha de loop está no bashrc, ela gera um novo processo, joga em background e sai do login root. Legal né. Fiz um pacote .deb para instalar via dpkg e um script para rodar direto no terminal. Para cada situação o script está escrito com alguns detalhes diferentes para se instalar, mas no final o resultado é o mesmo. Para parar o processo, fiz o script “limpa-vaca”, que remove os pacotes fortune e xcowsay. De forma manual, é necessário parar os processos gerados e em background. Depois de reiniciar o sistema, o mais provável é que tudo volte ao normal como antes.
Obs 0: fiz os testes somente no modo livedvd do ubuntu mate, o que faz que perca todas as informações e configurações. Mesmo assim, evite fazer os testes em máquinas e sistema em produção.

Segundo Script:
Sistema Operacional: Linux Ubuntu Mate 18.10 x64, rodando no VirtualBox. Pode ser utilizado via Live/DVD ou pendrive bootavel.
Alertando: Não utilize os scripts em ambientes de produção. Somente em ambientes de teste.

Procedimento: o script utiliza comandos nativos do bash e algumas funções básicas para facilitar o estrago. Move arquivos e diretórios do home do usuário para tmp, deixando-os ocultos e mudando para nomes aleatórios utilizando a variável de ambiente $RANDOM, que serão substituídos por números. Variações do mesmo script para poder mover e apagar arquivos aleatórios e com sleep ininterruptos, dificultado encerrar o processo ou processos gerados.

Os códigos fontes dos scripts e o pacote .deb, estão no github.
Reforçando e Relembrando:
Mesmo estes scripts sendo simples, relativamente inofensivos, não deve-se utilizar para causar danos à terceiros. Servem somente para fins didáticos. De forma alguma devem utilizados para outros fins, que possam causar danos à terceiros. Utilize com responsabilidade e em ambiente controlado.

Existem outros tipos de scripts e/ou comandos que causam diversos transtornos em sistema UNIX/Linux. Uma busca no Google por “comandos perigosos em linux” retorna uma enorme quantidade de sites com as informações solicitadas.
Nenhum desses scripts que fiz, tem as características típicas ou conceituais dos virus de computadores. Tem somente um esboço dos conceitos, mas mesmo assim, podem causar danos, contratempos e com alguns ajustes nos códigos pode-se deixar os scripts com mais características de variantes de vírus.
Portanto, em sistemas UNIX/Linux, o maior causador de problemas é o vírus conhecido como usuário. Esse sim, pode causar estragos em escalas imensuráveis. E na maioria das vezes sem ser forma intencional.

Conclusão:
Linux pode se infectar com vírus? Sim! Como eu mencionei anteriormente, não é um sistema invulnerável. Mas a probabilidade de se pegar é muito baixa e não é algo tão simples assim. Está um tanto quanto paranóico? Configure seu firewall, que por um não acaso do universo, em Linux funciona sim. Tente acompanhar os changelogs dos desenvolvedores da sua distro. Utilize repositórios oficiais, que tenham uma boa manutenção e atenção de segurança. Claro, que não é necessário excluir, por excesso de zelo, outros repositórios ou os pacotes .deb ou de outro formato de sua distro. Só precisa dar uma lida na documentação dos pacotes, que normalmente tende a ser bem completa.
Outro detalhe, por mais eficiente e próximo da perfeição que seja o Linux ou qualquer outro sistema operacional, existe uma imperfeição que talvez passe despercebido: o usuário.
Em Linux, boa parte de seus usuários tem um conhecimento técnico bem mais apurado do que de outros sistemas não UNIX LIKE. Tendem a aprender mais sobre o sistema. Uma vez que Linux lhe dá poder absoluto de utilização, seu conhecimento sobre ele tende a ser mais alto também. Mas como tudo na existência possui exceções, aqui não seria diferente. Pode sim, e já (constatei essa situação), usuário utilizando Linux e fazendo as mesmas “maravilhas técnicas” que se faz no sistema de tela azul, com um pequeno detalhe: os estragos são extremamente maiores e mais duradouros.
Até mais.

Arquivos no GitHub

Vídeo no Youtube

Artigo Medium

Algumas Referências e Links:
https://www.diolinux.com.br/2014/02/por-que-linux-android-nao-pega-virus.html
https://wiki.debian.org/configura%C3%A7%C3%A3o%20repositorios%20PT%20BR
https://en.wikipedia.org/wiki/Linux_malware
https://pt.wikipedia.org/wiki/Rootkit
https://pt.wikipedia.org/wiki/F.I.R.E
http://www.chkrootkit.org/

A referência sobre a infecção do ISO Linux Mint, que ocorreu em 20 de Fevereiro 2016, está em:

https://pplware.sapo.pt/linux/atencao-linux-mint-pode-estar-infectado/

Mario Medeiros
2019-02-22 – 15:31h.