🍁 ✍️ 🍈 A história da criação de uma nuvem doméstica. Parte 2. Criando um servidor

No caminho para criar nosso próprio serviço de nuvem, acabamos de nos acostumar com o sistema Debian . Agora chegou a hora do próximo passo - a criação e configuração de um servidor da Web, com base no qual o Nextcloud pode ser iniciado.

Sumário

Parte 1. Configurando seu ambiente Debian para uso diário
Parte 2. Criando um servidor - configurando o LAMP no Debian
Parte 3. Criando uma nuvem pessoal - instalando e configurando o Nextcloud
Parte 4. Atualização 2018 - Debian 9 e Nextcloud 13
Parte 5. Atualizando 2019 - PHP 7.2, MariaDB 10.4 e Nextcloud 17

Navegação rápida por capítulo

Prefácio
Instalação de software
Configurando o servidor da web Apache2 e acessando-o através dos protocolos HTTP e HTTPS
Ajuste de SQL
Configuração do PHP
Configurações de acesso SSH
Proteção de acesso
Referência do servidor Web
Referência do MySQL
Material de referência Fail2ban

Prefácio

A primeira parte desta história mostrou uma das opções possíveis para configurar a GUI Debian para uso conveniente e familiar (ponto de vista exclusivamente subjetivo do autor) por uma pessoa que veio do Windows para Linux. E se eu usei apenas o sistema host para configurar a máquina virtual com o Debian, trabalhei especificamente nessa máquina virtual, procurando informações na Internet, anotando no Notepadqq ou no gedit, ouvindo música no Audacious, abrindo arquivos através do LibreOffice e similares. Dessa forma, você pode se acostumar e se sentir muito mais profundo e apreciar o trabalho com o sistema operacional e seu ambiente, que é bastante completo e funcional no pacote Debian padrão.

No momento, nosso sistema está configurado de tal maneira que, no futuro, você só poderá usar a linha de comando com um editor de texto do console, por exemplo, nano ou usar o gerenciador de arquivos Double Commander com o editor Notepadqq integrado. É possível combinar esses dois métodos, por exemplo, navegando no sistema e editando os arquivos de configuração por meio do gerenciador de arquivos e todos os outros comandos pelo console. Todos os métodos são equivalentes para alcançar o resultado final.

O objetivo atual é criar um servidor ao qual esta parte será dedicada. O servidor pode ser configurado com a instalação e o uso da interface gráfica e sem ela. No segundo caso, da parte anterior, você pode simplesmente pular as seções relativas à instalação e configuração de software para a interface gráfica e suas configurações, instalação de pacotes de software gráfico e vmware-tools.

Não vejo nada de errado em usar a interface gráfica ao criar um servidor: se é mais familiar, mais conveniente e confortável para uma pessoa criar seu primeiro ou segundo servidor com um ambiente gráfico - por que não? No final, meu servidor Web com uma interface gráfica funcionou por um ano e funcionará quantos anos forem necessários. No entanto, você precisa ter em mente alguns pontos.

Idealmente, uma vez configurado, o sistema terá que funcionar sem a nossa intervenção por muito tempo. Meu servidor na versão "finish" foi configurado em dois dias e funcionou sem intervenção por quase um ano. Isso significa que a interface gráfica utilizou 0,05% da existência ativa do servidor (o computador funciona apenas por meio dia) e, ao mesmo tempo, consumiu recursos: RAM, espaço em disco, tempo do processador. Todos esses recursos são mais bem gastos em garantir o funcionamento do próprio servidor: por exemplo, aumente o memory_limit para PHP ou armazene mais dados do usuário no disco rígido. Além disso, em caso de problemas e mau funcionamento ao trabalhar com um servidor remoto real, geralmente é muito mais fácil usar o acesso SSH . Nesse contexto, a presença de uma interface gráfica é indesejável e é por isso que o segundo servidor da minha rede já era uma máquina virtual sem um ambiente gráfico no qual apenas o Midnight Commander foi instalado a partir do software gráfico, que eu usei para navegar no sistema de arquivos e editar os arquivos de configuração através do editor do mcedit . Portanto, a seguir é uma instrução universal: dados comandos com ênfase no uso da linha de comando, no entanto, entende-se que, pela primeira vez, o usuário configura a máquina com um ambiente gráfico, devido ao uso de um navegador para verificar localmente a disponibilidade dos sites criados e alguns recursos de configuração do programa de correio.

No processo de criação do servidor e ao adicionar novos sites, acumulei algumas informações básicas que podem ser úteis para um usuário iniciante. Eu o descrevi após o material sobre instalação e configuração do servidor.

Nota
Após uma leitura mais aprofundada nas construções do formulário http: // 127.0.0.1 (https: // 127.0.0.1), o espaço após http: // (https: //) deve ser removido ao entrar na barra de endereços do navegador. Um espaço foi inserido ao publicar este artigo para impedir que o mecanismo converta automaticamente o texto em links.

Instalação de software

Apache e Nginx são um par de servidores Web de código aberto nos quais cerca de 55% dos servidores em todo o mundo são criados. O Apache é o servidor da web mais popular desde 1995 e eu o escolhi esperando por boa documentação, popularidade e, por assim dizer, eu queria começar do começo. Isso não significa que o Nginx é pior: o Nginx é mais eficiente no consumo de recursos e no trabalho sob carga. No segmento russo da Internet, o servidor Nginx ocupa cerca de 65%, enquanto o Apache - cerca de 18%. Um bom artigo comparativo de dois servidores é publicado no hub

Instalando o servidor Web Apache2:

# apt-get install apache2 apache2-doc

E isso é tudo. Cerca de vinte megabytes e um servidor web já estão instalados. Não são necessárias reinicializações ou configurações - o servidor já sabe como abrir páginas HTML . No entanto, um site moderno na Internet não é apenas um conjunto de arquivos estáticos, estilos, fontes e afins, como vinte anos atrás. Um site moderno contém scripts escritos em PHP e informações dinâmicas (por exemplo, conteúdo de texto, comentários, perfis de usuário) não são gravadas nos arquivos próximos aos arquivos PHP, mas em um banco de dados SQL especial. Para um servidor completo, você deve fornecer suporte para essas tecnologias. Além disso, não é difícil:

# apt-get install mysql-server mysql-client phpmyadmin
# apt-get install php5 php5-mysql libapache2-mod-php5

Durante a instalação do MySQL, você será solicitado a definir a senha do superusuário do mysql e precisará selecionar o servidor apache2 para configurar automaticamente o trabalho com o mysql. Ao instalar o pacote phpmyadmin , concordei em configurar automaticamente o pacote e em todos os lugares digitei a senha root do mysql. A instalação do PHP ocorre sem solicitações.

Eu não usei o PHP7 mais rápido ou o MariaDB gratuito como uma alternativa alternativa de SQL aberto e decidi construir meu servidor no LAMP "canônico" = Linux + Apache + MySQL + PHP, usando soluções antigas e comprovadas, em caso de problemas com os quais eu pudesse rapidamente e encontre facilmente informações na Internet.

Três equipes (que de fato podem ser reduzidas a uma) e instalamos localmente um servidor completo e moderno. É muito simples!

Mas a configuração do servidor leva muito mais tempo do que a instalação de seus componentes. Inicialmente, nesta parte, eu queria mostrar meus erros típicos, soluções falsas para os problemas e os resultados que eles levaram, mas aconteceu que muitas coisas foram apagadas da minha memória em um ano, eu tive que me recuperar muito dos registros, portanto, a seguir, apenas vou definir uma instrução de trabalho com pequenas comentários, permitindo alcançar um resultado de trabalho universal.

Configurar o servidor Web Apache2

Primeiro, você precisa garantir que o servidor da web esteja funcionando. Para fazer isso, abra um navegador e disque o endereço http: // 127.0.0.1 ( localhost ). Uma inscrição encorajadora deve abrir: “Página Padrão do Apache2 Debian. Isso funciona! O servidor realmente funciona. Se você tiver um conjunto de arquivos de site para o ano 2000, poderá colocá-lo no diretório / var / www / html e provavelmente será aberto em nosso servidor.

Todas as configurações básicas do servidor da web são armazenadas no caminho / etc / apache2. Se você abrir esse diretório, poderá ver o arquivo de configuração principal apache2.conf e os diretórios conf-available, mod-available, sites-available. Esses diretórios contêm arquivos pré-configurados com configurações (os chamados snippets), que você pode simplesmente usar por padrão, com suas próprias edições, ou levá-los como modelo para criar suas próprias configurações. Por exemplo, no diretório sites disponíveis, está o arquivo de configuração do host padrão 000-default.conf. Se você o abrir e estudá-lo, esse arquivo define o caminho pelo qual nosso site é aberto no endereço http: // 127.0.0.1: “DocumentRoot / var / www / html”. Além disso, a linha "<VirtualHost *: 80>" significa que, se eu liberar minha máquina em uma rede local e acessá-la na porta 80 (porta para HTTP ), vou abrir um site localizado no caminho / var / www / html. Como verificar isso?

Primeiro, você precisa descobrir o endereço IP atribuído à máquina virtual após o carregamento. Para visualizar a configuração dos adaptadores de rede, execute:

# ifconfig

Nas informações exibidas no console, é fácil determinar se o seguinte endereço está definido para o adaptador eth0:

inet addr:192.168.233.138

Agora, na máquina host, abro o endereço do navegador http: // 192.168.233.138 no navegador e espero que uma página familiar seja aberta. Mas ... ela não abre. Depois de algum tempo, meu navegador escreve: "A conexão expirou." E ele escreve corretamente. Na verdade, na primeira parte, liguei o firewall, mas a porta 80 não abriu! Vamos consertar isso:

# ufw allow 80

Novamente, tente abrir o endereço http: // 192.168.233.138 e verifique se a página esperada é aberta. O host virtual na máquina virtual foi aberto fora de toda essa virtualização. Demos um pequeno passo na construção de nossa própria pequena Internet virtual.

Além dos diretórios disponíveis, também existem diretórios ativados que contêm o que está atualmente "incluído". Se você olhar para eles, poderá ver que esses diretórios contêm links para arquivos localizados nos diretórios disponíveis. Atualmente, existe apenas um link no diretório habilitado para sites - o arquivo /etc/apache2/sites-available/000-default.conf. Isso é muito conveniente - podemos controlar atalhos dentro ou fora dos hosts sem editar seus arquivos de configuração. Além disso, a origem da configuração é se um arquivo de configuração está incluído independentemente ou não agora, e isso evita erros quando algo é corrigido em um arquivo e esquecido em outro. Para desativar nosso host, você precisa excluir o atalho necessário e, para ativá-lo, criá-lo. Para não excluir ou criar atalhos manualmente, é mais fácil e confiável usar utilitários especiais.

Desative o host virtual:

# a2dissite 000-default

Ligue o host virtual:

# a2enssite 000-padrão

Após cada alteração, você precisa reiniciar as configurações do host ou reiniciar o servidor:

# service apache2 reload

ou

# service apache2 restart

Portanto, agora está disponível um entendimento básico de como configurar hosts regulares no apache e mostrarei um exemplo de como configurei meu servidor para trabalhar com os protocolos HTTP e HTTPS .

Você precisa começar com o fato de que, ao desconectar o host virtual 000 padrão, a desconexão não ocorre. Ou seja, o site é aberto de dentro e de fora da máquina virtual - e será aberto independentemente de sua configuração estar na pasta habilitada para sites. Isso foi inesperado e passei um tempo relativamente longo para entender se fiz tudo certo ou entendi. Até o final, eu ainda não entendi isso, aparentemente isso se deve ao fato de o caminho / var / www / html estar definido globalmente como o diretório padrão do DocumentRoot. Como não queria que algo desnecessário fosse incluído e acessível, decidi me livrar do próprio diretório html e, para todos os / var / www aninhados, negar o acesso por padrão.

Para configurar o host virtual padrão, editei seu arquivo de configuração:

# nano /etc/apache2/sites-available/000-default.conf

O conteúdo do arquivo de configuração é o seguinte:

 <VirtualHost *:80> ServerName localhost ServerAdmin user@localhost DocumentRoot /var/www <Directory /var/www> Options FollowSymLinks AllowOverride All Require all denied </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>

Com essa configuração, redefini o diretório padrão para / var / www, permiti que o servidor seguisse links simbólicos nesse diretório, permiti que o servidor executasse todas as diretivas declaradas nos arquivos .htaccess encontrados e neguei acesso a esse diretório. A lógica dessas ações é que eu posso controlar o acesso a esse diretório sem acessar as configurações do servidor da Web e sem reiniciá-lo. Agora você precisa verificar esta solução.
Transfira o arquivo:

# mv /var/www/html/index.html /var/www/index.html

E exclua o diretório:

# rm / var / www / html

Reiniciamos o servidor para que as novas configurações padrão do host virtual entrem em vigor:

# service apache2 restart

Crie um arquivo:

# nano /var/www/.htaccess

Na qual escrevemos uma linha (sem aspas): "Exigir tudo concedido".

Para resumir. Agora não há caminho / var / www / html, mas o host é reconfigurado por padrão para o caminho / var / www, onde o arquivo index.html está localizado e, por padrão, no nível do servidor da web, o acesso a esse diretório é negado, mas o conteúdo é permitido localmente o arquivo .htaccess localizado lá.

Abra o navegador http: // 127.0.0.1 e veja a página já familiar “Página Padrão do Apache2 Debian. Isso funciona. " Agora vamos verificar a operabilidade do controle de acesso "local":
Exclua o arquivo .htaccess:

# rm /var/www/.htaccess

E atualizamos a página aberta no navegador - a página com o aviso de restrição de acesso (Proibido) deve abrir. Sim, tudo isso funciona, então tudo é feito corretamente.

Em princípio, essas configurações simples são suficientes para a operação sem complicações do servidor da web. Mas me pareceu não o suficiente. Agora, nosso servidor da web pode funcionar apenas usando o protocolo HTTP. Mas e o protocolo HTTPS? Afinal, se no futuro trazer projetos baseados nesse servidor da Web para a Internet, a capacidade de trabalhar nesse protocolo é pelo menos desejável. E decidi organizar o suporte HTTPS com base na criação de um certificado SSL autoassinado.

Primeiro, você precisa obter um certificado SSL que será instalado em nosso servidor. Não temos domínio e também não temos um endereço IP estático. Mas tudo isso não importa, porque eu mesmo gerarei o certificado, usando as ferramentas do meu sistema.

Atenção! As instruções abaixo assumem que o servidor está instalado em uma máquina sem nome. Se houver um IP ou nome de domínio real, eles deverão ser especificados em TRÊS locais: <Common Name IP / Domain>; <Nome_do_servidor IP / domínio>; <Redirecionar "/" "https: // IP / Domínio /"> - nas construções apropriadas, substitua IP / Domínio por um endereço IP ou nome de domínio. No texto abaixo, localhost é usado em vez de IP / Domínio.

Gere um certificado SSL:

# openssl req -x509 -nodes -days 3650 -newkey rsa: 2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Esse comando criará imediatamente um certificado autoassinado do padrão X.509 por 10 anos, ignorando a opção de proteção de certificado com uma senha - isso é necessário para que, ao iniciar o servidor Apache, possa ler o arquivo sem a intervenção do usuário, pois, ao definir uma senha, você deverá inseri-lo após cada inicialização ou reinicialização servidor. Juntamente com o certificado, uma nova chave RSA para 2048 bits será criada, com a qual o certificado será assinado. As opções –keyout e –out indicam os caminhos pelos quais o OpenSSL deve gerar a chave e o certificado.

No processo de criação do certificado, serão feitas perguntas, às quais indiquei os seguintes dados:

Nome do país = MW
Nome do estado ou província = Sun System
Nome da localidade = Lunar
Nome da Organização = Hellium Inc.
Nome da Unidade Organizacional = 2
Nome comum = localhost
Endereço de email = user @ localhost

Em seguida, crie as chaves Diffie-Hellman para fornecer suporte ao PFS :

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Pontos e vantagens serão executados no terminal e, após o final do desenho animado, você poderá criar o arquivo ssl-params.conf no qual os parâmetros SSL do servidor serão definidos:

# nano /etc/apache2/conf-available/ssl-params.conf

Para uma configuração segura e atualizada, usei o código gerado no gerador para configurar o SSL no mozilla.imtqy.com . No gerador, selecionei o servidor Apache2, o perfil Moderno e configurei corretamente as versões do servidor e do OpenSSL, que podem ser reconhecidos pelos seguintes comandos:

# apache2 -v
# versão openssl

Como resultado, recebi o seguinte texto:

 # 14-01-2018 / for apache2 2.4.10 & openssl 1.0.1t # from https://mozilla.imtqy.com/server-side-tls/ssl-config-generator/ # parametrs help: https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html # modern configuration, tweak to your needs SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 SSLHonorCipherOrder on SSLCompression off # OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)

Agora configure o host virtual com suporte SSL:

# nano /etc/apache2/sites-available/default-ssl.conf

Eu trouxe o texto deste arquivo para o seguinte formulário:

 <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin user@localhost ServerName localhost DocumentRoot /var/www <Directory /var/www> Options FollowSymLinks AllowOverride All Require all denied </Directory> # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15768000" ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule>

Do exposto acima, também temos / var / www definido como o diretório DocumentRoot, cujo acesso é configurado de forma semelhante às configurações anteriores. O mecanismo HSTS está ativado , o que ajuda a forçar a conexão através do protocolo HTTPS. O suporte a SSL está incluído no certificado e na chave usados, bem como no processamento de dados do certificado em scripts PHP e CGI . A última seção foi projetada para fornecer compatibilidade com versões anteriores do Internet Explorer e, em geral, não é necessária.

Agora vamos fazer os retoques finais.

Vamos abrir a porta para SSL:

# ufw allow 443

Ative os módulos apache para suporte a SSL e HSTS:

# a2enmod ssl
# a2enmod cabeçalhos

Habilite a configuração SSL:

# a2enconf ssl-params

Ative o host virtual ativado para SSL:

# a2ensite default-ssl

Reinicie o servidor para aceitar todas as novas configurações:

# service apache2 restart

Então chegou o momento interessante - verificar a operacionalidade da nova funcionalidade do sistema configurado.

Crie um arquivo:

# nano /var/www/.htaccess

Na qual prescrevemos uma linha: "Exigir tudo concedido".

Abra no navegador https: // 127.0.0.1. Uma página sobre um certificado desconhecido deve abrir, após aceitá-lo (permissão única ou permanente), uma página familiar com uma notificação sobre um servidor Web em execução será aberta.

Exclua o arquivo .htaccess:

# rm /var/www/.htaccess

E atualizamos a página aberta no navegador - a página com o aviso de restrição de acesso (Proibido) deve abrir. Tudo funciona corretamente. Agora, nossos sites estão acessíveis via HTTP e HTTPS.

O acesso HTTP pode ser deixado ativado, desativado ou forçado a redirecionar para HTTPS.

Para acesso ativado por HTTP, nada precisa ser feito, pois o servidor processa as solicitações das portas 80 e 443 individualmente e nosso site na pasta / var / www será aberto por HTTP e HTTPS.

Para desativar o acesso HTTP, basta desativar o host virtual correspondente e reiniciar o servidor da web:

# a2dissite 000-default
# service apache2 restart

Agora, se você abrir http: // 127.0.0.1 em um navegador, uma página com uma notificação sobre a ausência de uma página (não encontrada) deverá ser aberta.

A terceira opção mais interessante. Nesse caso, o HTTP permanece formalmente ativado, mas o processamento de dados será redirecionado à força via HTTPS.

Para fazer isso, primeiro habilite o módulo de redirecionamento:

# a2enmod reescrita

Agora abra o arquivo 000-default.conf:

# nano /etc/apache2/sites-available/000-default.conf

E antes da tag de fechamento, adicione o seguinte texto:

 RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

Reinicie o servidor:

# service apache2 restart

Crie um arquivo:

# nano /var/www/.htaccess

Na qual prescrevemos uma linha: "Exigir tudo concedido".

Agora, se você abrir o endereço http: // 127.0.0.1 em um navegador, seremos automaticamente redirecionados para https: // 127.0.0.1 com um aviso sobre um certificado desconhecido (se não tiver sido adicionado anteriormente à lista de exclusão no navegador), depois de aceitá-lo, um já familiar será aberto página de notificação do servidor da web.

Ajuste de SQL

Para a configuração inicial do mysql, basta executar o seguinte comando:

# mysql_secure_installation

Depois de inserir a senha do superusuário do mysql, respondi às perguntas na seguinte ordem:

recusou-se a alterar a senha root;
confirmou a remoção de usuários anônimos do banco de dados;
Confirmado o bloqueio da conexão remota por raiz (por razões de segurança, a raiz está conectada apenas localmente);
confirmou a remoção dos bancos de dados de teste;
concordou em recarregar tabelas de privilégios.

Para verificar a saúde do mysql, você pode executar o seguinte comando:

# mysql -uroot -p

Após digitar a senha do superusuário do mysql, vemos o prompt do mysql - significa que o serviço está em funcionamento. Você pode sair do terminal mysql digitando o comando exit.

Para verificar o desempenho do phpmyadmin, abra o endereço http: // 127.0.0.1/phpmyadmin no navegador. Se uma página for aberta com um convite para inserir phpmyadmin, o serviço estará em funcionamento.

Configuração do PHP

Depois de instalar o PHP, abri o arquivo de configurações:

# nano /etc/php5/apache2/php.ini

E ele trouxe alguns parâmetros para a seguinte forma:

memory_limit = 1024M
default_charset = "UTF-8"
upload_max_filesize = 256M
sendmail_path = /usr/bin/fake_sendmail.sh

Usando o módulo PHP, você pode fornecer armazenamento em cache de dados na memória. O armazenamento em cache é útil no caso de alta carga do servidor para dados, cuja geração requer uma grande quantidade de recursos, por exemplo, os resultados de consultas ao banco de dados ou o processamento de partes "pesadas" de um modelo de site. Como servidor de cache, escolhi o módulo memcached .

Instale o memcache:

^{[ Este texto foi escrito especificamente para o site geektimes.ru por AlexanderS .} ^{O link para a fonte é opcional, mas sua referência é altamente desejável!} ^]

# apt-get install memcached php5-memcached

Vamos dar uma olhada nas definições de configuração do serviço:

# nano /etc/memcached.conf

Nas configurações, aumentei o tamanho da memória usada para armazenar em cache: -m 64 -> -m 256. E verifiquei a disponibilidade do modo de operação apenas na zona local: -l 127.0.0.1.

Reiniciamos o serviço de armazenamento em cache e o servidor da web:

# service memcached restart
# service apache2 restart

Agora você precisa garantir que o serviço esteja funcionando. Para fazer isso, crie um arquivo:

# nano /var/www/info.php

E adicione o seguinte texto a ele:

 <?php phpinfo (); ?>

Não se esqueça de verificar a existência do arquivo .htaccess no diretório / var / www com o conteúdo permissivo correspondente, se não estiver lá, crie-o.

Agora você pode abrir em seu navegador http: // 127.0.0.1/info.php - uma página com informações sobre PHP deve abrir, na qual você precisa verificar a seção memcached nela. Se a tabela aparecer - o PHP está funcionando.

Você pode verificar o serviço memcached em execução assim:

$ ps -aux | grep memcached

O terminal deve retornar uma string contendo configurações armazenadas em cache.

Criando um Stub de Correio para PHP

Nas configurações do PHP, um script de shell foi especificado como o parâmetro sendmail_path. A função desse script é salvar as cartas enviadas através da função php mail () padrão na máquina local, em alguma pasta conveniente, e não enviá-las para algum lugar.

Crie um arquivo:

# nano /usr/bin/fake_semdmail.sh

Com o seguinte conteúdo:

 #!/bin/sh prefix="/var/mail/sendmail/new" numPath="/var/mail/sendmail" if [ ! -f $numPath/num ]; then echo "0" > $numPath/num fi num=`cat $numPath/num` num=$(($num + 1)) echo $num > $numPath/num name="$prefix/letter_$num.txt" while read line do echo $line >> $name done chmod 777 $name /bin/true

Torne este arquivo executável:

# chmod + x /usr/bin/fake_semdmail.sh

Crie os diretórios necessários, se você configurar a coleção de cartas pelo programa de email:

# mkdir / var / mail / sendmail / var / mail / sendmail / cur / var / mail / sendmail / novo / var / mail / sendmail / tmp

E atribuímos direitos para que o servidor possa gravar arquivos nesta pasta:

# chmod 777 -R / var / mail / sendmail

Agora todos os emails enviados serão adicionados a / var / mail / sendmail. Eles podem ser visualizados com um editor de texto ou podem ser coletados por programa de correio. O software pré-instalado Debian vem com um cliente de email Evolution. Ao configurar a conta, selecione “Diretórios de correio no formato Maildir” como o tipo de servidor e especifique o caminho para o diretório de correio (/ var / mail / sendmail) e selecione “Sendmail” como servidor.

Só isso. Em geral, terminamos o servidor - é obtida uma máquina virtual universal, com base na qual você pode criar seus serviços de rede. Deixei os acessos HTTP e HTTPS. No entanto, depois de ganhar experiência na criação e configuração de um servidor, além de adicionar sites (veja abaixo), eu recomendaria a criação de uma nova máquina virtual com um servidor sem uma interface gráfica como o consumo ideal de recursos.

Configurações de acesso SSH

Um servidor não seria um servidor completo sem acesso através do SSH. O chamado "shell" permite que você se conecte de forma rápida e segura a um servidor remoto, usando, por exemplo, um pequeno programa de massa - no computador local, obtemos acesso direto ao terminal do servidor remoto.

Instalação de serviço:

# apt-get install ssh

Vamos abrir a porta para SSH (na verdade, a porta padrão deve estar no número 22, mas abaixo eu redefini a porta na configuração SSH):

# ufw allow 106

Para organizar o acesso de nosso usuário, abra o arquivo:

# nano / etc / ssh / sshd_config

E adicione a diretiva no final do arquivo:

Usuário AllowUsers

Além disso, por motivos de segurança, fiz as seguintes alterações neste arquivo:

porta alterada de 22 para outra ( lista de portas ): Porta 22 -> Porta 106
desativou o protocolo herdado: Protocolo 2.1 -> Protocolo 2
acesso remoto desabilitado para raiz: PermitRootLogin yes (ou PermitRootLogin sem senha) -> PermitRootLogin no

Em seguida, reinicie o serviço:

# service sshd restart

Agora posso executar o programa putty na máquina host e conectar-me ao meu servidor no modo console digitando o endereço de conexão 192.168.233.138, porta 106 e nome de usuário user.Ao conectar, você deve responder afirmativamente para aceitar as chaves e inserir a senha do usuário. Se você precisar executar comandos do superusuário, poderá usar o comando su já conhecido.

Proteção de acesso

Não comecei a proteger o servidor da Web do DDoS, acreditando inicialmente que, se ele estiver hospedado no VPS / VDS, a hospedagem fornecerá uma proteção eficaz e, se você fizer o seu servidor "se destacar" na Internet, esse problema deverá ser tratado com seriedade e este é um tópico artigo separado. A proteção lenta contra DDoS HTTP é relativamente simples, de acordo com inúmeras instruções na Internet, mas não o salva de um ataque distribuído de muitos endereços IP diferentes.

Com o DDoS, nosso servidor simplesmente para de funcionar por um tempo. Mas após um ataque que não durará para sempre, o servidor se recuperará. Mas se alguém conseguir obter acesso via SSH, o controle sobre o servidor será perdido e os dados serão comprometidos; portanto, o controle de acesso ao servidor via SSH é uma boa idéia.

A coisa mais simples e comum que pode ser feita é alterar a porta padrão, o que fizemos ao configurar o SSH. Cerca de cinco anos atrás, eu "enviei" o servidor recém-criado para a Internet em um endereço IP real recebido recentemente e fiquei surpreso que, durante a semana de existência do servidor, sobre a qual ninguém sabia nada ainda, um grande número de logs foi acumulado nos logs do sistema sobre tentativas malsucedidas de autorização via SSH e FTP. Obviamente, na Internet moderna, há um número considerável de serviços robóticos que procuram computadores com portas abertas e tentam se conectar a eles, classificando senhas com base no banco de dados existente ou usando o método exaustivo de pesquisa.

Felizmente para nós, existe o fail2ban:

# apt-get install fail2ban

Imediatamente após a instalação, o utilitário já está configurado para proteger a maioria das portas e se mais de seis tentativas falhas de conexão aparecerem nos logs do sistema em dez minutos, o invasor será bloqueado por dez minutos. O mecanismo de operação do fail2ban é bastante simples - as chamadas prisões que acionam uma ação projetada para proteger o aplicativo são acionadas por certos acionadores.

Os parâmetros de bloqueio podem ser definidos individualmente:

# nano /etc/fail2ban/jail.local

No arquivo criado, é necessário prescrever as configurações que substituirão as existentes por padrão. Um exemplo do conteúdo do meu arquivo:

#
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 2592000
findtime = 43200
maxretry = 6
banaction = iptables-multiport
#
destemail = user@localhost
sendername = Fail2Ban
mta = sendmail
action = %(action_mwl)s

# SSH
[ssh]
enabled = true
port = 106
filter = sshd
logpath = /var/log/auth.log

#
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log

# php
[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache*/*error.log

#
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

#
[apache-nohome]
enabled = true
port = http,https
filter = apache-nohome
logpath = /var/log/apache*/*error.log
maxretry = 2

A configuração acima permite que você não controle o acesso local e, com seis tentativas incorretas de login em 12 horas, o endereço IP do invasor usando o iptables será banido por 30 dias. Ele controla não apenas o acesso à porta para SSH, mas também ações suspeitas destinadas a desestabilizar a operação do servidor da web.

Referência do servidor Web

Iniciando, parando e reiniciando o servidor:

# service apache2 start
# service apache2 stop
# service apache2 restart

Recarregando as configurações do servidor:

# service apache2 reload

Ativando e desativando o host de teste:

# a2ensite test
# a2dissite test

Ativando e desativando a configuração de teste:

# a2enconf test
# a2disconf test

Verificando a sintaxe dos arquivos (retorne: “Syntax OK”):

# apache2ctl configtest

Opção para adicionar um site com acesso HTTP ou HTTPS usando um host virtual existente

Digamos que precisamos adicionar um novo site ao nosso servidor, localizado no diretório site.com, localizado em / home / user / www. Isso pode ser conveniente, pois o usuário não precisará sair dos limites do diretório inicial ao trabalhar com o site.

Definimos as permissões para o diretório do usuário (apenas no caso):

# chmod 755 / home / user

Crie um diretório para o site:

$ mkdir / home / user / www /home/user/www/site.com Colocamos um

link simbólico para o diretório do site:

# ln -s /home/user/www/site.com /var/www/site.com

Para adicionar acesso via HTTP, abra o arquivo:

# nano /etc/apache2/sites-available/000-default.conf

Ou para adicionar acesso via HTTPS abra o arquivo:

# nano /etc/apache2/sites-available/default-ssl.conf

E adicione o seguinte conteúdo ao arquivo aberto antes da tag de fechamento / VirtualHost:

 <Directory /var/www/site.com> Options FollowSymLinks AllowOverride All Require all granted </Directory>

Reiniciamos o servidor da Web:

# service apache2 restart

Verificamos a disponibilidade do site em http: // 127.0.0.1/site.com ou https: // 127.0.0.1/site.com (método de verificação - veja abaixo). Deve-se observar que o site será aberto independentemente da disponibilidade do arquivo .htaccess, uma vez que a diretiva: "Exigir tudo concedido" está definida para o diretório com o site.

Opção para adicionar um site com acesso HTTP ou HTTPS usando um novo host virtual e configurar o acesso através do nome de domínio, não

IP.As condições da tarefa são as mesmas que as anteriores: digamos que precisamos adicionar um novo site ao servidor localizado no diretório do site .com localizado em / home / user / www. Mas agora ainda quero acessar o site digitando apenas seu nome de domínio na linha do navegador.

Definimos as permissões para o diretório do usuário (apenas no caso):

# chmod 755 / home / user

Crie um diretório para o site:

$ mkdir /home/user/www/site.com Colocamos um

link simbólico para o diretório do site:

# ln -s / home / user /www/site.com /var/www/site.com

Para adicionar acesso via HTTP, crie um arquivo:

# nano /etc/apache2/sites-available/site.com.conf

E adicione o seguinte conteúdo:

 <VirtualHost *:80> ServerName site.com ServerAlias www.site.com ServerAdmin user@localhost DocumentRoot /var/www/site.com <Directory /var/www/site.com> Options FollowSymLinks AllowOverride All Require all granted </Directory> # Redirect HTTP->HTTPS #RewriteEngine On #RewriteCond %{HTTPS} off #RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L] ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>

Ou, para adicionar acesso via HTTPS, crie um arquivo:

# nano /etc/apache2/sites-available/site.com-ssl.conf

E adicione o seguinte conteúdo:

 <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerName site.com ServerAlias www.site.com ServerAdmin user@localhost DocumentRoot /var/www/site.com <Directory /var/www/site.com> Options FollowSymLinks AllowOverride All Require all granted </Directory> # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15768000" ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule>

Adicione a linha “127.0.0.1 site.com” a

/ etc / hosts : # echo >> / etc / hosts 127.0.0.1 site.com

Ative o host HTTP:

# a2ensite site.com.conf

Ou ative o host HTTPS:

# site a2ensite. com-ssl.conf

Reiniciamos o servidor da Web:

# service apache2 restart

Verificamos a disponibilidade do site em http: // site.com ou https: // site.com (método de verificação - veja abaixo). Note-se que o site será aberto independentemente da disponibilidade do arquivo .htaccess, pois a diretiva: "Exigir tudo concedido" está definida para o diretório com o site.

Todas as ações são executadas dentro da máquina virtual convidada. Seria interessante "abrir" o site no navegador do sistema host. Não é difícil.Conhecemos o nome de domínio e o endereço IP da máquina convidada. Se o sistema host for Windows, será necessário abrir o arquivo c: \ Windows \ System32 \ drivers \ etc \ hosts e adicionar a seguinte linha no final:

192.168.233.138 site.com

Após essa alteração, o computador ou o sistema host precisará reiniciar. Agora, quando você abrir o site.com em seu navegador, o acesso a ele será redirecionado para nossa máquina virtual. De fato, fizemos o roteamento mais simples em nossa Internet pessoal no nível do sistema operacional do host.

Caso você precise acessar o host virtual somente via HTTPS, mas não desejar perder conexões via HTTP, você pode configurar o redirecionamento:

- crie o arquivo /etc/apache2/sites-available/site.com.conf de acordo com as instruções acima, se não estiver criado
- no arquivo /etc/apache2/sites-available/site.com.conf, remova o comentário das três linhas de RewriteEngine / RewriteCond / RewriteRule
- ative o host site.com.conf se não estiver ativado
- reinicie o servidor: # service apache2 restart

Verificando a integridade do site adicionado

A maneira mais fácil de verificar a disponibilidade do site é colocar o arquivo index.html com algum conteúdo em seu diretório raiz.

Crie um arquivo index.html:

$ nano /home/user/www/site.com/index.html

e adicione o seguinte conteúdo:

 <html> <head> <title>TEST OK</title> </head> <body> <h1>TEST OK</h1> </body> </html>

Dependendo do método de adição do site, abra no navegador o endereço http: // 127.0.0.1/site.com (https: // 127.0.0.1/site.com) ou http: // site.com (https: // site.com ) - uma página contendo o texto "TEST OK" deve ser aberta.

Referência do MySQL

Criando usuário user123 com senha pass123 e banco de dados db123 através do console.

Digite mysql digitando a senha do superusuário mysql quando solicitado:

# mysql -u root -p

E crie um banco de dados (você não precisa digitar o prefixo “mysql>”, o ponto e vírgula é obrigatório no final):

mysql> CREATE DATABASE `db123`;

Crie o usuário user123 com a senha pass123:

mysql> CREATE USER 'user123' @ 'localhost' IDENTIFICADO POR 'pass123';

Conceda privilégios ao usuário no banco de dados:

mysql> GRANT ALL PRIVILEGES ON `db123`. * TO 'user123' @ 'localhost';

Atualizar tabela de privilégios:

mysql> FLUSH PRIVILEGES;

Saia do mysql:

mysql> exit

Para verificar, abra o endereço http: // 127.0.0.1/phpmyadmin e efetue login com os detalhes de acesso do usuário123 / pass123. O acesso ao banco de dados db123 deve ser aberto.

Alterando a senha do mysql raiz com pass123 para pass456:

# mysqladmin -uroot -ppass123 senha pass456

Alterando a senha do usuário123 de pass123 para pass456:

# mysqladmin -uuser123 -ppass123 senha pass456

Removendo user123:

mysql> DROP USER 'user123' @ 'localhost' ;

Excluindo a tabela db123:

mysql> DROP DATABASE `db123`;

Material de referência Fail2ban

Reiniciando o serviço:

# service fail2ban restart

Verificando as regras de execução:

# fail2ban-client status

Estatísticas detalhadas sobre a regra sshd:

# fail2ban-client status ssh

Desconectando:

# fail2ban-client defina ssh unbanip Banned_IP

Retorne ao início, ao índice .

A história da criação de uma nuvem doméstica.Parte 2. Criando um servidor - configurando o LAMP no Debian.
Versão texto: 1.0.1.
Data da primeira publicação: 30/01/2018.
Última edição: 15/01/2020.

Atualizar log

1.0.1 [15-01-2020]
Atualizando o índice.

1.0.0 [30-01-2018]
A primeira versão.
Descreve como instalar e configurar o LAMP no Debian 8.7.x.

A história da criação de uma nuvem doméstica. Parte 2. Criando um servidor - configurando o LAMP no Debian