Olá a todos!
No meu último artigo,
escrevi sobre virtualização de servidores, e neste artigo vou
apresentar uma solução que vem se consolidando no mercado, apesar de ser
estudada já há algum tempo. É uma solução relativamente nova: o SDN (Software Defined Networking).
As atuais tecnologias de rede não dão conta de todas as exigências
dos usuários e das empresas devido à sua complexidade e à quantidade de
protocolos utilizados; geralmente são desenvolvidas e definidas de forma
isolada e, para dificultar ainda mais, alguns fabricantes desenvolvem
“protocolos proprietários”.
Dessa forma, quando é preciso escalar a rede e adicionar mais
dispositivos, essa tarefa se torna cada vez mais complexa, pois
praticamente não existe interoperabilidade entre alguns fabricantes e,
quando isso se faz necessário, novos aplicativos e protocolos são
desenvolvidos, o que às vezes pode ser um processo lento, o que
inviabiliza a implantação de novas tecnologias em uma planta de redes já
existente.
Além desse detalhe, os pesquisadores na área de redes de computadores
têm problemas em testar novas ideias, uma vez que os switches/routers
encontrados hoje no mercado são criados com protocolos fechados e com
software pertencente às empresas. Em consequência disso, novas ideias
surgem para melhorar o desempenho das redes existentes, porém essas
pesquisas permanecem em ambientes de laboratório, não sendo possível
testar essas ideias em diferentes escalas para avaliar se a solução tem
ou não o funcionamento esperado. E, como sabemos, hoje é praticamente
impossível testar soluções em redes de produção, ainda mais em grandes
empresas.
Com esse problema em mente, a arquitetura Software Defined Networking
(SDN) surgiu para superar os problemas de switches e routers fechados e
de softwares proprietários, a fim de não comprometer os serviços de
redes em produção, e para facilitar a inovação. O SDN permite uma
separação útil entre os planos de controle e de dados: essa separação
torna possível haver switches e routers encaminhando dados de acordo com
novas regras que se encontram num servidor. O resultado é que o plano
de controle da rede fica à disposição dos pesquisadores, que agora podem
aplicar as suas novas ideias sem violar as regras existentes de
roteamento e sem causar problemas de funcionamento das redes em
produção.

A grande sacada da arquitetura SND é possibilitar a rápida
configuração da rede conforme a demanda de serviços e os negócios das
empresas, além de permitir a criação de features e protocolos, independentemente dos fabricantes.
Os principais fabricantes de equipamento de redes estão correndo para
a oferta de produtos compatíveis com o modelo, como a compra da Nicira
pela VMware, o lançamento de switches com software aberto, como os da
Arista Networks, entre outros.
Outra dificuldade encontrada hoje é que um grande parque de
equipamentos de diferentes fabricantes sempre exige mão de obra
altamente especializada, o que nem sempre é possível. No caso de uma
rede definida por software, um administrador de rede pode moldar o
tráfego a partir de um controle centralizado sem precisar mexer em
equipamentos de diversos fabricantes. O administrador pode alterar as
regras de qualquer switch de rede, quando necessário, priorizando ou
mesmo bloqueando determinados tipos de pacotes com um nível muito alto
de controle. Isso é especialmente útil em redes grandes e cloud computing, pois permite que o administrador gerencie as cargas de tráfego de uma forma flexível e mais eficiente.
SDN é por vezes referido como o “assassino Cisco”, porque permite que
os engenheiros de rede suportem redes de múltiplos fabricantes.
Atualmente, a especificação mais popular para a criação de uma rede
definida por padrão é chamada de OpenFlow .
Hoje, os clientes já estão “vendidos” para Infraestruturas de
Serviços (IaaS),(PaaS) e (SaaS), que possuem diversos sistemas e
softwares proprietários vindos de vários fabricantes, mas o que dizer de
se utilizar a rede como um serviço? Apesar do fato de a nuvem estar
ligada através da rede, ouve-se pouco ou nada sobre um novo paradigma
para a nuvem. Rede como um serviço não só é real, mas é provável que se
torne universal. No entanto, pode ser necessário utilizar um software de
rede definida (SDN) sob a forma de OpenFlow para que isso aconteça.
Cloud computing implanta uma infinidade de recursos que
podem ser provisionados sob demanda. A nuvem também envolve conexões aos
seus usuários, acesso a armazenamento, comunicações unificadas e
alocação de recursos ou de gestão. As tecnologias de rede Ethernet têm
deficiências quando se trata de serviços em nuvem por causa de
segurança, QoS, escalabilidade e custos operacionais.
Como praticamente todos os devices de rede e servidores
funcionam sob IP, a presunção de conectividade universal torna mais
difícil de gerenciar e ter segurança no tráfego. Uma solução proposta é
centralizar uma política de conexão usando SDN. Em SDNs, os terminais
não têm como se conectar, então nada na rede está ligado em primeiro
lugar. Em vez disso, um controle de software decide que conexões serão
permitidas, quais as premissas de segurança, engenharia de tráfego e
somente então será acessada por quem tem permissão de se conectar.
Essa gestão de recursos de rede centralizada é virtualmente idêntica
ao recurso de gestão por trás das IaaS, PaaS e SaaS em nuvem. Portanto,
não será uma surpresa a arquitetura SDN servir de base para a rede como
um serviço. Muitos dos principais fabricantes de switches e roteadores
manifestaram apoio ao OpenFlow, que é a arquitetura por trás da implementação da SDN.
OpenFlow é uma combinação de software de especificação e de código aberto que funciona nos devices de rede, com controle unificado. Em uma rede OpenFlow, quando um switch ou roteador recebe um pacote, em vez de tomar a decisão sozinho, o device
envia o pacote para o controlador, que, em seguida, utiliza critérios
para tomar a decisão. Essas políticas, então, criam uma regra de
encaminhamento, que o controlador passa de volta para o dispositivo
solicitante.
Um dos maiores desafios é que uma rede OpenFlow não pode
funcionar se cada pacote precisar ser enviado para um controlador
central a fim de ser analisado. Para fazer um trabalho de rede com
escalabilidade, o OpenFlow deve ser melhorado ou o seu uso deve ser contido dentro de rede em nuvem. Ambas as opções já estão sendo propostas. OpenFlow
vai funcionar melhor quando o tráfego for composto de um número modesto
de fluxos previsíveis. Dessa forma, uma vez que os switches e
roteadores tiverem aprendido as regras de trânsito a partir do
controlador, a interação adicional com o controlador será reduzida.
Quando usado em um datacenter para o controle de servidor para servidor ou servidor para storage, o OpenFlow serve de contribuição muito importante. Mesmo dentro de datacenters em uma nuvem (pública, privada ou híbrida) distribuída, o OpenFlow poderia ser utilizado para gerenciar o tráfego.
Felizmente, várias pesquisas estão sendo feitas para interagir OpenFlow
com MPLS e gerar um novo tipo de rede IP que oferecerá uma combinação
de conectividade aberta e políticas de gestão de conectividade. Existem
também as formas potenciais de fazer o controle OpenFlow de forma mais hierárquica e escalável. Além disso, há iniciativas em cloud computing,
em que o conceito de rede como um serviço surgiu, para gerir a forma de
lidar com aplicações em nuvem. Essas iniciativas convertem aplicativos
em “serviços virtuais” na nuvem. É muito cedo para dizer se eles irão
criar um OpenFlow escalável, mas, se o fizerem, haverá um
avanço em modelos de rede como um serviço, melhorando a forma de como os
recursos são acessados.
Essas novidades podem não ser disponíveis para todos agora, porém
todos os indícios apontam que essa inovação ocorrerá em um futuro breve.
Até a próxima!
|
Baseado no artigo: http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations
Na primeira parte deste artigo criamos a Web API com o suporte as operações CRUD e agora vamos criar a interface na aplicação MVC usando Javascript e jQuery para usar o serviço criado.
Portanto, abra o projeto ProdutosRepositorio criado no artigo
anterior no Visual Web Developer 2010 Express Editionu Visual Studio
2010.
Usando Web API com JavaScript e jQuery
Na janela Solution Explorer, expanda a pasta
Views a seguir expanda a pastaHomeVocê deverá ver um arquivo chamado
Index.vbhtml. Clique duas vezes nesse arquivo para abri-lo no editor
conforme abaixo:

O arquivo Index.vbhtml processa o HTML utilizando o mecanismo de
exibição Razor. No entanto, não vamos usar todos os recursos Razor,
quero mostrar apenas como um cliente pode acessar o serviço usando HTML
simples e Javascript. Portanto, remova o código do arquivo
substituindo-o pelo código abaixo:
@section scripts
{
<style type="text/css">
table
{
border: 1px solid #000;
border-collapse: collapse;
color: #666666;
min-width: 200px;
}
tr
{
border: 1px solid #000;
line-height: 25px;
}
th
{
background-color: #B1C3CC;
color: #000;
font-size: 13px;
text-align: left;
}
th, td
{
padding-left: 5px;
}
</style>
<script src="@Url.Content("~/Scripts/jquery-1.6.2.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/knockout-2.0.0.debug.js")" type="text/javascript"></script>
<script type="text/javascript">
function limpaStatus() {
$('#status').html('');
}
var detailModel = function () {
this.Nome = ko.observable();
this.Categoria = ko.observable();
this.Preco = ko.observable();
}
var API_URL = "api/produtos/";
var viewModel = new detailModel();
function add() {
limpaStatus();
var produto = ko.toJS(viewModel);
var json = JSON.stringify(produto);
$.ajax({
url: API_URL,
cache: false,
type: 'POST',
contentType: 'application/json; charset=utf-8',
data: json,
statusCode: {
201 /*Created*/: function (data) {
self.produtos.push(data);
}
}
});
}
function find() {
limpaStatus();
var id = $('#produtoId').val();
$.getJSON(API_URL + id,
function (data) {
viewModel.Nome(data.Nome);
viewModel.Categoria(data.Categoria);
viewModel.Preco(data.Preco);
})
.fail(
function (xhr, textStatus, err) {
$('#status').html('Erro : ' + err);
});
}
function update() {
limpaStatus();
var id = $('#produtoId').val();
var produto = ko.toJS(viewModel);
var json = JSON.stringify(produto);
$.ajax({
url: API_URL + id,
cache: false,
type: 'PUT',
contentType: 'application/json; charset=utf-8',
data: json,
success: function () { $.getJSON(API_URL, self.produtos.update); }
})
.fail(
function (xhr, textStatus, err) {
$('#status').html('Erro : ' + err);
});
}
function deleta() {
limpaStatus();
var id = $('#produtoId').val();
var produto = ko.toJS(viewModel);
var json = JSON.stringify(produto);
$.ajax({
url: API_URL + id,
cache: false,
type: 'DELETE',
contentType: 'application/json; charset=utf-8',
data: json,
success: function () { $.getJSON(API_URL, self.produtos.remove); }
})
.fail(
function (xhr, textStatus, err) {
$('#status').html('Erro : ' + err);
});
}
$(document).ready(function () {
self.produtos = ko.observableArray();
self.produtos.update = function (data) {
var c = self.produtos;
c.removeAll();
c.push.apply(c, data);
// Sort by ID
c.sort(
function (left, right) { return left.Id - right.Id }
);
};
ko.applyBindings(self.produtos, document.getElementById('produtos'));
ko.applyBindings(viewModel, document.getElementById('detail'));
$.getJSON(API_URL, self.produtos.update);
});
</script>
end section
<div id="body">
<section>
<h3>Produtos</h3>
<table id="produtos">
<thead>
<tr><th>ID</th><th>Nome</th><th>Categoria</th><th>Preço</th></tr>
</thead>
<tbody data-bind="foreach: produtos">
<tr>
<td data-bind="text: Id"></td>
<td data-bind="text: Nome"></td>
<td data-bind="text: Categoria"></td>
<td data-bind="text: Preco"></td>
</tr>
</tbody>
</table>
</section>
<section id="detail">
<h3>Ver Produto</h3>
<div>
<label for="produtoId">ID</label>
<input type="text" title="ID" id="produtoId" size="5"/>
<input type="button" value="Procurar" onclick="find();" />
</div>
<div>
<label for="nome">Nome</label>
<input data-bind="value: Nome" type="text" title="Nome" id="nome" />
</div>
<div>
<label for="categoria">Categoria</label>
<input data-bind="value: Categoria" type="text" title="Categoria" id="categoria" />
</div>
<div>
<label for="preco">Preco</label>
<input data-bind="value: Preco" type="text" title="Preco" id="preco" />
</div>
<div>
<input type="button" value="Atualizar" onclick="update();" />
<input type="button" value="Incluir" onclick="add();" />
<input type="button" value="Deletar" onclick="deleta();" />
</div>
<div>
<p id="status"></p>
</div>
</section>
</div>
No código do arquivo index.vbhtml temos as seguintes definições:
- Estilo aplicado a página;
- Funcões jQuery : limpaStatus() , add(), find(), update(), deleta();
- Código HTML da página.
Executando o projeto iremos obter:

|
Nos últimos anos venho me envolvendo em discussões de estratégias
tecnológicas com empresas de software, conhecidas pela sigla ISV
(Independent Software Vendor). O Brasil já tem uma indústria de
software e tecnologia da informação bem consolidada, com aproximadamente
73 mil empresas que faturaram US$ 37 bilhões no ano de 2011. É,
portanto, uma indústria significativa em termos do PIB brasileiro. O
governo já reconhece esta importância e vem criando incentivos como o
projeto TI Maior. Entretanto, é um mercado altamente competitivo e
intensamente afetado pelas rápidas inovações tecnológicas. Este tem
sido o ponto focal das conversas com os empresários do setor de
software: onde investir em termos de tecnologia?
É indiscutível que, para os ISVs, as tecnologias que envolvem cloud
computing, mobilidade e business analytics/Big Data são prioritárias e
têm um efeito significativo, podendo inclusive ser transformadores de
modelos de negócios já estabelecidos. Aliás, estas tecnologias não devem
ser vistas de forma isolada, mas fazendo parte de um contexto único,
que realmente faça nexo.
Mas, para facilitar nossa conversa, vamos analisar cada uma destas
três tendências. Neste primeiro artigo vou abordar cloud computing e nos
dois seguintes analisaremos mobilidade e business analytics.
Cloud computing já é uma realidade. Uma pesquisa feita nos EUA
mostrou que 83% das empresas de software criadas naquele país nos
últimos dois anos entraram no mercado diretamente via modelo SaaS. As
pesquisas apontam que até 2015, 24% das compras de software – aí olhando
o mundo todo – serão por este modelo. Em termos financeiros, isto
significa que em 2015, provavelmente um em cada cinco dólares gasto na
aquisição de softwares comerciais serão via SaaS. Este é um mercado que
cresce cinco vezes mais rápido que o modelo tradicional, on-premise, de
licenças para uso nos servidores da própria empresa. Nos próximos anos
veremos mais intensamente um declínio das vendas pelo modelo on-premise e
um contínuo e acelerado crescimento do SaaS. Indiscutível, portanto,
que SaaS deve estar no planejamento estratégico de todos os ISVs
existentes. E uma start-up já deve nascer como SaaS.
Mas entrar no modelo de cloud apresenta desafios. O ISV vai construir
seu próprio data center ou usar um provedor externo? Ter seu próprio
data center implica em um investimento significativo em instalações
fisicas e hadware que ofereça um nível de confiabilidade,
disponibilidade e desempenho de alto padrão. Provavelmente, serão poucos
os ISVs brasileiros que terão condições técnicas e financeiras para
bancar este investimento. Geralmente, recomendo que pequenas e médias
empresas de software adotem nuvens de provedores de alta qualidade,
como a Smart Cloud Enterprise, da IBM. Por outro lado, para
implementarem adequadamente o modelo SaaS, os ISV terão que, ao longo do
tempo, redesenharem suas aplicações para explorarem este modelo,
tornando-as multi-tenants, quebrando projetos complexos em componentes
menores que possam ser mais facilmente desenvolvidos e implementados. O
desenvolvimento via processos ágeis se torna fundamental neste
contexto. O modelo SaaS adota evoluções contínuas e incrementais, ao
contrario do atual, que espera longo tempo por atualizações em blocos,
que obriga aos usuários fazerem custosos upgrades de versões. Por outro
lado, um software operado via SaaS permite que o ISV monitore
diretamente o seu uso pelos usuários, permitindo implementar melhorias a
partir deste monitoramento e não baseado apenas em suas intuições ou
mesmo sugestões de alguns poucos clientes.
Outro aspecto interessante é que os produtos SaaS do ISV
provavelmente deverão ser arquitetados como uma plataforma com APIs que
permita aos usuarios expandirem funcionalidades. Por mais que o ISV
adicione funcionalidade, sempre haverá necessidades especificas, que
poderão ser desenvolvidas pelos próprios clientes. Um exemplo são os
ERP, que por mais completo que sejam, não atendem a mais que 40% das
aplicações de uma média empresa e provavelmente a menos de 30% dos dados
que ela precisa para criar vantagens competitivas no mercado. A
mobilidade é um exemplo bem prático. A maior parte das inovações que
virão das apps serão desenvolvidas pelos próprios clientes ou parceiros
de negócio, e não pelo ISV. Por que não facilitar as coisas criando APIs
para incentivar esta inovação?
O mundo da computação em nuvem também abre novas oportunidades de
geração de demanda, permitindo criar técnicas inovadoras de
go-to-market. Um exemplo: test-drives gratuitos. Na minha opinião, a
experiência prática sentida pelo usuário das funcionalidades da
aplicação é muito mais eficiente e convincente que uma apresentação em
powerpoint. Outra mudança signficativa: o ISV passa a ser muito mais uma
empresa de serviços, com sua equipe de vendas interagindo com o cliente
não apenas antes da venda, mas também (e principalmente) depois. No
modelo atual, uma vez instalado o software, eventuais problemas de
desempenho são do cliente. No SaaS é um problema do ISV. Este é um
desafio e tanto, pois mudar uma cultura de venda de produtos para venda
de serviços não é apenas questão de querer, mas implica em repensar
pessoas e processos. É sair da cultura da venda mais focada no
transacional para uma de gerar e manter relacionamentos sustentáveis a
longo prazo.
Entra outra transformação. O modelo SaaS muda o fluxo de caixa do ISV
e os próprios modelos de remuneração dos vendedores. No modelo atual, o
cliente paga um alto valor pela licença de uso e taxas anuais de
manutenção. No SaaS, a receita é gerada no decorrer da manutenção do
contrato, basicamente pelo critério pay-as-you-go ou pagamento pelo uso.
Tem uma clara vantagem: o ciclo de vendas tende a ser menor, pois as
barreiras de entrada para o cliente, os custos de investimento up-front
deixam de existir. Também implica em uma cultura diferente. O processo
de billing passa a ter um papel importante, ao contrário do modelo
anterior, cuja preocupcão era basicamente enviar a fatura da venda da
licença. Como analogia, imaginem um ISV atuando como uma operadora de
telefonia móvel, preocupado em oferecer continuamente serviços de
qualidade, billing corretos e evitando o chamado churn rate.
A mudança para SaaS também implica em uma análise dos atuais
contratos. Quando propor que o cliente mude de on-premise para SaaS?
Aguardar que ele se manifeste ou ser pró-ativo? E em caso de mudança,
não esquecer que os contratos serão bem diferentes dos atuais…
Em muitas das conversas com ISVs, identificamos outros benefícios na
adoção do modelo SaaS, como entrada em novos mercados, antes dificultado
pela necessidade de investimentos up-front e a possível diminuição da
diferença entre grandes e pequenos ISVs – uma vez que um aplicativo de
qualidade oferecido por um pequeno ISV em uma nuvem de alta
confiabilidade, como a da IBM, pode ser tão eficiente quanto a de um ISV
de maior porte. Além disso, a dispensa do suporte on-site para
instalação diminui os custos operacionais dos ISVs, permitindo que eles
se concentrem em ajudar os seus clientes a explorar melhor o seu
aplicativo em termos de negócios. Menos tecnologia e mais negócios.
No próximo post vamos abordar o efeito da mobilidade nos negócios dos ISVs. *** Artigo de Cezar Taurion
|
Se o seu aplicativo .NET executar um sprint, será que ele
ganharia a corrida? Para determinar se o aplicativo encontra os seus
objetivos de desempenho (e vence a corrida) e para ajudar a identificar
os gargalos, é preciso medir o desempenho do aplicativo e coletar as
métricas. As métricas de interesse particular tendem a ser o tempo de
resposta, o rendimento, e a utilização de recursos o seu aplicativo
consome durante a execução de suas tarefas.
Vamos começar dando uma olhada nas ferramentas e técnicas que estão
disponíveis para coletar dados de desempenho para o seu aplicativo .NET.
Técnicas e ferramentas
Você pode precisar fazer a coleta de dados durante a prototipagem, o
desenvolvimento de aplicativos, os testes de desempenho e ajustes em um
ambiente de produção. As seguintes ferramentas e técnicas podem ajudá-lo
a fazer essa coleta:
- Métricas do sistema e da plataforma;
- Ferramentas de monitoramento de rede;
- Ferramentas de criação de perfil;
- Ferramentas para analisar arquivos de log;
- Aplicativos de instrumentação.
Não iremos nos aprofundar nos detalhes dessas ferramentas, já que
elas vão além do âmbito deste artigo e a maioria delas são ferramentas
padrão que vêm com ferramentas de desenvolvimento, como o Visual Studio.
Instrumentação de aplicativos
Além do perfil e dos instrumentos de monitoramento, você pode
instrumentar o seu código para capturar informações específicas do
aplicativo. Este tipo de informação é muito mais refinada do que a
fornecida pelos contadores do sistema de desempenho padrão. É também uma
ótima maneira de capturar as métricas em torno de cenários de
aplicativos específicos.
Por exemplo, a instrumentação permite medir quanto tempo leva para
adicionar um item ao carrinho de compras, ou quanto tempo leva para
validar um número de cartão de crédito. Existem várias formas para você
instrumentar seu código. Elas estão resumidas na seção seguinte, e cada
abordagem vai ser expandida nas seções seguintes.
Instrumentação
Instrumentação é o processo de adicionar o código ao seu aplicativo
para gerar eventos para que você possa monitorar a integridade e o
desempenho do aplicativo. Os eventos são geralmente registrados a uma
fonte de evento apropriada, que pode ser monitorada por ferramentas de
monitoramento adequadas, tais como o MOM. Um evento é uma notificação de
alguma ação.
Instrumentação permite executar várias tarefas:
- Aplicativos de perfil. A criação de perfis permite
identificar quanto tempo um determinado método ou uma determinada
operação leva para ser executada e quão eficiente ela é em termos de CPU
e uso de recursos de memória;
- Coletar dados personalizados. Isto pode incluir os
contadores de desempenho personalizados que você usa para controlar a
atividade específica do aplicativo específico de atividade;
- Rastreamento de código. Isso permite que você
entenda o caminho do código do aplicativo e todos os métodos são
executados por um caso de uso particular.
Você pode usar várias ferramentas e tecnologias para te ajudar a
instrumentar o seu aplicativo. A escolha certa depende de sua plataforma
de desenvolvimento, a frequência de registro, o volume de dados que
estão sendo registrados e como você pretende fazer o monitoramento. Você
possui várias opções:
- Rastreamento de Eventos para Windows (ETW);
- Instrumentação de gerenciamento do Windows (WMI);
- Contadores de desempenho personalizados;
- Instrumentação de Empresa Framework (EIF);
- Classes Trace e Debug.
As diversas opções disponíveis para o registro são adequadas para
diferentes cenários. As perguntas a seguir ajudam a fazer uma escolha
consciente:
O que você quer realizar com a instrumentação?
Existem vários objetivos para instrumentação. Por exemplo, se você só
precisa de recursos de depuração e rastreamento, você pode usar esses
recursos principalmente em um ambiente de teste onde o desempenho não é
um problema. Mas se você pretende registrar as ações empresariais
realizadas por cada usuário, isso é muito importante do ponto de vista
do desempenho e precisa ser considerado no momento da criação.
Caso precise rastrear e registrar a atividade, é necessário optar por
uma ferramenta que permita que você especifique vários níveis de
instrumentação por meio de um arquivo de configuração.
Com que frequência você precisa registrar eventos?
A frequência de registro é um dos fatores mais importantes e que vão
te ajudar a decidir pela ferramenta certa de instrumentação para você.
Por exemplo, o registro de eventos é adequado apenas para eventos com
frequências muito baixas, enquanto um arquivo de log personalizado ou
ETW é mais adequado para registro de alta frequência. Os contadores de
desempenho personalizados são melhores para tendências a longo prazo,
tais como testes de estresse de uma semana.
A sua instrumentação é configurável?
Em um cenário da vida real de um aplicativo, você pode querer
instrumentá-lo, de modo que os dados coletados sejam úteis em diversas
etapas do aplicativo, como o desenvolvimento (depuração/rastreamento),
teste de sistema, ajuste e planejamento de capacidade.
Todos os códigos stub para geração dos dados precisam ser inseridos
no aplicativo durante a fase de desenvolvimento do ciclo de vida. Os
códigos stub usados para a geração de uma quantidade tão grande de dados
podem, eles mesmos, adicionar a sobrecarga de desempenho. No entanto,
na maioria dos cenários, é em um pequeno subconjunto de dados que você
está interessado durante uma fase específica do ciclo de vida. Você
precisa de uma instrumentação configurável, de modo que o conjunto
relevante possa ser ligado à vontade para minimizar a sobrecarga de
desempenho.
Com base nas considerações anteriores, os cenários de utilização para as diversas opções são os seguintes.
- Rastreamento de Eventos para Windows (ETW) – O ETW é
adequado para o registro de alta frequência de eventos como erros,
avisos ou auditorias. A frequência de corte pode ser de centenas de
milhares de eventos por segundo em um aplicativo em execução. Isto é
ideal para os aplicativos de servidor que registram as ações
empresariais realizadas pelos usuários. A quantidade de registros feitos
pode ser elevada, dependendo do número de usuários simultâneos
conectados ao servidor;
- Windows Management Instrumentation (WMI) – O
Windows Management Instrumentation é a tecnologia de núcleo de gestão
embutido no sistema operacional do Windows. O WMI suporta uma ampla gama
de ferramentas de gestão que permite analisar os dados coletados para o
seu aplicativo. Conectar um coletor ao WMI é mais dispendioso do que os
outros coletores, então você geralmente deve fazê-lo apenas para
eventos críticos e de alta visibilidade, como uma falha de driver do
sistema;
- Contadores de desempenho personalizados – Você pode
usar contadores personalizados para cronometrar os principais cenários
de tempo dentro do seu aplicativo. Por exemplo, você pode usar um
contador personalizado para cronometrar quanto tempo o aplicatvo leva
para colocar as coisas em uma ordem ou quanto tempo leva para recuperar
os registros de clientes;
- Instrumentação de Empresa Framework (EIF) – O FEI
permite que aplicativos .NET estejam instrumentados para publicar um
amplo espectro de informações, como erros, avisos, auditorias,
diagnósticos, eventos e eventos de negócios específicos. Você pode
configurar quais eventos você gera e para onde eles vão – para o serviço
de Log de Eventos do Windows ou SQL Server, por exemplo. O FEI
encapsula a funcionalidade do ETW, o serviço de registro de eventos e
WMI. O FEI é adequado para aplicativos de grandes empresas, onde você
precisa de vários níveis de log em seu aplicativo entre as camadas. O
FEI também oferece um arquivo de configuração onde você pode ligar ou
desligar o interruptor para o registro de um contador em particular. O
FEI possui também uma característica importante do pedido de
rastreamento que permite rastrear os processos de negócios ou serviços
de aplicativos, seguindo um caminho de execução de um aplicativo que
mede múltiplas camadas físicas.
- Classes Trace e Debug – As classes Trace e Debug
permitem adicionar funcionalidade em seu aplicativo, principalmente para
fins de depuração e rastreamento. O código adicionado, usando a classe
Debug, é relevante para compilações de depuração do aplicativo. Você
pode imprimir as informações de depuração e verificar a lógica das
afirmações para várias expressões regulares em seu código. Você pode
escrever as informações de depuração, registrando um ouvinte específico,
como mostrado no exemplo de código a seguir.
public static void Main(string[] args){
Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.AutoFlush = true;
Debug.WriteLine(“Entering Main”);
Debug.WriteLine(“Exiting Main”);
}
Os códigos stub adicionados usando a classe Trace são habilitados
tanto para a depuração, quanto para as compilações do aplicativo. Essa
classe pode ser usada para isolar os problemas, permitindo o
rastreamento através do caminho de código de execução.
No Visual Studio. NET, o rastreamento é ativado por padrão. Ao
utilizar a linha de comando para construir o código fonte C#, você
precisa adicionar / d: Trace flag para o compilador ou # define TRACE no
código-fonte para permitir o rastreamento. Para o código fonte Visual
Basic .NET, você precisa adicionar / d: TRACE = True para o compilador
de linha de comando. O exemplo de código a seguir usa a classe Trace
para adicionar o recurso de rastreamento em seu código.
public static void Main(string[] args){
Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
Trace.AutoFlush = true;
Trace.WriteLine(“Entering Main”);
Trace.WriteLine(“Exiting Main”);
}
***
O artigo original está disponível em: http://blog.monitis.com/index.php/2012/09/07/measuring-net-application-performance/
|
Ano passado, nós tivemos um coding dojo em AdaptWorks.
Lá, decidimos usar Scala como a linguagem de codificação, e o problema a
ser resolvido foi o Anagram Puzzle. Infelizmente, não conseguimos
resolver o problema durante a sessão de codificação, mas eu tenho
certeza de que todos aprenderam um pouco mais sobre Scala, o que é
sempre o objetivo principal =)
Agora, é claro que eu queria ter resolvido esse enigma. Então,
finalmente usei algum tempo livre e codei uma solução. Ela não é a
melhor possível, mas funciona e foi muito divertido trabalhar nela.
Antes de mostrar a solução, segue uma breve explicação sobre o problema, traduzida a partir da descrição em português:
Escreva um programa que gere todos os anagramas possíveis de uma determinada string.
Por exemplo, os possíveis anagramas de “biro” são os seguintes:
biro brio biou broi boir bori
ibro Ibor irbo irob iobr iorb
rbio rboi ribo riob roib robi
obir obri oibr oirb orbi orib
Eu ainda estou tentando encontrar soluções melhores e mais legíveis, mas por enquanto a atual é a seguinte:
01 class Anagram {
02 def anagrams(word: String): Set[String] = anagram(word).toSet
03
04 def anagram(word: String): List[String] = {
05 if (word.length == 1) {
06 List(word)
07
08 } else {
09 var anagrams = ListBuffer[String]()
10 0 to word.length-1 foreach { i =>
11 anagrams ++= (anagram(without(i, word)) map (word.charAt(i) + _))
12 }
13
14 anagrams.toList
15 }
16 }
17
18 def without(index: Int, word: String): String = new StringBuilder(word).deleteCharAt(index).toString
19 }
Em resumo, o que eu tentei fazer foi combinar o char ‘atual’ com
todas as combinações do resto da string de entrada. Espero que isso faça
sentido durante a leitura do código. O código funciona – tenho alguns
unit tests que geramos durante o coding dojo mais alguns testes que eu
adicionei depois. No entanto, eu não estou feliz com o anagrama
ListBuffer … Eu acho que isso poderia ser resolvido de uma forma mais
elegante. Ideias?
Uma curiosidade extra. Ao olhar para a API do Scala Docs para
encontrar formas possíveis de resolver o quebra-cabeça, eu descobri uma
função muito útil que pode ser chamada nas strings (e outros tipos de
coleções também): permutações. Ela resolve basicamente este
quebra-cabeça em um único método de chamada…
***
Texto original disponível em http://jcranky.com/2011/08/02/the-anagram-puzzle-in-scala/
|
Groovy e XSLT são duas ótimas opções para trabalhar com XML.
Embora ambos tenham seus usos, eu estava curioso para combiná-los para
gerar uma transformação XSLT com um script Groovy. Acontece que fazer
isso é bem simples, com pequenas ressalvas.
Namespaces
Os comandos XSLT como template e value-of são definidos no namespace “http://www.w3.org/1999/XSL/Transform” (comumente apelidado de xsl). Portanto, gerar XML com comandos XSLT requer o uso de um namespace.
Felizmente, o StreamingMarkupBuilder do Groovy tem suporte para namespaces através de um objeto de marcação especial chamado mkp, o qual contém a função declareNamespace():
def xmlWithNamespace = new StreamingMarkupBuilder().bind {
mkp.declareNamespace(abc: "some namespace" )
}
Uma vez declarada, a criação de um node usando o namespace é simplesmente uma questão de usar a notação “.”:
namespace.nodeName {
namespace.anotherNodeName {
...
}
}
Casing Style não-amigável
Como a maioria dos outros padrões W3C, o XSLT usa o estilo “minúsculas-com-hífens” para suas palavras-chave: value-of, apply-templates,
e assim por diante. Isso cria uma ligeira complicação para o Groovy,
porque as palavras com hífens não são símbolos válidos (ou seja, xsl.value-of{} não funcionará). Em vez disso, você tem que colocar esses termos entre aspas: xsl.”value-of”{}.
Resultado final
Então, aqui vai um script Groovy para gerar uma simples transformação XSLT:
def xmlWithNamespace = new StreamingMarkupBuilder().bind {
}
xsl.stylesheet(version: "2.0" ) {
xsl.template(match: "/" ) {
html {
head {
title( "list of items" )
}
}
body {
h1( "items" ) {
ul {
xsl. "apply-templates" (select: "items/item" )
}
}
}
}
xsl.template(match: "item" ) {
li {
xsl. "value-of" (select: "name" )
}
}
}
}
E aqui está o XSLT que o script acima gera:
<? xml version = "1.0" encoding = "UTF-8" ?>
< xsl:template match = "/" >
< html >
< head >
< title >list of items</ title >
</ head >
</ html >
< body >
< h1 >
< ul >
< xsl:apply-templates select = "items/item" />
</ ul >
</ h1 >
</ body >
</ xsl:template >
< xsl:template match = "item" >
< li >
< xsl:value-of select = "name" />
</ li >
</ xsl:template >
</ xsl:stylesheet >
***
Texto original disponível em http://tatiyants.com/how-to-generate-xslt-using-groovy-streamingmarkupbuilder/
|
Scrapping ou raspagem de sites é a técnica utilizada para obter
informações de um determinado site de forma automatizada. Esse tipo de
técnica pode ser utilizada para baixar imagens ou informações diversas
que, se agrupadas corretamente, podem se tornar relevantes (como por
exemplo scrapping em sites governamentais).
No meu caso, escrevi um pequeno programa para obter as imagens deste site.
Utilizei a linguagem Python, pois para mim, ela é extremamente rápida
para prototipar algo; utilizei também as bibliotecas requests e lxml
(sendo que essas duas podem ser substituídas pelo urllib2 e
BeautifulSoup).
Definições
- Requests / urllib2: São bibliotecas utilizadas para efetuar o acesso a sites;
- lxml / Beautifulsoup: São bibliotecas utilizadas para manipular HTML;
Nota: lxml, porém, não tem a manipulação de HTML como sua função principal, mas sim a manipulação de arquivos XML.
Instalando o Requests e lxml
Para efetuar a instalação dessas bibliotecas, utilizaremos o pip:
pip install requests lxml
Caso essas bibliotecas já estejam instaladas, o pip informará; senão ele efetuará o download e instalação delas.
Código do Scrapper
import requests
from lxml.html import fromstring
import os
def connect(url):
return requests.get(url)
def parser(page):
els = fromstring(page.text).cssselect('a')
total_els = len(els)
for index, el in enumerate(els):
if el.get('href').__contains__('?id'):
page = fromstring(connect('http://www.coloring-book.info/coloring/%s' % el.get('href')).text)
dir_image = page.cssselect('img.print')[0].get('src')
directory = dir_image.split('/')[0]
if not os.path.exists(directory):
os.makedirs(directory)
print "Saving %s / %s" % (index, total_els)
open(dir_image, 'wb').write(connect('http://www.coloring-book.info/coloring/%s' % dir_image).content)
def run():
url = 'http://www.coloring-book.info/coloring/'
links = fromstring(connect(url).text).cssselect('center a')
for link in links:
if link.text_content() != '':
print 'Scrapping: %s' % link.text_content()
page = connect(url + link.get('href'))
parser(page)
Utilizando o Scrapper
Eu não coloquei um método __main__, pois nesse caso eu prefiri chamar
o script utilizando o modo interativo do Python (onde ele roda o
arquivo e abre o prompt do REPL para que eu possa executar os comandos).
python -i scrapper.py
>>>
Se tudo estiver correto, será exibido o prompt do Python aguardando
um comando. Fiz um comando chamado run(), que busca todos links na
página inicial e vai entrando em um por um, buscando as imagens e
salvando no diretório correspondente.
Caso voce queira baixar somente alguns links específicos, uma opção é utilizar o scrapper da seguinte forma:
python -i scrapper.py
>>> parser(connect('http://www.coloring-book.info/coloring/coloring_page.php?id=176'))
Nesse caso, baixará somente as imagens que estiver no link referente ao id 176.
python -i scrapper.py
>>> ids = ['92', '15', '215']
>>> [parser(connect('http://www.coloring-book.info/coloring/coloring_page.php?id=%s' % id)) for id in ids]
Agora, a ideia foi baixar todas as imagens dos links que estiverem na lista ids.
Espero que seja útil e que esse script possa servir como base para outros scripts que vocês precisem escrever. *** Artigo de Igor Hercowitz
|
Os caches têm estado no mundo do software por muito tempo. Eles
são uma dessas coisas realmente úteis e, uma vez que você começa a
usá-los, você imagina como foi que você se deu bem sem eles antes.
Então, parece um pouco estranho que os caras do Spring só chegaram à
adição de um cache para a implementação no núcleo do Spring na versão
3.1. Estou supondo que antes isso não era visto como uma prioridade e
antes da introdução das anotações do Java, uma das dificuldades de
armazenamento em cache foi o acoplamento de cache de código com o código
da regra de negócio, o que pode muitas vezes se tornar bastante
confuso.
No entanto, os caras do Spring já desenvolveram um sistema de cache simples de usar baseado em algumas anotações: @Cacheable e @CacheEvict.
A ideia da anotação @Cacheable é que você pode usá-la para
marcar os valores de retorno do método que serão armazenados no cache.
Essa anotação pode ser aplicada tanto na declaração do método quanto na
declaração do tipo. Quando aplicado na declaração do método, o valor de
retorno do método que recebeu a anotação armazenado em cache. Quando
aplicado na declaração do tipo, então o valor de retorno de cada método é
armazenado em cache.
O código abaixo demonstra como aplicar @Cacheable a uma declaração de método:
@Cacheable(value = "employee")
public class EmployeeDAO {public Person findEmployee(String firstName, String surname, int age) {
return new Person(firstName, surname, age);
}
public Person findAnotherEmployee(String firstName, String surname, int age) {
return new Person(firstName, surname, age);
}
}
A anotação Cacheable recebe três argumentos: value, que é obrigatório, juntamente com key e condition. O primeiro deles, value, é usado para especificar o nome do cache (ou caches) no qual o valor de retorno de um método é armazenado.
@Cacheable(value = "employee")
public Person findEmployee(String firstName, String surname, int age) {
return new Person(firstName, surname, age);
}
O código acima assegura que o novo objeto Person seja armazenado no cache “employee”.
Todos os dados armazenados em um cache necessitam de uma chave para
sua recuperação rápida. O Spring, por padrão, cria chaves de
armazenamento em cache usando a assinatura do método anotado como
demonstrado pelo código acima. Você pode substituir isso usando segundo
parâmetro do @Cacheable: key. Para definir uma chave personalizada, você utiliza uma expressão SpEL.
@Cacheable(value = "employee", key = "#surname")
public Person findEmployeeBySurname(String firstName, String surname, int age) {
return new Person(firstName, surname, age);
}
No código findEmployeeBySurname(…), a string ‘#surname’ é uma expressão SpEL que significa “ir e criar uma chave usando o argumento surname do método findEmployeeBySurname(…)“.
O argumento final de @Cacheable é o argumento opcional condition.
Mais uma vez, isso faz referência a uma expressão SPeL, mas desta vez
especifica uma condição que é utilizada para determinar se o seu valor
de retorno do método é adicionado ou não ao cache.
@Cacheable(value = "employee", condition = "#age < 25")
public Person findEmployeeByAge(String firstName, String surname, int age) {
return new Person(firstName, surname, age);
}
No código acima, eu apliquei a regra de negócio de só fazer armazenamento em cache de objetos Person se o empregado tiver menos do que 25 anos de idade.
Após ter demonstrado rapidamente como aplicar alguns caches, a
próxima coisa a fazer é dar uma olhada no que tudo isso significa.
@Test
public void testCache() {
Person employee1 = instance.findEmployee("John", "Smith", 22);
Person employee2 = instance.findEmployee("John", "Smith", 22);
assertEquals(employee1, employee2);
}
O teste acima demonstra armazenamento em cache na sua forma mais simples. Na primeira chamada para findEmployee(…),
o resultado ainda não é armazenado em cache, então o meu código será
chamado e Spring irá armazenar o valor de retorno no cache. Na segunda
chamada para findEmployee(…), o meu código não é chamado e o Spring retorna o valor em cache; daí o employee1 variável local se refere à mesma referência de objeto como empoyee2, o que significa que o seguinte é verdadeiro:
assertEquals(employee1, employee2);
Mas as coisas nem sempre são tão evidentemente claras. Lembre-se que de em findEmployeeBySurname
eu modifiquei a chave de armazenamento em cache para que o argumento
surname fosse usado para criar a chave, e a coisa a se observar ao criar
seu próprio algoritmo de codificação é garantir que qualquer chave se
refira a um único objeto.
@Test
public void testCacheOnSurnameAsKey() {
Person employee1 = instance.findEmployeeBySurname("John", "Smith", 22);
Person employee2 = instance.findEmployeeBySurname("Jack", "Smith", 55);
assertEquals(employee1, employee2);
}
O código acima encontra duas instâncias Person que se
referem claramente a diferentes funcionários, no entanto, por eu estar
fazendo o armazenamento em cache apenas do sobrenome, o Spring irá
retornar uma referência para o objeto que é criado durante a minha
primeira chamada para findEmployeeBySurname(…). Esse não é um problema com o Spring, mas com a minha definição deficiente de chave de cache.
Um cuidado parecido deve ser tomado quando nos referimos a objetos criados por métodos que têm uma condição aplicada à anotação @Cachable. No meu exemplo de código, eu apliquei a condição arbitrária para armazenar em cache apenas instâncias Person, nas quais o empregado tem menos de 25 anos de idade.
@Test
public void testCacheWithAgeAsCondition() {
Person employee1 = instance.findEmployeeByAge("John", "Smith", 22);
Person employee2 = instance.findEmployeeByAge("John", "Smith", 22);
assertEquals(employee1, employee2);
}
No código acima, as referências a employee1 e employee2 são iguais porque, na segunda chamada para findEmployeeByAge(…), o Spring retorna a sua instância em cache.
@Test
public void testCacheWithAgeAsCondition2() {
Person employee1 = instance.findEmployeeByAge("John", "Smith", 30);
Person employee2 = instance.findEmployeeByAge("John", "Smith", 30);
assertFalse(employee1 == employee2);
}
Do mesmo modo, no código de teste unitário acima, as referências a employee1 e employee2 e se referem a diferentes objetos, já que, nesse caso, John Smith é superior a 25.
Isso praticamente cobre @Cacheable, mas e quanto a @CacheEvict
e limpeza de itens do cache? Além disso, existe a questão de adicionar o
armazenamento em cache nas configurações do Spring e escolher a
implementação de cache mais adequada. . No entanto, falaremos mais sobre
isso depois…
***
Texto original disponível em http://www.captaindebug.com/2012/09/spring-31-caching-and-cacheable.html
|
Continuando a série de artigos básicos sobre o WebMatrix, vou
falar sobre como podemos usar e implementar a segurança e a associação.
É uma exigência muito comum no design de aplicações web que partes de
um site só estejam disponíveis para certos usuários com determinados
privilégios. Na prática, isso é implementado fazendo com que os usuários
efetuem o login no site para determinar a sua identidade; este processo é conhecido como autenticação.
Uma vez que a identidade de
um usuário foi estabelecida, os acessos definidos em sua conta de
usuário são aplicados e ele poderá ter acesso ao site conforme seus
privilégios a isso chama-se associação ou membership.
Você pode configurar a segurança e os membros de diferentes maneiras:
- Se você estiver usando WebMatrix, uma maneira fácil é criar como
novo site baseado no modelo Starter Site. Este modelo já está
configurado para a segurança e os membros e já tem uma página de
registro, uma página de login, e assim por diante;
- O site criado pelo modelo também tem uma opção para permitir aos
usuários fazer login usando um site externo, como Facebook, Google, ou
Twitter;
- Se você quiser adicionar segurança a um site existente, ou se você
não quiser usar o modelo Starter, você pode criar sua página de registro
próprio ou sua página de login,etc.;
Neste artigo, vamos ver como o helper (ajudante) WebSecurity do WebMatrix pode ser usado para implementar as funcionalidades de autenticação e associação em um site web.
Vamos aprender como
restringir as áreas de um site para indivíduos e grupos de usuários
autenticados, bem como permitir que novos usuários se inscrevam para uma
conta, e também como permitir que os usuários existentes possam entrar,
mudar e redefinir suas senhas.
O sistema de associação armazena seus dados em um conjunto de tabelas de banco de dados. Vamos ver como o WebMatrix
pode gerar essas tabelas para nós em um banco de dados e como conectar
os dados existentes de usuários de outras fontes ao sistema.
Veremos também um exemplo de
como podemos fornecer páginas nas quais seja possível realizar a
administração do usuário e como armazenar as informações do usuário com
segurança em um banco de dados.
Provavelmente, terei que tratar destes assuntos em mais de um artigo, então vamos lá…
Configurando Helper WebSecurity
A fim de usar o helper (auxiliar) WebSecurity, ele deve primeiro ser inicializado via código. Para fazer isso, precisamos chamar o método WebSecurity.InitializeDatabaseConnection(), passando em alguns valores de inicialização.
A chamada para o método InitializeDatabaseConnection()
pode ser feita a qualquer tempo antes da primeira interação com helper.
Na maioria dos casos, o melhor é fazer isso durante a inicialização da
aplicação, colocando-o dentro do arquivo _AppStart.cshtml do site.
O método InitializeDatabaseConnection() tem uma assinatura contendo cinco parâmetros e uma sobrecarga contendo seis parâmetros:
public static void InitializeDatabaseConnection
(
string connectionStringName,
string userTableName,
string userIdColumn,
string userNameColumn,
bool autoCreateTables
)
public static void InitializeDatabaseConnection
(
string connectionStringName,
string providerName,
string userTableName,
string userIdColumn,
string userNameColumn,
bool autoCreateTables
)
Parâmetros do método initializeDatabaseConnection:
Nome do parâmetro |
Descrição |
connectionStringName |
O nome da string de conexão ou do arquivo SQL Server Compact(sem a extensão .sdf) |
providerName |
O nome do provedor ADO.NET. Ao usar o SQL Server este parâmetro deverá ser omitido. |
userTableName |
O nome da tabela do banco de dados que contém a informação do perfil do usuário |
userIdColumn |
O nome da coluna que contém o ID do usuário. (Deve ser to tipo int) |
userNameColumn |
O nome da coluna que contém o nome do usuário |
autoCreateTables |
Valor boleano usado para indicar se as tabelas do perfil do usuário e dos membros serão
criadas automaticamente pelo ASP .NET se elas ainda não existirem. |
A flexibilidade do helper WebSecurity é
uma de suas principais características e benefícios. O helper pode
trabalhar tanto com os suas próprias tabelas de banco de dados ou pode
ser facilmente configurado para se integrar com qualquer dados
existentes.
Muitas empresas, por
exemplo, já contém a informação de usuários que poderiam ser usadas como
base para um sistema de autenticação e membros.Apontando o helper para uma base de dados existente, juntamente com as colunas para os ids de usuário e nomes de usuários a duplicação de dados pode ser minimizada.
O helper WebSecurity distingue entre o perfil e os dados dos membros.Os dados do perfil do usuário são: o nome de usuário e o ID, juntamente com qualquer outra informação pessoal que deseja armazenar sobre o usuário (endereços de email, números de contato, data de nascimento, etc.).
Os dados dos membros é a
informação de segurança exigida pelo sistema de associação para
autenticar e administrar os usuários deste sistema em particular (senhas, datas de mudança da última senha, funções de aplicativos, etc). Essa divisão entre o perfil e os dados dos membros torna possível ao helper trabalhar com os dados atuais do usuário.
Vamos criar um novo site para demonstrar o sistema de autenticação e membros do WebMatrix.
Abra o WebMatrix e clique em – Site From Template – para criar um novo site a partir de um modelo:

Escolha o modelo Empty Site e informe o nome do site. No exemplo eu dei o nome :

Vamos incluir na raiz do site um novo arquivo _AppStart.chstml. Para isso selecione a guia Files e a seguir no menu clique em New -> New File;
Na janela Choose a File Type, clique no tipo CSHTML e informe o nome _AppStart.cshtml e a seguir no botão OK;

Altere o conteúdo do arquivo conforme o código abaixo:

O código define a inicialização do helper WebSecurity
definindo a criação de um banco de dados chamado MembrosExemplo.sdf e
da tabela UserProfile contendo as colunas UserId e UserName. Temos, então, que criar o banco de dados MembrosExemplo.sdf no site.
Para isso, clique na guia DataBase e a seguir no menu New DataBase; Logo após altere o nome do banco de dados para MembrosExemplo.sdf:

Vamos agora incluir um novo arquivo chamado Default.cshtml na raiz do nosso site. Clique no item do menu New->New File e, a seguir, escolha o template CSHTML e informe o nome Default.cshtml e clique em OK. Em seguida, inclua o código abaixo no arquivo Default.cshtml:

Quando executamos o site pela primeira vez, veremos
que o método InitializeDatabaseConnection() invocado no arquivo
_AppStart.cshtml criou quatro tabelas no banco de dados
MembrosExemplo.sdf.

- UserProfile : contém apenas as duas colunas especificadas na chamada do método: UserID e UserName.
Nós podemos personalizar esta tabela para incluir informações pessoais
adicionais sobre o usuário, desde que não alteremos as definições destas
duas colunas;
- webpages_Membership contém as informações detalhadas dos membros e as informações de segurança exigidas pelo helper;
- webpages_Roles
é usada pelo helper para definir perfis que podem ser utilizados para
criar os grupos de usuários. Esta tabela é usada em conjunto com a tabela webpages_UsersInRoles, que vincula os usuários aos perfis;
Com essas tabelas criadas
temos o sistema para membros inicializado e podemos implementar uma
página de registro permitindo que novos usuários possam criar contas no
banco de dados.
No próximo artigo sobre o assunto irei mostrar como criar a página de registro usando os recursos do helper WebSecurity.
*** Artigo de José Carlos Macoratti
|
Introdução
O nmap (reduzido de “Network Mapper”) é uma ferramenta livre, de
código aberto, utilizada para mapeamento de redes e inclui diversas
funcionalidades como: varredura de portas, detecção de versão de
serviços, identificação remota de sistemas operacionais (OS
fingerprinting), etc. Esta ferramenta foi criada por Gordon “Fyodor”
Lyon, que ainda hoje participa ativamente do desenvolvimento da mesma. O
nmap é uma ferramenta versátil que é muito utilizada, entre outros, em
auditorias, teste de invasão, teste em firewalls e testes de
conformidade.
O nmap, em geral, opera nas camadas de rede e transporte. Entretanto,
também é capaz de manipular dados da camada de enlace (endereças MAC e
requisições ARP, por exemplo) e de interpretar dados da camada de
aplicação para inferir informações interessantes a respeito de seu alvo
(versões de serviços e sistemas operacionais, por exemplo).
A versão mais nova do nmap por ser obtida através do site oficial. Informações adicionais às apresentadas neste artigo podem ser encontradas na documentação oficial
ou no livro de autoria do próprio Fyodor dedicado à ferramenta (Nmap
Network Scanning, Gordon “Fyodor” Lyon, Insecure.com LCC Publishings.
ISBN: 9780979958717), que inclusive tem uma versão traduzida em
português brasileiro (Exame de Redes com NMAP, Gordon “Fyodor” Lyon,
Editora Ciência Moderna. ISBN: 9788573938654). Parte deste livro está disponível gratuitamente na Internet para leitura e consulta.
Nos exemplos de alvo apresentados neste artigo, são utilizados apenas faixas de endereços IP privados definidos na RFC 1918, a saber 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, e o endereço scanme.nmap.org,
que é um host preparado pelos próprios desenvolvedores da ferramenta
para receber este tipo de varredura. Os leitores são encorajados a não
executar varreduras sobre qualquer ativo que não seja de sua propriedade
ou que se tenha autorização formal para isso.
Especificação de alvos
Antes de iniciar uma varredura, seja esta muito simples ou
extremamente complexa, é preciso dizer ao nmap quais são os alvos desta
varredura. O nmap define como alvos válidos endereços IP, faixas de endereços IP
ou nomes de domínio dispostos em lista e separados por caracteres de
espaçamento (espaço, tab, nova linha, etc). Estes alvos podem ser
passados como parâmetro na linha de comando ou em um arquivo (pela
opção -iL arquivo_alvos.txt ).
Assim, quando o alvo é um endereço IP
único, este deve ser especificado como quatro números inteiros
positivos, entre 0 e 255, separados por pontos. São exemplos de
endereços IP únicos: 172.28.1.101 192.168.0.1. Quando o alvo é uma faixa de endereços IP,
este deve ser especificado com duas sintaxes distintas. A primeira
delas consiste do par endereço da rede e sua máscara de subrede. São
exemplos de pares endereço da rede e máscara de subrede: 10.20.0.0/16 172.16.1.32/27. A outra sintaxe aceita consiste de um endereço IP com listas de números separados por vírgulas ou intervalos especificados com hífen. São exemplos de endereço IP com listas de números ou intervalos: 10.0.0.0-255 172.16.1,3,5,0-127 (equivalente a 172.16.1.0-127 172.16.3.0-127 172.16.5.0-127).
Finalmente, quando o alvo é um nome de domínio, este deve ser
especificado por sequências de caracteres quaisquer separadas por
vírgulas. São exemplos de nomes de domínio: scanme.nmap.org e www.seginfo.com.br.
“Quickstart”
A forma mais simplista de executar a varredura utilizando o nmap é
executar a ferramenta sem parâmetros sobre o alvo especificado. Esta
varredura consiste de todas as opções padrão tanto de descoberta quanto
de varredura.
nmap scanme.nmap.org
Esta varredura verifica se o alvo está ativos na rede utilizando o
método de descoberta e faz a varredura utilizando o método de varredura
padrão. O resultado esperado de uma varredura como esta é:
- Verificação de atividade do alvo na rede; e
- Listagem de portas abertas, fechadas e filtradas associadas ao nome
do serviço que tradicionalmente utiliza cada porta, caso o alvo esteja
ativo.
Isto quer dizer que se um determinado serviço estiver sendo provido
em uma porta diferente da que tradicionalmente é utilizada, o nmap
fornecerá uma resposta incorreta sobre o serviço. Isto quer dizer que,
por exemplo, se um servidor ssh, que tradicionalmente utiliza a porta
22, for configurado para prover o serviço na porta 80, tradicionalmente
utilizada por servidores http, nesta varredura o nmap detectará um
servidor http e não um ssh, como esperado.
Nas próximas seções, “Descoberta de hosts” e “Técnicas de Varredura
de portas” respectivamente, é discutido do que consistem estes método de
descoberta e de varredura padrão.
Descoberta de hosts
Frequentemente, o primeiro passo de uma auditoria de segurança ou
projeto de mapeamento de rede é reduzir uma grande faixa de endereços IP
a uma lista de endereços de interesse. Este interesse pode variar
dependendo do propósito da varredura. Em uma auditoria teste de invasão
caixa preta, o auditor se interessa por qualquer host que esteja ativo
na rede, enquanto em um auditoria em aplicações web, o auditor se
interessa somente nos hosts que provejam serviços web. Assim, para cada
propósito distinto há uma forma diferente realizar a descoberta de
hosts.
O nmap fornece diversas opções a fim de perso nalizar a descoberta
de hosts para que esta se adeque aos propósitos da varredura. Estas
opções serão discutidas a seguir.
Primeiramente, pode ser interessante não fazer a descoberta de hosts.
Isto ocorre quando a varredura compreende um único endereço alvo, ou
quando já se sabe que os alvos estão ativos na rede. Para estes casos,
podem ser utilizadas as opções “List scan” (-sL ) ou “No Ping” (-PN ) como exemplificadas nos exemplos abaixo:
nmap -sL 10.0.0.0/24
nmap -PN 10.0.0.0/24
O “List scan” diz ao nmap que a varredura consiste apenas em listar
os alvos passados como parâmetro, embora o nmap ainda faça uma consulta
DNS (reversa, no caso de alvos especificados como endereços IP)
sobre os alvos. Portanto no caso do “List scan” nenhuma varredura ativa
é realizada sobre os alvos especificados. No caso do “No Ping”, o nmap
pula a faze de descoberta completamente. Versões mais antigas do nmap
apontarão a opção “P0 ” para o “No Ping”, mas esta opção é
considerada obsoleta, apesar de ainda funcionar nas versões atuais do
nmap, e, a título de curiosidade, esta opção foi modificada por ser
frequentemente confundida com o “IP Protocol Ping” (-PO ).
No exemplo dado acima, o nmap ainda faria a varredura utilizando o
método de varredura padrão sobre os alvos especificados. A única
situação em que o nmap não se comportaria desta forma acontece quando os
alvos especificados estão na mesma rede que o host que faz a varredura.
Neste caso, o nmap faria um “ARP Ping”, ignorando a opção do “No Ping”.
Uma vez que se queira fazer uma descoberta de hosts, esta deve ser ativada com a opção “-sP ”.
Quando esta opção esta ativada, o nmap não realiza varreduras, mas
apenas realiza a descoberta de hosts, se não houverem outras opções
comandando que a varredura seja feita. Neste caso, o nmap utiliza o
método de descoberta de hosts padrão, que é o “ARP Ping” (-PR ) para alvos localizados na rede interna e o “ICMP Echo Ping” (-PE ) para os demais.
O “ARP Ping” (-PR ) é sempre o método de descoberta de
hosts escolhido pelo nmap quando o alvo encontra-se na mesma rede que o
host de onde a ferramenta é executada. Mesmo que outro método de
descoberta de host seja explicitamente especificado o nmap irá realizar o
“ARP Ping” sobre endereços da rede interna. Para forçar o nmap a
utilizar outro método de descoberta de hosts sobre endereços na rede
interna é necessário utilizar a opção adicional “--send-ip ”.
Outro adendo importante é que esta opção não funciona nos sistemas da
família Microsoft Windows, pois os mesmo não oferecem suporte a sockets
brutos (não vinculados a protocolos). Assim, considerando que a faixa
de endereços IP 192.168.1.0/16 seja a rede interna, os comandos abaixo são equivalentes:
nmap -sP 192.168.1.0/16
nmap -sP -PR 192.168.1.0/16
O “ICMP Echo Ping” (-PE ) é o método de descoberta
padrão para endereços que não estão localizados na mesma rede que o
host de onde a ferramenta é executada. Este método faz parte da família
de métodos “ICMP Ping”, que ainda inclui os métodos “ICMP Timestamp
Ping” (-PP ) e “ICMP Address Mask Ping” (-PM ).
Todos estes métodos funcionam de maneira semelhante, pois detectam a
atividade em um host pelo envio de pacotes ICMP de diferentes tipos.
Assim como os comandos abaixo também são equivalentes para a rede
externa:
nmap -sP scanme.nmap.org
nmap -sP -PE scanme.nmap.org
Outros métodos de descoberta de hosts interessante são o “TCP SYN Ping” (-PS lista_de_portas ) e o “UDP Ping” (-PU lista_de_portas ).
Estes métodos são úteis, pois alguns hosts podem não respondem
requisições ICMP, seja por restrições no firewall ou do próprio sistema
operacional. Assim, estes métodos de descoberta enviam pacotes TCP ou
UDP a uma porta que pode estar aberta ou fechada. Se a porta estiver
aberta, o host certamente irá responder, denunciando a atividade do
host. No entanto, se a porta estiver filtrada, nenhuma resposta será
enviada (bloqueada pelo mesmo firewall que impediu descoberta via
ICMP). Assim, a desvantagem destes métodos, além de serem mais lentos
que o “ARP Ping” e o “ICMP Ping”, está na escolha das portas utilizadas,
pois se todas as portas escolhidas estiverem filtradas, não será
possível detectá-lo, ainda que o host esteja ativo. São exemplos de
descobertas de host por “TCP SYN Ping” e “UDP Ping”:
nmap -sP -PS22,80,443 scanme.nmap.org
nmap -sP -PU53,631 scanme.nmap.org
Varredura de portas
Esta seção trata da principal funcionalidade do nmap, a varredura de
portas. Mesmo quando estava em suas primeiras versões, o nmap sempre foi
capaz de fazer a varredura de portas de forma rápida e eficiente. O
nmap fornece diversos métodos para realizar varreduras de portas e a
escolha de qual método utilizar depende do objetivo que se pretende
atingir. Varreduras de portas podem ter por objetivo detectar serviços
providos por um host alvo, verificar se um firewall está filtrando
requisições de forma adequada ou ainda confirmar se a pilha TCP foi
implementada conforme especificado na RFC 793.
É importante frisar que embora hajam diversos métodos de varredura de
portas disponíveis, só é possível utilizar um por vez. Outro adendo
importante é que a maioria dos métodos de varredura de portas exige
altos privilégios de usuário. Isto é necessário, pois algums pacotes
são veiculados por sockets brutos (não vinculados a protocolos) que
exigem este tipo de privilégios.
Outra parte importante na varredura de portas é a listagem de portas (-p ). A listagem de portas a serem consideradas separadas por vírgulas e, assim como as faixas de endereços IP,
é possível especificar faixas de portas utilizando um hífen. As podem
ser associadas a um protocolo manualmente ou automaticamente pelo nmap
dependendo do contexto da varredura. Quando os protocolos são
especificados manualmente, a listagem de portas é sempre precedida por
uma letra que identifica o protocolo utilizado (‘T’ para TCP e ‘U’ para
UDP) e quando são especificados automaticamente, basta informar a
listagem de portas. Também é possível se utilizar todas as portas
através da opção “-p ” ou limitar por uma determinada quantidade de porta mais utilizadas através da opção “--top-ports qtd_portas ” e se esta quantidade for 100 é possível utilizar o “Fast Scan” (-F ), que é equivalente a “--top-ports 100 ”. Assim, são exemplos de listagem de portas: -p2225,80,443; -pT:22,80,U:53,631 .
A varredura de portas sempre é feita para cada execução do nmap, exceto para o caso do “Ping Scan” (-sP ),
quando é necessário escolher um método de varredura de portas para que
esta seja executada. Quando nenhum método de varredura de portas é
explicitamente especificado, o nmap executa o “TCP SYN Scan”, caso
tenha sido executado por um usuário com privilégio de criar sockets
brutos (não vinculados a protocolos), e o “TCP Connect Scan”, caso
contrário.
O “TCP SYN Scan” (-sS ) é considerado pelos
desenvolvedores da ferramenta como o método de varredura de portas
mais popular. Esta varredura consiste em enviar pacotes TCP com a flag
SYN ativada para as portas alvo. Esta flag é ativada para se iniciar
uma nova conexão TCP entre os hosts, no entanto o nmap não completa o
processo de abertura da conexão (“ThreeWay Handshake”, explicado na
seção 3.4 da RFC 793)
e por isto é considerado um método bem furtivo e difícil de se
detectar. Nesta varredura, uma porta é considerada aberta se a resposta
recebida for um pacote com as flags SYN e ACK ativadas. Se a resposta
for um pacote com a flag RST ativada a porta é classificada como fechada
e se nenhuma resposta for recebida, a porta é classificada como
filtrada. Assim, considerando que a faixa de endereços IP 192.168.1.0/16
seja a rede interna, os comandos abaixo são equivalentes (considerando
que um usuário privilegiado esta executando as varreduras):
nmap 192.168.1.0/16
nmap -sP -sS 192.168.1.0/16
nmap -sP -PR -sS 192.168.1.0/16
De forma semelhante, os comandos abaixo também são equivalentes para a rede externa:
nmap scanme.nmap.org
nmap -sP -sS scanme.nmap.org
nmap -sP -PE -sS scanme.nmap.org
O “TCP Connect Scan” (-sT) funciona de forma muito semelhante ao “TCP
SYN Scan”. Esta varredura consiste em tentar criar conexões entre os
hosts na porta alvo. Isto é feito através da execução completa do Aperto
de Mão em Três Vias (“Three-Way Handshake”, explicado na seção 3.4 da RFC 793) executado pela chamada de sistema “connect()”.
Este método de varredura de portas é mais lento e menos furtivo que o
“TCP SYN Scan”, pois a conexão é, de fato, estabelecida, no entanto, por
usar a chamada de sistema, esta varredura pode ser executar por um
usuário sem privilégios. Nesta varredura, uma porta é considerada aberta
se a conexão for estabelecida com sucesso. Se a conexão for rejeitada a
porta é classificada como fechada e se o tempo limite para estabelecer a
conexão expirar, a porta é classificada como filtrada. Assim,
considerando que a faixa de endereços IP 192.168.1.0/16
seja a rede interna, os comandos abaixo são equivalentes (considerando
que um usuário sem privilégios esta executando as varreduras):
nmap 192.168.1.0/16
nmap -sP -sT 192.168.1.0/16
nmap -sP -PR -sT 192.168.1.0/16
De forma semelhante, os comandos abaixo também são equivalentes para a rede externa:
nmap scanme.nmap.org
nmap -sP -sT scanme.nmap.org
nmap -sP -PE -sT scanme.nmap.org
Outros métodos de varredura de portas sobre o protocolo TCP interessante são o “TCP ACK Scan” (-sA ), “TCP NULL Scan” (-sN ), o “TCP FIN Scan” (-sF ) e o “TCP Xmas Scan” (-sX ).
Estes métodos são úteis, pois permitem explorar falhas de configuração
de um firewall stateless ou roteador que filtre pacotes, que estejam
dificultando uma varredura direta. Estas varreduras enviam pacotes TCP
com a flag ACK ativada para o “TCP ACK Scan”, com nenhuma flag ativada
para “TCP NULL Scan”, com a flag FIN ativada para o “TCP FIN Scan” e,
finalmente, as flags FIN, PSH e URG ativadas para o “TCP Xmas Scan”.
Estas varreduras, em geral, são executadas para agregar informação a
outras varreduras já executadas, visto que nem sempre oferecem
resultados confiáveis. Isto acontece, pois nem todos os sistemas
operacionais implementam sua pilha TCP em conformidade com a RFC 793
e respondem de maneiras inesperadas a requisições como as utilizadas
para este tipo de varredura. Outro adendo importante é que as soluções
mais modernas de IDS/IPS são capazes de detectar e bloquear este tipo de varredura, tornando-as ineficazes. São exemplos deste tipo de varredura:
nmap -PN -sN -p- 172.17.16.1
nmap -sX -p2125,53,80,443 192.168.1.0/24
nmap -sP -PP -sA --top-ports 512 scanme.nmap.org
Existem também métodos de varredura de portas sobre outros protocolos
além do TCP. A varredura sobre o protocolo UDP é chamada “UDP Scan” (-sU ).
Esta é a única varredura que pode ser executada simultaneamente com
outras. Diferentemente das outras varreduras, um pacote UDP vazio é
enviado para a porta alvo. Uma porta é considerada aberta se um pacote
UDP de qualquer espécie for recebido. Se um pacote “ICMP Port
Unreachable” (ICMP tipo 3, código 3) for recebido, se um pacote “ICMP
Destination Unreachable” (ICMP tipo 3, qualquer código) de qualquer
código diferente de 3 for recebido, a porta é classificada como filtrada
e se nenhuma resposta for recebida, a porta é classificada como aberta
ou filtrada. Maiores informações sobre os protocolos UDP e ICMP e seus
tipos e códigos podem ser encontradas nas RFC 768, 792 e Registro de Parâmetros do ICMP disponibilizado pela IANA, respectivamente. São exemplos deste tipo de varredura:
nmap -sP -sU -F scanme.nmap.org
Há também a varredura sobre o protocolo SCTP, chamada “SCTP INIT Scan” (-sY ).
O SCTP é um protocolo que combina características tanto do TCP quanto
do UDP e introduz novas funcionalidades como multihoming e
multistreaming. Maiores informações sobre o SCTP podem ser encontradas
nas RFC 3286 e 4960.
Quanto a varredura SCTP, ela é muito similar à “TCP SYN Scan”, pois
nunca completa a associação SCTP e é relativamente furtiva e pouco
intrusiva. São exemplos deste tipo de varredura:
nmap -PN -sY -p- 172.17.16.1
Detecção de serviço, versão e sistema operacional
As vulnerabilidades publicadas em entidades especializadas, em geral,
são eficazes somente sobre determinadas versões de uma dada aplicação.
Assim, é interessante obter uma leitura mais específica sobre um serviço
detectado do que somente a porta em que este está sendo executado, uma
vez que estes serviços podem ser executados em, virtualmente, qualquer
porta. Sendo assim, o nmap fornece uma opção para aferir o serviço e a
versão do software provendo este serviço através da opção “-sV ”.
Esta opção tenta obter, através do envio de pacotes construídos com
este propósito, descobrir qual serviço está sendo provido de fato e sua
versão aproximada. Vale ressaltar que se o nmap for compilado com
suporte a OpenSSL, a ferramenta tentará aferir serviço provido e sua
versão aproximada mesmo com a camada extra de criptografia. Maiores
informações sobre a detecção da versão de serviços e aplicações podem
ser encontradas no capítulo 7 do livro do próprio autor da ferramenta, disponibilizado gratuitamente.
nmap -sP -sS -sV --top-ports 256 scanme.nmap.org
Assim como são publicadas vulnerabilidades para serviços providos em
uma rede, o mesmo é acontece com sistemas operacionais, portanto também é
importante detectar qual sistema é executado por uma alvo na rede. O
nmap também fornece uma opção para aferir o sistema operacional e sua
versão aproximada através da opção “-O ”. Esta operação também é conhecida como “OS
Fingerprinting”. Esta opção tenta obter, através do envio de pacotes
construídos com este propósito, descobrir qual sistema operacional está
sendo executado e sua versão aproximada. Maiores informações sobre a
detecção remota do sistema operacional podem ser encontradas no capítulo 8 do livro do próprio autor da ferramenta, disponibilizado gratuitamente.
nmap -sP -sS -sV -O -p- scanme.nmap.org
Conclusão
O nmap é uma ferramenta que oferece uma gama de opções úteis e é de
grande valia para obtenção de informação para diversas atividades, como
auditorias de segurança em geral, mapeamento de redes inteiras, teste em
firewalls, etc. Este artigo discutiu apenas as funcionalidades
principais, no entanto ainda há muitas outras que não foram sequer
mencionadas, como: o Nmap Scripting Engine (NSE), opções de controle de
desempenho, opções de evasão de firewalls/IDS/IPS, opções de spoofing, e muitas outras. O leitor é encorajado a buscar mais informações na documentação oficial, no livro oficial e outras fontes, como o Webinar #4 da Clavis sobre “NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança”.
Vale mencionar que, apesar de não haver legislação especifica que
tipifique como crime o ato de executar varreduras de qualquer tipo em
redes de qualquer espécie, o objetivo deste artigo não é incentivar os
leitores a fazer varreduras aleatórias em redes que não são de sua
propriedade ou que não se tenha autorização para fazêlo, mas informar
quanto a que tipo de informação relevante pode ser extraída destas
varreduras e como estas podem ajudar em auditorias teste de invasão,
depuração de firewalls ou administração de servidores, etc.
Referências
- [1] Nmap Free Security Scanner For Network Exploration & Security Audits: http://nmap.org/
- [2] Nmap Official Documentation: http://nmap.org/docs.html
- [3] Nmap Network Scanning, Gordon “Fyodor” Lyon, Insecure.com LCC
Publishings. ISBN: 9780979958717 [4] Exame de Redes com NMAP, Gordon
“Fyodor” Lyon, Editora Ciência Moderna. ISBN: 9788573938654 [5] Nmap
Network Scanning, Gordon “Fyodor” Lyon, http://nmap.org/book/toc.html
- [6] RFC 1918 Address Allocation for Private Internets: http://tools.ietf.org/html/rfc1918
- [7] RFC 793 Transmission Control Protocol: http://tools.ietf.org/html/rfc793
- [8] Linux Man Pages Section 2 (System Calls) connect(): http://linux.die.net/man/2/connect
- [9] RFC 768 User Datagram Protocol: http://tools.ietf.org/html/rfc768
- [10] RFC 792 Internet Control Message Protocol: http://tools.ietf.org/html/rfc792
- [11] Internet Control Message Protocol (ICMP) Parameters Registry: http://www.iana.org/assignments/icmp parameters/icmpparameters.xml
- [12] RFC 3286 An Introduction to the Stream Control Transmission Protocol: http://tools.ietf.org/html/rfc3286 [13] RFC 4960 Stream Control Transmission Protocol: http://tools.ietf.org/html/rfc4960
- [14] Nmap Network Scanning, Gordon “Fyodor” Lyon, Chapter 7. Service and Application Version Detection. http://nmap.org/book/vscan.html
- [15] Nmap Network Scanning, Gordon “Fyodor” Lyon, Chapter 8. Remote OS Detection. http://nmap.org/book/osdetect.html
- [16] Webinar #4 – NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança http://www.blog.clavis.com.br/webinar4softwarelivreparaexploracaoderedeeauditorias
- deseguranca/
- [17] Webinar #14 – “Teste de Invasão com o Nmap Scripting Engine
- http://www.blog.clavis.com.br/webinar-14-teste-de-invasao-com-o-nmap-scripting-engine/
*** Artigo de Bruno Salgado
|
Antigamente o modelo de segurança era somente baseado no nível de
acesso (ou role) que um usuário possuía, ou seja, todo o código que era
executado com a autenticação daquele usuário rodava com os mesmos
privilégios. Com o surgimento da Internet, e consequentemente das
aplicações Web, os softwares ficaram cada vez mais expostos, tornando-os
mais visíveis para terceiros em qualquer parte do mundo. Novos e
poderosos ataques surgiram, exigindo cada vez mais investimentos e
preocupações da equipe de desenvolvimento com a segurança da aplicação.
Um processo de desenvolvimento de software que prima (e devemos
sempre primar) pela qualidade do produto a ser entregue não pode de
forma nenhuma desconsiderar a questão da segurança. A equipe da qual
faço parte, por exemplo, criou um documento de orientação para
desenvolvimento de software seguro, com base no projeto OWASP TOP 10.
Esse projeto tem por objetivo educar desenvolvedores, designers,
arquitetos e organizações a respeito das consequências das
vulnerabilidades mais comuns encontradas em aplicações Web e elenca os
10 principais riscos de segurança, em ordem pelos tipo de ataque, de
problema ou de impactos que causam.
Pra quem não conhece, a OWASP (The Open Web Application Security
Project) é uma organização sem fins lucrativos, focada em auxiliar
indivíduos e organizações a melhorar a segurança de software. Com o
intuito de me aprofundar mais no tema, participei no último mês de
setembro do OWASP Floripa Day Security Conference.
A primeira edição do capítulo Florianópolis, organizado brilhantemente
por Gabriella de Bem (gabidebem@owasp.org) e Tiago Natel
(natel@owasp.org), foi muito boa com diversas palestras e tendo a
segurança como tema principal.
Abaixo, temos a lista de riscos referente aos principais ataques registrados até a última revisão feita em 2010:
A1 – Injection
A2 – Cross-Site Scripting
A3 – Broken Authentication and Session Management
A4 – Insecure Direct Object References
A5 – Cross-Site request Forgery
A6 – Security Misconfiguration
A7 – Insecure Cryptographic Storage
A8 – Failure to restrict URL Access
A9 – Insufficient Transport Layer Protection
A10 – Unvalidated Redirects and Forwards
Provavelmente teremos uma revisão do TOP 10 em 2013, e novos itens
poderão entrar ou a ordem dos itens atuais poderá ser alterada. Em uma
próxima oportunidade, podemos conversar mais detalhadamente sobre esses
itens.
O risco A1 – Injection, que é o mais conhecido pela maioria dos
desenvolvedores, ocorre quando os dados fornecidos pelo usuário são
enviados a um interpretador como parte do comando ou consulta. Muitas
das vezes, o desenvolvedor determina que o software é seguro se estiver
protegido por SQL Injection. Calma, não é bem assim. O assunto segurança
é muito mais abrangente e merece toda a nossa atenção. A própria
orientação do OWASP é para que você não fique ligado apenas no TOP 10, e
sim que esteja atento às demais possibilidades de vulnerabilidades que
possam existir.
Aos profissionais de desenvolvimento cabe o estudo, a dedicação e a
disciplina para uma demanda crescente que é a entrega de soluções
seguras, e o conteúdo disponível no portal da OWASP é um excelente
caminho para isso. Explore-o. Faça dele sua referência, sua inspiração.
Comece a escrever código realmente seguro.
Até a próxima. *** Artigo de Max dos Santos
|
Em tempos em que a sustentabilidade está na consciência de um
grande segmento da população, fica difícil de fechar os olhos ao rápido
desenvolvimento tecnológico que deixa muitos sistemas rapidamente
supérfluos e cria grandes quantidades de hardware que em pouco tempo é
jogado no lixo. Mesmo computadores de apenas cinco anos atrás enfrentam
verdadeiros desafios para competirem com os sistemas operativos mais
recentes, já que, em muitos casos, os usuários percebem que é mais caro
fazer o upgrade de um processador ou um RAM do que comprar um novo
computador.
Claro que esse rápido desenvolvimento tecnológico também tem chegado a
essas companhias, que são cada vez mais capazes de se desfazerem de
partes de computadores que contem materiais tóxicos de forma mais
segura. Além disso, com frequência, muitos computadores sem uso
encontram uma segunda vida nas mãos de usuários menos exigentes.
Contudo, existe ainda uma melhor solução criada precisamente por esta
sofisticação tecnológica: os computadores antigos podem ser usados como
“clientes magros” numa VDI (Virtual Desktop Infrastructure).
A VDI é um modelo computacional em que todos os programas de software
relevantes (incluindo o sistema operativo) são instalados e corridos
num servidor acessível com o “cliente magro”: um tipo de computador que
consegue se conectar ao servidor. Como todos os processos são geridos a
nível central, as características do “cliente magro” são irrelevantes.
Pode ser um smartphone, um tablet pc, ou um computador abandonado há
algum tempo.
Com esta inovação, você se beneficia de grande flexibilidade e
mobilidade. Por exemplo, nas suas férias você pode acessar dados do seu
computador de casa através de um smartphone ou poderá usar o software
licenciado do seu trabalho usando um tablet no conforto da sua casa. Em
última instância, isso significa que os usuários não têm que depender
mais das capacidades individuais dos seus computadores. Mas, não só o
usuário habitual poderá levar essa opção em conta. Escolas, bibliotecas e
centros comunitários são alguns exemplos de organizações com fundos
limitados e com a responsabilidade de providenciar informação e
educação. Se assegurarem um bom computador que sirva como servidor,
podem contar com esses computadores de segunda mão sem sofrerem com
incompatibilidades de software devido a processadores lentos e velhos.
Os usuários comuns podem usar os espaços públicos para se conectarem com
o servidor a partir de um computador antigo ou de um smartphone, usando
o poder do processador central mas mantendo os dados privados nos seus
sistemas.
Ao atingir o objetivo de diminuir a demanda por novos computadores
enquanto se aumenta a acessibilidade, se permite chegar mais perto de um
desenvolvimento tecnológico sustentável que será cada vez menos um
mito, se tornando uma possibilidade real. Embora seja claro que a VDI
tem suas limitações (como por exemplo, a dependência de uma conexão à
Internet e o aumento do risco de segurança por ter a informação toda
concentrada num só computador), a verdade é que dar um propósito a estes
materiais fora de uso é um passo sólido na sustentabilidade ambiental e
financeira. *** Artigo de Nicole Smith
|
Com a chegada do novo Windows 8, foi introduzido um novo tipo de
aplicação: a Windows Store App. Essa nova família de aplicativos conta
com um visual totalmente renovado e irá funcionar em uma variedade de
dispositivos, e não apenas em PCs ou notebooks. Isso mesmo, o objetivo é
que seu aplicativo possa ser executado em um desktop, um tablet, ou
qualquer outro dispositivo rodando Windows 8.

Para desenvolver esses aplicativos, você pode optar por uma variedade
de linguagens e tecnologias, de acordo com o seu conhecimento ou
preferência:
- Se você está acostumado com o ambiente Web, você pode desenvolver um
aplicativo Windows Store App usando HTML5, CCS, Level 3 (CSS3) e
Javascript.
- Se você tem conhecimentos em .NET, WPF ou Silverlight, você pode
desenvolver seu aplicativo Windows Store App usando XAML com o código em
C++, C# ou VB .NET.
- Se o seu aplicativo tiver um apelo gráfico, como jogos por exemplo,
você poderá optar pelo DirectX, usando C++ e HLSL para aproveitar ao
máximo os recursos gráficos.
É importante dizer que aplicações Windows Store App
são suportadas apenas no Windows 8. Você não irá conseguir desenvolver
ou executar esses aplicativos em Windows XP, Windows Vista, Windows 7 ou
qualquer versão de Windows Server, nem mesmo o Windows Server 2012.
O Windows 8 ainda aceita aplicativos convencionais, mas eles não
contam com o novo universo de possibilidades que nasce junto com esse
tipo de aplicativo.
Diferente de qualquer app que estamos acostumados a ver, aplicativos
para Windows Store app não possuem barras, o que faz com que o usuário
se concentre no que é mais importante: o conteúdo.
O layout
Uma Windows Store app pode suportar diferentes tipos de layouts e
visualizações, o que permite criar uma experiência harmoniosa e fluida
nos mais variados tamanhos de tela.

A interação
Windows Store apps funcionam bem com uma variedade de fonte de
entrada incluindo toque (touch), caneta, mouse e teclado. Seus usuários
poderão contar com os mais variados tipos de interações com o seu
aplicativo.

Aonde foram parar as barras e os menus?
Não existem mais menus como estamos acostumados, a primeira interface
de comando com a sua aplicação é a app bar. Você deve utiliza-lá para
apresentar a navegação, os comandos e as ferramentas para o usuário. O
app bar é oculto por default e aparece quando o usuário toca o dedo na
parte superior ou inferior da tela ou clica com o botão direito do mouse
na tela do aplicativo.

Outra interface de comando que podemos utilizar é chamada de charms
bar. Essa barra é composta por um conjunto específico e consistente de
botões (pesquisar, compartilhar, conectar, configurar e iniciar) e está
disponível em todas aplicações.
A Microsoft acredita que algumas tarefas são interessantes em todo aplicativo, bem como:
- Pesquisar por um conteúdo localizado na sua aplicação ou em outra aplicação.
- Compartilhar o conteúdo de sua aplicação com pessoas ou serviços.
- Ir diretamente para o Iniciar.
- Conectar dispositivos, enviar conteúdo e imprimir.
- Usar o botão Configurações para definir as preferências para sua aplicação.

Neste artigo, tratamos alguns dos novos conceitos que foram
introduzidos com a chegada do Windows 8. No próximo, iremos dar
continuidade a todas essas novidades na pratica.
Obrigado e até a próxima. *** Artigo de Ricardo Saggioni
|
O iostat é um aplicativo com o qual podemos analisar uma série de
informações sobre o sistema de I/O, podendo identificar qual o disco
está sendo mais utilizado nos aspectos de leitura ou gravação. Com ele
também podemos visualizar são as estatísticas da CPU (avg-cpu – average
cpu).

Dissecando a figura acima
São apresentados dois blocos de informações. No primeiro, podem ser
conferidos dados relacionados ao processador que permitem realizar uma
análise minuciosa. Já o segundo exibe informações de estatísticas de
funcionamento dos discos. Podemos observar as seguintes métricas:
- tps – quantidade de transferência por segundo;
- KB_read/s – blocos lidos por segundo;
- KB_wrtn/s – blocos escritos por segundo;
- KB_read – quantidade total de blocos lidos;
- KB_wrtn – quantidade total de blocos escritos.
Observando essas informações por um segundo, o administrador (ou
usuário) será capaz de identificar qual tipo de acesso está sendo
predominantemente feito no sistema, ou seja, se estão sendo feitas
maiores quantidades de requisições de leitura ou escrita, além de
constatar se o disco está com “sobrecarga”.
Utilização
Visualizando a saída em megabytes:
# iostat -m
Para um ajuste fino é possível definir o parâmetro -p e a partição a ser monitorada:
# iostat -p /home
Visualizando os valores de cpu:
# iostat -c
Instalação
Fedora
# yum install sysstat
Debian e derivados
# aptitude install sysstat *** Artigo de Deividson Ludolf
|
Enquanto eu desenvolvia com Scala, descobri que é possível fazer
combinações de uma classe com traits. Pode parecer óbvio, se você já
sabe, mas eu particularmente não sabia.
O que aconteceu é que eu precisava de algo como combinar esse tipo de
combinação… E este artigo fala sobre algo de Scala que eu amo: ele se
torna intuitivo depois de um tempo. Então, como foi que descobri que tal
correspondência é possível? Eu simplesmente tentei … =)
O recurso se parece com isto:
msg match {
case x: X with Z => println("matching combination!")
}
Nesse caso, X seria uma classe e Z, uma trait. O case x será acionado apenas se msg for uma instância da class X e se misturar com a trait Z. Com isso, certifique-se de ter acesso a todos os membros, tanto da classe quanto das traits,
enquanto estiver muito seguro sobre o tipo de correspondência. Nenhuma
combinação não suportada irá passar, e não há necessidade de castings,
como seria necessário em Java.
Vamos tentar um exemplo fictício. Imagine que temos uma classe Superman, e duas traits: BlueCape e RedCape, como o seguinte código:
class Superman(val realname: String)
trait BlueCape
trait RedCape
Agora, queremos corresponder em uma instância de Superman, mas
queremos saber se é falsa ou não. Finalmente, também queremos imprimir o
nome do cara, o que significa que precisamos de acesso ao campo realname. Você pode fazer isso assim:
def whichSuperman(superman: AnyRef) = superman match {
case s: Superman with RedCape => println("real superman: " + s.realname)
case f: Superman with BlueCape => println("fake superman: " + f.realname)
}
Flexível e do tipo seguro! E se traits tivessem qualquer campo, também seríamos capazes de acessá-los. Pequeno exemplo de código:
val mys = new Superman("clark") with RedCape
val myf = new Superman("clurk") with BlueCape
whichSuperman(mys)
whichSuperman(myf)
A parte que corresponde à classe não é muito útil nesse exemplo, uma
vez que isso poderia ser definido no parâmetro de função, mas estava em
meu cenário local, onde estamos usando atores e as mensagens podem ser AnyRef.
Se quiser saber um pouco mais sobre a correspondência de padrões, eu escrevi sobre isso há um tempo aqui. Eu também descrevi como combinar uma série de números aqui.
***
Texto original disponível em http://jcranky.com/2011/12/19/matching-a-combination-of-class-and-trait-in-scala/
Artigo de Paulo “JCranky” Siqueira
|