A Rede Informática do ISEL e do IPL Introdução

16
2000/13/04 Nuno Cruz / Pedro Ribeiro / Vítor Almeida #1 A Rede Informática do ISEL e do IPL Segurança e Segurança e Qualidade de Serviço Qualidade de Serviço Nuno Cruz Pedro Ribeiro Ví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 de atacar 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!).

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:

������������ ������������������������������ �������� ���� !"���#$$%