mchk.exe – Configurando emails no plesk via linha de comando

Os scripts de linha de comando do plesk ficam na pasta: %plesk_bin%

mchk.exe

Para resetar todas as configurações de email dos domínios e do servidor

mchk.exe --all --fix-all

Para verificar e restaurar configurações para um domínio específico

mchk.exe --domain --domain-name=dominiodousuario.com

Para verificar e restaurar somente as configurações do servidor

mchk.exe --global-settings

websrvmng.exe – Gerenciando sites e domínios no plesk via linha de comando

Os scripts de linha de comando do plesk ficam na pasta: %plesk_bin%

websrvmng.exe

Para instalar hosting físico para um domínio

websrvmng.exe --install-vhost --vhost-name=<nome_do_dominio>

Para remover hosting físico de um domínio

websrvmng.exe --remove-vhost --vhost-name=<nome_do_dominio>

Para reconfigurar o hosting físico para um domínio

websrvmng.exe --reconfigure-vhost --vhost-name=<nome_do_dominio>

Para reconfigurar um subdomínio

websrvmng.exe --update-subdomain --vhost-name=<nome_do_dominio> --subdomain=<subdominio>

Senhas de usuários de sistema, FTP e IIS user podem ser sincronizados usando:

websrvmng.exe --update-anon-password --domain-name=<nome_do_dominio>

Para reconfigurar webmail

websrvmng.exe --reconfigure-webmail
defpackagemng.exe" --fix --type=webmail

Segurança do asp.net 2.0 e asp.net 3.5 em servidores compartilhados

O .NET v1.1 não vem configurado corretamente para servidores compartilhados, como já vimos em outro artigo. O mesmo vale para o asp.net 2.0 e também o seu framework 3.5.

Por padrão, .NET 2.0 vem instalado com “Full trust”. By default .NET 2.0 is installed with Full trust. Microsoft recomenda utilizar “Medium Trust” para servidores compartilhados.

Após instalar o .Net Framework 2.0 em seu servidor, você precisará modificar algumas configurações, assim como é feito no asp.net v1.1.

Primeiramente, abra o arquivo web.config, localizado em: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG por padrão. (Você pode utilizar o notepad para abrir e editar este arquivo).

Localize o seguinte bloco de texto:

<location allowOverride="true">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low"  policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy>
<trust level="Full" originUrl="" />
</system.web>
</location>

Nós precisaremos alterar a seguinte linha:

<location allowOverride="true">

para:

<location allowOverride="false">

isto certifica que os usuários não poderão alterar estas configurações em seus próprios web.config. Agora, mudaremos também a seguinte linha:

<trust level="Full" originUrl="" />

para

<trust level="Medium" originUrl=".*" />

Então, imediatamente após esta linha, adicione o seguinte:

<identity impersonate="true" userName="" password="" />

isto irá forçar o .NET 2.0 a rodar em “Medium Trust mode”, e ser executado sobre a conta anonima do IIS.
this is now forcing .NET 2.0 to run in Medium trust mode and to execute under the IIS anonomous user. Os principais inconvenientes de setar as configurações para Medium Trust são:

  • OleDbPermission não estará disponível. Significa que você não poderá utilizar ADO.NET e OLE DB data provider para acessar banco de dados. Entretanto, você poderá usar o SQL Server provider para acessar SQL Server databases.
  • EventLogPermission não estará disponível. Quer dizer que você não terá logs do asp.net no windows event.
  • ReflectionPermission não estará disponível. Você não poderá usar “reflection”.
  • RegistryPermission não estará disponível. Você não terá acesso ao registro.
  • WebPermission é restrita. Sua aplicação poderá se comunicar somente com a faixa de endereços que você definiu no elemento.
  • FileIOPermission é restrito. Só será possível acessar arquivos dentro da sua hierarquia da aplicação virtual.

Entretanto, ainda é possível criar um policy personalizado baseado no Medium trust, e permitir aplicações menos restritivas.Nós iremos cobrir alguns exemplos num próximo artigo.

Como desabilitar o botão desligar (shutdown) do windows server

Esta dica é importante para evitar acidentes. Algumas vezes, ao mandar reiniciar um servidor dedicado, você pode clicar no lugar errado e acabar desligado o mesmo.

Desabilite o botão shutdown (desligar). Assim você não correrá mais este risco.

1) Clique Start — > Run (iniciar -> executar)
2) Digite “gpedit.msc” e clique em  “OK”
3) Vá em: Local Computer Policy -> User Configuration -> Administrative Templates -> Start Menu and TaskBar
4) Dê um duplo click em “Remove and prevent access to the shut down command” e então selecione a opção Enable.  Clique em Ok.

Você não terá mais o botão desligar disponível.

Como alterar o limite de upload de arquivos do IIS

Por padrão, o IIS permite upload de apenas 200kb via http por arquivo através das suas páginas. Para aumentar este limite, pare o IIS e edite o arquivo C:\windows\system32\inetsvr e altere metabase.xml.

O valor padrão setado para AspMaxRequestEntityAllowed é de 204800 (200kb). Para permitir upload de arquivos maiores, aumente este valor. Para aumentar para 2 megas, coloque 2048000.

Como configurar as portas de ftp passivo no IIS

Ao configurar um firewall, geralmente é necessário também configurar as portas de ftp passivo no servidor. O IIS não traz esta opção em sua interface, mas é possível determinas as portas através dos seguintes passos:
(suponhamos que você queira liberar as portas entre 5500 a 5700)

Passo 1: Habilite Direct Metabase Edit

1. Abra o IIS Microsoft Management Console (MMC).
2. Clique com o botão direito em Local Computer.
3. Selecione Properties.
4. Marque a opção Enable Direct Metabase Edit.

Passo 2: Configure a faixa de portas através do scrpit ADSUTIL

1. Clique Start -> Run, digite “cmd” e clique OK.
2. Digite

cd \Inetpub\AdminScripts
cscript adsutil.vbs set /MSFTPSVC/PassivePortRange "5500-5700"

4. Reinicie o serviço FTP.

Você verá a seguinte saída após configurar através do script ADSUTIL

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

PassivePortRange : (STRING) “5500-5700”

Segurança do Asp.net em servidores compartilhados

Por padrão, o asp.net 1.1 não está bem configurado para servidores compartilhados. Um usuário que está rodando uma aplicação em .net na configuração padrão terá acesso a partes sensíveis do sistema, o que representa um problema para a segurança.

Abaixo, vou descrever como forçar o ASP.NET 1.1 a executar com a conta anonima do IIS e reduzir assim os privilégios das aplicações em ASP.NET.

Para incrementar a segurança, é recomendado executar sites em asp.net em aplication pools isoladas no IIS. Assim os códigos executados em asp.net poderão afetar apenas o contexto da aplicação (ou das permissões que envolvem o usuário da aplicação.

Para incrementar a segurança, nosso primeiro passo deverá ser forçar as aplicações a serem executadas com o usuário anonimo do IIS. Para fazer isto, vamos editar o arquivo machine.config, localizado na pasta:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG

Abra o arquivo no notepad e procure pela palavra impersonate. Ela estará no padrão abaixo:

<!–
identity Attributes:
impersonate="[true|false]" - Impersonate Windows User
userName="Windows user account to impersonate" | empty string implies impersonate the LOGON user specified by IIS
password="password of above specified account" | empty string
–>
<identity impersonate="false" userName="" password=""/>

troque a linha em negrito acima por todo este bloco de textos abaixo:

</system.web>
<location allowOverride="false">
<system.web>
<identity impersonate="true" userName="" password=""/>
</system.web>
</location>
<system.web>

O que estamos fazendo é setando a propriedade impersonate para true, e além disto colocando uma tag location, que informa que não será possível ao usuário alterar o valor do impersonate (algo que por padrão é possível no arquivo web.config).

Feito isto, os scripts asp.net irão ser executados pelo usuário anonimo marcado no IIS.

Não terminamos. A instalação padrão do asp.net permite executar os arquivos em Full trust mode. Isto quer dizer que qualquer assemblies chamado ou desenvolvido pelo usuário terá acesso irrestrito ao sistema (o que nós não queremos de jeito nenhum).

Procure no topo do arquivo machine.config pelo código abaixo:

<location allowOverride="true">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy> <!– level="[Full|High|Medium|Low|Minimal]" –>
<trust level="Full" originUrl="" />
</system.web>
</location>

Como você pode ver, ASP.NET está marcado por padrão para executar em Full trust mode. Precisamos alterar isto.

Em hosting compartilhados, o ideal é alterar para o medium trust, que permite uma certa flexibidade sem comprometer a segurança do sistema.

<location allowOverride="false">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy> <!– level="[Full|High|Medium|Low|Minimal]" –>
<trust level="Medium" originUrl=".*" />
</system.web>
</location>

Como saber o numero de conexões ao servidor por ip

Esta é uma dica muito simples, porém acredito ser muito útil quando desejamos saber o numero de conexões ativas no servidor e assim killar possíveis abusos.

Digite no prompt de comando :

netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Você verá uma lista como esta:

2 xx.xx.xxx.xxx.1
5 xx.xx.xxx.xxx.2
8 xx.xx.xxx.xxx.3
12 xx.xx.xxx.xxx.4
16 xx.xx.xxx.xxx.6
...

Sendo:
xxx. será o ip cliente e o numero antes do ip é referente ao numero de conexões em seu servidor.

Germano P Ferreira
Administrador Linux

Como desabilitar File System Object (FSO)

O FSO (FileSystem Object) é um componente que permite manipular arquivos e pastas através de scripts (asp, vbs, etc). Ele é um componente windows nativo.

O seu uso é recomendado quando se tem, no servidor, a necessidade de manipulação destes arquivos. Em servidores bem configurados, isto não deve ser nenhum problema, devido a utilização das permissões NTFS corretas.

Porém, caso não tenha necessidade de uso, você pode desabilitá-lo e conseguir, assim, melhorar a permissão de segurança.

O processo para desabilitar o FSO é extremamente simples.

1. Abra o executar (iniciar -> executar).
2. Digite

regsvr32.exe -u scrrun.dll 

Desta maneira, você estará removendo o registro da dll scrrun.dll, responsável pela execução do FSO.

Para registrar novamente, faça:

1. Abra o executar (iniciar -> executar).
2. Digite

regsvr32.exe scrrun.dll

Como criar um alerta por e-mail ao acessar o SSH como root ?

Abaixo vamos criar um alerta que será enviado a sua conta de e-mail toda vez que alguém efetuar login no SSH como root em seu servidor.

Efetue login no SSH de seu servidor como root.

Edite o arquivo .bashrc

pico /root/.bashrc

Após a ultima linha cole o texto abaixo modicando SeuServidor para Nome do Seu Servidor , e voce@seudominio
pelo seu e-mail :

echo 'ALERT - Acesso ao Root (SeuServidor) em:' `date` `who` | mail -s "Alerta: Acesso ao root por `who | cut -d"(" -f2 | cut -d")" -f1`" voce@seudominio

Salve e saia do pico( ctrl+x e y).

Feito. Quando alguém efetuar login em seu ssh como root, você receberá um e-mail informando o nome do servidor, IP de quem efetuou o login, hora e data.

Muito simples e sem duvida bastante util 🙂

Germano Pires Ferreira
Administrador Linux

Como instalar BFD (Brute Force Detection)

BFD é uma ótima excelente solução para detectar e bloquear ataques do tipo “Brutal Force”

**Importante: Certifique-se de ter instalado e configurado o APF Firewall antes de instalar o BFD.

Abaixo vamos abordar a instalação e configuração deste simples porém muito util sistema.

Conecte no SSH de seu servidor como root:

cd /root/
wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
tar -xvzf bfd-current.tar.gz
cd bfd-0.9
./install.sh

Após a instalação, vamos ao arquivo de configuração:

pico /usr/local/bfd/conf.bfd

Localize:

ALERT_USR="0"

mude para:

ALERT_USR="1"

Localize:

EMAIL_USR="root"

mude para:

EMAIL_USR="voce@dominio.com"

Salve e saia do pico (ctrl+x e y)

Para iniciar o bfd:

bfd -s

Germano P Ferreira
Administrador Linux

Como corrigir dns recursivo aberto

Uma vulnerabilidade bastante comum e que abre a possibilidade de alguns tipos de ataques, são as “Open DNS” para consultas externas.

Possíveis Riscos com “DNS Recursivo Aberto”:

• Ser vítima de ataques de envenenamento de cache (cache poisoning), que levam o servidor recursivo a armazenar informações forjadas. Tais informações podem ser usadas para comprometer a segurança de clientes que façam consultas a esse servidor.
• Ter esse servidor abusado por atacantes e utilizado para desferir ataques de negação de serviço distribuídos (DDoS), que podem implicar nas seguintes conseqüências:

– o grande número de consultas DNS forjadas recebidas e, principalmente, a quantidade de respostas grandes enviadas para a vítima, podem consumir uma quantidade considerável de banda da rede com um servidor DNS recursivo aberto;
– dependendo do contrato do provedor de conectividade, a rede com o DNS aberto sendo abusado pode ser co-responsabilizada em caso de ataque de negação de serviço contra terceiros.

Para verificar se este é o seu caso, vá em

http://www.intodns.com e digite um domínio no servidor que deseja verificar.

Se estiverem abertas, você irá ver um alerta em vermelho “Open DNS”

Para corrigir este problema siga os passos abaixo:

Efetue login como root em seu servidor pleo SSH e edite o named:

pico /etc/named.conf

Procure por:

key "rndckey" {

};

Após este código acima de options { insira:

acl "trusted" {
xxx.xxx.xxx;
xxx.xxx.xxx;
xxx.xxx.xxx;
127.0.0.1
};

onde xxx são os números de seus servidores de DNS, geralmente definidos no arquivo /etc/nameserverips

Dentro de “options {”
abaixo de:

// query-source address * port 53;

coloque o seguinte:

version "Servidor DNS Seguro";
allow-recursion { trusted; };
allow-notify { trusted; };
allow-transfer { trusted; };

Salve e feche o editor ( ctrl+x e y)

Agora, reinicie seu servidor DNS

service named restart

Se você utiliza um firewall deixe aberta a porta 53 tanto para udp quanto para tcp.

Germano P. Ferreira
Administrador Linux

Alterando o limite de memória no MSDE

O limite de consumo de memória do servidor de banco de dados MSDE, por padrão, é 2147483647Mb. Isto mesmo, pouco mais de 2 terabytes de memória.

Como nossos servidores não tem tanta memória disponível, vamos limitar o uso de memória no banco de dados. Para isto, crie um arquivo chamado limitmemory.sql, com o seguinte conteúdo:

USE master
EXEC sp_configure ’show advanced options’, 1
RECONFIGURE WITH OVERRIDE

USE master
EXEC sp_configure ‘max server memory (MB)’, 512
RECONFIGURE WITH OVERRIDE

USE master
EXEC sp_configure ’show advanced options’, 0
RECONFIGURE WITH OVERRIDE

Em seguida, utilize o seguinte comando para executar este script sql (lembre de mudar o caminho para o arquivo sql):

osql -E -S servername\MSFW -i c:\sqlmemorylimit.sql

Se você quiser apenas verificar o valor que está setado para limite de memória no MSDE, use o seguinte script:

USE master
EXEC sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE

USE master
EXEC sp_configure 'max server memory (MB)'

USE master
EXEC sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE

Salve-o como sqlmemorycheck.sql, e execute o seguinte comando:

osql -E -S servername\MSFW -i c:\sqlmemorycheck.sql