A Rede Informática do ISEL e do IPL Introdução
Transcript of A Rede Informática do ISEL e do IPL Introdução
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #1
A Rede Informática doISEL e do IPL
Segurança eQualidade de Serviço
Nuno CruzPedro RibeiroVítor Almeida
Segurança eSegurança eQualidade de ServiçoQualidade de Serviço
Nuno CruzPedro RibeiroVítor Almeida
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #2
Introdução
A Internet é neste momento um ‘lugar’ inseguro!– Utilizadores mal intencionados a comprometer serviços como forma
de afirmação pessoal e provocação.– ‘Gangs’ formados por adolescentes e não só que usam ferramentas
(existem sites inteiros cheios delas) elaboradas no sentido deatacar alguma falha conhecida dos sistemas.
– Falta de leis efectivas no combate ao crime informático(concertação mundial).
É necessário proteger os nossos utilizadores da ‘poluição’exterior (e o exterior dos nossos utilizadores!).
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #3
Política de segurança
Politica de segurança a seguir– Sistemas “abertos” por omissão
• Se alguém descobrir que consegue fazer algo que não e suposto conseguir,não vai a correr avisar o administrador.
– Sistemas “fechados” por omissão• Se alguém não consegue fazer algo que é suposto conseguir, imediatamente
avisa o administrador.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #4
Medidas genéricas de protecçãoEndereços Públicos/PrivadosEndereços Públicos/Privados
Todos os pontos de acesso têm dois blocos deendereços– Público, com poucos endereços disponíveis, só deve ser
usado quando necessário (Serviços públicos), a coordenarcom a segurança implementada nos “routers”
– Privado, com muitos endereços disponíveis,comunicações intra escolas, com os servidores centrais,eventualmente inter escolas e para alguns serviços deacesso público
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #5
Medidas genéricas de protecçãoEndereços PrivadosEndereços Privados
Usar nas máquinas clientes internas um plano deendereçamento privado (RFC1918)– A Internet não sabe da existência deles (não são
anunciados). Mensagens destinadas a tais endereços nãosão encaminhadas para a rede interna.
Comunicações com o exterior– Agentes (Proxys) com endereços públicos servem de
intermediários.– Conversão automática de endereços (NAT) nos routers
‘fronteira’.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #6
Medidas genéricas de protecçãoEndereços PúblicosEndereços Públicos
O exterior de cada ponto de acesso só terá acesso ao interiorpara serviços específicos bem definidos
O acesso ao exterior é condicionado a serviços bemconhecidos para evitar “abusos” de serviço
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #7
Medidas genéricas de protecçãoDespoluição da RedeDespoluição da Rede
Impedir que mensagens com parâmetros ilegais circulem.– Não podem entrar na nossa rede mensagens cujo endereço origem
é da nossa rede (Protecção anti ‘spoof’ de IP).– Não devem sair da nossa rede mensagens com endereço:
• origem que não seja do bloco de endereços públicos legalmente atribuído.• origem: 224.0.0.0/4 ( Classe E, F e resto )• origem ou destino 127.0.0.0/8 (loopback), 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16 (RFC1918 Internal Networks), 169.254.0.0/16 (LocalLink)
– Mensagens que se transformem em broadcasts locais.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #8
Medidas genéricas de protecçãoConectividade das máquinas públicasConectividade das máquinas públicas
Devem ter conectividade única e somente para os serviçosque nelas correm ‘oficialmente.Devem correr os serviços estritamente necessários para odesempenho da sua função.
Para serviços simples pode-se recorrer a NAT paradisponibilizar conectividade a partir do exterior a serviços quecorram em máquinas de endereço interno.
Actualização atempada das máquinas com as correcções de‘bugs’ que afectem os serviços disponibilizadas pelosfabricantes.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #9
Medidas genéricas de protecçãoSegurança das máquinas clienteSegurança das máquinas cliente [1][1]
Um e-Mail que parece enviado por uma pessoa de confiançapode ser forjado (trivialmente!) ou ter sido enviado por um‘troiano’ instalado na máquina dele.Se quer ter a certeza da autenticidade/privacidade demensagens de e-Mail exija que estas sejam enviadas comassinatura digital e eventualmente cifradas (PGP).Desconfiar de actividades anormais de acesso a disco ecomunicações.
Manter instalado e actualizado um antivírus da nova geraçãoque intercepta inclusive as comunicações de rede.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #10
Medidas genéricas de protecçãoSegurança das máquinas clienteSegurança das máquinas cliente [2][2]
Não executar programas que não ofereçam garantias– Proibir a instalação de serviços desconhecidos ou desnecessários nas máquinas..
Especial atenção !– Sistemas “proxy” (Ex. Wingate)– Acessos “dialup” por modem / RDIS– Máquinas UNIX com áreas públicas– Máquinas com endereços do bloco público
Manter-se atento à divulgação de falhas de segurança eactualizações do software usado– “Maillist” BUGTRAQ http://www.securityfocus.com/forums/bugtraq/faq.html
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #11
Qualidade de ServiçoEvitar ‘Evitar ‘abusos’abusos’ nas comunicaçõesnas comunicações
Restringir para limites razoáveis os diversos tipos decomunicações.Tentar ‘equalizar’ o uso do recurso escasso que é a linhaexterior por todos os utilizadores e de acordo com umaheurística do interesse relativo.Ouvir as rádios da rede pode ter alguma piada, mas não maisque isso.– Usam a rede de uma forma ineficaz e abusadora.– A qualidade é significativamente pior que a obtida num receptor FM
(que não ocupa continuamente a linha exterior).
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #12
Qualidade de ServiçoOptimizar o uso da capacidade disponívelOptimizar o uso da capacidade disponível
Configuração coerente dos algoritmos de serviço das filas de esperados routers (scheduling/queueing).– A rede pode tratar o tráfego de forma diferenciada (finalmente os bits têm côr!)
• Escolha de caminhos.• Gestão das filas de espera.
– Adequação do serviço a aplicação• Precedence – Prioridade: 0 ... 7 (Crescente)• TOS – Tipo de Serviço: LowDelay, HighThroughput, LowCost, HighReliability
• Telnet: LowDelay, FTPControl: LowDelay, FTPData: HighThroughput, DNS:HighReliability
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #13
Qualidade de ServiçoUso do algoritmoUso do algoritmo token buckettoken bucket
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #14
Qualidade de ServiçoGestão das filas de espera com WFQGestão das filas de espera com WFQ
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #15
Qualidade de ServiçoOptimizar o uso da capacidade disponívelOptimizar o uso da capacidade disponível
Classificação do tráfego– Utilizador– Sistema
Evitar que os utilizadores abusem desta possibilidade, classificando oseu tráfego de forma a enganar o sistema.– Verificação da validade dos campos TOS/Precedence do tráfego IP alterando a
classificação em caso de abuso.
Futuro: As aplicações vão ter de passar a negociar explicitamente estascondições usando RSVP (Resource Reservation Protocol)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #16
Qualidade de ServiçoOO ProxyProxy -- Agente de comunicações HTTP/FTPAgente de comunicações HTTP/FTP
Tem conectividade com os clientes que usam endereços internos.Tem conectividade com o exterior.Os clientes ligam ao proxy, o proxy é que faz a ligação ao exterior.Conhece profundamente os protocolos HTTP/FTP– Pode tomar decisões baseadas nas informações das camadas superiores do
modelo OSI• Modelação do tráfego - traffic-shaping• Rejeição de comunicações
• Optimização das comunicações – caching
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #17
Qualidade de ServiçoOO ProxyProxy -- Agente de comunicações HTTP/FTPAgente de comunicações HTTP/FTP
Transporta de uma forma transparente as ligações seguras (https).Torna anónimos os clientes perante os servidores– Informações em excesso que os browsers enviam
• Versão do Sistema Operativo e Fabricante• Versão do browser e fabricante
• Outras
Realiza caching distribuído– Recurso a neighbours
• É mais rápido e económico ir buscar um objecto dentro da rede nacional que à origem(infelizmente inactivo devido ao desinteresse e falta de coordenação).
Devidamente configurado para que não possa ser usado como agentede clientes exteriores no acesso à rede interna.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #18
Sistema ProxySituação actualSituação actual
Máquina actual– 512Mbytes de RAM dos quais 384Mbytes reservados para cache
‘hot’.– Dois processadores PII333 (partilhados com outros serviços)– 4Gb de cache em disco UW-SCSI-LVD
Máquina nova em preparação– 512Mbytes de RAM (ou mais ...)– Dual PIII500 (quase dedicados)– Cache com dois discos UDMA/66 (2Mbyte de RAM cache cada) de
capacidade 27Gb cada.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #19
Sistema ProxyConfiguração do acesso aoConfiguração do acesso ao proxyproxy
Por ordem de preferência decrescente– Automática – WPAD através do DHCP (IE5) – Só ISEL
– Script – IE4/IE5/Netscape• ISEL: http://www.isel.ipl.pt/proxy.pac• Escolas IPL: http://www.<escola>.ipl.pt/proxy.pac
– Manual – proxy.ipl.pt Porto:3128 para todos osprotocolos, têm de se colocar excepções ao uso de proxy,a afinar caso a caso:
• Ex: ISEL - *.isel.pt;*.ipl.pt;193.137.220.*;193.137.221.*;10.*
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #20
Sistema ProxyConfiguraçãoConfiguração –– CachingCaching
Não realiza caching de:– Conteúdos seguros – Método CONNECT– Dinâmicos - URL’s com ?,cgi-bin,.asp,.cgi,.dll– Explicitamente requerido pelo servidor – Pragma: no-cache– Excepção para a publicidade online (banners) que é cached como optimização.
Os objectos têm um critério de validade dependente de:– Cabeçalho Expires fornecido junto com o objecto na altura da carga.– Nome do objecto ( index.html, .txt, .gif, .jpg, etc. ).– Relação entre a data de carga do objecto e a de criação do mesmo.
Algoritmo de manutenção da cache (quando cheia):– LFUDA: Least Frequently Used with Dynamic Aging (actualmente configurado)– GDSF: Greedy-Dual Size Frequency– LRU: Least Recent Used
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #21
Sistema ProxyConfiguraçãoConfiguração –– Controlo de acessosControlo de acessos
É negado o uso do proxy para máquinas internas acederem aservidores internos (minimizar carga)
É negado o acesso a servidores internos realizado paraportos não standardDimensão máxima das mensagens enviadas pelos clientes(PUT/POST) de 2Mbyte.
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #22
Sistema ProxyUtilização deUtilização de traffic shapingtraffic shaping
Uso do algoritmo token bucket.– De segundo a segundo é colocado um token que dá
credito para R bytes (débito sustentado) no ‘balde’.– Se os tokens encherem o ‘balde’ de volume B
(dimensão de ‘rajada’), entornam fora e perdem-se.– Para cada N bytes a serem transferidos, é removida
a quantidade de tokens correspondente do ‘balde’.– Se não houver tokens no balde, espera-se até
existam ...
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #23
Sistema ProxyUtilização deUtilização de traffic shapingtraffic shaping
A cada grupo de clientes é atribuído:– Dimensão individual de ‘rajada’ (burst)
– Débito individual sustentado– Dimensão de ‘rajada’ por rede– Débito sustentado por rede
– Dimensão de ‘rajada’ do grupo– Débito sustentado do grupo
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #24
Sistema ProxyGrupos de clientes (Grupos de clientes (traffic shapingtraffic shaping))
Para detalhes das limitações aplicadas em tempo real consultar http://www.isel.ipl.pt/~squid/
Débitos em Kbytes/s, Dimensões de Rajada em KBytes
Grupos de Grupo Rede Indiv idual
Traffic Shaping Débito Rajada Débito Rajada Débito Rajada
TráfegoDesinteressante 1 4096 N/A N/A 0,2 4
AcessosSeguros 0,5 4096 N/A N/A 0,5 512
ISELDocentesForaHoras 64 2048 N/A N/A 32 512
ISELAlunosForaHoras 32 1024 N/A N/A 16 256
ISELAE 8 32000 16 8000 24 256
ISELDocentes 64 2048 32 1024 16 512
ISELAlunos 32 1024 24 512 6 256
ISCAL 32 512 8 8000 16 256
ESTC 32 512 8 8000 16 256
ESCS 32 512 8 8000 16 256
ESEL 32 512 8 8000 16 256
ESD 32 512 8 8000 16 256
ESM 32 512 8 8000 16 256
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #25
Sistema ProxySimulação: Carga de um ficheiroSimulação: Carga de um ficheiro
Débito limite da fonte32KBytes/sFicheiro de 5MBytesDimensão de rajada512KBytes(inicialmente ‘cheio’)Débito sustentado8KBytes/s
0
100
200
300
400
500
600
0 30 60 90 120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
Cré
dit
o(K
Byt
es)
0
5
10
15
20
25
30
35
0 30 60 90 120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
Déb
ito
(KB
ytes
/s)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #26
Sistema ProxySimulação: Navegação interactiva normalSimulação: Navegação interactiva normal
Rajada 512KBytesDébito sustentado8KBytes/sLimitação da fonte de32KBytes/s
0
100
200
300
400
500
600
0 30 60 90 120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
Tempo (s)
Cré
dito
(KB
ytes
/s)
0
5
10
15
20
25
30
35
0 30 60 90 120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
Tempo (s)
Déb
ito
(KB
ytes
/s)
0
100
200
300
400
500
600
700
800
900
0 30 60 90 120 150 180
210
240
270
300
330 360 390
420
450
480
510 540 570 600
630
660
690
Tempo (s)
Dim
ensã
odo
spe
dido
s(K
Byt
es)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #27
Sistema ProxySimulação: Reacção para diversosSimulação: Reacção para diversos prefisprefis ((ISELDocentesISELDocentes))
Evolução do Débito (ISELDocentes)(1 Transferencia limitada pela fonte a 64KBytes/s)
0
10
20
30
40
50
60
70
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tempo (s)
Déb
ito(K
Byt
es/s
)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #28
Sistema ProxySimulação: Reacção para diversosSimulação: Reacção para diversos prefisprefis (ESM)(ESM)
Evolução do Débito (ESM)(1 Transferencia limitada pela fonte a 64/14KBytes/s)
0
10
20
30
40
50
60
70
0 26 52 78 104
130
156
182
208
234
260
286
312
338
364
390
416
442
468
494
520
546
572
598
Tempo (s)
Déb
ito
(KB
ytes
/s)
64
14
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #29
Sistema ProxySimulação: Reacção para diversosSimulação: Reacção para diversos prefisprefis (AEISEL)(AEISEL)
Evolução do Débito (AEISEL)(1 Transferencia limitada pela fonte a 64KBytes/s)
0
10
20
30
40
50
60
70
0 74 148
222
296
370
444
518
592
666
740
814
888
962
1036
1110
1184
1258
1332
1406
1480
1554
1628
1702
1776
1850
Tempo (s)
Déb
ito
(KB
yte
s/s
)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #30
Sistema ProxyEstatísticas de utilização (amostra de um dia)Estatísticas de utilização (amostra de um dia)
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #31
Sistema ProxyEstatísticas de utilização (amostra de um dia)Estatísticas de utilização (amostra de um dia)
Period: Wed Apr 12 05:00:28 2000 - Thu Apr 13 04:59:42 2000 (23.99 hours)– Total requests: 515707 (21499 per hour)
TCP:– TCP total requests, i.e. HIT,MISS,EXPIRED,REFRESH,IMS,etc.: 515545– TCP_HITs (including IMS_HITs, excluding REFRESH and EXPIRED): 221909 (43%)– TCP_MISSs: 227455– TCP average elapsed time: 7985 ms (per request)
• on TCP_HITs: 1087 ms (per request)• on TCP_MISSs: 16550 ms (per request)
BYTES: (all)– Total 3114.832 Mbytes ( 3.04 Gbytes )– Greatest object was 39749.72 Kbytes:
������������ ������������������������������ �������� ���� !"���#$$%