개인적인 IT관련 내용 정리

메모리 누수가 의심될때 한가지는 스왑 메모리의 사용량이다. 아래 내용으로 간단히 확인 가능하다.

• 배경
  • 리눅스는 free 메모리를 최대한 cache 메모리로 사용하여 시간이 지날수록 cache 메모리 사용량이 증가하면서 애플리케이션의 로딩 속도가 향상됨.
    • free 메모리가 필요한 순간에는 cache 메모리를 줄이고 free 메모리를 확보함.

• top 예제

• 

• ※ 위 그림에서 used는 실제 메모리 사용량이 아니라 빨간색으로 묶은 buffers + cached, 그리고 여기에 표시되지 않은 다른 메모리사용량(실제 메모리 사용량)을 합한 값으로 보여지게 된다.

• free 예제

• 

• 
  
  
  • 실제 메모리 사용량을 확인할 수가 있는데, 빨간색으로 보여지는 부분의 used가 실제 메모리 사용량이고 free가 실제 여유 메모리를 나타낸다.
    • 첫번째 라인의 used는 buffers + cached + 실제 메모리사용량 --> 1420 = 167 + 1072 + 180 (mb로 표시하여 1의 오차가 발생, free -k로 보면 값이 정확함)
    • 두번째 라인의 free는 첫번째 라인의 free + buffers + cached --> 1845 = 606 + 167 + 1072 (mb로 표시하여 1의 오차가 발생, free -k로 보면 값이 정확함)

게임 포털 웹서비스 조직에서 개발자 지원 업무를 하고 있었을때 발생한 보안 이슈였고 원인과 해결 방법에 대해 정리해본다.

1. 현상

사이트내 갤러리 게시판이고, 이미지를 클릭하면 다운로드하는 형태.

특정 url의 response 데이터에 /etc/passwd 내용이 노출되었다,

ex) http://xxx.xxx.com/xxx/xxx?param=file%3A%2F%2F%2Fetc%2Fpasswd

2. 원인

원래는 http://xxxxxx 식의 이미지 경로가 들어와야 하는 하며, 내부 로직에서는 들어온 파라미터를 이용해 

new Url("http://xxxx") 처리를 하도록 되어 있다. 문제는 파라미터로 들어온 file%3A%2F%2F%2Fetc%2Fpasswd

 url decoding을 하면 file:///etc/passwd 값인데 Url클래스가 로컬 파일 접근이 가능하기 때문에 

password 가 response 에 고스란히 노출되었던 것이었다.

3. 해결

기본적으로 XssFilter 적용이 되어 있어서 CRCF injection (http://www.acunetix.com/websitesecurity/crlf-injection/) 

공격과  directory/path traversal 도 되지 않도록 아파치 설정이 되어 있어 노출만 될뿐 추가적인 피해는 없었다.

따라서 아래와 같은 방법으로 해결하도록 가이드하여 적용하였다.

1. 파일 확장자 체크 - 정해진 확장자만 허용  (.gif, .jpg, .png )

2. URL 클래스 사용시 새로운 객체 생성에서 url에 HTTP만 허용 (ftp, telnet, file 등은 사용하지 않도록)

 추후에라도 파일 다운로드를 하는 웹서비스를 할 경우 까먹지 말고 유의하도록 해야겠다.

연관 이슈

sql injection, xss, parameter manipulation, buffer overflows, directory/path traversal etc.

                                                                    그림. L4 DSR 처리 방식

클라이언트와 먼저 3way handshaking을 한 뒤 정상적이면 2차로 서버와 동일하게 3way handshaking을 하게 된다.

이 과정 후에 클라이언트가 http로 보낸 요청에 대해 서버가 요청을 처리하게 되면 L4로 경유하지 않고 바로 L3 스위치를 통해

클라이언트와 서버 모두 FIN을 보내지 않기 때문에 L4에 저장된 세션 정보의 Destination Ip를 보고 동일한 서버로 요청이 들어가게 된다.

* 주요 L4 Switch 설명

  1. SLB (Server Load Balancing)

       - 과거에 서비스를 했었던 방법으로 클라이언트에서 서버로 보낼때와 서버에서 리턴될때 모두 L4 Switch를 거치기 때문에 과부하가 걸리는 서비스의 경우 DNS RR방식으로 서비스를 구성하기도 한다.

  2. GSLB (Global Server Load Balancing)

       - 특정 도메인으로 들어온 요청을 분산시키는 방법으로 도메인 네임에 대한 쿼리 요청에 대해 응답을 변형하여 지역적으로 분산시킨다.

  3. DSR (Direct Server Return)

       - 현재 인프라에서 적용하여 사용하는 방법으로 SLB 방식으로 인한 L4 Switch의 과부하를 막기 위해 서버에서의 응답이 바로 클라이언트로 보내도록 한다.  위의 그림과 같이 동작하게 된다.