Longest Repeated Subsequence (Sequencia repetida comum mais longa)

bad ownership or modes for chroot directory component

Queria deixar o diretório /var/www disponível para um usuário fazer SFTP nele, sem poder acessar os demais diretório do servidor. Configurei o acesso do usuário no /etc/ssh/sshd_config (outro post).
Contudo ao tentar logar via sftp, obtinha o seguinte log

Accepted password for MY_USER
session opened for user MY_USER by (uid=0)
fatal: bad ownership or modes for chroot directory component "/var/www/RESTRICTED_DIR"
pam_unix(sshd:session): session closed for user MY_USER

Removendo a configuração do usuário no sshd_config, o usuário MY_USER conseguia logar, mas com acesso a todos os diretórios.
No man page do chroot que é utilizado para limitar o acesso diz que

ChrootDirectory

Specifies the pathname of a directory to chroot(2) to after authentication.
All components of the pathname must be root-owned directories that are not 
writable by any other user or group. After the chroot, sshd(8) changes the 
working directory to the user's home directory.

Ou seja, os diretórios var e www devem ser do usuário root e não podem ter permissão de escrita por outro usuário. No meu caso o problema era no diretório www que era writable (+w) pelo grupo de MY_USER. Estas permissões podem ser garantidas configurando o owner dos dois diretórios e removendo a permissão e escrita do grupo e others.

$ sudo chown root /var
$ sudo chmod g-w /var
$ sudo chmod o-w /var
$ sudo chown root /var/vww
$ sudo chmod g-w /var/www
$ sudo chmod o-w /var/www

Redirecionando mensagens do iptables para outro arquivo

Administrar bem um firewall implica em avaliar constantemente os arquivos de log. Por default no Ubuntu 18 os logs do iptables são gravados no arquivo /var/log/syslog. Contudo neste arquivo também são gravadas diversas outras informações. Se seu firewall gera muita mensagem, fica difícil achar uma mensagem de outro serviço (por exem plo, do DNS), da mesma forma também não dá para descartar os arquivos syslog antigos que ficam muito grandes.
Isso pode atrapalhar as coisas e dificultar a verificação dos logs.

Se você deseja alterar o arquivo no qual o iptables registra, é necessário configurar as regras do iptables para gerar um prefixo de log.

O gerenciador de logs do ubuntu é rsyslog. Podemos configurá-lo para pegar o prefixo gerado pelo iptables e enviar todas as linhas com este prefixo para um arquivo de log personalizado, contendo apenas as informações de log do iptables.

As minhas linhas gerados pelo iptables tem o seguinte formato. Note que não estou utilizando um prefixo no log do iptables. e que dá para distinguir as linhas, pois todas contém a palavra: NETFILTER.

Mar  5 16:21:26 afirewall kernel: [ 1249.242830] NETFILTER NEW IN PACKET:IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.53 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=43478 DF PROTO=UDP SPT=58264 DPT=53 LEN=51
Mar  5 16:21:26 afirewall kernel: [ 1249.242863] NETFILTER NEW IN PACKET:IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.53 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=43479 DF PROTO=UDP SPT=58264 DPT=53 LEN=51

Então precisamos configurar o rsyslog para tratar de forma diferente as linhas geradas pelo iptables.
Para isto, crie um arquivo de configuração vazio (todos os comandos a seguir são dados como root ou via sudo) com o seu editor favorito:

$ sudo vi /etc/rsyslog.d/10-iptables.conf

Entre as duas linhas a seguir neste arquivo e grave-o:

:msg, contains, "NETFILTER " -/var/log/iptables.log
& ~

Salve o arquivo e saia do editor. A primeira linha verifica os dados do log para a palavra "NETFILTER " e os anexa ao arquivo /var/log/iptables.log. Note que você pode utilizar no iptables prefixos diferentes para regras diferentes e assim ter diversos arquivos. No meu caso, só quero colocar tudo em um arquivo chamado iptables.log. A segunda linha simplesmente interrompe o processamento das informações de log, para que elas não sejam registradas em /var/log/syslog.

Reinicie o rsyslog:

$ sudo service rsyslog restart

Pronto! O syslog agora está gravando as mensagens do iptables no arquivo desejado.

"Route not found" no Debian

Você está usando o Debian e quer ver quais as rotas configuradas no seu sistema. Um comando útil para isto é route. Porém quando vocë dá o comando:

$ route
bash: route: command not found

Existem normalmente dois motivos para que isto aconteça. O primeiro motivo é que o caminho para route não está configurado para seu usuário, pois ele fica em /sbin. Quando você procura usando whereis, o sistema não retorna. Note no segundo comando abaixo que /sbin não está no path.

$ whereis route:
route:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin

Assim você pode simplesmente chamá-lo usando o caminho completo /sbin/route.

Contudo, pode ser que mesmo assim você não ache o comando. 




$ /sbin/route
bash: /sbin/route: No such file or directory

Isto ocorre porque o pacote net-tools não está instalado. Para instalar basta:

$ sudo apt install net-tools

Agora finalmente o comando deve funcionar. Note que ainda assim o caminho não está no PATH, portanto você precisa colocar o caminho completo.

$ route -n
bash: route: command not found

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s3

Parametros do BIND para fazer uma migração de IP em seu domínio

Existem duas configurações diferentes para o TTL padrão nos arquivos do  DNS (BIND) que você precisa alternar quando for alterar o endereço IP de um ou mais servidores para um endereço IP diferente.
Neste post estamos considerando a versão 9 do BIND, mas o conceito deve funcionar para a maioria dos DNS. Podendo, contudo, alterar com cada parâmetro é configurado.


As configurações que você terá que fazer são:

1. configuração de armazenamento em cache negativo no registro SOA. Este parâmetro é última entrada do registro SOA. Normalmente, o TTL padrão é definido como um dia, que é 86400 segundos. Para obter mais informações sobre cache negativo, consulte rfc2308.
2. TTL padrão na parte superior do arquivo (é uma linha começada com $ttl). O valor padrão para este campo é definido como 86400.
3. Pode ser que existam ainda casos pontuais nas linhas de configuração do seu arquivo, pois o BIND permite que você tenha configurações TTL diferentes para cada registro individual. Neste caso você terá mais trabalho pois será necessário defini-las também. 

Se os valores do cache negativo no registro SOA e do TTL padrão estiverem nos valores default, isso significa que respostas negativas e consultas positivas serão armazenadas em cache por um dia.


No exemplo a seguir, mudamos os TTLs para 14400 que corresponde a 4 horas:

$ORIGIN meudominio.com.br.
$TTL    14400          ; 4H (ttl)
@       IN  SOA ns.meudominio.com.br.   admin.meudominio.com.br. (
            2020012101 ; serial
            1H         ; refresh
            7200       ; retry = 7200 min
            14D        ; expiration time
            4H         ; ttl
            )

Note que em algumas linhas existem comentários, que começam com ponto e vírgula.

Colocar Ubuntu rodando somente texto

Em sistemas mais antigos bastava a gente acertar o runlevel para o nível 2.
O Ubuntu 18.04 usa systemd em vez de init (no 16.04 também já é assim),
O conceito de runlevels é substituído por "target", que é o modo de operação do linux.
Portanto, existe realmente um mapeamento entre os níveis de execução (runlevel) baseados em init e os destinos baseados em systemd como mostrado na tabela abaixo:

Assim para trocar para o runlevel 2, utilizamos os comando abaixo:

$ sudo systemctl isolate multi-user.target
$ sudo systemctl enable multi-user.target
$ sudo systemctl set-default multi-user.target

Tento executado estes comando, basta dar um reboot para que o sistema entre no runlevel 2. 


Observação: 
Para testar somente o runlevel, você pode dar

$ sudo init 2

Instalar o skype no Ubuntu pela linha de comando

A instalação na linha de comando no Ubuntu não deu muito problema no meu caso.
Basicamente basta entrar com a sequência de comandos abaixo no terminal (digite CTRL+ALT+T para abri-lo na interface gráfica).
Pode ser que no seu caso apt-transport-https já esteja instalado (no meu estava), contudo não tem problema dar o comando, pois a única coisa que irá acontecer é que vai demorar alguns segundos a mais e o Ubuntu dar um aviso que já está instalado.

$ echo "deb [arch=amd64] https://repo.skype.com/deb stable main" | sudo tee /etc/apt/sources.list.d/skype-stable.list
$ wget https://repo.skype.com/data/SKYPE-GPG-KEY
$ sudo apt-key add SKYPE-GPG-KEY
$ sudo apt install apt-transport-https
$ sudo apt update
$ sudo apt install skypeforlinux

Tento finalizado com sucesso a instalação. Você dever digitar o comando abaixo no terminal para abrir a interface gráfica do Skype.

$ skypeforlinux

Basta fazer o login, permitir acesso ao microfone, câmera, etc. e pronto.