Arquivo da categoria ‘normal’

Clique aqui e veja nosso novo site

Iae galera,

Estamos agora em outro site… http://www.segurancaemrede.com

E la iremos disponibilizar tudo quanté conteudo que pensarem.

Inclusive os livros que muitas pessoas estao pedindo atraves deste site

Clique aqui e veja nosso novo site

Evolução do IP vs Clean Slate

Uma das discussões centrais destes dois dias de evento foi em torno da forma que a rede terá no futuro. Há pesquisadores que defendem que uma nova Internet deve ser criada, ou seja, que deve-se abandonar o protocolo IP, sobre o qual está fundamentada a Internet atual, e desenvolver uma base inteiramente nova sobre a qual a rede passará a funcionar. Esta idéia de “recomeçar a Internet do zero” é conhecida entre os pesquisadores como Clean Slate, ou arquitetura disruptiva.

Os que pensam desta forma argumentam que a Internet como conhecemos foi criada há aproximadamente 30 anos, com o objetivo de atender um público restrito (cientistas e pesquisadores). Hoje, entretanto, a mesma estrutura básica é usada mundialmente por centenas de milhões de pessoas que enviam, consultam e recebem cada vez mais informações (de texto, de imagens, de áudio, de vídeo etc). Como a rede não foi a princípio preparada para isto, os novos aplicativos que surgiram ao longo dos anos foram sendo “ajustados” a rede de maneira desordenada. Atualmente, portanto, a Internet seria constituída por vários “remendos”, responsáveis por uma série de vulnerabilidades, instabilidades, incompatibilidades e outros problemas da rede. Os defensores do Clean Slate argumentam que uma Internet recalculada do zero seria mais robusta e confiável, com maior flexibilidade e facilidade de administração.

Os que defendem o IP argumentam que este protocolo vem funcionando satisfatoriamente nos últimos 30 anos e que, embora uma mudança na Internet seja necessária, ela partirá de uma evolução do próprio IP, e não de uma ruptura com ele. Vale ressaltar que estas visões não são totalmente excludentes: além de ser possível que o novo desenho seja baseado em uma adaptação do protocolo IP (e não uma ruptura completa com este), é possível, ainda, que o IP seja agregado a uma nova estrutura, mesmo que ela não tenha este protocolo como base.

Aparentemente há um consenso entre os pesquisadores de que as mudanças estruturais na Internet (ocorram elas em decorrência de uma evolução do IP ou a partir de um redesenho da arquitetura), ainda devem ser amplamente discutidas durante a próxima década. Isto pois embora todos concordem que a Internet precisa passar por profundas mudanças, ainda não se tem estabelecida nenhuma solução concreta. Desta forma, o workshop do CPqD incluiu também palestras sobre possíveis soluções para alguns dos problemas pontuais da rede, assim como apresentações sobre possibilidades de novas aplicações para a Internet atual e futura.

Problemas e possíveis soluções

Além das questões relativas às redes experimentais, o workshop contou ainda com palestras sobre diversos outros fatores que gravitam em torno do tema “Futuro da Internet”, tais como: desafios e tendências em segurança; questões em torno da mobilidade crescente dos dispositivos conectados a Internet; possibilidades para separar identificação e localização; hiperconectividade; novos requisitos na engenharia de tráfego e gerenciamento de recursos; monitoramento de redes; soluções ópticas para o aumento da sustentabilidade energética das redes, entre outros.

Um dos temas apresentados no evento diz respeito aos ambientes experimentais para o teste das novas soluções para a Internet, importante tanto quando se fala da rede do futuro, quanto quando se fala das redes atuais. Embora muitos pesquisadores concordem que em muitos casos estes ambientes (também conhecidos como testbeds) não dão a medida exata do que ocorre em situações reais, a necessidade deles é não somente inegável, como também crescente, dado o número cada vez maior de aplicações para a Internet.

A palestra do diretor de Inovação da RNP, Michael Stanton, teve como tema justamente os ambientes de suporte para trabalhos de Pesquisa e Desenvolvimento (P&D) experimentais em redes e aplicações distribuídas.

Stanton descreveu a evolução desses ambientes, que podem ser infraestruturas físicas ou virtuais, bem como a maneira como o suporte é dado. Além das atividades já realizadas no Brasil, ele também examinou o contexto de algumas redes experimentais usadas no exterior, especialmente as relacionadas ao futuro desenvolvimento da Internet.

No cenário internacional, o diretor de Inovação da RNP destacou o PlanetLab, uma infraestrutura mundial para a realização de pesquisas em tecnologias e protocolos de aplicações Internet (TCP/IP), atualmente presente em mais de 400 nós espalhados pelo mundo. A contribuição fundamental do PlanetLab para a realização de pesquisa experimental é o uso da virtualização de recursos computacionais nestes nós, permitindo que múltiplas aplicações possam ser instaladas paralelamente em cada nó, e que uma determinada aplicação possa estar presente em uma fração de muitos nós diferentes, o que é chamada de uma “fatia”.

Em 2006, o ambiente PlanetLab foi estendido para permitir experimentos com outras arquiteturas de Internet, além do TCP/IP. Este “meta-testbed” se chama Vini, e permite que os servidores nos nós possam funcionar como roteadores para diversos protocolos. A virtualização dos recursos em Vini inclui também os roteadores e os enlaces entre estes.

O Vini serviu como inspiração para o Global Environment for Network Innovations (Geni), uma iniciativa da norte-americana National Science Foundation (NSF) para criação de um ambiente compartilhado de experimentação que auxilie na validação de novas arquiteturas de redes. O objetivo do Geni é apoiar pesquisas que possam levar a uma futura Internet melhor, com características como maior segurança, integração com tecnologias ópticas e de rádio, maior atratividade econômica, entre outras. Uma das palavras-chave do ambiente Geni é a virtualização, que permite que múltiplas arquiteturas funcionem em uma infraestrutura compartilhada, dando uma representação razoável da complexidade da Internet. Michael falou ainda de outras iniciativas similares ao Geni, como a europeia Future Internet Research & Experimentation (Fire) e a japonesa Akari.

Para concluir, o diretor de Inovação da RNP examinou as perspectivas para montar no Brasil um programa de P&D experimental sobre a Internet do Futuro, com a participação da RNP. Inicialmente falou sobre o projeto Giga, que tratou da implementação de uma rede óptica experimental própria, com de 2,5 Gbps e 735 Km de extensão. A primeira fase do projeto foi oficialmente encerrada em 200. Atualmente, a RNP e o CPqD buscam recursos para continuar mantendo a rede experimental ativa, sendo a proposta da RNP a realização de P&D em arquiteturas novas de rede, visando o futuro da Internet. Além disto, a RNP e quatro universidades formularam em 2008 uma linha de pesquisa experimental em futuras arquiteturas de rede, com base em ambiente inspirado no Vini, para compor o projeto Ciência Web (consórcio liderado pela UFRJ), um dos selecionados no recente edital do INCT (Institutos Nacionais de Ciência e Tecnologia) do CNPq. Nesta proposta a RNP proveria conectividade a longa distância para a rede experimental pretendida.

O uso de Vini neste contexto requereria uma infraestrutura subjacente de camada 2 do modelo OSI, para poder implementar possivelmente múltiplos protocolos de rede (camada 3), sendo IP apenas uma das alternativas. Os atuais planos da RNP são compatíveis com este projeto, com a migração do backbone para tecnologia de rede de camadas 1 e 2, e o uso amplo de Ethernet (camada 2) nas redes metro (pertencentes a iniciativa Redes Comunitárias de Educação e Pesquisa – Redecomep) e nas principais conexões internacionais (Whren-Lila/AtlanticWave). Seria possível, portanto, imaginar que a RNP do futuro pudesse reservar banda para experimentação, isolada do tráfego de “produção”, em toda sua extensão, como é feito em Geni.

Stanton encerrou a apresentação apontando as oportunidades que surgiriam para realizar P&D colaborativos com pesquisadores de outros países se existisse uma rede experimental do tipo Geni no Brasil, que pudesse ser interconectada (federada) com as iniciativas semelhantes em outros países, e notou que as políticas enunciadas por Geni e Fire dão suporte a esta forma de colaboração. Para Stanton, isto permitiria ao Brasil participar no esforço internacional para definir como seria a Internet do Futuro.

Redes híbridas

Outro assunto bastante abordado ao longo do workshop foram as redes híbridas, que se apresentam no cenário acadêmico como uma tendência mundial. Em uma rede híbrida, a mesma infraestrutura de comunicação é usada simultaneamente para prestar serviço de pacotes IP, como opera hoje a rede Ipê, e para circuitos fim-a-fim voltados a aplicações selecionadas. Atualmente, estes circuitos fim-a-fim, que funcionam como canais diretos de transferência de dados entre dois pontos, são configurados manualmente, uma atividade demorada, trabalhosa e sujeita a erros.

A discussão sobre qual é a melhor solução tecnológica para tornar automático o aprovisionamento dos circuitos fim-a-fim, permitindo que ele seja feito sob demanda e de maneira agendada, também foi abordada durante o workshop, assim como diversos outros assuntos relativos às redes híbridas.

Em maio, o projeto Futura RNP, que lança as bases para a próxima a nova rede acadêmica brasileira (possivelmente de arquitetura híbrida), completará um ano. Vale ressaltar que a maioria dos palestrantes que se apresentaram no workshop são parceiros da RNP no Futura RNP.

O futuro da internet está nas maos de quem ?

Fonte: RNP

Esse POST tem como objetivo detalhar os estados de uma conexão TCP para instantaneamente viabilizar a análise do resultado da captura de pacotes na rede.

O TCP é o protocolo da camada de transporte do modelo de referência OSI que é orientado a conexão.

Por ter essa característica, antes de ocorrer a transmissão de dados deve-se estabelecer uma sessão de comunicação entre as duas partes. Essa sessão é estabelecida através de um processo chamado three-way handshake, Figura 1, que irá sincronizar os números de seqüência e oferecer informações de controle necessárias para estabelecimento da conexão.

Como o início e o fim de uma sessão de comunicação são bem definidos e o TCP acompanha o estado de suas conexões com flags é importante saber quais são os muitos estados que uma conexão TCP passa.

O estabelecimento da conexão TCP com o 3-way handshake.

Os estados possíveis da conexão TCP são os seguintes:

  • LISTEN: esse é o estado verdadeiro de uma conexão TCP, ele ocorre quando um host está esperando um pedido para iniciar uma conexão.
  • SYN-SENT: esse estado indica que o host enviou um SYN para iniciar a conexão e está aguardando a resposta SYN-ACK adequada.
  • SYN-RCVD: esse estado indica que o host enviou a resposta SYN-ACK depois de ter recebido o SYN.
  • ESTABLISHED: esse estado indica que a conexão foi estabelecida. O host que iniciou a conexão entra nesse estado depois de receber o SYN-ACK e o host que responde depois que recebe o ACK.

Como verificamos na Figura 1 esses são os estados que os hosts passam no processo de estabelecimento da conexão TCP no processo chamado 3-way handshake.

Existem outros estados que acontecem no desmembramento de uma conexão TCP:

  • FIN-WAIT-1: O estado que um host se encontra após ter enviado um pacote FIN inicial pedindo um fechamento correto da conexão TCP.
  • CLOSE-WAIT: O estado da conexão do host que recebeu um FIN inicial e envia de volta um ACK para confirmar o FIN.
  • FIN-WAIT-2: O estado da conexão do host que recebeu a resposta ACK para seu FIN inicial, e indica que agora está esperando um FIN final.
  • LAST-ACK: Esse estado indica que o host acabou de enviar seu segundo FIN, que é necessário para encerramento correto da conexão TCP, e está aguardando uma confirmação.
  • TIME-WAIT: Nesse estado encontra-se o host iniciador que recebeu um FIN final e enviou um ACK para fechar a conexão. Nesse momento ele não irá mais receber nenhuma confirmação do ACK que acabou de enviar, portanto espera um período de tempo para fechar a conexão.
  • CLOSED: pode-se considerar como “sem estado”. Esse estado existe antes que uma conexão seja iniciada ou quando ela é finalizada.

Estes estados estão ilustrados na Figura 2, e ocorrem no fechamento correto da conexão TCP:


Clique aqui e veja nosso novo site

 

SYN flood ou ataque SYN é uma forma de ataque de negação de serviço (também conhecido como Denial of Service – DoS) em sistemas computadorizados, na qual o atacante envia uma seqüência de requisições SYN para um sistema-alvo.

Quando um cliente tenta começar uma conexão TCP com um servidor, o cliente e o servidor trocam um série de mensagens, que normalmente são assim:

  • O cliente requisita uma conexão enviando um SYN (synchronize) ao servidor.
  • O servidor confirma esta requisição mandando um SYN-ACK(acknowledge) de volta ao cliente.
  • O cliente por sua vez responde com um ACK, e a conexão está estabelecida.

Isto é o chamado aperto de mão em três etapas (Three-Way Handshake).

Um cliente malicioso pode não mandar esta última mensagem ACK. O servidor irá esperar por isso por um tempo, já que um simples congestionamento de rede pode ser a causa do ACK faltante, Ou seja. O servidor ficará esperando varias respostas deixando de responder as outras requisições que são feitas por outros clientes.

Esta chamada conexão semi-aberta pode ocupar recursos no servidor ou causar prejuízos para empresas usando softwares licenciados por conexão. Pode ser possível ocupar todos os recursos da máquina, com pacotes SYN. Uma vez que todos os recursos estejam ocupados, nenhuma nova conexão (legítima ou não) pode ser feita, resultando em negação de serviço. Alguns podem funcionar mal ou até mesmo travar se ficarem sem recursos desta maneira.

Algumas contra-medidas para este ataque são os SYN cookies. Apenas máquinas Sun e Linux usam SYN cookies.

Ao contrário do que muitos pensam, não se resolve negação de serviço por Syn flood limitando conexões por minuto (como usar o módulo limit ou recent do iptables), pois as conexões excedentes seriam descartadas pelo firewall, sendo que desta forma o próprio firewall tiraria o serviço do ar. Se eu, por exemplo, limito as conecões SYN a 10/seg, um atacante precisa apenas manter uma taxa de SYNs superior a 10/s para que conexões legítimas sejam descartadas pelo firewall. O firewall tornou a tarefa do atacante ainda mais fácil. Em “Iptables protege contra SYN Flood?” tem uma boa descrição dos motivos pelos quais uma configuração de firewall não resolve.

Um ataque de Syn Flood é feito com os ips forjados (spoof), para que o atacante não receba os ACKs de suas falsas solicitações.

~juancarloscunha.wordpress.com~

Ferramentas para ataques DDoS,   funcionamento das ferramentas ddos

Ao contrário do que se pensa, os ataques DDoS não são novos. A primeira ferramenta conhecida com esse propósito(ataques ddos) surgiu em 1998. Desde então, foram diversas as ferramentas de DDoS desenvolvidas, cada vez mais sofisticadas e com interfáceis mais amigáveis. O que é no mínimo preocupante, pois nos dá uma idéia de quão rápido se movimenta o mundo hacker. A seguir, elas são listadas na ordem em que surgiram:

1. Fapi (1998)      2. Blitznet
3. Trin00 (jun/99)

4. TFN (ago/99)

5. Stacheldraht(set/99) 6. Shaft

7. TFN2K(dez/99)   8. Trank

9. Trin00 win version

Não é propósito deste artigo abordar todas as ferramentas de DDoS disponíveis,mas apenas conhecer o funcionamento básico das principais, que são: Trin00, TFN, Stacheldraht e TFN2K.

TRIN00

O Trin00 é uma ferramenta distribuída usada para lançar ataques DoScoordenados, especificamente, ataques do tipo UDP flood.Para maiores informações a respeito de ataques deste tipo, veja em: http://www.cert.org/advisories/CA-96.01 … enial.html

Uma rede Trinoo é composta por um número pequeno de masters e um grande número de agentes.

O controle remoto do master Trin00 é feito através de uma conexão TCP via porta 27665/tcp. Após conectar, o atacante deve fornecer uma senha(tipicamente, “betaalmostdone”).

A comunicação entre o master Trin00 e os agentes é feita via pacotes UDP na porta 27444/udp ou via pacotes TCP na porta 1524/tcp. A senha padrão para usar os comandos é “l44adsl” e só comandos que contêm a substring “l44″ serão processados.

A comunicação entre os agentes e o master Trin00 também é através de pacotes UDP, mas na porta 31335/udp. Quando um daemon é inicializado, ele anuncia a sua disponibilidade enviando uma mensagem (”*HELLO*”) ao master,o qual mantém uma lista dos IPs das máquinas agentes ativas, que ele controla.

Tipicamente, a aplicação cliente que roda no master tem sido encontrado sob o nome de master.c, enquanto que os daemons do Trin00 instalados em máquinas comprometidas têm sido encontrados com uma variedade de nomes, dentre eles: ns, http, rpc.trinoo, rpc.listen, trinix, etc. Tanto o programa cliente (que roda no master) quanto o daemon (que roda no agente) podem ser inicializados sem privilégios de usuário root.

TFN – TRIBE FLOOD NETWORK

O TFN é uma ferramenta distribuída usada para lançar ataques DoS coordenados a uma ou mais máquinas vítimas, a partir de várias máquinas comprometidas. Além de serem capazes de gerar ataques do tipo UDP flood como o Trin00, uma rede TFN pode gerar ataques do tipo SYN flood, ICMP flood e Smurf/Fraggle. Maiores informações a respeito deste tipo de ataques podem ser encontradas em:

http://www.cert.org/advisories/CA-96.21 … oding.html
http://www.cert.org/advisories/CA-98.01.smurf.html

Neste tipo de ataque é possível forjar o endereço origem dos pacotes lançados às vítimas, o que dificulta qualquer processo de identificação do atacante.

No caso específico de se fazer uso do ataque Smurf/Fraggle para atingir a(s) vítima(s), o flood de pacotes é enviado às chamadas “redes intermediárias” que consolidarão o ataque, não diretamente às vítimas.

O controle remoto de uma master TFN é realizado através de comandos de linha executados pelo programa cliente. A conexão entre o atacante e o cliente pode ser realizada usando qualquer um dos métodos de conexão conhecidos, tais como: rsh, telnet, etc. Não é necessária nenhuma senha para executar o cliente, no entanto, é indispensável a lista dos IPs das máquinas que têm os daemons instalados. Sabe-se que algumas versões da aplicação cliente usam criptografia (Blowfish) para ocultar o conteúdo desta lista.

A comunicação entre o cliente TFN e os daemons é feita via pacotes ICMP_ECHOREPLY.Não existe comunicação TCP ou UDP entre eles.

Tanto a aplicação cliente (comumente encontrada sob o nome de tribe) como os processos daemons instalados nas máquinas agentes (comumente encontrados sob o nome de td), devem ser executados com privilégios de usuário root.

STACHELDRAHT

Baseado no código do TFN, o Stacheldraht é outra das ferramenta distribuídas usadas para lançar ataques DoS coordenados a uma ou mais máquinas vítimas, a partir de várias máquinas comprometidas. Como seu predecessor TFN, ela também é capaz de gerar ataques DoS do tipo UDP flood, TCP flood, ICMP flood e Smurf/fraggle.

Funcionalmente, o Stacheldraht combina basicamente características das ferramentas Trin00 e TFN, mas adiciona alguns aspectos, tais como: criptografia da comunicação entre o atacante e o master;e atualização automática dos agentes.

A idéia de criptografia da comunicação entre o atacante e o master surgiu exatamente porque uma das deficiências encontradas na ferramenta TFN era que a conexão entre atacante e master era completamente desprotegida, obviamente sujeita a ataques TCP conhecidos (hijacking, por exemplo). O Stacheldraht lida com este problema incluindo um utilitário “telnet criptografado” na distribuição do código.

A atualização dos binários dos daemons instalados nos agentes pode ser realizada instruindo o daemon a apagar a sua própria imagem e substituí-la por uma nova cópia (solaris ou linux). Essa atualização é realizada via serviço rpc (514/tcp).

Uma rede Stacheldraht é composta por um pequeno número de masters onde rodam os programas clientes (comumente encontrados sob o nome de mserv, e um grande número de agentes, onde rodam os processos daemons (comumente encontrados sob o nome de leaf ou td). Todos eles devem ser executados com privilégios de root.

Como foi mencionado anteriormente, o controle remoto de um master Stacheldraht é feito através de um utilitário “telnet criptografado” que usa criptografia simétrica para proteger as informações que trafegam até o master. Este utilitário se conecta em uma porta TCP,comumente na porta 16660/tcp.

Diferencialmente do que ocorre com o Trinoo, que utiliza pacotes UDP na comunicação entre os masters e os agentes, e do TFN, que utiliza apenas pacotes ICMP, o Stacheldraht utiliza pacotes TCP (porta padrão 65000/tcp) e ICMP (ICMP_ECHOREPLY).

TFN2K – TRIBLE FLOOD NETWORK 2000

A ferramenta Tribe Flood Network 2000, mais conhecida como TFN2K, é mais uma ferramenta de ataque DoS distribuída. O TFN2K é considerado uma versão sofisticada do seu predecessor TFN. Ambas ferramentas foram escritas pelo mesmo autor, Mixter.

A seguir são mencionadas algumas características da ferramenta:

* Da mesma forma que ocorre no TFN, as vítimas podem ser atingidas por ataques do tipo UDP flood, TCP flood, ICMP flood ou Smurf/fraggle. O daemon pode ser instruído para alternar aleatoriamente entre estes quatro tipos de ataque.
* O controle remoto do master é realizado através de comandos via pacotes TCP, UDP, ICMP ou os três de modo aleatório. Estes pacotes são criptografados usando o algoritmo CAST.Deste modo, a filtragem de pacotes ou qualquer outro mecanismo passivo, torna-se impraticável e ineficiente.
* Diferentemente do TFN, esta ferramenta é completamente “silenciosa”, isto é, não existe confirmação (ACK) da recepção dos comandos, a comunicação de controle  é unidirecional. Ao invés disso, o cliente envia 20 vezes cada comando confiando em que, ao menos uma vez, o comando chegue com sucesso.
* O master pode utilizar um endereço IP forjado.

A título de ilustração se resume, através da seguinte tabela comparativa, como é realizada a comunicação entre os”personagens” encontrados em um típico ataque DDoS, para cada uma das ferramentas:
Comunicação Trin00 TFN Stacheldraht TFN2K
Atacante->Master 1524/27665/tcp icmp_echoreply 16660/tcp icmp/udp/tcp
Master->Agente 27444/udp icmp_echoreply 65000/tcp,
icmp_echoreply icmp/udp/tcp
Agente->Master 31335/udp icmp_echoreply 65000/tcp,
icmp_echoreply icmp/udp/tcp

De um modo geral, os binários das ferramentas DDoS têm sido comumente encontrados em máquinas com sistema operacional Solaris ou Linux. No entanto, a fonte dos programas pode ser facilmente portado para outras plataformas.

Ainda em relação às ferramentas, vale lembrar que a modificação do código fonte pode causar a mudança de certas propriedades da ferramenta, tais como: portas de operação, senhas de acesso e controle, nome dos comandos, etc. Isto é, a personalização da ferramenta é possível.

Information Schema Views são um conjunto de visões que se encontram no esquema chamado INFORMATION_ SCHEMA e fornece informações dos meta-dados em um formato uniforme.

Por exemplo, a consulta abaixo realizada na View INFORMATION_SCHEMA.TABLES  apresenta as tabelas de usuario no atual banco de dados juntamente com os respectivos nomes de esquema:

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = N’BASE TABLE’;

information_schema.table

information_schema-table.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A consulta abaixo em INFORMATION_SCHEMA.COLUMNS apresenta informações sobre colunas da tabela Sales.Orders:

SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, COLLATION_NAME, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = N’Sales’
AND TABLE_NAME = N’Orders’;

Resultado…

table_schema

table_schema

 

Espero que vocês tenham entendido como é feito esta consulta. Si não entendeu, cinto muito; vai ter que ler novamente. Ou, si não entender quando ler novamente. Entre em contato comigo!

~Bye: Juancarloscunha.wordpress.com~

Uma das formas mais fáceis de si descobrir nomes de tabelas é o uso do comando, show:

sqlinjection

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Agora, vou tentar listar do banco de dados werp, O nome da tabela de usuarios, Geralmente os nomes das tabelas são: users, roots,usuarios…Vamos ver qual o nome:

sqlinjection_tabelas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Agora, eu já sei o nome do banco de dados, e também sei o nome das tabelas que tem no database, inclusive a de usuarios, agora, eu quero saber o nome das colunas da tabela usuarios.

3

 

 

 

 

 

 

 

 

 

 

 

 

Agora, vou listar o nome do usuário administrador e a senha do usuário:

4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Conclusão:

 

Aqui, você aprendeu listar todos databases do banco de dados, Listar todas as tabelas do database, Listar todas as colunas das tabelas,  Listar dados das colunas.

Existem varias maneiras de fazer isso. Eu só estou ensinando uma das maneiras aqui.