O fluxo de informações na sociedade moderna a crescente e mais intenso a cada dia. Cada vez mais as ferramentas de tratamento da informação ou seja, os computadores, necessitam interconexão de forma a proporcionar acesso a dados importantes e serviços especializados. Neste contexto, as redes de computadores agem como catalizadores do processo de disseminação e tratamento da informação. A demanda por serviços distribuídos cresce a cada dia, fazendo com que as redes cresçam também. Muitas vezes este processo a rápido e desordenado, a entropia do sistema aumenta e seu controle torna-se uma tarefa árdua. Para que possa exercer maior controle sobre as redes de computadores o gerente da rede deve dispor de ferramentas (e métodos) de auxilio. Assim pode-se manter a prestação de serviços a que a rede se propõe. Em Gerencia de Redes, duas arquiteturas tem sido apontadas como "modelos" a serem adotados: a arquitetura OSI para gerencia de redes (OSINM) [DOT91] e a arquitetura INTERNET [SCH91]. Ambas arquiteturas consideram que os diferentes componentes inseridos no domínio de gerencia são capazes de emitir e decodificar mensagens de gerencia. Por outro lado, tem sido destacada a necessidade de gerenciar componentes que não suportam funções de gerencia ou que não possuem as mesmas funções de gerencia que o restante da rede, desta forma pretende-se que o sistema de gerencia da rede seja completo e confiável. O sistema especificado e prototipado se encaixa neste contexto pois orientado a gerencia de Redes Locais do tipo CSMA/CD que ainda não possuem funções de gerencia. Defende-se a ideia de que, a partir do tráfego gerado, pode-se inferir o perfil ou estado da rede, derivando ou antecipando os problemas da instalação que não poderiam ser detectados pelo administrador da rede de outra maneira [DOT90]. Assim sendo, uma estação da rede a escolhida para este trabalho. Esta estação captura o trafego da rede e o submete continuamente a um processo de analise que detecta as diversas situações anormais que podem ser verificadas nos padrões de trafego. As ocorrências de situações anormais, denominadas alarmes, são repassadas a um processo de diagnose. O processo de diagnose, contendo uma base de conhecimento em forma de regras e a descrição estrutural da rede, leva em conta estes alarmes para reconhecer o problema. Uma vez reconhecido o problema, formula-se um procedimento de cone* que a levado ao Gerente da Rede. O sistema foi especificado com o use de dois métodos formais: • Para especificar a interação, do sistema com o ambiente em que se insere foi usado o método CSP (Communicating Sequential Processes), proposto por Hoare em 1978 [H0A87] e reformulado também por Hoare em 1985 [H0A85]; • Para especificar o sistema em si, o funcionamento do processo de agregação de conhecimento, foi utilizado o método denotacional VDM (Vienna Development Method), [BJ078] e PON861. Para a construção do protótipo foram utilizadas as linguagens "C" e "PROLOG". Futuramente, quando inserido em um Domínio de Gerencia (segundo a terminologia OSI/ISO), este sistema poderá reportar os problemas que fogem ao escopo da base de conhecimento local para o Processo Gerente do Domínio que responder com os procedimentos de solução cabíveis a porção da rede gerenciada pelo sistema. / The information flow in the modern society becomes bigger and faster day by day. Aidding the task of information treating, the computers need to be interconnected in order to proportionate access to important data and specialized services. In this context, the computer networks are like catalyzers of the process of dissemination and treating of information. The demand for distributed services is increasing, making the computer networks increase too. Many times this growth is fast and disordered and the network control becomes a hard task. For achieving more control over the computer network, powerful tools and methods for problem solving must be provided to the Network Manager. With this, the services offered by the network can be kept running. In Network Management, two architectures have been pointed as "models" to be used: the OSI network management architecture (OSINM) [DOT91] and the INTERNET architecture [SCH91]. Both consider that every network component must be capable of sending and receiving management messages. However, there are many components that do not support management functions, or that have management functions that are distinct of the rest of the network. This different components must be managed because without this the management system would not be representative and trustworthy. The specified and prototyped system deals with the problem above boarded. It is oriented to the management of a CSMA/CD Local Area Networks that do not support management functions. The central idea is that, through traffic analysis, the network state can be obtained (or infered) and the problems arising in the network can be detected or even predicted. A network station is chosen to perform this task. This station gathers all traffic and submit it continuously to an analysis process that detects the different anormal situations over the network. The occurrences of anormal situations, called alarms, feeds a diagnosis process. This process has a knowledge base with rules and the structural description of the network, it uses this knowledge and the alarms to recognize the network problems. Once the problems are recognized, the system is ready for advise the possible corrections to the Network Manager. The system was specified using two formal methods: To specify the interaction of the system with the environment in which it is embeeded was used CSP (Communicating Sequential Processes), proposed by Hoare in 1978 [HOA87] and reformulated by Hoare too in 1985 [H0A85]; To specify the software, the way the knowledge aggregation task acts, was used the denotational method VDM (Vienna Development Method), [BJ078] and [JON86]. For the prototyping were used the languages "C" and PROLOG. In the future, when embeded in a Management Domain, this system will be capable of reporting the problems that are not treated by the local knowledge base (or that are not in the scope of the system) to the Management Process of the domain. The Management Process will give some advising and the local system will obey to it.

Embora firewall seja um assunto bastante discutido na área de segurança da informação, existem lacunas em termos de verificação de firewalls. Verificações de firewalls têm o intuito de garantir a correta implementação dos mecanismos de filtragem e podem ser realizadas em diferentes níveis: sintaxe das regras; conformidade com a política; e relacionamento entre as regras. Os aspectos referentes a erros de sintaxe das regras são geralmente tratados pela ferramenta de filtragem em uso. O segundo nível, no entanto, depende da existência de uma política formal e documentada, algo não encontrado na maioria das organizações, e de uma metodologia eficaz que, através da entrada da política de segurança e do conjunto de regras de firewall implementado, possa comparálas e apontar as discrepâncias lógicas entre a especificação (política) e a implementação (regras). O último, verificação dos relacionamentos entre regras, não requer qualquer documentação, uma vez que somente o conjunto de regras do firewall é necessário para a identificação de incoerências entre elas.Baseado nessas considerações, este trabalho objetivou o estudo e a definição de uma metodologia para a análise de relacionamentos entre regras, apontando erros e possíveis falhas de configuração. Três metodologias já existentes foram estudadas, analisadas e utilizadas como base inicial para uma nova metodologia que atingisse os requisitos descritos neste trabalho. Para garantir a efetividade da nova metodologia, uma ferramenta protótipo foi implementada e aplicada a três estudos de caso. / Although firewalls are a well discussed issue in the information security field, there are gaps in terms of firewall verification. Firewall verification is aimed at enforce the correct filtering mecanisms implementation and can be executed in three distinct levels: rules syntax, policy compliance and rules relationship. The aspects related to rule syntax errors are usually addressed by the filtering tool in use. However, the second level depends on the existance of a formalized and documented policy, something not usual in most organizations, and on an efficient metodology that, receiving the security policy and the firewall rules set as inputs, could compare them and point logical discrepancies between the specification (policy) and the implementation (rules set). The last level, rules relationship verification, doesn't require any previous documentation, indeed only the firewall rule set is required to conduct a process of rules incoherencies identification. Based on those considerations, this work aimed at studying and defining a methodology for analysis of rules relationships, pointing errors and possible misconfigurations. Three already existent methodologies were studied, analyzed and used as a initial foundation to a new methodology that achieve the requirements described in this work. To assure the effectivity of the new methodology, a prototype tool were implemented and applied to three case studies.

Embora firewall seja um assunto bastante discutido na área de segurança da informação, existem lacunas em termos de verificação de firewalls. Verificações de firewalls têm o intuito de garantir a correta implementação dos mecanismos de filtragem e podem ser realizadas em diferentes níveis: sintaxe das regras; conformidade com a política; e relacionamento entre as regras. Os aspectos referentes a erros de sintaxe das regras são geralmente tratados pela ferramenta de filtragem em uso. O segundo nível, no entanto, depende da existência de uma política formal e documentada, algo não encontrado na maioria das organizações, e de uma metodologia eficaz que, através da entrada da política de segurança e do conjunto de regras de firewall implementado, possa comparálas e apontar as discrepâncias lógicas entre a especificação (política) e a implementação (regras). O último, verificação dos relacionamentos entre regras, não requer qualquer documentação, uma vez que somente o conjunto de regras do firewall é necessário para a identificação de incoerências entre elas.Baseado nessas considerações, este trabalho objetivou o estudo e a definição de uma metodologia para a análise de relacionamentos entre regras, apontando erros e possíveis falhas de configuração. Três metodologias já existentes foram estudadas, analisadas e utilizadas como base inicial para uma nova metodologia que atingisse os requisitos descritos neste trabalho. Para garantir a efetividade da nova metodologia, uma ferramenta protótipo foi implementada e aplicada a três estudos de caso. / Although firewalls are a well discussed issue in the information security field, there are gaps in terms of firewall verification. Firewall verification is aimed at enforce the correct filtering mecanisms implementation and can be executed in three distinct levels: rules syntax, policy compliance and rules relationship. The aspects related to rule syntax errors are usually addressed by the filtering tool in use. However, the second level depends on the existance of a formalized and documented policy, something not usual in most organizations, and on an efficient metodology that, receiving the security policy and the firewall rules set as inputs, could compare them and point logical discrepancies between the specification (policy) and the implementation (rules set). The last level, rules relationship verification, doesn't require any previous documentation, indeed only the firewall rule set is required to conduct a process of rules incoherencies identification. Based on those considerations, this work aimed at studying and defining a methodology for analysis of rules relationships, pointing errors and possible misconfigurations. Three already existent methodologies were studied, analyzed and used as a initial foundation to a new methodology that achieve the requirements described in this work. To assure the effectivity of the new methodology, a prototype tool were implemented and applied to three case studies.

Embora firewall seja um assunto bastante discutido na área de segurança da informação, existem lacunas em termos de verificação de firewalls. Verificações de firewalls têm o intuito de garantir a correta implementação dos mecanismos de filtragem e podem ser realizadas em diferentes níveis: sintaxe das regras; conformidade com a política; e relacionamento entre as regras. Os aspectos referentes a erros de sintaxe das regras são geralmente tratados pela ferramenta de filtragem em uso. O segundo nível, no entanto, depende da existência de uma política formal e documentada, algo não encontrado na maioria das organizações, e de uma metodologia eficaz que, através da entrada da política de segurança e do conjunto de regras de firewall implementado, possa comparálas e apontar as discrepâncias lógicas entre a especificação (política) e a implementação (regras). O último, verificação dos relacionamentos entre regras, não requer qualquer documentação, uma vez que somente o conjunto de regras do firewall é necessário para a identificação de incoerências entre elas.Baseado nessas considerações, este trabalho objetivou o estudo e a definição de uma metodologia para a análise de relacionamentos entre regras, apontando erros e possíveis falhas de configuração. Três metodologias já existentes foram estudadas, analisadas e utilizadas como base inicial para uma nova metodologia que atingisse os requisitos descritos neste trabalho. Para garantir a efetividade da nova metodologia, uma ferramenta protótipo foi implementada e aplicada a três estudos de caso. / Although firewalls are a well discussed issue in the information security field, there are gaps in terms of firewall verification. Firewall verification is aimed at enforce the correct filtering mecanisms implementation and can be executed in three distinct levels: rules syntax, policy compliance and rules relationship. The aspects related to rule syntax errors are usually addressed by the filtering tool in use. However, the second level depends on the existance of a formalized and documented policy, something not usual in most organizations, and on an efficient metodology that, receiving the security policy and the firewall rules set as inputs, could compare them and point logical discrepancies between the specification (policy) and the implementation (rules set). The last level, rules relationship verification, doesn't require any previous documentation, indeed only the firewall rule set is required to conduct a process of rules incoherencies identification. Based on those considerations, this work aimed at studying and defining a methodology for analysis of rules relationships, pointing errors and possible misconfigurations. Three already existent methodologies were studied, analyzed and used as a initial foundation to a new methodology that achieve the requirements described in this work. To assure the effectivity of the new methodology, a prototype tool were implemented and applied to three case studies.

Redes de computadores estão sob constante ameaça, ainda mais quando conectadas à Internet. Para reduzir o risco, dispositivos de segurança como o filtro de pacotes são usados. Uma primeira camada de segurança, o filtro de pacotes é responsável pelo bloqueio do tráfego indesejado em posições chave da rede. Os pacotes que devem ser permitidos ou bloqueados pelo filtro são definidos através de um conjunto de regras programadas pelo administrador da rede. Essas regras tem duas partes: a seleção e a ação. Conforme cresce a rede e o número de serviços, a quantidade de regras tende a aumentar. Passado certo limite, a complexidade de manter uma quantidade grande de regras se torna um fardo para o administrador. Isso aumenta a probabilidade de enganos que podem prejudicar a segurança da rede. Este trabalho desenvolve o conceito de “anomalia”, cada qual representa um problema em potencial, uma contradição ou uma regra supérflua dentro do conjunto de regras; ou seja, cada anomalia alerta o administrador da rede para determinada situação. Há 7 tipos de anomalias, que podem ser divididos em dois grupos: anomalias de filtro único e anomalias em rede. As anomalias de filtro único alertam o administrador sobre regras que se contradizem (“bloqueio”) ou que não possuem efeito no filtro (“invisibilidade” e “redundância”). As anomalias em rede, por sua vez, alertam o administrador sobre filtros que se contradizem (“discordância”), filtros que bloqueiam tráfego desejado (“bloqueio”), regras que não se aplicam a nenhum pacote que passe pelo filtro onde estão (“irrelevância”) e roteadores que permitem a passagem de tráfego indesejado (“vazamento”). Cada um desses tipos de anomalia é definido formalmente e apresentado junto com um algoritmo que a encontra. As anomalias e seus algoritmos foram usados para implementar uma ferramenta, o Packet Filter Checker (PFC), que lê as regras e a descrição da topologia da rede e cria um relatório com todas as anomalias presentes. Este trabalho apresenta um caso de uso fictício que é analisado e corrigido com base nos resultados apresentados pela ferramenta. O caso de uso é apresentado em diversas iterações, cada uma representando alterações nos requisitos da rede. Este caso mostra a ferramenta e os conceitos no contexto-alvo: na ajuda ao administrador da rede. / Computer networks are under constant threat, even more when connected to the Internet. To decrease the risk of invasions and downtime, security devices such as the packet filter are deployed. As a first layer of security, the packet filter is responsible for blocking out unwanted traffic at key network locations. The packets dropped or forwarded by the filter are defined by a set of rules programmed by the network administrator. These rules are in the form of guarded commands, each with a condition and a decision section. As the number of services and networks grow, the number of rules tend to grow as well. Beyond a certain threshold, the complexity of maintaining such a large and distributed set of rules becomes a burden for the network administrator. Mistakes can be easily made, compromising security. This work develops the concept of “anomaly”, each representing a potential problem, a contradiction or a superfluous rule in the rule set; i.e. a warning to the system administrator. There are 7 types of anomalies divided in two groups: single filter anomalies and networked anomalies. The single-filter anomalies warns the administrator about rules that contradict one another (the “conflict” anomaly) or have no effect (“invisibility” and “redundancy”) in the analysed filter. The networked anomalies, on the other hand, analyse the filters in the context of the network topology and warn the administrator about filters that contradict one another (“disagreement”), filters that block desired traffic (“blocking”), rules that have no effect on the given network topology (“irrelevancy”) and routers that are enabling unwanted traffic (“leaking”). Each type of anomaly is formally defined along with its algorithm. The developed concepts were used to implement a tool — the Packet Filter Checker (PFC) — that reads a description of the rules and network topology in a simple custom language and reports all anomalies present. This tool is used to analyse and fix a fictional user case in several iterations of changing requirements. This shows the tool and the anomalies in the target context: where they help the network administrator.

Uma das tendências para o aumento do desempenho dos sistemas de computação atuais tem sido a distribuição do processamento em uma rede de computadores. Já foram pesquisados diversos modelos para obter essa distribuição, e um dos que tem se mostrado mais promissor é aquele no qual o controle da distribuição é efetuado diretamente pelo sistema operacional. Um sistema operacional desse tipo é chamado de sistema operacional distribuído[TAN85], e seu principal objetivo e fornecer a seus usuários a ilusão de uma maquina uniprocessadora constituída pela soma dos recursos oferecidos pelos componentes da rede. A forma de realizar tal ilusão é o sistema operacional controlar a utilização dos recursos distribuídos para o usuário, independentemente de onde estejam localizados, a medida que sejam requisitados e estejam disponíveis. Esta sendo desenvolvido no CPGCC da UFRGS o projeto DIX, cujo objetivo é o desenvolvimento de um Sistema Operacional Distribuído. Para o desenvolvimento desse projeto, foi tornado como base o sistema operacional MINIX. As principais razoes dessa opção foram: o alto grau de modularidade do MINIX, a utilização do paradigma de troca de mensagens para comunicação entre processos e a sua disponibilidade. A plataforma de hardware inicial para o desenvolvimento do projeto é um grupo de estações de trabalho Proceda. Tais estações caracterizam-se por possuir internamente dois elementos processadores distintos. O projeto DIX teve inicio com o porte do sistema operacional MINIX para o ambiente multiprocessador heterogêneo das estações. Devido a necessidade de comunicação entre as estações e a indisponibilidade de hardware adequado para tal, foi desenvolvida uma forma alternativa de comunicação, baseada na utilização da interface paralela existente nas estações. Este trabalho descreve o núcleo do sistema operacional. A filosofia adotada foi torná-lo o mais simples possível, colocando em processos servidores, externos ao núcleo, grande parte das tarefas. Outro objetivo foi alterar o mínimo possível a interface original do MINIX, para que as camadas superiores do sistema continuassem em funcionamento. Dessa forma, a principal função do núcleo é fornecer aos processos mecanismos para troca de mensagens e transferência de dados entre processos. Foi desenvolvido um método para a identificação global dos processos, que permite identificar cada processo do sistema de forma unívoca e um mecanismo de comunicação entre processos que suporta transparência de localidade, migração de processos e falhas em nodos da rede. / One of the modern trends in Computer Science has been the use of distribution to improve system performance. Many models of distribution have been proposed, and the most promising one is that in which the distribution is directly controlled by the operating system. Such type of system is called a distributed operating system[TAN85], and its main goal is to provide its users an illusion of an uniprocessor system more powerful than its components. The operating system controls the utilization of the distributed resources in a transparent way, in order to present such illusion to its users. There is a project, named DIX, under development at CPGCC/UFRGS, whose goal is to gather experience in the field while developing a distributed operating system. The MINIX operating system has been chosen as a software basis for the project, because of its high degree of modularity, its message passing IPC paradigm and the availability of its source code. The initial hardware configuration is a set of Proceda workstations. Those workstations have two distincts processors that can run in parallel. The project was started with the porting of MINIX to the workstations' heterogeneous multiprocessor environment. Due to the need of information exchange among the workstations and to the unavailability of suitable communication hardware, an alternative communication scheme was developed. This work describes the kernel of the operating system. The adopted methodology was to keep it as simple as possible, putting a great number of tasks in server processes outside the kernel. Another goal was to preserve the MINIX original interface, so that the upper layers of the system could remain functional. So, the main purpose of the kernel is to supply an efficient message exchange mechanism. That mechanism supports locality transparency: the sender of a message is not aware of the destination location, and it is even possible that processes migrate. A method has been developed for the global unique identification of processes.

Redes de computadores estão sob constante ameaça, ainda mais quando conectadas à Internet. Para reduzir o risco, dispositivos de segurança como o filtro de pacotes são usados. Uma primeira camada de segurança, o filtro de pacotes é responsável pelo bloqueio do tráfego indesejado em posições chave da rede. Os pacotes que devem ser permitidos ou bloqueados pelo filtro são definidos através de um conjunto de regras programadas pelo administrador da rede. Essas regras tem duas partes: a seleção e a ação. Conforme cresce a rede e o número de serviços, a quantidade de regras tende a aumentar. Passado certo limite, a complexidade de manter uma quantidade grande de regras se torna um fardo para o administrador. Isso aumenta a probabilidade de enganos que podem prejudicar a segurança da rede. Este trabalho desenvolve o conceito de “anomalia”, cada qual representa um problema em potencial, uma contradição ou uma regra supérflua dentro do conjunto de regras; ou seja, cada anomalia alerta o administrador da rede para determinada situação. Há 7 tipos de anomalias, que podem ser divididos em dois grupos: anomalias de filtro único e anomalias em rede. As anomalias de filtro único alertam o administrador sobre regras que se contradizem (“bloqueio”) ou que não possuem efeito no filtro (“invisibilidade” e “redundância”). As anomalias em rede, por sua vez, alertam o administrador sobre filtros que se contradizem (“discordância”), filtros que bloqueiam tráfego desejado (“bloqueio”), regras que não se aplicam a nenhum pacote que passe pelo filtro onde estão (“irrelevância”) e roteadores que permitem a passagem de tráfego indesejado (“vazamento”). Cada um desses tipos de anomalia é definido formalmente e apresentado junto com um algoritmo que a encontra. As anomalias e seus algoritmos foram usados para implementar uma ferramenta, o Packet Filter Checker (PFC), que lê as regras e a descrição da topologia da rede e cria um relatório com todas as anomalias presentes. Este trabalho apresenta um caso de uso fictício que é analisado e corrigido com base nos resultados apresentados pela ferramenta. O caso de uso é apresentado em diversas iterações, cada uma representando alterações nos requisitos da rede. Este caso mostra a ferramenta e os conceitos no contexto-alvo: na ajuda ao administrador da rede. / Computer networks are under constant threat, even more when connected to the Internet. To decrease the risk of invasions and downtime, security devices such as the packet filter are deployed. As a first layer of security, the packet filter is responsible for blocking out unwanted traffic at key network locations. The packets dropped or forwarded by the filter are defined by a set of rules programmed by the network administrator. These rules are in the form of guarded commands, each with a condition and a decision section. As the number of services and networks grow, the number of rules tend to grow as well. Beyond a certain threshold, the complexity of maintaining such a large and distributed set of rules becomes a burden for the network administrator. Mistakes can be easily made, compromising security. This work develops the concept of “anomaly”, each representing a potential problem, a contradiction or a superfluous rule in the rule set; i.e. a warning to the system administrator. There are 7 types of anomalies divided in two groups: single filter anomalies and networked anomalies. The single-filter anomalies warns the administrator about rules that contradict one another (the “conflict” anomaly) or have no effect (“invisibility” and “redundancy”) in the analysed filter. The networked anomalies, on the other hand, analyse the filters in the context of the network topology and warn the administrator about filters that contradict one another (“disagreement”), filters that block desired traffic (“blocking”), rules that have no effect on the given network topology (“irrelevancy”) and routers that are enabling unwanted traffic (“leaking”). Each type of anomaly is formally defined along with its algorithm. The developed concepts were used to implement a tool — the Packet Filter Checker (PFC) — that reads a description of the rules and network topology in a simple custom language and reports all anomalies present. This tool is used to analyse and fix a fictional user case in several iterations of changing requirements. This shows the tool and the anomalies in the target context: where they help the network administrator.

Redes de computadores estão sob constante ameaça, ainda mais quando conectadas à Internet. Para reduzir o risco, dispositivos de segurança como o filtro de pacotes são usados. Uma primeira camada de segurança, o filtro de pacotes é responsável pelo bloqueio do tráfego indesejado em posições chave da rede. Os pacotes que devem ser permitidos ou bloqueados pelo filtro são definidos através de um conjunto de regras programadas pelo administrador da rede. Essas regras tem duas partes: a seleção e a ação. Conforme cresce a rede e o número de serviços, a quantidade de regras tende a aumentar. Passado certo limite, a complexidade de manter uma quantidade grande de regras se torna um fardo para o administrador. Isso aumenta a probabilidade de enganos que podem prejudicar a segurança da rede. Este trabalho desenvolve o conceito de “anomalia”, cada qual representa um problema em potencial, uma contradição ou uma regra supérflua dentro do conjunto de regras; ou seja, cada anomalia alerta o administrador da rede para determinada situação. Há 7 tipos de anomalias, que podem ser divididos em dois grupos: anomalias de filtro único e anomalias em rede. As anomalias de filtro único alertam o administrador sobre regras que se contradizem (“bloqueio”) ou que não possuem efeito no filtro (“invisibilidade” e “redundância”). As anomalias em rede, por sua vez, alertam o administrador sobre filtros que se contradizem (“discordância”), filtros que bloqueiam tráfego desejado (“bloqueio”), regras que não se aplicam a nenhum pacote que passe pelo filtro onde estão (“irrelevância”) e roteadores que permitem a passagem de tráfego indesejado (“vazamento”). Cada um desses tipos de anomalia é definido formalmente e apresentado junto com um algoritmo que a encontra. As anomalias e seus algoritmos foram usados para implementar uma ferramenta, o Packet Filter Checker (PFC), que lê as regras e a descrição da topologia da rede e cria um relatório com todas as anomalias presentes. Este trabalho apresenta um caso de uso fictício que é analisado e corrigido com base nos resultados apresentados pela ferramenta. O caso de uso é apresentado em diversas iterações, cada uma representando alterações nos requisitos da rede. Este caso mostra a ferramenta e os conceitos no contexto-alvo: na ajuda ao administrador da rede. / Computer networks are under constant threat, even more when connected to the Internet. To decrease the risk of invasions and downtime, security devices such as the packet filter are deployed. As a first layer of security, the packet filter is responsible for blocking out unwanted traffic at key network locations. The packets dropped or forwarded by the filter are defined by a set of rules programmed by the network administrator. These rules are in the form of guarded commands, each with a condition and a decision section. As the number of services and networks grow, the number of rules tend to grow as well. Beyond a certain threshold, the complexity of maintaining such a large and distributed set of rules becomes a burden for the network administrator. Mistakes can be easily made, compromising security. This work develops the concept of “anomaly”, each representing a potential problem, a contradiction or a superfluous rule in the rule set; i.e. a warning to the system administrator. There are 7 types of anomalies divided in two groups: single filter anomalies and networked anomalies. The single-filter anomalies warns the administrator about rules that contradict one another (the “conflict” anomaly) or have no effect (“invisibility” and “redundancy”) in the analysed filter. The networked anomalies, on the other hand, analyse the filters in the context of the network topology and warn the administrator about filters that contradict one another (“disagreement”), filters that block desired traffic (“blocking”), rules that have no effect on the given network topology (“irrelevancy”) and routers that are enabling unwanted traffic (“leaking”). Each type of anomaly is formally defined along with its algorithm. The developed concepts were used to implement a tool — the Packet Filter Checker (PFC) — that reads a description of the rules and network topology in a simple custom language and reports all anomalies present. This tool is used to analyse and fix a fictional user case in several iterations of changing requirements. This shows the tool and the anomalies in the target context: where they help the network administrator.

Uma das tendências para o aumento do desempenho dos sistemas de computação atuais tem sido a distribuição do processamento em uma rede de computadores. Já foram pesquisados diversos modelos para obter essa distribuição, e um dos que tem se mostrado mais promissor é aquele no qual o controle da distribuição é efetuado diretamente pelo sistema operacional. Um sistema operacional desse tipo é chamado de sistema operacional distribuído[TAN85], e seu principal objetivo e fornecer a seus usuários a ilusão de uma maquina uniprocessadora constituída pela soma dos recursos oferecidos pelos componentes da rede. A forma de realizar tal ilusão é o sistema operacional controlar a utilização dos recursos distribuídos para o usuário, independentemente de onde estejam localizados, a medida que sejam requisitados e estejam disponíveis. Esta sendo desenvolvido no CPGCC da UFRGS o projeto DIX, cujo objetivo é o desenvolvimento de um Sistema Operacional Distribuído. Para o desenvolvimento desse projeto, foi tornado como base o sistema operacional MINIX. As principais razoes dessa opção foram: o alto grau de modularidade do MINIX, a utilização do paradigma de troca de mensagens para comunicação entre processos e a sua disponibilidade. A plataforma de hardware inicial para o desenvolvimento do projeto é um grupo de estações de trabalho Proceda. Tais estações caracterizam-se por possuir internamente dois elementos processadores distintos. O projeto DIX teve inicio com o porte do sistema operacional MINIX para o ambiente multiprocessador heterogêneo das estações. Devido a necessidade de comunicação entre as estações e a indisponibilidade de hardware adequado para tal, foi desenvolvida uma forma alternativa de comunicação, baseada na utilização da interface paralela existente nas estações. Este trabalho descreve o núcleo do sistema operacional. A filosofia adotada foi torná-lo o mais simples possível, colocando em processos servidores, externos ao núcleo, grande parte das tarefas. Outro objetivo foi alterar o mínimo possível a interface original do MINIX, para que as camadas superiores do sistema continuassem em funcionamento. Dessa forma, a principal função do núcleo é fornecer aos processos mecanismos para troca de mensagens e transferência de dados entre processos. Foi desenvolvido um método para a identificação global dos processos, que permite identificar cada processo do sistema de forma unívoca e um mecanismo de comunicação entre processos que suporta transparência de localidade, migração de processos e falhas em nodos da rede. / One of the modern trends in Computer Science has been the use of distribution to improve system performance. Many models of distribution have been proposed, and the most promising one is that in which the distribution is directly controlled by the operating system. Such type of system is called a distributed operating system[TAN85], and its main goal is to provide its users an illusion of an uniprocessor system more powerful than its components. The operating system controls the utilization of the distributed resources in a transparent way, in order to present such illusion to its users. There is a project, named DIX, under development at CPGCC/UFRGS, whose goal is to gather experience in the field while developing a distributed operating system. The MINIX operating system has been chosen as a software basis for the project, because of its high degree of modularity, its message passing IPC paradigm and the availability of its source code. The initial hardware configuration is a set of Proceda workstations. Those workstations have two distincts processors that can run in parallel. The project was started with the porting of MINIX to the workstations' heterogeneous multiprocessor environment. Due to the need of information exchange among the workstations and to the unavailability of suitable communication hardware, an alternative communication scheme was developed. This work describes the kernel of the operating system. The adopted methodology was to keep it as simple as possible, putting a great number of tasks in server processes outside the kernel. Another goal was to preserve the MINIX original interface, so that the upper layers of the system could remain functional. So, the main purpose of the kernel is to supply an efficient message exchange mechanism. That mechanism supports locality transparency: the sender of a message is not aware of the destination location, and it is even possible that processes migrate. A method has been developed for the global unique identification of processes.

Uma das tendências para o aumento do desempenho dos sistemas de computação atuais tem sido a distribuição do processamento em uma rede de computadores. Já foram pesquisados diversos modelos para obter essa distribuição, e um dos que tem se mostrado mais promissor é aquele no qual o controle da distribuição é efetuado diretamente pelo sistema operacional. Um sistema operacional desse tipo é chamado de sistema operacional distribuído[TAN85], e seu principal objetivo e fornecer a seus usuários a ilusão de uma maquina uniprocessadora constituída pela soma dos recursos oferecidos pelos componentes da rede. A forma de realizar tal ilusão é o sistema operacional controlar a utilização dos recursos distribuídos para o usuário, independentemente de onde estejam localizados, a medida que sejam requisitados e estejam disponíveis. Esta sendo desenvolvido no CPGCC da UFRGS o projeto DIX, cujo objetivo é o desenvolvimento de um Sistema Operacional Distribuído. Para o desenvolvimento desse projeto, foi tornado como base o sistema operacional MINIX. As principais razoes dessa opção foram: o alto grau de modularidade do MINIX, a utilização do paradigma de troca de mensagens para comunicação entre processos e a sua disponibilidade. A plataforma de hardware inicial para o desenvolvimento do projeto é um grupo de estações de trabalho Proceda. Tais estações caracterizam-se por possuir internamente dois elementos processadores distintos. O projeto DIX teve inicio com o porte do sistema operacional MINIX para o ambiente multiprocessador heterogêneo das estações. Devido a necessidade de comunicação entre as estações e a indisponibilidade de hardware adequado para tal, foi desenvolvida uma forma alternativa de comunicação, baseada na utilização da interface paralela existente nas estações. Este trabalho descreve o núcleo do sistema operacional. A filosofia adotada foi torná-lo o mais simples possível, colocando em processos servidores, externos ao núcleo, grande parte das tarefas. Outro objetivo foi alterar o mínimo possível a interface original do MINIX, para que as camadas superiores do sistema continuassem em funcionamento. Dessa forma, a principal função do núcleo é fornecer aos processos mecanismos para troca de mensagens e transferência de dados entre processos. Foi desenvolvido um método para a identificação global dos processos, que permite identificar cada processo do sistema de forma unívoca e um mecanismo de comunicação entre processos que suporta transparência de localidade, migração de processos e falhas em nodos da rede. / One of the modern trends in Computer Science has been the use of distribution to improve system performance. Many models of distribution have been proposed, and the most promising one is that in which the distribution is directly controlled by the operating system. Such type of system is called a distributed operating system[TAN85], and its main goal is to provide its users an illusion of an uniprocessor system more powerful than its components. The operating system controls the utilization of the distributed resources in a transparent way, in order to present such illusion to its users. There is a project, named DIX, under development at CPGCC/UFRGS, whose goal is to gather experience in the field while developing a distributed operating system. The MINIX operating system has been chosen as a software basis for the project, because of its high degree of modularity, its message passing IPC paradigm and the availability of its source code. The initial hardware configuration is a set of Proceda workstations. Those workstations have two distincts processors that can run in parallel. The project was started with the porting of MINIX to the workstations' heterogeneous multiprocessor environment. Due to the need of information exchange among the workstations and to the unavailability of suitable communication hardware, an alternative communication scheme was developed. This work describes the kernel of the operating system. The adopted methodology was to keep it as simple as possible, putting a great number of tasks in server processes outside the kernel. Another goal was to preserve the MINIX original interface, so that the upper layers of the system could remain functional. So, the main purpose of the kernel is to supply an efficient message exchange mechanism. That mechanism supports locality transparency: the sender of a message is not aware of the destination location, and it is even possible that processes migrate. A method has been developed for the global unique identification of processes.