Question


현재 저희 서비스의 Access Log 확인 결과, 어떤 Device로 접근하던 두가지의 IP만 확인되고 있습니다.


해당 현상의 원인 확인 요청 드리며, Access Log, Error Log 조회 시 클라이언트의 접속 IP를 확인할 수 있도록 조치 바랍니다.

( 작업 시 서비스 영향도 검토 부탁드립니다. )

또한 각 ELB의 로그를 활성화하고 싶습니다. ( 가능하시다면 ELB 로그에서 표시되는 로그 형태에 대해 항목별로 자세한 설명 부탁드립니다. )




Answer


안녕하세요. SRE 5팀 강혜수입니다.


문의 주신 내용을 다음과 같은 내용으로 파악하였습니다.


1. Access Log 확인 결과, 어떤 Device로 접근하던 두가지의 IP가 확인되는 현상 원인 확인

2. 작업 시 서비스 영향도

3. Access Log, Error Log 조회 시 클라이언트의 접속 IP를 확인할 수 있도록 조치

4. ELB의 로그 활성화


이번 시간에는 클라어언트의 접속 IP 확인 및 ELB 로그를 활성화하는 방법을 알아보겠습니다 :)




1 프록시 서버

1.1 Proxy 서버란 ?

  • 서버와 클라이언트 사이에서 중계 역할을 하며, 대리로 통신을 수행하는 서버를 말합니다.

                   

1.2 Proxy 서버 사용시 유의 사항

  • 웹 네트워크 통신에서 로드밸런서의 동작위치는 다음과 같습니다.
    고객(Client)↔로드밸런서(LB)↔서버(Server)
  • 서버 입장에서는 통신의 상대가 고객이 아니라 로드밸런서(LB)가 됩니다.
  • 따라서 Client IP를 저장하고 처리해야하는 시스템이라면, 이러한 Proxy 환경을 위해 추가적인 작업이 필요합니다.


2 X-Forwarded-For(XFF)

2.1 X-Forwarded-For(XFF)란 ?

  • HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하기 위해 사용하는 표준헤더입니다.
  • 웹 서버나 WAS 앞에 L4 같은 Load balancer나 Proxy server 등의 장비가 있을 경우 웹 서버는 Proxy server나 장비 IP에서 접속한 것으로 인식합니다.
  • 그렇기 때문에 웹서버는 실제 클라이언트 IP가 아닌 앞단에 있는 Proxy server IP를 요청한 IP로 인식하고, Proxy장비 IP로 웹 로그를 남기게 됩니다.



2.2 X-Forwarded-For 적용 과정 (Access log)


1. 웹 서버에서 httpd.conf 파일 수정합니다.

  • LogFormat에 xforwardedfor라고 정의해준 별명을 CustomLog지시문에 똑같이 정의해줍니다.


    [로그 항목별 설명]
  • %{헤더명}i : 요청에 포함된 헤더명의 값 
  • %h : 원격 호스트 이름 
  • %l : 클라이언트 식별자 
  • %u : 인증 사용자명 
  • %t : 시간 
  • %r : 요청의 첫번째 행의 값
  • %>s : 마지막 응답의 상태 
  • %b : 전송된 바이트 수(헤더는 제외), 0바이트인 경우 '-' 



2. ALB의 DNS로 접속을 합니다.

  • Access log를 확인해보면 Client IP가 제일 앞단에 위치한 것을 확인할 수 있습니다. 
  • ALB는 퍼블릭 서브넷에 위치해 있기 때문에 그 영역대의 아이피로 번갈아가면서 확인됩니다.


2.3 X-Forwarded-For 적용 과정 (Error log)

  • ErrorLogFormat을 통해서 에러로그의 형식을 지정해줍니다.


    [로그 항목별 설명]
  • %t : 시간 
  • %l : 로그 레벨 
  • %7F : 문제가 발생한 소스 파일의 이름과 line number 기록 
  • %E : 에러 Status Code 
  • %{헤더명}i : 요청에 포함된 헤더명의 값 
  • %M : 실제 로그 메세지 내용 
  • %{Referer}i : Request의 Referer


  • 에러를 발생시키기 위해 접근 제한을 설정해줍니다.


  • 잘못된 경로로 접근했을시, 에러로그가 발생합니다.
  • 에러로그를 확인해보면, client 접속 IP가 보이는 것을 확인할 수 있습니다.



3 ELB 로그 활성화

3.1 ALB S3 Access log 확인

  • ELB에 Access log를 활성화 하려면, 로그가 저장될 S3 버킷을 생성하여야 합니다. 
  • 또한, 생성한 버킷의 경로와 함께 ELB의 액세스 로그를 활성화 시켜주어야 합니다. 


1. ELB의 로그가 저장될 버킷을 생성합니다.
 



2. S3 버킷의 폴더를 생성해줍니다. 


   



3. 버킷 정책을 생성해줍니다.



4. AWS Policy Generator에서 다음과 같이 설정해준 후 Add Statement 버튼을 클릭합니다.


  • [Step 1: Select Policy Type]
    - Select Type of Policy : S3 Bucket Policy
     
  • [Step 2: Add Statement(s)]
    - Effect : Allow - Principal : ELB 리전에 해당하는 Account ID (ex. 서울 리전 : 600734575887)
    - Actions : PutObject
    - Amazon Resource Name (ARN) : arn:aws:s3:::bucket/prefix/AWSLogs/aws-account-id/*




5. 생성된 표에 값이 맞는지 확인을 해준 후, Generate Policy 버튼을 클릭합니다.



6. JSON 포멧의 Policy를 복사해줍니다.



7. 콘솔로 돌아와서 붙여 넣어 줍니다.




8. Save changes 버튼을 클릭해서 정책을 적용시켜줍니다.



9. ELB의 액세스 로그를 활성화 시켜 준 후, S3 버킷 명을 입력해줍니다.

(ex. alb-log-001/myapp01 : alb-log-001버킷의 myapp01 폴더)



10. S3에서 해당 시간에 맞게 생성된 Access Log 파일을 확인합니다.



11. Open 또는 Download 버튼을 클릭합니다.



12. ELB의 로그 및 클라이언트 접속 IP가 잘 찍히는 것을 확인할 수 있습니다.




4 참고 자료

아파치 공식 페이지 : http://httpd.apache.org/docs/2.4/logs.html#errorlog

아파치 공식 페이지 : https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat

AWS Docs : https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-access-logs.html



읽어주셔서 감사합니다 ! ??