iptables (커널 2.4대의 방화벽 관리도구)

 커널 2.4대에서 방화벽, 규칙 설정, IP 매스커레이딩을 조정하는 커널 도구

 iptables -[ADC] chain 상세룰 [옵션]
 iptables -[RI] chain 룰번호 상세룰 [옵션]
 iptables -D chain 룰번호 [옵션]
 iptables -[LFZ] [chain] [옵션]
 iptables -[NX] chain
 iptables -E 이번체인이름 새로운체인이름
 iptables -P chain target [옵션]
 iptables -h

 -A chain, –append chain : chain을 추가한다.
 -D chain, –delete chain : chain에서 룰을 삭제한다.
 -D chain 룰넘버, –delete chain 룰넘버 : chain 정책 중 지정한 룰넘버를 삭제한다. 만일 룰넘버가 1이라면 chain 규칙의 첫 번째 룰을 삭제한다.
 -I chain [룰넘버], –insert chain [룰넘버] : chain 정책에 지정한 숫자번째에 삽입하거나, 마지막에 룰을 삽입한다.
 -R chain 룰넘버, –relace : chain 정책 중 지정한 숫자번째의 룰을 교체한다.
 -L [chain], –list [chain] 모든 chain 정책을 보거나, 지정한 chain 정책을 본다.
 -F [chain], –flush : 모든 chain 정책을 삭제하거나, 지정한 chain 정책을 삭제한다.
 -Z [chain], –zero : 모든 chain 정책을 제로로 만들거나, 지정한 chain 정책을 제로로 만든다.
 -C chain, –check chain : 설정한 chain 정책을 테스트한다.
 -N chain, –new-chain : 새로운 정책을 만든다.
 -X [chain], –delete-chain : 사용자가 만든 chain이나 모든 chain을 삭제한다.
 -P chain target, –policy chain target : chain 정책을 지정한 chain 정책으로 바꾼다.
 -E old-chain new-chain, –rename-chain old-chain new-chain : chain명을 바꾼다.
 -p, –protocol [!] proto : 프로토콜을 지정한다. !은 제외의 의미이다.
 -s, –source [!] address[/mask] : 출발지 주소를 지정한다. mask는 C클래스면 255.255.255.0이나 24비트로 표현된다.
 -d, –destination [!] address[/mask] : 목적지 주소를 지정한다.
 -i, –in-interface [!] input name[+] 수신하는 네트워크 인터페이스 이름을 지정한다. name+은 name으로 시작하는 모든 인터페이스 이름이다.
 -j –jump target : 지정하는 target으로 리다이렉트 시킨다.
 -m : 지정한 match로 확장이 가능하다.
 -n : IP주소와 포트번호를 숫자 그대로 보여준다.
 -o, –out-interface [!] output name[+] : 발신하는 네트워크 인터페이스 이름을 지정한다.
 -v, –verbose : 상세한 정보를 보여준다.
 –line-numbers : 룰정책을 보여줄 때 줄번호도 나타낸다.
 -x, –exact : 정확한 값으로 나타낸다.
 -V, –version : 버전 정보를 보여준다.

 iptables는 netfilter 필터링 룰에 사용한다. 대부분 ipchains와 사용법이 거의 같으나, 가장 큰 차이점은 확장성에 있다. 정상적으로 커널 확장은 커널 모듈 하부 디렉토리(/lib/modules/커널버전/kernel/net)에 존재하는데, iptables는 요구에 의하여 적재된다. 그래서, 아들 모듈을 직접 적재할 필요는 없다. iptables의 확장들은 공유 라이브러리 형태로 보통 /usr/local/lib/iptables 에 위치한다. 배포판은 이것을 /lib/tables나 /usr/lib/tables 에 넣으려 할 것이다.

User image 우분투 8.10-Desktop 의 경우 /lib/iptables 밑에 존재한다.

 ipchain이 iptables에서 변경된 사항들은 다음과 같다.

 * 미리 만들어진 체인 이름 (input, output, forward)가 소문자에서 대문자로 바뀌었다.

 * -i 지시자는 들어오는 인터페이스만 의미하고 INPUT과 FORWARD chain에서만 작동한다. FORWARD나 OUTPUT chain은 -o 로 사용한다.

 * TCP와 UDP 포트는 –source-port, –sport (–destination-port, –dport)과 사용하게 된다. -p tcp 또는 -p udp 옵션과 함께 사용되어져야 한다.

 * TCP -y 지시자는 –syn 으로 바뀌었고 -p tcp 다음에 와야한다.

 * DENY target 는 DROP으로 바뀌었다.

 * iptables 를 이용하여 정책들을 입력하였다면, 이는 메모리에 적재될 뿐이므로 시스템을 다시 시작한 후에는 모두 사라질 것이다. 이를 iptables-save 명령으로 저장이 가능하다.

 # iptables-save > iptables_test

 아래와 같이 iptables-restore 명령으로 저장한 정책 파일을 불러올 수도 있다.

 # iptables-restore < iptables_test

 * 매스커레이딩(iptables)
 ipchain 명령과 마찬가지로 내부 인터넷 연결 공유를 할 수 있다. masquerading 기법으로 한 컴퓨터에 두 개의 네트워크 인터페이스를 설정한 다음, 하나는 외부의 인터넷과 연결되어 있고, 다른 하나는 내부 게이트웨이(192.168.0.1 이라고 가정)의 역할을 하도록 설정한다. 내부 게이트웨이 역할을 하는 인터페이스와 연결된 허브를 통해 같은 192.168.0.0/24 대역의 아이피를 설정하여, 내부에서도 인터넷을 사용할 수 있도록 할 수 있다. 아래의 스크립트는 최소의 masquerading 기법을 위한 입력으로 손쉽게 내부에 인터넷을 공유할 수 있다.

 # /sbin/iptables -F
 # echo “1” > /proc/sys/net/ipv4/ip_forward
 # iptables -t nat -A POSTROUTING -s 192.168.1.2/24 -j MASQUERADE

 * 솔라리스(Solaris)
 솔라리스는 BSD 계열의 SunOS를 바탕으로 하여, System V 계열의 영향을 받은 SunOS 5 버전부터는 Solaris 2.x 라는 이름도 함께 사용해 왔다. 이후 Solaris 2.7 부터는 다시 Solaris 7이라는 이름으로도 통용되고 있다. Sun 사에서는 이 OS를 자사에서 생산하는 스팍 플랫폼 용으로만 개발하였으나 인텔 플랫폼을 사용하는 경우가 늘어나며 인텔용 버전도 함께 개발하였다. 그러나 본질적으로는 거의 동일한 소스를 기반으로 컴파일한 제품이므로 성능 면에서는 큰 차이가 없다.

두번째 미러링 사이트…

 여기에는 포스팅을 하지 않았지만 동아리 FTP 사이트를 꾸며 우분투 리눅스 미러링 서비스를 시작했었다.

 그리고 이번에는 두번째 서비스로 아파치 미러링을 시작하게 되었다… 얏호! 🙂

유스케이스

    *** 유스 케이스

 – 시스템이 제공하는 각 기능

   ** 유스케이스 이름

  * 명명 규칙1 : 행위 또는 동작을 뜻하는 명사 사용
 – 시스템의 기능을 나타내어야 함
 – ex) 수강 -> 수강신청, 출석부 -> 출석부 조회

  * 명명 규칙2 : 사용자가 얻고자 하는 목적이 명확히 나타나야 함.
 – ex) 수강 과목 선택 -> 수강 신청

  * 명명 규칙3 : 사용자(액터)의 입장에서 명명되어야 함
 – ex) 성적 관리 -> 성적 등록
 – ex) 수강 신청 관리 -> 수강 신청

  * 요약 : 사용자의 관점에서 바라보고 시스템이 제공하는 기능을 이용하여 궁극적으로 하고자 하는 행위를 나타내는 명사를 사용한다.

   ** 유스케이스 설명

  * 유스케이스를 이용하는 사용자에게 이 유스케이스를 통해서 시스템이 어떤 기능을 제공하는 지를 한/두 문장으로 간단하고 명확하게 기술하는 것

   ** 유스케이스의 특성

  * 특성 1 : 하나의 유스케이스는 일련의 액션들로 표현

  * 특성 2 : 하나의 유스케이스는 여러 variants를 포함
 – 기본 흐름(basic flow) : 가장 전형적이고, 정상적인 경우
 – 대안 흐름(alternative) : 기본 흐름을 벗어나는 다른 상황을 나타냄
 – 각 대안 흐름 별로 별도의 유스케이스를 정의하지 않음
 – ex) 카드 판독 실패 이벤트 흐름
+ 카드 판독이 불가능함을 사용자에게 알리고 카드를 배출시킨다.
+ 사용자는 카드를 회수한다.
 – ex) 잔액 부족 이벤트 흐름
+ 잔액 부족을 사용자에게 알리고, 카드를 배출하고, 영수증을 인자한다.
+ 사용자는 카드와 영수증을 회수한다.

  * 특성 3 : 유스케이스는 시스템이 제공하는 기능
 – 시스템에서 제공하지 않을 기능이 유스케이스에 포함되어서는 안됨
 – 수작업을 통해서하는 작업을 유스케이스에 포함시켜서는 안됨
 – ex) 학교에서 배포된 성적표로 성적 확인은 유스케이스에 포함시켜서는 안됨

  * 특성 4 : 유스케이스는 액터가 관찰할 수 있는 결과를 산출
 – ex) 현금 자동 인출기 시스템의 출금 유스케이스
+ 카드 판독의 성공 표시 및 거래 종류의 일력을 요청하는 화면
+ 암호의 입력을 요청하는 화면
+ 암호의 확인 성공 표시 및 인출할 금액의 입력을 요청하는 화면
+ 출금이 진행 중임을 표시하는 화면
+ 출금 시 배출된 현금과 영수증
 – 유스케이스는 액터가 궁극적으로 원하는 결과를 내야 한다.

  * 특성 5 : 유스케이스는 액터에 의해서 수행이 시작
 – ex) 출금 유스케이스 : 사용자 액터가 카드를 삽입함으로써 수행
 – 유스케이스의 이벤트 흐름은 반드시 액터에 의해서 시작된다.

  * 특성 6 : 한 유스케이스 내의 액션들을 트랜젝션처럼 수행
 – 한 유스케이스의 이벤트 흐름을 구성하는 각 이벤트들은 유스케이스가 수행될 때 모두 발생하는 것이며 부분적인 발생은 허용되지 않음.
 – 이벤트 흐름의 부분만을 수행하는 것이 가능하면 그것을 하나의 유스케이스라고 볼 수 없음.
 – ex) 성적 등록
 – ex) 출석부 조회

   ** 유스케이스 찾기

 – 질문1 : 사용자 액터가 시스템이 제공하기를 원하는 기능은 무엇인가?
+ ex) ATM : 입금, 출금, 조회, 이체, 통장 정리
+ ex) 대학 정보 시스템 : 학생(수강신청, 성적조회), 교수(출석부 조회, 성적 등록)
 – 질문2 : 시스템이 어떤 기능을 제공하면 사용자 액터의 일상 작업이 효율적이고 편해지는가?
+ 수업 담당자 : 수강료 청구서 발급
 – 질문3 : 사용자 액터가 시스템에 어떤 정보를 생성/조회/수정/삭제하고 싶어 하는가?
 – 질문4 : 시스템의 입력과 출력은 무엇인가?

액터

    *** 요구사항 정리

 – 기초공사
 – 사용자로부터 필요
 – 시스템 구축의 첫 과정
 – 요구사항 도출, 기술, 확인하는 활동
+ 유스케이스 모델링 기법 이용
+ 체계적인 요구사항 도출
+ 명확한 기술 방법 설명

   ** 요구사항의 유형

  * 기능적 요구사항 : 시스템이 제공해야 하는 동작/행위에 대한 요구사항
 – 교수/학생 정보를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
 – 강좌/강의를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
 – 수강 신청, 성적 등록, 성적 조회, 출석부 조회 기능
 – 로그인, 로그아웃, 암호 변경 기능

  * 비기능적 요구사항 : 동작/행위와 관련된 제약사항
 – 성능
 – 신뢰도
 – 사용 편의성
 – 유지 보수성

   ** 비기능적 요구사항

  * 성능
 – 정해진 특정 시간 내에 결과가 나와야 한다는 조건
 – ex) “학번, 이름을 입력한 후에 검색 명령을 내리고 검색 결과를 2초 이내에 화면에 보여 주어야 한다.”
 – 설계 활동의 중요한 요소로 작용
 – ex) JDBC로 직접 데이터베이스 조작, 무상태 세션 빈 사용, 성능 향상을 위한 프로그래밍 기술 사용

  * 신뢰도
 – 오류가 발생하지 않으면서 시스템이 동작할 확률
 – ex) 항공기 제어 시스템, 미사일 추적 시스템 등의 실시간 시스템
 – 특별한 기술 사용

  * 사용 편의성
 – 사용자들이 얼마나 편리하고 쉽게 시스템을 사용할 수 있는가
 – ex) 효과적인 메뉴 체계 정의
 – ex) UI화면의 일관되고 효과적인 정의
 – ex) 도움말 온라인 제공

  * 유지 보수성
 – 얼마나 유지 보수를 쉬우면서 효율적으로 할 수 있는가의 정도
 – 설계 시 약속된 기능을 정확히 제공
 – 설계 시 유지 보수 측면 고려

   ** 요구사항 정의의 중요성

  * 요구사항 정의 활동의 산출물
 – 개발자들에게 구축할 시스템의 정보 제공
 – 개발할 시스템 파악(개발자)

  * 요구사항 정의 활동 개발자와 분석/설계 개발자가 다른경우
 – 산출물을 바탕으로 한 작업 진행
 – 정확성과 완전성이 중요함

  * 요구사항의 명확한 정의 이후 개발 진행

  * 결정된 요구사항에 대한 사용자와 개발자 간의 합의 필요

   ** 요구사항 정의 활동

 – 시스템이 제공할 기능과 범위 밖을 명확하게 구분
 – 시스템의 결계 결정

  ** 유스케이스 모델링

 – Ivar Jacobson에 의해서 제안
 – 요구사항 도출 및 기술에 사용
 – 액터 : 개발할 시스템 외부의 존재
 – 유스케이스 : 시스템 범위 안에서 개발될 시스템의 단위 기능

    *** 액터

  * 개발될 시스템과 상호 작용을 하는 모든 대상
 – 사용자 액터
 – 시스템 액터

  * 사용자 액터
 – 개발될 시스템의 기능을 이용하는 사용자

  * 시스템 액터
 – 개발될 시스템과 연동 되는 또 다른 시스템
 – ex) 신용 대출 시스템 : 신용 정보 제공 시스템
 – ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템

   ** 액터 이름

  * 액터의 이름
 – 액터의 의미를 명확히 애해할 수 있는 단어 사용

  * 사용자 액터
 – 시스템 관점의 사용자 역할
 – ex) 교수, 학생, 학사 담당자, 수업 담당자
 – 역할 추측 가능한 구체적인 단어 사용

  * 시스템 액터
 – 해당 시스템의 이름 사용
 – 문제 기술서에 시스템의 이름이 명시되어 있음
 – ex) 수강료 청구서 발급 시스템, 신용 평가 시스템

   ** 액터 설명

  * 액터가 할 수 있는 일 기록
 – ex) 학사 담당자 : 교수 및 학생 정보를 관리한다.

   ** 액터의 특성

  * 개발될 시스템 범위 밖에 존재
 – 개발자가 개발할 범위가 아니라는 것.
 – ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템

  * 역할을 나타내야 함
 – 구체적인 실제 사용자가 아님
 – 시스템의 관점에서 바라본 그 사용자의 역할
 – 한 명이 두 개 이상의 역할을 하는 경우 : 대응되는 각각 사용자 액터를 정의
 – ex) 1명(도서 관리, 학생/교수 관리) : 사서, 학사 담당자 액터

   ** 액터 찾기

  * 질문 :  누가 개발될 시스템의 주요 기능을 이용하는가?
 – 문제 기술서 활용
 – 학적과의 학사 담당자는 학생 및 교수 정보를 관리해야 한다.
 – 수업 담당자는 새로운 강좌를 등록할 수 있다.
 – 학생을 수강 신청을 온라인 상으로 직접 할 수 있다.
 – 교수는 매 학기마다 자신이 강의하는 강좌를 신청한 학생 명단을 확인할 수 있다.

  * 질문 : 누가 이 시스템을 통해서 자신의 업무를 지원 받을 수 있는가
 – ex) 대학 정보 시스템 : 학사 담당자

  * 질문 : 누가 시스템이 만들어 낸 결과에 관심을 가지는가?

  * 질문 : 누가 시스템이 잘 운영될 수 있도록 유지 보수 및 관리를 하는가?
 – Primary actor : 시스템 본연의 기능을 이용하는 사용자
 – Secondary : 시스템의 유지 보수 기능을 이용하는 사용자
 – 음료수 자동 판매기 : 청소 및 관리자
 – 현금 자동 인출기 : 유지 보수 담당자
 – 시스템이 유지 보수 기능을 제공하지 않으면 유지 보수 담당자는 액터로 표기될 수 없음

  * 질문 : 개발할 시스템과 연동되는 다른 시스템에는 어떤 것이 잇는가?
 – 시스템 액터를 찾을 때 유용
 – ex) 대학 정보 시스템 : 기존에 존재하는 수강료 청구서 발급 시스템