Para a realização de autenticação de usuários do serviço web fornecido por um Apache em uma base LDAP, a configuração é extremamente simples.

Supondo que voce já tem um servidor LDAP rodando e autenticando seus usuários corretamente (se não tiver, veja meus posts anteriores) e seu servidor web funcionando corretamente, basta editar seu arquivo de configuração do servidor web, normalmente localizado em /etc/httpd/conf/httpd.conf, e ter a certeza de que estas linhas estarão presentes nele.

Novamente temos em nossas mãos a responsabilidade de acertar os relógios dos nossos computadores, além de ser sempre solicitado a acertar o relógio dos micros dos parentes, vizinhos, namoradas, ex-namoradas, amantes, etc.

Este ano o governo brasileiro decidiu facilitar um pouco e definiu datas fixas de início e encerramento do período de Horário de Verão.  Este decreto nº 6.558, de 8 de setembro de 2008, instituiu o início sempre à zero hora do terceiro domingo de outubro e o encerramento sempre à zero hora do terceiro domingo de fevereiro do ano seguinte.

Infelizmente, como em toda decisão governamental, há uma condição que impede a automatização definitiva do Horário de Verão nos computadores: se o terceiro domingo de fevereiro for um domingo de Carnaval então o encerramento é automaticamente transferido para zero hora do domingo seguinte.

Para facilitar um pouco a nossa vida (e a minha também, pois muitos micros e servidores não terão mais que ser ajustados), eu estou colocando um script que define o horário de verão brasileiro até o ano de 2078. Eu montei este script com base nas datas de carnaval definidas nesta Tabela de Páscoa, Carnaval e Corpus Christi, de 1951 a 2078, publicado nesta página na UFRGS.

Neste arquivo tem um script preparado para Linux, que ajudará voce a acertar estes horários nestes sistemas. Salve em um arquivo hv.sh e rode-o como root

É claro que eu sugiro que voces verifiquem o path do utulitário zic (costuma ficar em /usr/sbin/), para que as alterações sejam feitas corretamente.

Depois que o script for executado, basta rodar este comando para verificar as alterações:

# /usr/sbin/zdump -v Brazil/East | egrep “2009|2010″

Para quem não tem muita paciencia em ficar digitando a sua senha cada vez que se loga em uma máquina linux/unix, ou para quem executa scripts que vez ou outra necessitam obter informações de máquinas remotas, existe uma maneira de realizar um acesso seguro, através de SSH, para obter estas informações.

O legal do SSH, é que voce pode realizar um acesso com o comando e obter o resultado facilmente.

Por exemplo, imagine que voce criou um script chamado script.sh e que roda no servidor A e que este script necessita obter alguma informação que está no servidor B. Só que para obter esta informação, é necessário que voce se logue no servidor B, execute um comando, e pegue este resultado para continuar trabalhando.

Isto pode ser feito assim:

[user@serv-a ~]$ ssh -l user@serv-b

user@serv-b’s password:
Last login: Tue Jun  9 12:07:20 2009 from serv-c

[user@serv-b ~]$

[user@serv-b ~]$ ps -ef | grep nscd

nscd     22431     1  0 Apr28 ?        00:00:03 /usr/sbin/nscd

[user@serv-b ~]$ exit

[user@serv-a ~]$

Em resumo, voce loga na maquina remota, informa seu usuario e senha, executa o comando e volta pra sua maquina anterior.

Se isto for feito uma única vez, então não há qualquer problema, mas imagine realizar isto várias vezes ao dia, ou então usar um script para verificar se o NSCD está no ar, e se não estiver, então o processo deve ser re-iniciado.

O grande problema aqui é a autenticação. Não é possível executar comandos de shell usando HTTP (não de maneira simples ou automatizada) ou FTP. Deve-se utilizar o SSH.

Para fazer com que este “problema” de autenticação não atrapalhe o seu script, voce deve usar chaves para realizar a autenticação.

Faça assim:

[user@serv-a ~]$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
6d:9f:70:8a:b1:78:ea:12:85:49:d1:ac:ef:15:74:c7 user@serv-a
[user@serv-a ~]$

Este comando vai gerar um par de chaves pública/privada, com o algoritmo RSA, com tamanho 2048 bits.

Os arquivos estão localizados em /home/user/.ssh

O arquivo id_rsa é a chave privativa e o arquivo id_rsa.pub é a chave pública.

Agora faça um login no servidor b, e copie o conteúdo do arquivo id_rsa.pub para o arquivo /home/user/.ssh/authorized_keys

Salve e saia, deslogue do servidor B e refaça o login no servidor B. Voce verá que a sua senha não será mais pedida.

Aqui vai uma dica. Para executar o seu comando mostrado acima, execute o comando e veja o resultado:

[user@serv-a ~]$ ssh -l user@serv-b “ps -ef | grep nscd”

nscd     22431     1  0 Apr28 ?        00:00:03 /usr/sbin/nscd

[user@serv-a ~]$

O único cuidado que voce precisa ter é que se alguém obtiver uma cópia de seu arquivo id_rsa, esta pessoa poderá usar seu login para acesso a qualquer máquina que tenha a sua chave pública.

É por isso que o arquivo id_rsa tem modo 0600 e o diretório .ssh tem modo 700.

A carreira de engenheiro nos novos moldes:

A Carreira em “Y”
Nas grandes empresas (Bradesco, Votorantim, HSBC, Sony, Brasil Telecom, GM, ou qualquer empresa que tenha um grande número de pessoal de tecnologia) rola o que eles chamam de carreira em Y.  O indivíduo começa como Engenheiro 1 e pode chegar a ser Engenheiro 8.
Engenheiros 1
São comumente conhecidos como Engenheiros baby, ou seja, um pouco mais que estagiários.

Condições necessárias para voce virar Engenheiro 2, 3, 4, 5, 6, 7 e 8:

Engenheiros 2 e 3
Faça o seu dever, cumpra seus prazos, fique algumas vezes depois do  horário, faça cursos de aperfeiçoamento, seja sociável e trabalhe em equipe. É  necessário destruir plantações de pepinos (1 pepino = 1 problema).

Noções de Inglês Técnico.

Exemplo: Humanos normais

Engenheiro 4
Idem ao anterior + matar um leão por dia (1 leão = um grande problema), com  uma carga horária de 12 horas diárias. Ser responsável por 30% da administração de uma rede pequena tipo 700 usuários.

Inglês, espanhol e  Visual Basic obrigatórios + 1 linguagem desejável.

Exemplo: Fodões

Engenheiro 5
Idem ao anterior + um dragão por semana (1 dragão = um problema enorme),  com uma carga horária diária de 16 horas, sem feriados. Ser responsável por 40%  da administração de uma rede do tipo 1.000 usuários.

Inglês, francês, japonês, espanhol, VB e C++ obrigatórios.

Exemplo: Mister M, David Coperfield, Padre Quevedo, Chronos, Thomas Green Morton (Rá!).

Engenheiro 6
Idem aos anteriores, só que, mata-se 1 leão por hora, um dragão por dia, um ALIEN por semana (1 ALIEN = um problema do outro mundo) e mais uma área  equivalente a meio globo terrestre em plantações de pepino. Carga horária  diária de 20 horas. Ser responsável por 75% da administração de uma rede de  2.500 usuários e 30% de todos os projetos internos de tecnologia.

Inglês,  francês, alemão, japonês, espanhol, aramaico, latim, mandarim, vietnamita,  VB, C++, ASP, PHP, DHTML, Cobol obrigatórios.

Exemplo: Criaturas Mitológicas, Gnomos, NINJAS com o poder dos 9 cortes.

Obs. Assim como os NINJAS, somente um Engenheiro 6 pode matar um Engenheiro 6.

Engenheiro 7
Idem aos anteriores, só que, os leões e dragões fogem de você. Você terá  que caçá-los em outras dimensões e planetas. Uma área equivalente a uma estrela  classe 5 (Sol) em plantações de pepino e três ALIENS e um PREDADOR por dia  (1 PREDADOR = um problema impossível de ser resolvido, exemplo, fazer um  corpo com massa “m” viajar com velocidade acima da velocidade da luz).
Carga horária diária de 25 horas. Ser responsável por 100% da administração  de uma rede de 6.000 usuários e 60% de todos os projetos internos de  tecnologia.

Inglês, francês, alemão, japonês, italiano, espanhol, aramaico, latim,  mandarim, vietnamita, Borg, Klingon, pascal, fortran, C#, ASP, JAVA, XML,  EasyTrieve, IMS/DC, Telon e todas as 13500 línguas e dialetos que o C3PO  fala no filme Star Wars, obrigatórios.

Exemplo: Mago Merlin, JEDIs como Luck Skywalker e Obi-Wan Kenobi, Mestre  Yoda (daí o nome de carreira em Y), Darth Maul, SPECTROMAN.

Não desanime.  Conseguir você irá, um engenheiro 7 você será.

Grande poder tem o lado negro ADMINISTRATIVO da FORÇA.

Você também terá que ser um HIGHLANDER, pois só com uma vida eterna você  terá tempo para atingir este cargo, mas não se esqueça que só pode haver  um, e não deixe que nenhum outro engenheiro 7 corte sua cabeça.

Engenheiro 8
É o cargo máximo no UNIVERSO e você será considerado como o mestre dos  elementos. Você terá o poder sobre a vida e a morte dos seres, logo você  não precisa mais matá-los, você apenas deseja que os problemas se resolvam ou  cria novas leis físicas no universo para que isso aconteça. E você irá  perdoar a todos. Você será onisciente, onipresente e onipotente. Carga  horária diária indefinida, para você o tempo e o espaço já não existem. Ser  responsável por 100% dos projetos e 100% da área de tecnologia de uma  empresa de 30.000 usuários, em 7 dias por semana.

Exemplo: GAIA, ZEUS, ODIN, A FORÇA.

A palavra RAID é um acronimo para Redundant Array of Inexpensive Disks que surgiu em 1988 e oferece basicamente:

• Ganho de desempenho no acesso para leitura ou gravação
• Redundancia em caso de falha em um dos discos
• Uso múltiplo de várias unidades de discos
• Escalabilidade em recuperação de conteúdo

Existem hoje duas maneiras de criar um RAID – via Software ou via Hardware

O RAID feito via Software é feito através de softwares e módulos do kernel do Linux e só começa a funcionar após o kernel ser carregado (boot da máquina). Por este motivo não é possível utilizar o RAID via software na partição de boot.

Já o RAID criado via hardware permite incluir todas as partições do disco, inclusive a /boot. Neste caso, toda a configuração de RAID é feito através de uma placa controladora externa, onde se conectam os discos. Esta controladora é a responsável pelas funções de escrita e gravação, informando à máquina o(s) disco(s) disponível(is) para a instalação do(s) Sistema(s) Operacional(is), seja ele Linux, Windows ou outro. O grande problema é que se a controladora falhar, nada mais é acessado. Os discos SCSI e SATA oferecem este tipo de RAID.

Existem diversas configurações de RAID. As mais comuns são 0, 1 e 5.

O RAID 0 é o único nível que não implementa redundancia. A sua finalidade é aumentar o desempenho na leitura e gravação dos dados. Pense assim, se voce fizer RAID 0 com 3 discos de 72 GB, voce terá cerca de 210 GB de espaço total em disco. Se um destes 3 discos apresentar algum problema, voce perde todos os seus 210 GB de dados. Voce também pode usar quantos discos quiser e discos de tamanhos diferentes para criar este único discão.

O RAID 1 trabalha com dois discos, e cria um espelho de um disco no ooutro. Neste caso, se houver um problema em um dos discos, voce tem o outro para garantir os seus dados. Neste modo, a grande vantagem é o tempo de leitura, pois os dados são lidos dos dois discos ao mesmo tempo, duplicando o volume de dados lidos pelos discos. A desvantagem é que, se voce tem dois discos de 140 GB em RAID1, o seu disco total é de 140 GB.

O RAID 5 traz as vantagens do RAID 0 e 1, mas também alguma desvantagem. Em uma configuracao com 3 discos de 72 GB, voce fica com um discão de 140GB. 1/3 do espaço total dos discos é usado para a geração dos dados de redundancia. A vantagem é que este RAID fornece um bom ganho de desempenho na leitura. Quanto mais discos voce tiver neste RAID, mais rápida será a leitura, pois os dados são gravados espalhados.

Para configurar um RAID e administrá-lo, voce precisa da ferramenta mdadm, que é fornecida para todas as distribuições linux que suportam RAID.

Após a instalação da ferramenta, vamos considerar um único disco com 3 partições disponíveis e ainda não montadas ou em uso, e vamos criar 1 x RAID 1 utilizando estas 3 partições, sendo que uma delas será usada como disco spare.

Modifique as partições que serão usadas no RAID para o label “Linux raid auto”, código fd no fdisk.

# fdisk /dev/hda

Para acompanhar o estado de seus discos durante a criação do RAID, use o seguinte comando em um terminal separado

# watch cat /proc/mdstat

Para criar o RAID, utilize este comando

# mdadm –create /dev/md0 –level=1 –raid-devices=2 –spare-devices=1 /dev/hda5 /dev/hda6 /dev/hda7

Onde:

–create /dev/md0 ==> é o device que será criado.

–level=1 ==> indoca que usaremos RAID 1.

–raid-devices=2 ==> indica que teremos 2 partições ativas.

–spare-devices=1 ==> indica que 1 das 3 partições informadas será usada para spare.

As partições mencionadas no final do comando indicam quais serão as partições usadas. A última partição, neste caso, será usada para spare.

Caso o comando fosse este abaixo, então teríamos 2 discos de spare, respectivamente hda7 e hda8

# mdadm –create /dev/md0 –level=1 –raid-devices=4 –spare-devices=2 /dev/hda5 /dev/hda6 /dev/hda7 /dev/hda8

A partir de agora, com o RAID criado, basta criar o filesystem e usar a nova partição. Vou criar usando ext3

# mkfs.ext3 /dev/md0

Crie um ponto de montagem e monte a partição.

# mkdir /mnt/raid
# mount -t ext3 /dev/md0 /mnt/raid

Caso voce queira montar esta partição automoaticamente, altere o arquivo /etc/mdadm/mdadm.conf adicionando as linhas

DEVICE /dev/hda5 /dev/hda6 /dev/hda7 /dev/hda8
ARRAY /dev/md0 devices=/dev/hda5,/dev/hda6,/dev/hda7,/dev/hda8

E altere também o /etc/fstab

/dev/md0 /mnt/raid ext3 defaults 0 2

Para verificar o estado do RAID como um todo, use o comando

# mdadm –detail /dev/md0

/dev/md0:
Version : 00.90.01
Creation Time : Fri Oct 17 18:03:09 2008
Raid Level : raid1
Array Size : 240832 (235.23 MiB 246.61 MB)
Device Size : 240832 (235.23 MiB 246.61 MB)
Raid Devices : 2
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent

2 8 19 – spare /dev/hda7

Este post serve apenas para listas os diversos links que se encontram pela Internet e que sempre ajudam em alguma coisa.

É claro que falta muita coisa aqui, mas eu prometo que sempre tentarei incluir neste post as coisas interessantes que eu acabo sabendo/encontrando/esbarrando quando estou à toa.

Abraços

goetti.blogspot.com – Grupo de operação especial e tática em TI

meuip.com.br – Útil para saber seu ip

http://jodies.de/ipcalc – Calculadora IP

http://aurelio.net/shell/canivete.html – Um bom resumo sobre o shell Bash

http://www.pctools.com/guides/password/ – Gerador randomico de senhas

https://addons.mozilla.org/pt-BR/firefox/addon/433 – Add-on do Firefox 3 que elimina aquelas propagandas em flash que aparecem

Bom, agora que eu já tenho o certificado LPIC-1, eu preciso começar a estudar para obter a certificação LPIC-2.

Como parte deste estudo, eu vou colocar aqui alguns artigos com os pontos que a prova cobre. São eles:

• RAID
• HIDS
• Syslog
• DHCP
• FTP
• NFS
• Samba
• DNS
• Apache
• Postfix
• Squid
• PAM
• OpenLDAP
• OpenVPN

Eu vou apresentar configurações simples e em alguns casos algumas um pouco mais complicadas.

No tópico de OpenLDAP, eu já postei aqui alguns artigos descrevendo os passos para se utilizar este serviço.  Então este tópico não será mencionado.

http://searchsecurity.techtarget.com/magazinePrintFriendly/0,296905,sid14_gci1332745,00.html

Security Experts Bruce Schneier & Marcus Ranum Offer Their Opposing
Points of View

POINT by Bruce Schneier

We engage in risk management all the time, but it only makes sense if we do it right.

“Risk management” is just a fancy term for the cost-benefit tradeoff associated with any security decision. It’s what we do when we react to fear, or try to make ourselves feel secure. It’s the fight-or-flight reflex that evolved in primitive fish and remains in all vertebrates. It’s instinctual, intuitive and fundamental to life, and one of the brain’s primary functions.

Some have hypothesized that humans have a “risk thermostat” that tries to maintain some optimal risk level. It explains why we drive our motorcycles faster when we wear a helmet, or are more likely to take up moking during wartime. It’s our natural risk management in action.

The problem is our brains are intuitively suited to the sorts of risk management decisions endemic to living in small family groups in the East African highlands in 100,000 BC, and not to living in the New York City of 2008. We make systematic risk management mistakes–miscalculating the probability of rare events, reacting more to stories than data, responding to the feeling of security rather than reality, and making decisions based on irrelevant context. And that risk cockpit of ours? It’s not nearly as finely tuned as we might like it to be.

Like a rabbit that responds to an oncoming car with its default predator avoidance behavior–dart left, dart right, dart left, and at the last moment jump–instead of just getting out of the way, our Stone Age intuition doesn’t serve us well in a modern technological society. So when we in the security industry use the term “risk management,” we don’t want you to do it by trusting your gut. We want you to do risk management consciously and intelligently, to analyze the tradeoff and make the best decision.

This means balancing the costs and benefits of any security decision–buying and installing a new technology, implementing a new procedure or forgoing a common precaution. It means allocating a security budget to mitigate different risks by different amounts. It means buying insurance to transfer some risks to others. It’s what businesses do, all the time, about everything. IT security has its own risk management decisions, based on the threats and the technologies.

There’s never just one risk, of course, and bad risk management decisions often carry an underlying tradeoff. Terrorism policy in the U.S. is based more on politics than actual security risk, but the politicians who make these decisions are concerned about the risks of not being re-elected.

Many corporate security decisions are made to mitigate the risk of lawsuits rather than address the risk of any actual security breach. And individuals make risk management decisions that consider not only the risks to the corporation, but the risks to their departments’ budgets, and to their careers.

You can’t completely remove emotion from risk management decisions, but the best way to keep risk management focused on the data is to formalize the methodology. That’s what companies that manage risk for a living–insurance companies, financial trading firms and arbitrageurs–try to do. They try to replace intuition with models, and hunches with mathematics.

The problem in the security world is we often lack the data to do risk management well. Technological risks are complicated and subtle. We don’t know how well our network security will keep the bad guys out, and we don’t know the cost to the company if we don’t keep them out. And the risks change all the time, making the calculations even harder. But this doesn’t mean we shouldn’t try.

You can’t avoid risk management; it’s fundamental to business just as to life. The question is whether you’re going to try to use data or whether you’re going to just react based on emotions, hunches and anecdotes.

COUNTERPOINT by Marcus Ranum

Bruce, you’re taking a very naturalistic–even evolutionary–view of risk management, and it’s hard to disagree with something that has obviously worked for hundreds of thousands of years. The problem with any evolutionary viewpoint, however, is that we tend to sweep under the table the grim slaughter of the failures. The reason we got to where we are today (other than just plain dumb luck) is a pretty strong flight/fight reaction–in that order. As you say, our reflexes don’t work in today’s networks because there’s no place to run–and the bad guys cheat.

It’s fine to say we need to balance the costs and benefits of our decisions, but life has gotten a lot more abstract and our decisions are less visceral. If you let the guys in marketing have their way and open that port in the firewall, you might lose your job, but it’s not as if the barbarians are going to force their way in and put everyone in the cubicle farm to the sword. Whenever someone says something like “a firewall is like a castle wall,” I remind them that the stakes used to be different, and that’s why the number of openings in a castle wall tended to be autocratically and rigidly controlled.

But that’s the problem, isn’t it? The stakes are moving and attitudes are not. It was one thing when a company’s poor decision about a firewall rule affected its stock price; it’s something completely different when you contemplate sovereignty-ending events like losing a war because too many secrets were leaked or a command/control network was compromised. I think a lot of decisions are being made based on wishful thinking rather than a clear-eyed assessment of costs and benefits.

I don’t think we do a very good job of estimating costs, benefits or risk. Simple example: a company hooks SCADA systems to a wide-area network to save money, then spends many times the savings when it has to go back years later and secure it. The fact is, we’re good at estimating risks right in front of us, but tend to leave long-range problems for later, when someone else who cares can deal with them. I’ve sat in on “risk assessment” exercises, and they generally seem to be a process whereby security practitioners try to manipulate senior management’s perception by cooking up a bunch of wild guesses that multiply out to just the pretty number they think it should. You say we shouldn’t “trust our gut,” but that’s exactly what’s going on.

Once, as part of a group building command-and-control networks for war fighters, I made myself amazingly unpopular by pointing out, as a potential consequence of a network breach, that the U.S. might no longer be a world power. Everyone remembers Imperial Rome for having been eventually toppled by the outsourcers it had relied on to secure its northern borders–not for its advances in engineering or indoor plumbing.

Risk assessment numbers are cooked to make them complete-looking, cost-probable and organizationally acceptable to upper management. It’s as if a bunch of medieval castellans based their wall design on the worst-case scenario of being attacked by ducks rather than barbarians.

You’re right: We lack the data to do risk management well. Unlike Las Vegas, which is built on straightforward statistics, computer security is infinitely squishy because the attack vectors change every day, the target surface changes every week, and the value of what’s at stake changes every second. The insurance industry tracks a lot of discrete parameters to formulate its point spreads, but in technology we’re adding new parameters every day, and they’re fiendishly interdependent. We’ll never have the data to do risk management well unless the rate of innovation (also known as “the rate at which security gets worse”) slows down. That brings its risks too.

In short, I don’t think “risk management” is the correct term. We should call it something more accurate. The cargo cultists and voodoo practitioners would probably be insulted if we tried to insinuate we used their methods, so maybe we should just settle on “hand waving.”

Recentemente, o envio para contas de email do Hotmail começou a sofrer fortes filtragens pela Microsoft.

De acordo com este artigo (1), o filtro SmartScreen simplesmente apaga os emails, não informando o destinatário e o remetente que o email foi classificado como Spam ou que o mesmo não foi entregue. E ainda querem cobrar US$ 1.400,00 por ano para “permitir o recebimento”. Nada como gerar um problema e depois cobrar pela solução.

Já o nosso querido Rubens Queiroz (do Dicas-L) tomou uma decisão mais forte – todos os endereços de Hotmail, MSN.com e Live.com, estão sendo filtrados das mensagens da Dicas-L desde o dia 23 de julho de 2008 (2).

Mais um bom motivo para usar o Gmail…

(1) http://www.theregister.co.uk/2007/05/01/hotmail_friendly_fire/
(2) http://www.dicas-l.com.br/10anos/10anos_20080723.php

Para quem já montou o servidor LDAP explicado nos posts anteriores, segue uma parte interessante.

É possível autenticar máquinas Windows (2000, 2003, XP e Servers) na base LDAP. A mágica acontece através do software da Comtarsia (http://signon.comtarsia.com/main/en/Download)

Este software trabalha em duas frentes – autenticação e sessão. Para a autenticação é necessária a instalação do Comtarsia Logon Client. Já para o gerenciamento da sessão, é necessária a instalação do Comtarsia SignOn Gate.

Estes dois softwares estão disponíveis para download no site da Comtarsia, e podem ser testados anytime, anywhere.

O Comtarsia Logon Client troca o MSGina (interface de login padrão do Windows) pelo Gina da Comtarsia. Através dele é possível realizar a autenticação na base LDAP, e eventualmente, quando for necessário, pode-se clicar na opção para usar o MSGina e se autenticar no Windows através de um usuário local ou também através de um usuário no AD.

Sim, eu instalei estes softwares da Comtarsia em uma máquina com autenticação em um AD e neste ponto eu posso escolher onde eu quero autenticar – LDAP ou AD. Eu posso garantr que funciona porque eu uso. Caso voce tenha alguma dúvida, deixe um comentário.