Entity Manager는 JPA 에서 매핑한 엔티티를 CRUD 하는 모든 작업을 처리합니다. Entity Manager Factory는 이러한 Entity Manager를 생성하는 곳이며 일반적으로 연결된 DB당 하나씩 생성합니다. Factory를 생성하는 비용은 상당히 크기 때문에 생성 후 어플리케이션 전체에서 공유되도록 설계되어 있으며, 반면에 Entity Manager의 생성 비용은 거의 들지 않습니다. 또한 Entity Manager Factory는 Thread-safe하게 설계되어있지만 Entity Manager는 동시 접근 시 문제가 발생할 수 있으므로 공유가 되어서는 안됩니다. Hibernate를 포함한 JPA 구현체들은 Entity Manager Factory를 생성할 때 Connection Pool을 함께 생성하며, Entity Manager는 생성된 후에 보통 트랜잭션을 시작할 때 해당 커넥션을 획득합니다.

Persistence Context (영속성 컨텍스트)

JPA를 이해하는 데 가장 중요한 용어이며 실질적으로 보이지 않아 헷갈릴 수 있지만 '엔티티를 영구 저장하는 논리적인 영역'을 의미합니다. Entity Manager로 엔티티를 저장, 조회하면 해당 영속성 컨텍스트에 저장합니다. 영속성 컨텍스트 또한 엔티티 매니저가 생성될 때마다 생성이 되며 엔티티 매니저를 통해 영속성 컨텍스트에 접근합니다. 경우에 따라 여러 엔티티 매니저가 동일한 영속성 컨텍스트에 접근 또한 가능합니다.

엔티티의 생명주기

비영속 (New / Transient)

영속성 컨텍스트나 DB와 전혀 관계가 없는 순수한 객체 상태.

Member member = new Member();

영속 (Managed)

엔티티 매니저를 통해 엔티티를 영속성 컨텍스트에 저장한 상태. 이제 영속성 컨텍스트에 의해 관리가 되는 상태이며 영속성 컨텍스트의 이점을 적용받게 됩니다. 해당 이점은 아래에 작성하겠습니다.

em.persist(member)

준영속 (Detached)

특정 엔티티를 영속성 컨텍스트에서 제거하거나 (em.detach) 영속성 컨텍스트를 닫거나 (em.close) 영속성 컨텍스트를 초기화 하는 경우 (em.clear) 엔티티가 영속성 컨텍스트에서 분리되어 더 이상 관리되지 않는 상태입니다. 비영속 상태에 가깝지만 영속 상태였기 때문에 식별자의 존재는 보장이 됩니다. 나중에 정리할 지연 로딩 또한 지원이 되지 않습니다.

em.detach(member)
em.close()
em.clear()

삭제 (Removed)

엔티티를 영속성 컨텍스트와 DB에서 삭제한 상태.

em.remove(member)

영속성 컨텍스트 이점

1차 캐시

영속성 컨텍스트는 내부에 캐시를 갖고 있으며 해당 캐시를 1차 캐시라 부르며 영속 상태의 엔티티는 모두 이곳에 저장됩니다. 1차 캐시의 키는 식별자 값이며 테이블의 PK와 매핑되어 있습니다. em.find()를 통해 엔티티를 조회하면 우선적으로 메모리에 1차 캐시를 조회하며 캐시에 존재하지 않으면 그 때 DB를 통해 조회합니다. 하지만 해당 캐시는 보통 사용자 요청마다 생성이 되는 영속성 컨텍스트 내에 있기 때문에 엄청 복잡한 비즈니스 로직이 아니라면 큰 성능상의 효과는 없는 편입니다.

동일성 보장

영속성 컨텍스트는 자바 컬렉션 내의 객체와 같이 식별자가 같다면 반복해서 조회하더라도 동일한 엔티티를 반환합니다.

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b);

트랜잭션을 지원하는 쓰기 지연

em.persist(memberA);
em.persist(memberB);
// 여기 까지는 '쓰기 지연 저장소'에만 저장이 되며 실제 INSERT SQL을 보내지 않음
transaction.commit();
// 트랜잭션 커밋과 동시에 저장소에 모아놓은 쿼리를 한번에 날림

변경 감지

기존 SQL 수정 쿼리의 문제점은 테이블의 컬럼이 늘어날 수록 각각에 맞는 수정 쿼리가 많아지는 것은 물론이고 비즈니스 로직을 분석하기 위해 SQL을 계속 확인해야 하기 때문에 직간접적으로 비즈니스 로직이 SQL에 의존하게 된다는 점이 문제점입니다. 이를 보완하기 위해 JPA는 엔티티의 처음 저장할 때 최초 상태를 담은 스냅샷을 함께 저장해둡니다. 그리고 영속성 컨텍스트의 내용을 DB에 반영하는 'Flush'라는 이벤트가 발생하면 1차 캐시에 저장된 스냅샷과 엔티티가 다르다면 수정 쿼리를 작성하여 '쓰기 지연 SQL 저장소'에 저장을 하고 이를 포함하여 저장된 쿼리를 모두 날리게 됩니다. JPA의 기본 전략은 엔티티의 모든 필드를 업데이트 하는 것이며 이는 하나의 쿼리를 미리 생성하고 재사용할 수 있는 장점이 있습니다. 하지만 데이터 전송량이 부담되는 상황이라면 특정 컬럼만 업데이트할 수 있도록 변경도 가능합니다. (Dynamic Update)

지연 로딩

성능 최적화에 중요한 개념이므로 별도로 정리하겠습니다.

Flush

위에서 설명드린 것처럼 영속성 컨텍스트의 변경 내역을 DB에 반영하는 이벤트이며 해당 이벤트가 발생하면 모든 영속 상태의 엔티티를 스냅샷과 비교하여 수정 쿼리를 쓰기 지연 저장소에 등록하고 저장된 쿼리를 DB에 전달합니다. 플러시하는 방법은 아래와 같습니다.

직접 호출

em.flush()를 통해 강제로 플러시하는 방법이며 테스트할 때 제외하고는 거의 사용하지 않습니다.

트랜잭션 커밋

트랜잭션이 커밋되기 전에 플러시를 통해 DB에 쿼리가 전달이 되어야 데이터 변경이 이루어지기 때문에 JPA는 트랜잭션 커밋 전에 자동으로 플러시를 수행합니다.

JPQL 실행

JPQL에서 조회를 할 경우 플러시를 하지 않고 영속 상태일 경우는 JPQL에서 해당 엔티티를 조회하지 못하기 때문에 이를 보완하기 위하여 JPA는 JPQL실행 전 자동으로 플러시를 진행합니다.

• OS : Cent OS 7
• ELK Stack 버전 : 8.11
• JDK : 17.0.2

시스템 구조

0. 로그 파일 생성

여러개의 WAS가 동작 중인 상황이고 각 WAS 별로 별개의 로그 파일이 생성되어 파일 시스템에 저장되고 있는 상황을 가정합니다.

1. Filebeats

Filebeats를 활용하여 각각의 로그 파일에 접근하여 데이터 수집을 진행합니다. multiline 설정을 통해 여러 줄의 로그 내용을 하나의 단위로 수집하도록 설정을 진행합니다. 주석처리된 exclude, include 속성을 활용하여 제외 키워드, 포함 키워드 또한 설정이 가능합니다.

2. Filebeats

Filebeats로부터 데이터를 받아 Elasticsearch 적재를 위한 데이터 가공, Elasticsearch 전달을 담당합니다. input 영역에서는 beats를 통해 데이터 수신 설정 filter 영역에서는 데이터 가공 설정을 진행해야 하지만 현재는 별도 가공 없이 전달합니다. output 영역에서는 전달해야할 elasticsearch 정보 및 index 정보를 설정합니다.

3. Elasticsearch

Logstash로부터 데이터를 받아 적재하고 인덱싱 처리를 진행합니다.

이렇게 전달받은 데이터는 /var/lib/elasticsearch 폴더 내에 인덱싱이 되어 저장됩니다.

4. Kibana

데이터 적재 현황을 파악할 수 있는 Kibana Discover 페이지 입니다. 데이터 적재를 위해 WAS에 접속하여 강제로 로그를 생성한 후에 다시 Discover 페이지에 접속합니다. 설정한 기간 내에 몇 건의 데이터가 조회되었는지 카운트와 간단한 차트를 제공하며 아래 테이블에서 Field별로 확인 또한 가능합니다.

5. Alert (MS Teams)

Alert 목표는 각 운영 상황마다 다르겠지만 이번 실습에서는 간단하게 5분 이내에 5회 이상 'ERROR'라는 키워드가 포함된 로그 데이터가 적재되면 지정한 Webhook(MS Teams)을 통해 알림하는 것을 목표로 합니다.

Connector 설정을 통해 알림을 보낼 대상을 설정하며 2번째 사진의 Webhook URL에 MS Teams에서 제공받은 Webhook URL을 설정합니다.

Elastic Search는 루씬기반의 검색엔진이므로 조회를 위해서는 KQL 또는 Lucene 으로 쿼리를 작성해야 합니다. 단순 쿼리로 message 필드의 값 중 'ERROR'라는 키워드가 5분동안 5회 이상 노출되었을 때를 규칙으로 설정합니다.

현재는 message (로그 메세지) 속성만 사용해서 쿼리를 작성했지만 다른 속성들도 AND/OR로 작성이 가능합니다.

규칙 작성 후에 위에서 설정한 Connector를 연결합니다.

WAS에서 강제로 익셉션을 발생시킨 후 Teams를 보면 KIBANA에서 전달한 Alert가 수신됩니다. 간단한 오류 메세지가 담겨있으며 위에서 알 수 있듯 해당 메세지 또한 활용 가능한 변수들을 조합하여 커스터마이징이 가능합니다. Link의 값으로 접속하면 해당 내용의 Discover 페이지로 이동합니다.

TODO

이로써 간단한 로그 분석 및 알림 전송 시스템은 실습이 끝났습니다. 나아가서 아래 항목 또한 고려할 필요가 있습니다.

Elastic Search 서버 분리

Elasticsearch가 비교적 많은 메모리와 저장공간을 차지하며 별도로 Log Rotate를 하지 않는 이상 지속적으로 용량을 차지하기 때문에 적합한 리소스를 갖는 별도의 서버 구축이 필요합니다. 저장한 데이터는 정기적으로 다른 저장소에 전달하는 기능 또한 고려할 수 있습니다.

모니터링 대상 및 규칙 세분화

실제 운영 환경에 맞는 모니터링 대상 및 알림을 보내는 규칙의 구체화가 필요합니다.

Kibana 커스터마이징

현재는 정말 필요한 기능만 사용했지만 Kibana 는 다양한 기능을 갖고있는 강력한 도구이기 때문에 운영 상황에 맞는 Visualise/Dashboard활용, 알림, 외부 시스템 연동에 대한 고민이 필요합니다.

ELK 스택은 E(Elasticsearch), L(Logstash), K(Kibana)라는 데이터 처리 및 활용에 유용한 세가지 오픈소스 프로젝트로 구성된 스택을 의미하는 약어로 시작했으며 2015년 이후 데이터 수집에 유용한 Beats가 Stack에 추가되어 함께 ELK Stack이라고 불립니다. 원래는 별개의 프로젝트였지만 Elastic 측에서 데이터 검색 및 분석 기능에 대한 유연성을 제공하기 위해 스택으로 통합되었으며 이후에 업데이트 또한 함께 버전업이 되어 릴리즈됩니다. 각각의 Stack에 대한 설명은 아래에서 진행하도록 하겠습니다.

Beats

Beats는 로그 스태시와 같이 데이터 전송 역할을 하는 플랫폼입니다. 기존에 수집을 담당하는 Logstash와 다른 점은 FileBeat, MetricBeat와 같이 각 역할에 해당하는 단순한 전송 기능을 수행하는 경량화된 플랫폼이라는 점입니다. 로그 스태시를 사용한다면 데이터 소스의 종류/RDB의 SQL별로 프로세스가 따로 구동되어야 하기 때문에 다양한 데이터 소스를 필요로 하는 시스템에서는 데이터 성격에 맞는 비츠를 구성하여 서비스를 구성하는 것이 더욱 효율적입니다.

FileBeats

File을 수집하는 FileBeats는 다양한 형식의 로그파일을 수집하는 기능을 제공합니다.

MetricBeats

서버에서 발생하는 다양한 정보를 수집하는 기능을 제공합니다. CPU 사용률, 메모리 사용률, 네트워크 I/O, 디스크 I/O 등 다양한 정보를 수집하여 엘라스틱 서치로 전송합니다.

Logstash

자바 기반으로 만들어진 데이터 ETL(Extract, Transform, Load) 제품으로 간단하면서도 다양한 데이터 조회, 변환, 등록 설정을 제공합니다. 하지만 ETL대상마다 Logstash 프로세스를 생성해야하는 단점이 있습니다.

Elasticsearch

ELK Stack 중 데이터 저장소 역할을 하며 분산 환경으로서 하둡과 같이 자유롭게 Scale out을 지원하며, 데이터 적재 시 수행되는 인덱싱 처리와 메모리 캐싱을 통한 빠른 검색 가능, 사용자 접근이 쉽도록 RESTFUL 방식을 이용한 데이터 접근 등의 특징이 있습니다.

분산처리

Elasticsearch가 빅테이터 플랫폼으로 활용될 수 있는 가장 큰 이유이며 하둡 에코 시스템과 같이 자유롭게 Scaleout이 가능하여 데이터 용량에 제한 없이 필요에 따라 자유로이 스토리지, 자원, 서버등을 확장할 수 있기 때문에 빅데이터의 처리가 가능합니다.

고속 검색을 위한 인덱싱

Elasticsearch는 데이터 적재 시 기본적으로 인덱싱하는 과정을 거칩니다. 인덱싱된 데이터는 모두 Document라는 단위의 데이터로 생성되고, 다른 비슷한 인덱싱 프로세스를 가진 솔루션과 달리 이들이 메모리에도 캐싱되어서 고속 검색이 가능합니다.

HTTP RESTFUL API

HTTP 프로토콜을 이용한 RESTFUL API 방식으로 데이터 접근이 가능하기 때문에 플랫폼의 제약 없이 데이터 CRUD 작업이 가능하며 Bulk 모드를 통해 대량 건을 한 번에 적재할 수 있는 기능 또한 가능하다.

JSON 저장 방식

Elasticsearch는 데이터 적재 및 관리를 위해 JSON 형식을 사용합니다. 이러한 JSON 타입이 속도 측면에서 빠르다고 할 순 없지만 Key/Value형태인 JSON으로 데이터를 명확하게 관리할 수 있다는 점이 큰 장점이며 RDB의 NULL 개념과는 달리 필요한 데이터만 Field로 생성하기 때문에 불필요한 영역을 사용하지 않습니다.

Kibana

ELK Stack에서 시각화를 담당하는 도구입니다. GUI를 통해 간단하게 데이터 시각화, 차트 구성, 대시보드 생성 등이 가능한 강력한 도구입니다.

Discover

Elasticsearch에 적재된 인덱스로 키바나에서 인덱스 패턴 객체를 생성하면 Discover를 통해 데이터 적재 현황을 파악할 수 있습니다. JSON 필드별로 목록 화면을 조정할 수 있는 기능과 필드별 통계 기능 또한 제공합니다.

Visualize

Kibana는 사용자가 직접 데이터를 시각화하고 대시보드를 구성하며 필요에 맞게 분석을 할 수 있는 기능을 제공합니다. 다양한 형식의 차트, 테이블 등을 활용하여 시각화가 가능합니다.

Map

오픈 스트리트 맵을 비롯한 몇 가지 오픈소스를 활용하여 전세계 지도를 서비스하고, 그 위에 국가, 지역 등을 구분할 수 있는 폴리곤 정보 등을 조합하여 Elastic Maps라는 맵 서비스로 구성하여 서비스하고 있습니다.

Dashboard

앞선 Visualize를 통해 생성된 시각화 자료들을 활용하여 하나의 Dashboard로 조합이 가능합니다. 이렇게 생성된 대시보드는 외부에서 확인이 가능하도록 Export가 가능하며 타 시스템에 임베디드가 가능하도록 iframe 형대로도 Export가 가능합니다.

다음 게시물에서는 ELK Stack을 활용하여 간단한 로그 분석 시스템 구축과 알림 기능을 하는 시스템을 구축해보겠습니다.

Spring 3부터 제공되는 전통적인 Blocking HTTP Client입니다. Apache HttpClient 라이브러리를 활용하여 개발되었으며 HTTP 요청을 생성하기 위해 간단한 API를 제공하며 현재까지도 많은 프로젝트에서 활용되는 HTTP Client입니다. Java Servlet API를 활용하고 있기 때문에 기본적으로 하나의 스레드당 하나의 요청 방식으로 되어있으며 이는 클라이언트가 응답을 받을 때까지 스레드는 Block 상태이기 때문에 서버 자원과 응답 시간에 영향을 미치는 것을 의미합니다. 또한 많은 요청이 들어오면 이에 비례하여 스레드가 생성되기 때문에 메모리와 스레드풀에 영향을 미치고 잦은 Context Switching으로 인해 효율성이 저하됩니다.

Web Client?

Spring 5부터 제공되는 최신 Non-Blocking Reactive HTTP Client입니다. Non-Blocking을 지원하기 위해 Spring Reactive Framework를 기반으로 개발되었습니다. Reactive Framework는 Event-Driven 구조를 사용하기 때문에 비동기 로직을 Reactive Stream API를 통해 제공하게 됩니다. 이는 RestTemplate와 비교하여 적은 양의 스레드와 시스템 자원만으로 많은 요청을 처리할 수 있음을 의미하기 때문 많은 양의 요청을 병렬로 처리해야하는 경우 적합한 HTTP Client입니다.

RestTemplate vs Web Client (Concept)

두 클라이언트간 주요 차이점을 알아보겠습니다.

동기 / 비동기

RestTemplate는 요청에 대한 응답이 수신될 때까지 호출한 스레드를 Blocking하는 동기식 클라이언트입니다. 반면에 WebClient는 Non-Blocking 방식이기 때문에 메인 스레드를 차단하지 않고 여러 요청을 동시에 수행이 가능합니다.

반응형 / 비반응형

RestTemplate은 전통적인 비반응형 클라이언트인 반면, WebClient는 반응형 프로그래밍을 지원함으로써 대용량 데이터를 보다 효율적으로 처리할 수 있습니다.

오류 처리

RestTemplate는 예외를 발생시켜 오류를 처리하는 방식을 사용하고 있습니다. 반면에 WebClient는 반응형 스트림을 사용하여 오류를 전파하기 때문에 오류를 좀 더 쉽게 처리할 수 있습니다.

직렬화 / 역직렬화

RestTemplate는 다른 외부 라이브러리를 통해 객체를 (역)직렬화 하는 반면에 WebClient는 Spring에 내장된 기능을 사용하여 (역)직렬화하기 때문에 별도의 라이브러리가 필요하지 않습니다.

RestTemplate vs Web Client (Logic with Code)

RestTemplate

@GetMapping("/tweets-blocking")
public List<Tweet> getTweetsBlocking() {
    log.info("Starting BLOCKING Controller!");
    final String uri = getSlowServiceUri();

    RestTemplate restTemplate = new RestTemplate();
    ResponseEntity<List<Tweet>> response = restTemplate.exchange(
      uri, HttpMethod.GET, null,
      new ParameterizedTypeReference<List<Tweet>>(){});

    List<Tweet> result = response.getBody();
    result.forEach(tweet -> log.info(tweet.toString()));
    log.info("Exiting BLOCKING Controller!");
    return result;
}

먼저 RestTemplate 예시 코드입니다. RestTemplate는 동기적인 특성으로 인해 restTemplate.exchange 응답을 받을 때까지 Blocking 상태일 것이며 이 후의 코드는 Blocking 후에야 실행될 것입니다.

Starting BLOCKING Controller!
Tweet(text=RestTemplate rules, username=@user1)
Tweet(text=WebClient is better, username=@user2)
Tweet(text=OK, both are useful, username=@user1)
Exiting BLOCKING Controller!

콘솔에 나타난 실행 흐름입니다.

WebClient

@GetMapping(value = "/tweets-non-blocking", 
            produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<Tweet> getTweetsNonBlocking() {
    log.info("Starting NON-BLOCKING Controller!");
    Flux<Tweet> tweetFlux = WebClient.create()
      .get()
      .uri(getSlowServiceUri())
      .retrieve()
      .bodyToFlux(Tweet.class);

    tweetFlux.subscribe(tweet -> log.info(tweet.toString()));
    log.info("Exiting NON-BLOCKING Controller!");
    return tweetFlux;
}

다음은 WebClient 예시 코드입니다. Web Client가 일련의 데이터 스트림인 Flux 객체를 반환하고 메서드 실행이 완료됩니다. /tweets-non-blocking endpoint를 호출하는 클라이언트도 반환된 Flux 개체에 가입됩니다.

Starting NON-BLOCKING Controller!
Exiting NON-BLOCKING Controller!
Tweet(text=RestTemplate rules, username=@user1)
Tweet(text=WebClient is better, username=@user2)
Tweet(text=OK, both are useful, username=@user1)

콘솔에 나타난 결과 응답과 상관없지 메서드가 종료된 것을 알 수 있습니다.

Summary

RestTemplate도 현재까지 아직 사용중이지만 위에서 설명드린 특성들로 인해 WebClient가 성능상 이점을 많이 갖고 있기 때문에 HTTP Client를 선택해야할 때 이 점에 대해 인지하고 개발을 하면 좋겠습니다.

소프트웨어는 컴퓨터 등장 이후 하드웨어에 부수적으로 뒤따르는 존재로 등장했지만 소프트웨어가 독립적으로 상품성이 있음에 눈뜨게 된 이후 소프트웨어는 산업으로써의 길을 걷습니다. 오늘날 우리가 구매하는 소프트웨어는 이를 제한적으로 사용할 수 있는 권리를 구매하는 것에 가깝습니다.

OSS(Open Source Software)의 등장

IT에서의 지적재산권은 기업의 독점적 지위를 높이기도 하지만 IT 산업의 전반적인 기술혁신을 가로막는 장애물로 작용하기도 합니다. 소프트웨어가 상업화되어가면서 소스코드 비공개로 전환되는 것에 대한 반발로 자유소프트웨어 운동이 일었는데 리처드 스톨만의 주도로 1983년 'GNU프로젝트'가 시작되었습니다. 'GNU프로젝트'는 컴파일러, 빌드 도구 등 프로그래밍에 필요한 다양한 도구를 개발하면서 진행되다가 실질적인 결실은 리누스 토발즈의 리눅스 커널과의 결합에 의해 완성됩니다. 리눅스 커널은 1994년 1.0버전이 출시되면서 상업용 운영체제와 경쟁 가능성을 보이게 됩니다. OSS는 다수의 사람에 의해 버그를 잡아낼 가능성이 높기 때문에 우수한 개발 모델이라는 주장이 담겨 있습니다.

OSS의 정의

정리하자면 OSS는 소프트웨어의 ‘소스코드’를 공개하여 누구나 개량·재배포할 수 있는 소프트웨어입니다. 처음 듣기엔 소스코드를 공개하는 것에 의문이 들 수 있지만 주로 아래와 같은 이유들이 있습니다.

• 이미 있는 오픈 소스를 포크하여 새 프로젝트가 만들어지는 경우, 아래에서 설명할 라이센스로 인해 공개해야 함.
• 외부 개발자들이 참여하도록 하면 더 다양한 환경에서 소프트웨어를 시험해보고 품질을 높일 수 있으므로 소프트웨어를 더 좋게 만들기 위함.
• 사회 공헌의 측면에서 기술의 공유는 물질의 공유보다 상대적으로 희소성이 반감되는 자산으로 다루어질 수 있기 때문.
• 프로그램의 신뢰성을 보장하는 방법일 수 있음.

OSS의 장단점

• 장점
  • 이용에 비용이 들지 않거나 적다.
  • 각자의 니즈와 호나경에 맞게 변형 가능
  • 외부 개발자들로 인해 보안 취약점이 쉽게 발견된다. (그러나 오픈 소스가 보안 측면에서 더 우수하다는 것을 의미하지는 않는다.)
  • 누구나 버그를 고칠 수 있고 소프트웨어에 기여할 수 있다.
  • 특정 제조업체인 벤더(vendor)에 의존하지 않아도 된다.
• 단점
  • 사용이 편리한 배포판이 아닌 소스 코드를 직접 빌드하여 사용하기에는 비숙련 사용자들은 이용이 어려울 수 있다.
  • 이미 표준적으로 사용되는 소프트웨어가 있는 경우 호환성 문제가 발생.
  • 고객 지원이 상업 소프트웨어에 비해 상대적으로 약함.
  • 잘못된 정보를 가진 소프트웨어일 수 있음.

라이센스 목록 및 제약

이 글을 작성하게 된 주된 이유입니다. 오픈소스라고 하여 무작정 가져다가 변형하고 배포하였다간 오픈소스에 적용된 제약에 위배되어 법적, 금전적, 신뢰적으로 큰 피해를 입을 수 있으므로 사용하려는 오픈소스의 라이센스의 제약을 명확히 인지하고 사용하는 것이 반드시 필요합니다.

Cache Provider를 소개하기 앞서 캐시 저장 공간은 제한적이기 때문에 각 Provider는 서로 다른 기존의 캐시 제거 전략을 갖고 있습니다. 대표적인 전략은 아래 표와 같으며 각 캐시 구현체는 필요에 따라 각 전략을 혼합하고 커스터마이징 하여 캐시를 관리합니다.

Cache Provider

Spring에서 사용 가능한 대표적인 Cache Provider 목록과 상세 정보는 아래 표와 같습니다.

Benchmarks

캐시 구현체들의 성능 비교입니다. (MacBook Pro i7-4870HQ CPU @ 2.50GHz(4코어) 16GB Yosemite에서 실행)

1. 계산

캐시는 제한이 없고 완전히 채워져 있으며 결과는 상수를 반환한다고 가정합니다. 항목이 있을 때 잠금으로 인한 오버헤드를 보여줍니다.

2. 읽기(100%)

최대 크기로 구성된 캐시에서 동시에 8개의 스레드를 읽습니다.

3. 읽기(75%) / 쓰기(25%)

6개의 스레드는 최대 크기로 구성된 캐시 에서 동시에 읽고 2개의 스레드는 캐시에 씁니다.

4. 쓰기(100%)

8개의 스레드는 최대 크기로 구성된 캐시에 동시에 씁니다.

Spring Configuration (Caffeine)

대부분의 벤치마크에서 좋은 성능을 보여주는 Caffeine을 간단히 설정하는 방법을 알아보겠습니다.

의존성

<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.1</version>
</dependency>

Configuration

 @Bean
public Caffeine<Object, Object> caffeineConfig() {
    return Caffeine.newBuilder()
        .expireAfterWrite(300, TimeUnit.SECONDS)
        .initialCapacity(10);
}

@Bean
public CacheManager cacheManager(Caffeine caffeine) {
    CaffeineCacheManager caffeineCacheManager = new CaffeineCacheManager();
    caffeineCacheManager.setCaffeine(caffeine);
    return caffeineCacheManager;
}

위와 같은 간단한 설정만으로도 1부에서 설명드린 어노테이션을 사용하며 캐시를 구성할 수 있으며 stats (통계 활성화 여부), asynchronous (비동기 캐싱), cache-null-values(null 저장 여부) 등의 프로젝트에 맞는 추가 설정 또한 가능합니다. 자세한 사항은 Github 에서 확인 가능합니다.

Spring Cache에 앞서 Cache에 대해 정의하자면 CPU가 자주 사용하는 정보, 데이터 및 프로그램을 임시로 저장합니다. 데이터가 필요할 때 CPU는 더 빠른 데이터 액세스를 위해 자동으로 가장 가깝고 빠른 캐시 메모리에 액세스합니다. 캐시 메모리에서 데이터가 발견되면 캐시 적중이 발생합니다. 캐시 적중을 통해 프로세서는 데이터를 빠르게 검색하여 시스템의 전반적인 응답 속도 및 효율성을 높일 수 있습니다. 대신 비교적 저장 공간이 작고 비용이 비싼 단점이 있습니다.

Spring Cache

이어서 Spring Cache는 스프링 프레임워크에서 제공하는 캐싱 추상화 라이브러리로, 메서드의 결과나 데이터를 캐시에 저장하여 반복적인 계산이나 데이터베이스 액세스를 피하고 성능을 향상시키는 기능을 제공합니다. 스프링에서 사용하는 캐시는 대부분 자바 플랫폼에 대한 규격을 기술한 JSR(Java Specification Requests)-107 을 따르고 있으며 이를 따르는 캐시 구현체는 모두 추상화를 지원합니다. 추상화 단계에서는 다중 스레드, 다중 프로세스 환경을 별도로 고려하고 있지는 않으며 이는 각 구현체에서 처리되고 있습니다. '도중에 변경될 일이 없는 DB 조회 값' 또는 '자주 조회되는 데이터'에 캐시를 적용한다면 성능 향상, DB 접근 및 시스템 부하 감소의 이점을 얻을 수 있습니다.

Cache 범위

• 로컬 캐시 로컬(캐시를 저장한 서버)에서만 사용하는 캐시. 주로 서버의 메인 메모리에 위치하여 외부 시스템과 트랜잭션 비용이 들지 않기 때문에 속도가 빠르다는 장점이 있지만 분산 서버 구조에선 캐시를 공유하기 어려운 단점이 있습니다.

• 글로벌 캐시 여러 서버에서 접근할 수 있는 캐시 서버를 구축하여 사용하는 방식입니다. 주로 Redis와 같은 별도의 서버로 운영되기 때문에 서버 간 데이터 공유에 용이하지만 네트워크를 통해 접근해야하기 때문에 로컬 캐시에 비해 상대적으로 느린 단점이 있습니다.

Annotation

Spring에서는 간단한 어노테이션 만으로 캐시 추상화를 사용할 수 있습니다.

1. @Cacheable (캐시 생성)

@Cacheable("books")
public Book findBook(ISBN isbn) {...}

캐시 생성을 담당하는 어노테이션입니다. 어노테이션을 선언한 후에는 해당 캐시명을 선언해야 합니다. 최초 캐시 생성 시에는 메서드가 정상적으로 실행되나 이후 findBook 메서드가 호출될 때마다 반복할 필요가 없는 지 확인하기 위해 캐시를 확인합니다. 정상적으로 캐시가 조회되면 메서드는 실행되지 않고 저장된 캐시의 값이 반환됩니다.

1-1. 기본 키 생성

캐시는 본질적으로 key-value 저장소이므로 캐시 조회를 위해선 캐시 액세스에 적합한 키로 변환되어야 합니다. 기본키 생성은 아래의 알고리즘을 사용합니다.

• 메서드에 매개 변수가 없는 경우 : SimpleKey.EMPTY 반환
• 메서드에 매개 변수가 하나일 경우 : 해당 인스턴스 반환
• 메서드에 매개 변수가 하나 이상일 경우 : 모든 매개 변수를 포함한 SimpleKey 인스턴스 반환

1-2. 사용자 지정 키 생성

@Cacheable("books")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

모든 매개변수가 메서드에 영향을 미치지만 캐시에는 쓸모가 없는 경우 '사용자 지정 키 생성' 방식을 고려할 수 있습니다. 아래와 같이 @Cacheable 매개 변수에 key를 명시하여 직접 key를 선언합니다.

@Cacheable(cacheNames="books", key="#isbn")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

@Cacheable(cacheNames="books", key="#isbn.rawNumber")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

@Cacheable(cacheNames="books", key="T(someType).hash(#isbn)")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

키 생성을 담당하는 알고리즘이 복잡한 경우 아래 인터페이스를 구현하여 커스텀 키 생성기를 제공합니다.

org.springframework.cache.interceptor.KeyGenerator

@Cacheable(cacheNames="books", keyGenerator="myKeyGenerator")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

1-3. 캐싱 동기화

기본적으로 캐시 추상화는 캐시에 대해 락을 걸지 않으며 이는 동일한 값이 여러 번 계산되어 캐싱의 목적을 무산시킬 수 있습니다. sync옵션을 통해 대상 항목이 캐시에 업데이트될 때 까지 다른 스레드를 차단하는 기능을 제공합니다.

@Cacheable(cacheNames="foos", sync=true) 
public Foo executeExpensiveOperation(String id) {...}

1-4. 조건부 캐싱

@Cacheable(cacheNames="book", condition="#name.length() < 32") 
public Book findBook(String name)

때로는 매개변수의 특정 조건에서만 캐시 생성할 때가 있습니다. condition 옵션을 통해 위 예시와 같이 name 변수의 길이가 32보다 작을 경우에만 캐시 생성을 합니다.

@Cacheable(cacheNames="book", condition="#name.length() < 32", unless="#result.hardback") 
public Book findBook(String name)

condition과 달리 unless는 메서드가 호출된 후에 평가되며 위 예시는 메서드의 반환값 (Book)이 hardback이 아닐 경우에만 캐싱을 진행합니다.

1-5. Cache SpEL

키 또는 조건부 연산에 사용살 수 있는 표현식은 아래 표와 같습니다.

2. @CachePut (캐시 수정)

@CachePut(cacheNames="book", key="#isbn")
public Book updateBook(ISBN isbn, BookDescriptor descriptor)

메서드 실행을 방해하지 않고 캐시를 업데이트 하고 싶은 경우 @CachePut 어노테이션을 사용합니다. 이 어노테이션은 메서드는 항상 실행이 되며 그 결과는 선언한 옵션에 따라 캐시에 저장됩니다.

3. @CacheEvict (캐시 제거)

@CacheEvict(cacheNames="books", allEntries=true) 
public void loadBooks(InputStream batch)

캐시에서 자주 사용하지 않는 데이터를 삭제할 경우에는 @CacheEvict를 통해 캐시를 삭제합니다. 위 예제에서는 allEntries 옵션을 통해 books캐시의 모든 엔트리를 삭제하는 작업을 진행합니다. beforeInvocation=true 옵션을 추가한다면 메서드 실행 전에 항상 실행이 되기 때문에 메서드의 실행 여부, 예외 여부 상관없이 항상 제거를 진행할 수 있습니다.

4. @Caching (동일 캐시 작업 그룹화)

@Caching(evict = { @CacheEvict("primary"), @CacheEvict(cacheNames="secondary", key="#p0") })
public Book importBooks(String deposit, Date date)

경우에 따라 하나의 메서드에 동일한 유형(@CacheEvice or @CachePut)을 여러번 선언해야하는 경우에는 위 예시와 같이 @Caching어노테이션을 통해 어노테이션 그룹화가 가능합니다.

Summary

지금까지 캐시 추상화가 제공하는 개념 및 어노테이션을 알아봤습니다. 다음에는 이를 구현한 Provider 들을 비교해보고 간단하게 설정해보도록 하겠습니다.

TLS는 안전한 인터넷 통신을 위한 암호화 및 인증 프로토콜입니다. 주요 사용 사례는 클라이언트와 서버 간의 통신을 암호화하여 보호하는 것이지만, 보호되지 않은 네트워크를 통한 이메일, VoIP, 기타 통신을 보호하는 곳에도 사용 가능합니다. TLS 핸드셰이크는 TLS 암호화를 사용하는 통신 세션을 실행하는 프로세스입니다. TLS 핸드셰이크 중에 양측에서는 메시지를 교환하고 서로를 검증하며 사용할 암호화 알고리즘을 구성하고 세션 키에 합의합니다. TLS 핸드셰이크는 HTTPS 작동 원리의 근간을 이룹니다.

TLS Handshake 발생 시점

TLS Handshake는 위 사진과 같이 일반적으로 알고 있는 TCP 3-way-handshake가 성립된 이후에 진행이 됩니다. TLS Handshake는 HTTPS를 통해 브라우저가 처음 요청 서버를 쿼리할 때 발생하며 이후에는 생성된 세션을 활용하므로 추가적인 Handshake를 진행하지 않습니다. API 호출 및 HTTPS를 통한 DNS 쿼리를 포함하는 HTTPS를 사용할 때에도 TLS 핸드셰이크가 발생합니다.

TLS Handshake 교환 정보

• TLS 버전 (1.0, 1.2, 1.3 등)
• 암호화 알고리즘
• SSL인증서 기관의 디지털 서명 및 공개키를 통해 클라이언트 쪽에서의 서버 ID 인증 (기술적으로 모든 웹 사이트 소유자는 자체 SSL인증서 생성 후 자체 서명이 가능하지만 브라우저마다 신뢰하는 인증서 기관 목록이 있기 때문에 신뢰할 수 있는 것으로 간주되지 않습니다.)
• Handshake 이후 데이터 대칭 암복호화를 위해 세션 키 생성 및 공유

TLS Handshake 단계 (TLS 1.3 이전 - RSA 키 교환 알고리즘)

1. '클라이언트 헬로' 메시지 클라이언트가 서버로 "헬로" 메시지를 전송하면서 핸드셰이크를 개시합니다. 이 과정에서 클라이언트가 지원하는 TLS 버전, 지원되는 암호 제품군, 그리고 "클라이언트 무작위"라고 하는 무작위 바이트 문자열이 포함됩니다.

2. '서버 헬로' 메시지 클라이언트 헬로 메시지에 대한 응답으로 서버가 서버의 SSL 인증서, 서버에서 선택한 암호 제품군, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열인 "서버 무작위"를 포함하는 메시지를 전송합니다.

3. 인증 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증합니다. 이를 통해 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지를 확인합니다.

4. 예비 마스터 암호 클라이언트가 "예비 마스터 암호"라고 하는 무작위 바이트 문자열을 하나 더 전송합니다. 예비 마스터 암호는 SSL 인증서를 통해 전달 받은 공개 키로 암호화되어 있으며, 서버가 개인 키로만 해독할 수 있습니다.

5. 개인 키 사용 서버가 예비 마스터 암호를 해독합니다.

6. 세션 키 생성 클라이언트와 서버가 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 이용해 세션 키를 생성합니다.

모두 같은 결과가 나와야 합니다.

7. 클라이언트 준비 완료 클라이언트가 세션 키로 암호화된 "완료" 메시지를 전송합니다.

8. 서버 준비 완료 서버가 세션 키로 암호화된 "완료" 메시지를 전송합니다.

9. 안전한 대칭 암호화 성공 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행됩니다.

세션 키를 생성하는 과정에서 개인키를 사용하는 알고리즘 외에도 Diffie-Hellman 알고리즘을 통해서도 세션키 생성이 가능합니다.

TLS Handshake 단계 (TLS 1.3)

TLS 1.3은 RSA나 공격에 취약한 기타 알고리즘을 지원하지 않습니다. 핸드셰이크 과정이 단축되어 더 빠르고 안전해집니다.

1. 클라이언트 헬로 클라이언트는 프로토콜 버전, 클라이언트 무작위, 암호 모음 목록이 포함된 클라이언트 헬로 메시지를 보냅니다. 클라이언트 헬로에는 예비 마스터 암호를 계산하는 데 사용되는 매개변수도 포함되어 있습니다. 이렇게 하면 핸드셰이크의 전체 길이가 줄어드는데, 이는 TLS 1.3 핸드셰이크와 TLS 1.0, 1.1, 1.2 핸드셰이크의 중요한 차이점 중 하나입니다.

2. 서버가 마스터 암호를 생성 이 시점에서 서버는 클라이언트 무작위, 클라이언트의 매개변수, 암호 그룹을 받았습니다. 서버는 이미 서버 무작위를 자체적으로 생성할 수 있으므로 이미 서버 무작위를 보유하고 있습니다. 따라서 서버는 마스터 암호를 생성할 수 있습니다.

3. 서버 헬로 및 '완료됨' 서버 헬로에는 서버의 인증서, 디지털 서명, 서버 무작위, 선택한 암호 그룹이 포함됩니다. 서버는 이미 마스터 암호를 가지고 있으므로 "완료됨" 메시지도 전송합니다.

4. 마지막 단계 및 클라이언트 '완료됨' 클라이언트가 서명 및 인증서를 확인하고 마스터 암호를 생성한 후 "완료됨" 메시지를 전송합니다.

5. 안전한 대칭 암호화 성공

대칭 암복호화

위 과정을 통해 세션키가 생성이 되면 해당 세션키를 대칭키로 활용하여 요청/응답 데이터 암복호화가 이뤄집니다. 세션키를 통한 대칭키 암복호화가 아닌 매번 비대칭 알고리즘을 통해 데이터를 암복호화 한다면 성능에 영향을 미칠 것이기에 비대칭 알고리즘은 세션키 생성에만 활용됩니다.

• Response Header Field (표준, 공통 필드 제외)

월드 와이드 웹(WWW)에서 정보를 주고받기 위해 사용되는 프로토콜 중 하나로, 클라이언트와 서버 간의 데이터 통신을 위한 규칙과 프로토콜을 정의합니다. HTTP는 본래의 단순함의 대부분을 지키면서 확장성 위에서 많은 수정을 거쳐왔으며 이러한 변화 과정을 알아보고자 합니다.

HTTP/0.9 (원-라인 프로토콜)

HTTP 초기 버전으로서, 초기에는 버전 번호가 없었지만 이후에 다른 버전과 구별하기 위해 0.9로 불리게 됐습니다. 구조는 극히 단순합니다. 단일 라인으로 구성되며 프로토콜, 서버, 포트는 서버가 연결되고 나면 불필요하기에 리소스에 대한 경로 및 가능한 메서드는 'GET'이 유일했습니다.
GET /mypage.html
응답 또한 파일 내용 자체만으로 구성되어 극도로 단순합니다.
<HTML> A very simple HTML page </HTML>
해당 버전은 HTML 파일만 전송될 수 있었기에 헤더가 존재하지 않았으며 문제가 발생한 경우, 사람이 직접 처리할 수 있도록 해당 파일 내부에 문제에 대한 설명과 함께 리턴이 되었기에 상태 혹은 오류 코드도 존재하지 않았습니다.

HTTP/1.0 (확장성 고려)

• HTTP 버전 정보가 전송되기 시작했습니다. (HTTP/1.0)
• 상태 코드가 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대해 성공 또는 실패를 알게되었고, 해당 결과에 대한 동작을 설정할 수 있게 되었습니다.
• HTTP 헤더의 도입으로 요청/응답에 대한 메타데이터 설정이 가능해지고 HTTP 프로토콜을 유연하고 확장 가능한 프로토콜로 만들어 주었습니다. 또한 헤더의 도움으로 HTML문서 외의 다른 유형의 데이터를 전송할 수 있게 되었습니다.
  GET /mypage.html HTTP/1.0 User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK Date: Tue, 15 Nov 1994 08:12:31 GMT Server: CERN/3.0 libwww/2.17 Content-Type: text/html <HTML> A page with an image <IMG SRC="/myimage.gif"> </HTML>
  
  

HTTP/1.1 (표준 프로토콜)

HTTP의 첫 번째 표준 버전인 1.1버전은 1.0이 나온 지 몇 달 되지 않은 1997년 1월에 처음 공개되었습니다. (RFC 2068) 이전 버전에 비해 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다.

• 커넥션을 재사용할 수 있게 함으로써 문서 내의 리소스들을 다시 접근하기 위해 사용된 커넥션을 다시 열어 시간이 절약되었습니다.
• 파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 커뮤니케이션 레이턴시를 낮췄습니다.
• 청크된 응답 지원.
• 추가적인 캐시 제어 메커니즘이 도입.
• 언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 했습니다.
• Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 합니다.
  GET /ko/docs/Glossary/Simple_header HTTP/1.1 Host: developer.mozilla.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: https://developer.mozilla.org/ko/docs/Glossary/Simple_header
200 OK Connection: Keep-Alive Content-Encoding: gzip Content-Type: text/html; charset=utf-8 Date: Wed, 20 Jul 2016 10:55:30 GMT Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a" Keep-Alive: timeout=5, max=1000 Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT Server: Apache Transfer-Encoding: chunked Vary: Cookie, Accept-Encoding
(content)
  
  

  HTTP/2.0 (더 나은 성능을 위한 프로토콜)

  몇 년에 걸쳐, 웹 페이지는 매우 복잡해지면서, 하나의 요청에 대한 스크립트의 양과 크기는 점점 더 많이 증가하고 있습니다. HTTP/1.1 커넥션은 순차적으로 전송되는 요청을 필요로 합니다. 몇몇 병렬 커넥션이 이론적으로 사용 가능한 경우에도 여전히 많은 양의 오버헤드와 복잡도가 남아 있습니다. 이러한 상황에서 HTTP/2 프로토콜은 HTTP/1.1 버전과 다른 몇가지 근본적인 차이점은 아래와 같습니다.
• 텍스트 프로토콜 -> 이진 프로토콜. 이진 프로토콜이기에 더 이상 읽을 수도 없고 수작업을 만들어낼 수 없지만, 이런 결점에 대한 보상으로, 새로운 최적화 기술이 구현될 수 있습니다.
• 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로, 순서를 제거해주고 HTTP/1.x 프로토콜의 제약사항을 막아줍니다.
• 전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킵니다.
• 서버로 하여금 사전에 클라이언트 캐시를 서버 푸쉬라고 불리는 메커니즘에 의해 필요하게 될 데이터로 채워넣도록 허용합니다.
  

2015년 5월에 공식적으로 표준화된 HTTP/2는 정보 전송 시 오버헤드 감소로 많은 웹사이트들은 해당 프로토콜을 급속도로 받아들이기 시작했습니다. 이러한 변화는 어느 정도의 제한된 액터 세트만이 필요했고 이외에는 최신의 브라우저, 서버만 있으면 전환이 손쉬웠기에 가능했습니다.

HTTP/3 (HTTP over QUIC)

HTTP의 다음 메이저 버전인 HTTP/3에서는 전송 계층 부분에 'TCP/TLS' 대신 'QUIC(Quick UDP Internet Connection)'가 사용됩니다. Firefox에서의 구현 상태는 Firefox bug 1158011을 참조해주세요.

Switch Port는 한정되어 무한히 확장할 수 없기 때문에 물리적 Port확장이 아닌 논리적으로 Port를 확장시키는 방식인 EtherChannel을 사용하게 되는데 같은 속성을 공유하는 여러개의 Link를 논리적으로 하나의 Link로 묶어 하나의 Logical Link가 생성되므로 더 많은 대역폭을 제공할 수 있으며 물리적인 Port 또한 절약할 수 있고 2계층과 3계층의 Port 모두 EtherChannel 방식을 지원합니다.

• Ether Channel 종류 EtherChannel을 생성하고 유지하기 위해 필요한 프로토콜에는 아래의 종류가 있습니다.

1.PAgP : Cisco 전용 EtherChannel Protocol이며 EtherChannel 구성에 필요한 협상방식은 아래와 같습니다.

• On : 협상없이 Channel Member를 구성하는 Mode
• Off : 해당 Interface를 EtherChannel로 구성하지 않는다는 Mode로서 어느 한 쪽이 Off일 시 EtherChannel은 형성되지 않는다.
• Auto : 소극적으로 Channel구성을 기다리는 Mode로서 양쪽이 모두 Auto일 때 역시 EtherChannel이 형성되지 않는다.
• Desirable : 적극적으로 Channel구성을 협상하는 Mode.

2. LACP : IEEE 802.3ad 표준 방식

• On : (PAgP와 같음)
• Off : (PAgP와 같음)
• Passive : Pagp의 Auto와 같은 형태의 Mode
• Active : Pagp의 Desirable과 같은 형태의 Mode

3. Static : Protocol을 사용하지 않고 Static한 방식으로 EtherChannel을 구성하는 방식.

(L2 Ether Channel)

1. 각 Switch에 필요한 VLAN을 지정해주고 PC에 IP와 Gateway를 지정해준다.
2. EtherChannel을 설정할 Interface범위를 지정하여 해당 Mode로 진입

-Switch(config)# interface range Fa0/10-11 (SW01 기준) 3. EtherChannel을 위한 Protocol 지정 -Switch(config-if-range)# channel-protocol lacp 4. EtherChanne Group을 생성하고 해당 Port Group의 Mode를 정한다 -Switch(config-if-range)# channel-group 1(number) mode active (active / on / off / passive ) (같은 Switch내에서의 Group Number는 중복 불가) 5. 지정한 Group의 Interface (int port-channel 1)로 들어가서 Vlan공유를 위한 Trunk 설정 

(L3 Ether Channel)

1. Switch의 Configuration Mode에서 ip routing명령어를 통해 routing을 활성화
2. L2방식과 동일하게 Ether Channel을 구성
3. 지정한 Group의 Interface로 들어가 swich mode를 해제(no switchport)한 후 ip지정
4. 서로 다른 VLAN통신을 위해 Inter-VLAN지정
5. EIGRP등의 방식을 사용하여 각 L3 Switch에게 보유 Network광고 

• IP 설정 방식
  • Static IP 설정 : 고정 IP주소를 요구하는 서버에서 사용되며 사용자가 직접 지정할 시 잘못 입력될 가능성이 있어 네트워크가 연결되지 않을 수 있으므로 일반 사용자에게는 비권장되는 방식입니다.
  • Dynamic IP 설정 : 이 방식이 바로 DHCP서버를 이용하여 자동적으로 IP를 지정해주는 방식이며 사용자는 IP설정에 관해 신경 쓸 필요가 없어지게 되고 잘못된 입력가능성이 줄어들게되고 IP의 효율적 관리와 지정된 IP만 서버에 배정 및 승인하므로 보안적 목적 등의 효과가 있습니다.

DHCP 서버는 위의 사진처럼 Gateway쪽에 위치할 수도 있으며 같은 Broadcats에서 나와 외부적으로 연결될 수도 있습니다.

• IP배정 순서

1. Client는 Discover Message를 사용하여 Broadcasting방식으로 DHCP 서버를 탐색하게 된다.
2. Message를 받은 DHCP 서버는 이에 OFFER라는 응답을 하게 되는데 위에서 소개한 Gateway쪽에 위치한 경우는 Unicast로 외부에 위치한 경우는 Broadcast방식으로 응답을 하게되는데 배정이 가능한 IP를 Client에게 보내주어 최종 요정인 Request Message를 기다리게 된다.
3. DHCP 서버는 여러개 있을 수 있으므로 가장 먼저 Offer가 온 서버에게 Request Message를 보내 최종적으로 IP지정을 요청하게 된다.
4. Request 요청을 받은 Server는 IP설정을 완료한다는 Acknowledgement Message를 보내어 최종적으로 IP지정이 완료되게 된다

D.O.R.A D,R (Discover, Requset) : Client  O,A (Offer, Acknowledgement) : Server

• DHCP 설정

[같은 Broadcast위치]

1. POOL 설정 : 구분이 쉬운 단어로 이름을 지정해준다.

2. 해당 대역대 할당

3. Gateway 및 선택적 요소인 Option 지정 (DNS등 255여개)

4. 무제한으로 IP를 제공하지는 않으므로 시간을 한정 ->제한 시간의 50~87.5%가 지나면 임대 갱신 필요, 그 이후로는 갱신이 안되고 반환.

5. 특정 Service를 제공해야하는 Server나 Gateway의 주소 제외해야 할 IP주소 등을 예외처리한다

6. 결과 확인

받아간 사용자 정보 확인**

[Server 외부 위치] 같은 Broadcast안에 위치하고 있지 않은 경우 IP helper-address라고 하여 해당 Server의 IP주소를 지정 해 주어야 한다.

sw(config)# interface vlan 10 sw(config-if)# ip address 10.1.10.1 255.255.255.0 sw(config-if)# ip helper-address 10.1.100.1

목적지의 주소가 같을 경우 우선순위를 확인하여 우선순위가 가장 높은 Path를 선택하여 보내게 되는데 우선순위는 아래와 같습니다.

1. Longest Match 먼저 CIDR(=/24...)을 확인하여 체크해야하는 비트수가 많을수록 정확도가 더 높아지게 되므로 체크 비트수가 높을수록 높은 우선순위를 갖게 됩니다.

2. AD값 =>Longest Match가 같다면 다음으로는 Administrative Distance라는 관리 거리를 두어 관리자가 라우팅 정보의 신뢰도를 입력하는 정보로 낮을수록 높은 우선순위를 갖게되며, 입력하지 않을 시 Default 값은 1을 갖게 됩니다.

3. Metric값 =>다음으로는 몇 개의 Router를 거쳐야 목적지에 도착하는지의 정보를 나타내는 Metric값 역시 낮을수록 높은 우선순위를 갖게되며 Metric값은 static으로는 설정이 불가능합니다.

[Floating Static Routing]

Floating Static Routing이란 Routing의 경로에 대해 이중화를 적용하는 개념으로 Static으로 최적의 Path를 설정한 뒤 이 최적경로가 문제가 생길 경우를 대비해 Distance값을 조정하여  Backup Path를 적용할 수 있습니다.

R1 Router에 대해 100.1.3.0 /24 대역대에 대해 Best Path로는 R3방향인 10.1.13.2로 Backup Path로는 R2방향인 10.1.12.2방향을 설정하고 Distance값을 Best Path의 값(default 1)보다 높은 10설정

traceroute를 사용하여 경로를 확인하면 당연히 10.1.13.2를 향해 가는 것을 알 수 있습니다.

하지만 문제가 생긴 것을 가정하고 s1/1의 연결을 끊고 다시 확인해보면 Backup-Path인 10.1.12.2방향으로 우회하여 목적지로 향하는 것을 알 수 있습니다. => 양쪽 경로 모두 best, backup 설정이 되어야 오고가는 정보 모두 원하는 경로로 갈 수 있습니다.

• 종류
• - /proc :* 현재 동작중인 Program의 정보 저장 (volatility, 휘발성)
• - /var :* 자주 변경되는 기록 File 저장소 (비휘발성, 누적 기록 File 저장소) (대부분의 Log들은 /var/log에 저장)
• - /var/run/utmp :* 현재 접속중인 사용자의 정보를 담은 Log (단축키 w, who, users 를 통해 접속중인 사용자의 log정보를 출력할 수 있다)
• - /var/log/wtmp :* 접속을 성공했던 사용자의 Log출력 (단축키 last를 통해서도 확인 가능)
• - /var/log/btmp :* 접속을 실패했던 사용자의 로그 출력 (단축키 lastb를 통해서도 확인 가능)
• - /var/log/cron :* 주기적, 예약 작업 Log
• - /var/log/messages :* 시스템 메세지 Log (Event)
• - /var/log/secure~ :* 접속 및 인증 관련 Log
• - /var/log/spooler :* 프린트 연결 Log
• - /var/log/boot.log :* 부팅 시 시스템 장치 및 데몬 실행 상태 확인 Log
• - /var/log/xferlog :* 파일 송수신에 관한 Log -> 인증방식 또한 확인할 수 있기 때문에 보안적으로도 좋음

->/etc/loglotate.cont로 들어가서 로그인 정보를 저장하는 파일의 순환주기를 정할 수 있는데 monthly 대신에 weekly , rotate 4 등으로 주면 4주동안 해당 로그를 저장시킬 수 있으며 btmp의 missingok는 로그인이 실패해도 저장된다는 의미입니다.

• 설정

LVM에 사용될 장치들을 PV(Physical Volumn)으로 생성

• LVM 명령어
• create (생성) remove (삭제) scan (검색) display (확인) extend(확장) reduce(축소) change(속성변경)*

pvscan으로 확인한 PV설정

pvdisplay로 확인한 PV설정

LVM이라는 VG(Volumn Group)을 생성하여 PV들을 하나로 묶습니다.

EX) vgextend LVM /dev/sde => 장치 추가가능

VG를 사용하기위해 LV(Logical Volumn)을 생성하여 각자의 메모리 부여 및 -n(볼륨명)지정

** lvcreate -L [size] -n [볼륨명] [볼륨그룹]** => 500M와 같이 고정 용량 또는 100%FREE 등도 사용하여 나머지 용량을 동적으로 할당할 수 있습니다. EX)lvreduce -L -1G /dev/LVM/LV1 => 1G 줄이기

LV를 사용하기 위해 포맷 실행

tune2fs -L [라벨명] [LV명]을 사용하여 라벨링이 가능합니다.

e2label [LV명] [라벨명] 또한 라벨링이 가능하며 해당 LV의 라벨을 확인할 수 있습니다.

영구 마운트를 위해 fstab수정 및 마운트 확인

장치명 공간에 부여한 Label을 입력하고 마운트 정보를 입력합니다.

• 설정 (Level 5)

RAID로 묶을 하드디스크를 추가합니다. mdadm  --create(-C) [/dev/md(x)] --level(-l) [0~6] --raid-devices(-n) [sdb(x)]

RAID생성 명령어를 사용하여 /dev/md5란 이름의 level 5단계로 sdb,sdc,sdd까지 3개의 디바이스를 묶습니다.

마운트를 위한 포맷

마운트 및 mount -a로 마운트를 확인합니다.

blkid란 명령어로 추가된 디바이스의 UUID및 구조 확인이 가능합니다.

/etc/fstab에 추가하여 영구적으로 마운트를 하기위해 awk명령어로 UUID만을 추출하여 redirection으로 추가합니다.

mdadm -D(Detail)로 확인할 수 있는 생성된 RAID의 구조

정상적으로 추가되는 파일

level 5는 각 하드에 분산패리티영역이 생성되기 때문에 랜덤한 하드 1개가 오류가나도 복구가 가능합니다.

-> /dev/sdb를 제거한 상태

정상적으로 생성되는 파일

하지만 장치를 하나 더 제거할 시 읽기전용 파일 시스템으로 변환되어 파일을 생성할 수 없게됩니다.

• ** RAID 관련 명령어**
• mdadm /dev/md5  -f (기존 디바이스 비활성)* -r (기존 디바이스 삭제) -a (RAID에 새로운 디바이스 추가)
• mdadm --stop(-S) /dev/md5 (RAID 비활성)*

• DoS(Denial Of Service) Attack? 시스템을 악의적으로 공격해 해당 시스템의 리소스를 부족하게 하여 원래 의도된 용도로 사용하지 못하게 하는 공격. 대량의 데이터 패킷을 통신망으로 보내고 특정 서버에 수많은 접속 시도를 하는 등 다른 이용자가 정상적으로 서비스 이용을 하지 못하게 하거나, 서버의 TCP 연결을 바닥내는 등의 공격이 이 범위에 포함된다.

• Scapy? : 파이썬으로 작성된 패킷 조작 도구로서, 패킷 디코딩, 패킷전송, 패킷 캡쳐, 패킷 수정 등의 다양한 기능이 있다

• 실습 환경

  • 공격자 : 192.168.1.129
  • 희생자 : 192.168.1.130

위와 같이 scapy를 실행하면 파이썬 언어를 인식하는 인터프리터가 다음과 같이 나오며 필요에 따라 라이브러리를 추가로 설치해야 스크립트가 정상적으로 작동하는 경우가 있습니다.

ls()와 같이 입력한다면 scapy에서 지원하는 프로토콜들을 보여줍니다.

lrs()를 입력한다면 scapy에서 사용가능한 기능들을 보여줍니다.

공격을 위해 공격자 PC에서 iptables를 사용하여 TCP 플래그가 RST인 패킷을 DROP시킵니다.

#iptables -A OUTPUT -p tcp --tcp-flags RST RST -J DROP #iptables -L

scapy를 실행하여 IP헤더를 확인하는 IP()를 입력하여 아직 아무 것도 없는 것을 확인할 수 있으며 display() 함수를 사용하여 좀 더 자세히 봄으로써 src,dst모두 루프백주소로 되어 있는 것을 확인할 수 있습니다.

IP(dst="192.168.1.130").display

를 입력한다면 위와 같이 헤더 내용이 바뀌는 것을 확인할 수 있지만 아직까지는 실제로 변경된 것은 아닙니다. IP 주소 대신 도메인 주소를 넣어도 무관합니다.

위와 같이 TCP 또한 같은 방법으로 헤더 내용 확인 및 헤더의 값 변경이 가능합니다.

위의 값들을 실제 변수에 넣기위해

>>>ip=IP(dst="192.168.1.130") >>>tcp=TCP(sport=RandNum(1024,65535), dport=80, flags='S') >>>syn=ip/tcp >>>syn.display()

를 사용하여 변수 값 변경 및 내용을 확인합니다. TCP의 sport는 RandNum함수를 사용하여 Well-Known 포트를 제외한 1024-65535포트 중 하나를 선택하며 syn이라는 변수에 /로 구분을 하여 ip,tcp 값을 넣어줍니다.

실제로 tcp의 three-way-handshaking 과정을 확인하기 위해 three-way-handshake를 맺는 파이썬 스크립트를 위와 같이 작성합니다. sy1()함수를 사용하여 syn변수에 정의된 패킷을 보내고 그 응답(syn+ack)를 syn_ack에 저장한 후 ack변수에 응답 값을 설정하여 보냅니다.

희생자 PC에서 apache서버를 구동합니다.

공격자 PC에서 작성한 스크립트를 실행하여 패킷을 보냅니다.

공격자 pc에서 wireshark를 사용하여 패킷을 분석해보면 정상적인 three-way-handshake 과정을 확인할 수 있습니다.

• TCP SYN Flooding? 3-way-handshake를 맺을 때, 공격자가 희생자의 listen 포트로 연결을 요청하는 SYN패킷을 보낸 후 SYN+ACK를 받게 된다. 하지만 이 후 최종적으로 ACK패킷을 보내지 않게 된다면 서버는 Half-open상태로 변하며 일정 기간(약 75초) ACK를 기다리며 Backlog Queue 메모리 공간에 SYN정보를 계속 쌓아두게 된다. 이러한 공격이 계속된다면 희생자 서버는 더 이상 SYN을 받을 수 없는 상태가 되며 이를 TCP SYN Flooding공격이라 한다.

TCP SYN Flooding을 실습하기 위해 공격자 PC에서 위와 같은 파이썬 스크립트를 작성합니다.

희생자 PC에서

#sysctl -a | grep syncookies

를 사용하여 syncookies가 설정되어 있는지 확인합니다.

• Syncookies? syncookies가 설정되어 있다면 syn+ack 패킷을 보낼 때 seq num을 쿠키 값으로 설정한다. 상대방 ack패킷이 쿠키 값+1로 설정되어 있지 않으면 비정상 패킷으로 받아들여 연결을 맺지 않게 된다.

#sysctl -w net.ipv4.tcp_syncookies=0

을 사용하여 해당 값을 초기화 시킵니다.

공격자 PC에서 위에서 작성한 스크립트를  스크립트명, 희생자 IP, 희생자 PORT와 함께 실행한다면 위와 같이 실행되게 됩니다.

브라우저를 열어 희생자 PC IP로 정상적인 접근을 한다고 하더라도 무한루프가 돌게 되어 접근이 불가능 합니다.

또한 wireshark를 사용하여 syn+ack만을 주고 받는 것을 확인할 수 있습니다.

희생자 pc에서 half-open 상태의 소켓을 확인하는

#netstat -an | grep -i syn_recv

를 사용하여 공격자의 random포트에게 syn를 받은 채 대기중인 상태임을 알 수 있습니다. 이번에는 응용 계층의 http 프로토콜의 취약점을 사용한 slowloris attack를 실습해봅니다.

• Slowloris attack? http 헤더가 끝날 때, 개행(carriage return line feed)을 두 번 하게되어 헤더와 데이터를 구분하는데 slowloris attack은 헤더 마지막 부분에 \r\n\r\n대신 \r\n 한 번만 보내 아직 헤더가 더 남은 것처럼 서버를 속여 해당 연결을 계속 유지하게 한다.

공격자 pc에서 위와 같이 script를 입력합니다.

해당 스크립트를 공격자 pc에서 희생자 ip, 연결 횟수와 함께 실행을 시킨 후 희생자 pc의 브라우저에서  http://localhost/server-status를 입력하여 현재 apache의 상태를 확인하면 연결 상태들이 모두 R(읽고 있는 상태)임을 알 수 있습니다.

wireshark를 사용하여 해당 패킷을 hex dump모드로 확인하면 개행문자 0d 0a가 한 개 밖에 없는 것을 확인할 수 있습니다.

또한 ascii모드로 확인한다면 개행으로 인한 헤더와 데이터 구분 없이 확인을 위한 메세지가 헤더에 이어 작성된 것을 알 수 있습니다.

• Nmap(Network Map)? 고든 라이온(Gordon Lyon)이 작성한 보안 스캐너. 컴퓨터와 서비스를 찾을 때 쓰이며, 네트워크 "지도"를 함께 만듭니다. 다른 간단한 포트 스캐너들처럼, Nmap은 서비스 탐지 프로토콜로 자신을 광고하지 않는 수동적인 서비스들도 찾아낼 수 있습니다. 게다가 Nmap은 원격 컴퓨터들의 자세한 정보를 알아낼 수 있으며 주요 항목들은 아래와 같습니다.
  • 운영체제
  • 장치 종류
  • 운영 시간
  • 서비스에 쓰이는 소프트웨어 제품
  • 그 제품의 정확한 버전
  • 방화벽 존재 여부
  • 근거리 네트워크의 네트워크 카드 공급자
  • 네트워크 연결된 호스트들의 IP/OS
  • 서버의 열린 포트

이를 통해 공격자는 침투에 필요한 정보를 얻을 수 있으며 방어자는 불필요하게 노출되는 정보를 확인하여 방어를 할 수 있습니다.

• 실습 환경
  • 공격자 IP : 192.168.1.129
  • 희생자 IP : 192.168.1.130

테스트를 위해 희생자 pc에서 ftp,dns,http서비스를 시작한후 wireshark를 실행합니다.

공격자 pc에서 nmap을 사용하여 확인 시 희생자 pc에서 열려있는 21,53,80 포트 번호의 서비스를 확인할 수 있습니다.

희생자 pc에서 실행한 wireshark로 확인 시 열린 포트들에 대해서는 SYN+ACK를 보내지만 닫혀진 포트에 대해서는 RST패킷을 전송하여 연결을 종료합니다. 이러한 스캔 방식을 TCP Half(SYN) Open Scan이라고 하며 불완전한 TCP 세션 과정에서 Open된 Port를 확인하며 Log를 남기지 않습니다. 옵션을 주지 않는다면 -sS(TCP Half open scan)과 같은 의미로 스캔합니다.

[TCP Half Open Scan]

로그를 남기기 때문에 많이 쓰이진 않지만

#nmap -sT [IP Address]

를 사용하면 완전한 세션을 맺어 로그를 남기는 TCP Open Scan을 실행합니다.

[TCP Open Scan]

스캔하는 대상에 로그를 남기지 않는 Stelth Scan에는 TCP Half Scan, FIN Scan, Xmas Scan, Null Scan이 있으며 옵션은 다음과 같습니다.

<FIN Scan>

열린 포트라면 아무 응답이 오지 않으며, 닫힌 포트이면 RST응답이 옵니다.

<X-mas Scan>

공격자는 FIN,PSH,URG 패킷을 보내며 열린 포트이면 아무런 응답이 오지 않고 닫힌 포트이면 RST 응답이 돌아옵니다.

<Null Scan>

공격자는 Null 패킷을 보내며 열린 포트이면 아무런 응답이 오지 않으며, 닫힌 포트라면 RST 응답이 돌아옵니다.

이외에도 포트를 지정하는 옵션 -p와 OS를 판별하는 옵션 -O를 사용하여 추가적인 정보를 얻는 것이 가능합니다.

UNIX/LINUX에서 Name Server를 운용하기위한 패키지인 BIND(Berkeley Internet Name Domain)을 설치합니다. BIND패키지를 사용하면 도메인을 IP로 변환시켜 주는 DNS Server구축이 가능합니다.

설치 후 패키지내 /etc/bind에서 목록을 확인합니다.

zone 파일의 기본형식인 db.local파일을 복하사여 db.zone파일로 설정합니다.

• zone file? 도메인 네임과 IP를 매핑한 정보들이 들어 있는 중요한 파일. DNS 서버는 ZONE파일을 읽어 도메인 주소를 IP주소로 변환한다.

웹서버,ftp서버,메일 서버를 humanist.hum.kr라는 도메인으로 묶어주기 위해 db.zone파일의 정보를 위와 같이 수정합니다. 각 레코드의 정보는 아래와 같습니다.

• TTL(Time To Live) : DNS 캐시를 저장하는 기간을 초단위로 나타냄. ZONE파일에서 가장 먼저 선언되어야 합니다.
• @ : $ORIGIN 지시어라고 하며 도메인 주소 원형을 뜻한다. named.conf.local에 설정해 줄 도메인인데, 여기서는 humanist.hum.kr.로 설정했습니다.
• IN : 클래스로서 iNTERNET을 나타낸다.
• SOA(Start Of Authority) : zone파일의 시작을 알리며 네임 서버 주소(ns.humanist.hum.kr.)와 관리자 메일 주소(root.humanist.hum.kr.)를 정의하고 소괄호를 이용하여 몇 가지 설정을 해줍니다. 도메인 끝에 오는 '.'는 최상위 root도메인을 의미합니다. 브라우저에서는 자동으로 최상위 도메인을 처리하기 때문에 표시하지 않아도 되지만 zone파일에서는 표기해줘야 합니다.
• NS : 네임서버의 도메인 주소(localhost.으로 매핑). localhost.는 SOA레코드에서 설정한 ns.humanist.hum.kr.과 같습니다.
• MX : 메일 서버의 라우팅 경로. MX 다음의 숫자는 Priority number로서 우선순위를 나타냅니다.
• A : 도메인 주소에 IPV4를 매핑합니다.
• AAAA :** 도메인 주소에 IPV6를 매핑합니다.

#vi named.conf.local

위와 같이 zone파일의 형식과 경로를 지정해줍니다.

bind데몬을 재시작한 후

#vi /etc/resolv.conf

에서 

nameserver 192.168.1.130 (서버주소) nameserver 168.126.63.1 (한국통신 DNS 서버 주소)

를 설정한 후 Ping을 통해 확인합니다.

네임 서버가 등록된 공격자 PC에서

#dnsmap humanist.hum.kr

을 실행하여 dns정보 수집을 시작합니다. 위 경우는 8개의 도메인 네임과 8개의 ip를 찾았다는 메세지가 출력됩니다.

희생자 PC에서 wireshark를 통해 확인합니다. Filter창에 dns를 입력하연 목록 창에 dns관련 패킷만 표시되며

dns.flags.response == 0이면 DNS조회 목록이 dns.flags.response == 1을 입력하면 DNS 응답 목록이 출력됩니다.

dns.flags.rcode != 0을 입력하면 DNS응답 중에 에러만 필터링해서 출력합니다.

위와 같이 [Analize] > [Display Filter]에서 필터를 저장하여 사용이 가능합니다.

• DNS Spoofing? DNS 스푸핑(DNS spoofing) 또는 DNS 캐시 포이즈닝(DNS cache poisoning)은 변질된 DNS 데이터가 DNS resolver의 캐시에 유입되어 네임 서버가 유효하지 않은 결과 레코드(예: IP 주소)를 반환합니다. 이를 통해 공격자의 컴퓨터(또는 다른 컴퓨터)로 공격 우회를 할 수 있습니다.

• 실습 환경

  • Web Server : Apache2
  • 공격자 IP : 192.168.1.128
  • 희생자 IP : 192.168.1.130

먼저 공격자 host 쪽에서 웹서버 데몬인 apache2를 실행합니다.

이 후 사용할 LAN구간에서 Man-IN-THE-MIDDLE공격을 하기 위한 무료 Opensource dns spoofing 도구인  Etter cap의 host 파일(/etc/ettercp/etter.dns)을 위와 같이 수정하여 희생자가 naver나 google로 접속할 시 공격자가 지정해놓은 ip로 들어올 수 있도록hosts파일을 수정합니다. 이렇게 한다면 dns server를 직접적으로 공격하지 않아도 hosts file의 변조를 통해 DNS Spoofing 공격을 실행할 수 있습니다.

공격자 PC에서 'etthercap -G'을 입력하여 ettercap GUI를 실행한 후 Sniff 탭의 unified sniffing을 선택합니다.

Network interface로 eth0을 선택한 후 scan for hosts를 선택하여 같은 LAN구간에 있는 hosts를 스캔한 후 게이트웨이인 192.168.1.2를 Target 1로, 희생자 ip인 192.168.1.130을 Target 2로 지정합니다.

Mitm메뉴의 arp posisoning을 선택한 후 Sniff remote connection을 체크하여 이로 인해 공격자가 둘 사이로 들어가 arpspoofing을 할 수 있도록 설정합니다.

마지막으로 Plugin메뉴의 Manage the plugins를 선택한 후 dns-spoof를 활성화합니다.

이로 인해 희생자 pc에서 위와 같이 www.google.com으로 접속을 시도하면 arp spoofing과 dns spoofing으로 공격자의 web server가 표시되게 됩니다. 이렇게 되면 희생자의 DNS Cache table에서 google과 관련된 cache가 공격자 ip로 바뀌어 있기 때문에 cache가 유지되어 있는 동안에는 공격자의 web server가 계속 나타나게 됩니다.

C:\>ipconfig /flushdns (windows) , $ sudo /etc/init.d/nscd restart (Unix/Linux)

등의 명령어로 dns cache table을 초기화합니다. =>DNS Spoofing의 대응방안으로는 앞에서 위조했던 hosts파일의 무결성을 검사하거나 dns cache의 Poisoning을 보호하는 솔루션을 사용(DNSSEC...) 또는 이전에 다뤄봤던 ARP Spoofing 방지 솔루션을 사용하여 대응할 수 있습니다.