천객만래 [千客萬來] (It has an interminable succession of visitors)

Sandbox 샌드박스

IT - 과학 2020. 11. 24. 00:37
반응형

보안 샌드박스 - 웹 서비스 API 

보호된 범위 내에서 프로그램을 작동시키는 보안 소프트웨어 기술. 샌드박스(sandbox)는 보호가 필요한 어린아이들을 위해 모래통에서만 놀도록 하는데서 유래한 소프트웨어 보안 개발기법이다.

웹 브라우저는 한 도메인의 리소스가 다른 도메인의 리소스에 접근하지 못하도록 제한하는 샌드박스(Sandbox) 메카니즘을 구현한다. 예를 들어, 사용자 데이터의 수정 및 검색을 허용하는 API와 이 API에 대한 인터페이스를 제공하는 웹사이트가 있을 수 있다. 브라우저가 '동일 출처 정책(same-origin-policy)'을 구현하지 않은 상태에서 사용자가 자신의 세션에서 로그아웃하지 않는다고 가정하면, 악성 페이지가 사용자에게 알리지 않고 API에 요청을 보내고 수정할 수 있다.

관련 기술은 JSONP(패딩된 JSON)과 CORS(Cross-Origin Resource Sharing)

 

규제 샌드박스(sand box)

규제 샌드박스(sand box)는 신기술이 출시될 때 기업에 불합리한 규제를 면제 또는 유예하는 제도다. 이 가운데 임시허가는 정부가 제품과 서비스의 출시를 일시적으로 허용하는 것이고, 실증특례는 제품 ・ 서비스를 검증하는 동안 규제를 면해주는 제도다. 실증특례 허가를 받은 기업은 일단 2년간 서비스를 제공하고, 이 기간에 문제가 없을 경우 1회 연장해 총 4년 동안 규제를 유예받을 수 있다.

 

샌드박스 (미국, 어린이용품)

아이가 안에 들어가서 노는 모래상자

 

 

 

반응형

'IT - 과학' 카테고리의 다른 글

MAC 숨김파일 보기  (0) 2021.01.31
보스턴다이나믹스, 이제 할 수있다  (0) 2021.01.04
Sandbox 샌드박스  (0) 2020.11.24
변수명 짓기  (0) 2020.05.11
화상회의 솔루션 점유율  (0) 2020.04.10
과제할 때 꿀팁 사이트  (0) 2020.02.10
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

큰 숨
의도적이거나 안도의 행동으로 하는 것으로
복식호흡으로 안 공기를 밖으로 내보내고 바깥 공기를 안으로 들이마시는 행동으로
하고 나면 리프레시한 기분이 듭니다.

한 숨
근심이나 설움이 있을 때나 긴장했을 때, 무의식 중일 때 짜증이 날 때
크고 길게 내쉬는행동입니다.
여운이 생깁니다.

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

[apache] HTTP/HTTPS 리다이렉트(Redirect/Rewrite) 하는 방법

 

1. 개요

Apache에서 HTTP/HTTPS 프로토콜 별로 리다이렉트/라라이트 하는 방법.

 

2. 활용

RewriteCond %{HTTPS} on/off 설정을 이용하여 프로토콜 별로 처리할 수 있다.

 

Rewrite를 추가하는 부분에서 SSL 인증서를 사용하고 있다면 [P] 옵션을 사용하기 때문에  (P=Proxy)

SSLProxyEngine On 설정을 추가해줘야 한다.

 

Proxy를 사용하지 않아도 될 경우에는 [P,R,L] -> [R=301,L] 사용

 

ㅁ HTTP를 HTTPS로 리다이렉트 

   <IfModule mod_rewrite.c>

        RewriteEngine On

        RewriteCond %{HTTPS} off

        RewriteRule (.*) https://%{HTTP_HOST}/$1 [P,R,L]

   </IfModule>

 

 

ㅁ  HTTPS를 HTTP로 리다이렉트

 SSLProxyEngine On    => SSL 인증서를 이용하고 있다면 넣어줘야 한다.

   <IfModule mod_rewrite.c>

        RewriteEngine On

        RewriteCond %{HTTPS} on

        RewriteRule (.*) http://%{HTTP_HOST}/$1 [P,R,L]

   </IfModule>

 

 

ㅁ HTTP/HTTPS를 고려하여, 받은 URL 그대로 리다이렉트.

 SSLProxyEngine On  => SSL 인증서를 이용하고 있다면 넣어줘야 한다. 

   <IfModule mod_rewrite.c>

        RewriteEngine On

        RewriteCond %{HTTPS} on

        RewriteRule .* https://%{HTTP_HOST}/$1 [P,R,L]

        RewriteCond %{HTTPS} off

        RewriteRule (.*) http://%{HTTP_HOST}/$1 [P,R,L]

   </IfModule>

 

 

ㅁ 

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}%/$1 [L,R=301]

 

1)  RewriteCond %{HTTPS} off

    - HTTP로 접속 된 경우,

 

2) RewriteRule의 [R,L]

[L]은 정의의 마지막 줄(Last)을 의미함. 이 줄 아래의 RewriteRule은 모두 무시. 가장 마지막 행에 씀.

[L]을 쓰지 않아도 동작은 함.

[R]은 리다이렉트 실행함. 

 

 

=============================================================================[apache] http -> https로 리다이렉트 처리

 

ㅁ httpd-vhosts.conf 수정

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

 

1. RewriteEngine On

   - RewriteEngine 활성화

 

2. RewriteCond %{HTTPS} off (or !=on)

   - 조건 : HTTPS 가 아니면   

 

3. RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

   - R=301은 301 리디렉션이라는 뜻이고, L은 마지막이라는 뜻입니다.

     L은 반드시 필요한건 아니지만 R=301은 반드시 해줘야 합니다. 저게 빠지면 302 리디렉션이라고 감지합니다.

     (301은 영구적인 이동, 302는 일시적인 이동)

 

ㅁ 유사한 처리 방식

Redirect permanent / https://hanajava.net

 

 

참고 : https://httpd.apache.org/docs/2.4/ko/mod/mod_alias.html 

 

(https://%{HTTP_HOST}/$1 이랑 https://%{HTTP_HOST}%{REQUEST_URI}  둘 다 잘 작동함)

https://%{HTTP_HOST}/$1 (O - 올바른 설정)

https://%{HTTP_HOST}$1 (X - 잘못된 방식) : 이렇게 설정하면 최상위 도메인까지만 되고 그 이하 페이지는 리다이렉트가 안됨.

 

 

 

4. 그 외

- https://(도메인)\.(도메인)/$1 [R=301,L] 이런 방식이 있는데, 이것도 잘 작동합니다.

 

(.*)이 아니라 ^(.*)$라고 되어 있는것도 많은데 별 차이는 없다고 하네요

 

Redirect permanent / https://example.com

 

 

ㅁ NGINX 설정 방법

# Redirect non-https traffic to https

if ($scheme != "https") {

return 301 https://$host$request_uri;

} #

 

[출처] [apache] HTTP/HTTPS 리다이렉트(Redirect/Rewrite) 하는 방법|작성자 하나자바

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

아파치 로드밸런싱으로 여러 WAS 운영하기

Aug 04, 2019 in tech

 

웹서버 하나만 사용하거나 WAS 하나만을 사용하며 웹서비스를 운영하는 경우는 극히 드물다. 웹서버의 장점과 WAS의 장점 그 두마리의 토끼를 다 잡기 위해 보통 앞단에 웹서버를 두고 그 뒤에 WAS를 두며 서비스를 운영하곤 한다. 헌데 운영하는 서비스가 인기가 많아져(?) 사용량이 많아지다면 그만큼 응답이 느려 (TPS 등) 서버를 늘려야 하는 상황이 생긴다고 가정해보자. (물론 서버를 늘리는 것보다 캐시를 적용하거나 로직을 바꿔보는 노력이 선행되야 하겠지만…) 당연히 서버부터 구매하며 “Scale Out”을 하려고 할것이다. 만약 원래 운영하던 서버가 너무 좋아서 CPU나 메모리 사용률이 거의 바닥이여도 서버를 구매해야 할까?

 

서버를 구매하게되면 결국 두개 이상의 서버가 운영될텐데 그 서버들을 앞에서 묶어주며 트래픽을 분산시켜주는 무언가가 필요하다. 그러한 기술을 바로 로드밸런싱 이라고 한다. 통상 L4 스위치를 활용하여 요청을 여러 서버들로 분산시키며 산술적으로는 서버 대수만큼 성능이 좋아지는 효과를 볼 수 있다.

 

하지만 앞서 말했듯 서버의 자원 사용률이 바닥일 정도로 거의 사용을 안할경우 서버를 구매하는건 너무나 비효율적이다. 이번 포스팅에서는 서버를 늘리지 않으면서 웹서버 중 아파치를 활용하여 여러 WAS를 운영하는 방법에 대해 알아보고자 한다. 서버 늘려야 하는 상황에서 사용해 볼 수 있는 나만의 좋은 무기(?)가 생긴게 아닐까 생각이 든다.

 

아파치는 EOL이 되었기 때문에 2.4버전으로 설치하고, WAS는 편의상 톰켓 최신버전으로 설치해서 동일한 서버에 아파치 한대와 톰켓 3대를 연동하는것을 목적으로 한다. 로드밸런싱이 어떤식으로 이루어 지고 하위에 연결된 톰켓을 컨트롤 하는 방법 또한 알아볼 예정이다.

 

서버 환경 및 설치하게 될 각 버전은 다음과 같다.

서버 : CentOS 7.4 64Bit

apache : httpd-2.4.39

tomcat : apache-tomcat-8.5.43

tomcat-connectors(mod_jk) : 1.2.46

 

# Apache 와 Tomcat 설치

필자의 포스팅에서 종종 나오는 부분이기도 하고, 구글링 해보면 바로 설치 방법을 쉽게 찾을 수 있겠지만 그렇다고 언급을 안하고 넘어가기엔 너무 불친절하니… 치트키처럼(?) 빠르게 정리해보자.

 

Apache

$ wget http://apache.tt.co.kr//httpd/httpd-2.4.39.tar.gz

$ tar -zxvf httpd-2.4.39.tar.gz

$ ./configure --prefix=/home/~~~/apache

$ make && make install

$ cd /home/~~~/apache/bin

$ sudo chown root:계정명 httpd

$ sudo chmod +s httpd

$ vi /home/~~~/apache/conf/httpd.conf

User 계정명

Grop 계정명

 

$ /home/~~~/apache/bin/apachectl start ← 실행

이렇게 설치를 한뒤 실행을 시키고 서버의 ip를 접속해보면 아래와 같은 화면을 볼 수 있다.

 

Tomcat

$ wget http://mirror.apache-kr.org/tomcat/tomcat-8/v8.5.43/bin/apache-tomcat-8.5.43.tar.gz

$ tar -zxvf apache-tomcat-8.5.43.tar.gz

$ /home/apache-tomcat-8.5.43/bin/start.sh ← 실행

 

 

톰켓의 기본 http 포트인 8080으로 접속을 해보면 귀여운 고양이가 있는 톰켓 기본화면을 볼 수 있다.

 

# 아파치와 톰켓 연동하기

아파치와 톰켓의 연동은 mod_jk 와 mod_proxy 등 다양한 모듈로 연동을 할 수 있는데 이번 포스팅에서는 mod_jk 를 활용하는 방법에 대해 알아보고자 한다. 우선 mod_jk 를 설치하자.

 

간단히 mod_jk 는 컴파일, 설정 등 복잡하지만 톰켓 전용 바이너리 프로토콜인 AJP를 사용하기 때문에 높은 성능을 기대할수가 있다. mod_proxy 는 반면 기본으로 아파치에 탑재되어있는 모듈이기 때문에 별도의 모듈 설치가 필요 없고 설정도 간단하다는 장점이 있다. 각 연동방식의 장단점이 있기 때문에 본인이 운영하는 서버 상황에 맞추어 적용 할 필요가 있다.

 

mod_jk 설치

$ wget http://apache.tt.co.kr/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz

$ tar -zxvf tomcat-connectors-1.2.46-src.tar.gz

$ cd tomcat-connectors-1.2.46-src/native

$ ./configure --with-apxs=/home/~~~/apache/bin/apxs

$ make && make install

$ /home/~~~/apache/modules 하위에 mod_jk.so가 생김

 

mod_jk 를 활용하면 AJP라는 통신으로 아파치와 톰켓이 연동되는데 톰켓의 기본 AJP 포트는 8009번임을 알고 다음처럼 설정을 해주자.

 

#vi apache/conf/workers.properties

 

worker.list=tomcat1

worker.tomcat1.port=8009

worker.tomcat1.host=localhost

worker.tomcat1.type=ajp13

worker.tomcat1.lbfactor=1

apache/conf/httpd.conf

 

LoadModule jk_module modules/mod_jk.so

<IfModule jk_module>

    JkWorkersFile    conf/workers.properties

    JkLogFile        logs/mod_jk.log

    JkLogLevel       info

    JkMount /*  tomcat1

</IfModule>

 

이렇게 하고서 아파치와 톰켓을 재시작 후에 서버의 ip로 접속해보면 (별도의 port 없이) 톰켓 설정페이지로 랜딩이 되는것을 확인할 수 있다.

 

# 로드밸런싱을 위한 작업

여기까지는 본 포스팅을 작성하기 위한 밑거름이라고 말할 수 있다. 이제 실제로 로드밸런싱을 해볼 차례.

앞서 톰켓 하나만 설치했는데 편의상 톰켓 3개를 설치해두자. (하나를 설치하고 cp -r 명령어를 활용하는게 빠르다.) 그 다음 각 톰켓의 모든 포트를 셋다 다르게 설정해야 하는데 겹치지 않도록 설정해 두고 (필자는 앞자리를 1,2,3 이런식으로 다르게 설정하였다.) 워커(workers.properties)를 아래처럼 설정해주자.

 

#vi apache/conf/workers.properties

worker.list=load_balancer

 

worker.load_balancer.type=lb

worker.load_balancer.balance_workers=tomcat1,tomcat2,tomcat3

 

worker.tomcat1.port=18009

worker.tomcat1.host=localhost

worker.tomcat1.type=ajp13

worker.tomcat1.lbfactor=1

 

worker.tomcat2.port=28009

worker.tomcat2.host=localhost

worker.tomcat2.type=ajp13

worker.tomcat2.lbfactor=1

 

worker.tomcat3.port=38009

worker.tomcat3.host=localhost

worker.tomcat3.type=ajp13

worker.tomcat3.lbfactor=1

 

이렇게 설정을 한 뒤 앞서 설정한 httpd.conf 에 JkMount 부분도 아래처럼 변경해주자.

 

apache/conf/httpd.conf

JkMount /* load_balancer

위 설정을 다시한번 살펴보자면, /*으로 들어오는 요청을 load_balancer라는 워커로 넘기는데 워커 설정에서는 로드밸런싱이 설정되어 있기 때문에 tomcat1, tomcat2, tomcat3 골고루 요청을 분산해준다는 의미이다.

tomcat 하위 logs 폴더에 보면 아래 기본 설정에 의해 엑세스 로그가 로깅이 되는데

 

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"

       prefix="localhost_access_log" suffix=".txt"

       pattern="%h %l %u %t &quot;%r&quot; %s %b" />

 

실제로 테스트를 해보면 다음처럼 9번의 요청을 3대의 톰켓에 골고루 요청된 것을 확인할 수 있다.

 

 

# 로드밸런싱을 컨트롤 하기 (jkmanager)

위에서 알아본 mod_jk 를 활용한 로드밸런싱을 별도의 서버 재시작 없이 컨트롤이 가능하다고 한다. 이게 어떤것을 의미하냐면 연동된 톰켓 3대중에 한대를 별도의 서버 셧다운을 하지 않아도 제외시킬수 있으며 반대로 다시 투입도 가능하다는 이야기이다. 이를 활용해보면 서비스 배포를 할 경우 위와 같은 설정이 되어있을때 제외 > 배포 > 투입하는 식으로 서비스가 무중단 상태에서 배포가 될수 있는 효과를 얻을 수 있다.

설치는 별도로 하지 않아도 되고 mod_jk 모듈 내에 있기 때문에 별도의 설정만 추가해주면 된다.

 

apache/conf/httpd.conf

 

<IfModule jk_module>

    JkWorkersFile    conf/workers.properties

    JkLogFile        logs/mod_jk.log

    JkLogLevel       info

    JkMount /* load_balancer

 

    <Location /jkmanager/>

        JkMount jkstatus

        Order deny,allow

        Deny from all

        Allow from 127.0.0.1

        Allow from {접근 가능한 IP}

    </Location>

</IfModule>

apache/conf/workers.properties

 

worker.list=jkstatus

worker.jkstatus.type=status

 

설정에서 볼 수 있듯이 해당 설정은 다른측면에서는 상당히 취약점이 많은 부분이다. 해당 설정이 외부에 노출이 되어있다면 그 컨트롤을 서버 관리자가 아닌 다른 누군가가 할수 있기 때문에 꼭 Allow 설정으로 접근 제한을 해둬야 한다. 이렇게 하고 서버 IP/jkmanager/ 을 접속해보면 “JK Status Manager” 이라는 문구와 함께 아파치에 연동된 톰켓의 상태를 한눈에 파악할 수 있다.

 

여기서 tomcat1 좌측에 있는 E(=edit)를 클릭하고 Activation 값을 “Disabled” 으로 바꿔본 뒤 앞서 테스트한 방법을 다시 해보면 tomcat1 에는 엑세스가 들어오지 않고 9번 엑세스가 골고루 tomca2 와 tomcat3 으로 로드밸런싱이 된것을 확인할 수 있다.

 

 

# 마치며

각 설정값들은 아무리 필자가 설명을 잘 해도 도큐먼트를 따라갈 수 없듯이 실제 각 도큐먼트를 보면서 설정값 하나하나를 조절해보며 운영하고 있는 서비스의 특징과 상황에 맞도록 맞춰가는것이 핵심일것 같다. (본 포스팅은 아주 가볍게 연동만 해보는 형태이고, 각 설정이나 워커들간의 우선순위 로드밸런싱 같은 경우는 직접 설정을 해가면서 확인이 필요하다. )

사실 이부분은 머릿속으로는 어떻게 하는구나라고 알고만 있었는데 실제로 해보니 각 설정들이 어떤 의미이고 어떻게 조절하면 보다 더 좋은 성능이나 다양한 이득을 취할수 있을것 같다는 생각을 해본다.

 

참고 링크

https://tomcat.apache.org/connectors-doc/reference/workers.html

https://tomcat.apache.org/connectors-doc/common_howto/loadbalancers.html

 

출처 : https://taetaetae.github.io/2019/08/04/apache-load-balancing/

[출처] 아파치 로드밸런싱으로 여러 WAS 운영하기

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

넷스케이프가 만든 신뢰연결을 위한 SSL/TLS에 대한 설명입니다.

 

종단-대-종단의 안전한 통신을 위해 설계되었으며, 인증 및 암호화 기능을 가집니다.(공개키 암호화 방식)

웹 브라우저와 웹 서버간에 서로를 확인하는 기능이 있습니다.

데이터 무결성을 검사할 때는 일방향 해쉬 함수를 사용하여 검증합니다.

 

SSL/TLS 를 겨냥한 취약점을 이용한 공격이 몇가지 있는데, BEAST 공격과 CRIME Attack 입니다.

 

사용자 브라우저 취약점을 이용하여 HTTPS 쿠키를 훔쳐 공격하는 BEAST, (Browser Exploit Against SSL/TLS)

HTTPS의 압축에 따른 취약점을 이용해 HTTPS 세션을 가로채는 CRIME attack 이 있습니다.

(Compression Ration Info-Leak Mass Exploitation)

 

SSL/TLS은 다음 네 가지의 프로토콜로 이루어져 있습니다.

 

핸드쉐이크 프로토콜

클라이언트와 서버가 서로 어떤 알고리즘과 공유키를 사용할지 서로에게 공유합니다.

 

Chage cipher spec 프로토콜

암호 방법을 변경할 때, 상대에게 전하기 위한 규칙입이다.

둘 사이에 합의한 암호사양을 적용하자고 상대방에게 알려줍니다.

 

alert 프로토콜

에러 발생 시 상대방에게 알립니다.

 

record 프로토콜

메시지를 압축/암호화 하여 상대방과 통신 합니다.

 

 

정리하면,

IPSec 은 네트워크 계층의 보안을 위해 쓰이고,

SSL/TLS 는 TCP계층과 응용계층 사이에서 쓰이는 종단간 보안서비스입니다.



출처: https://huscarl.tistory.com/33?category=793268

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

Forward Proxy & Reverse Proxy

포워드 프록시와 리버스 프록시 개념

 

Forward Proxy

클라이언트가 example.com 에 연결하려고 하면 사용자 PC 가 직접 연결하는게 아니라 포워드 프록시 서버가 요청을 받아서 example.com 에 연결하여 그 결과를 클라이언트에 전달(forward) 해 준다.

포워드 프록시는 대개 캐시 기능이 있으므로 자주 사용되는 컨텐츠라면 월등한 성능 향상을 가져올 수 있으며 정해진 사이트만 연결하게 설정하는 등 웹 사용 환경을 제한할수 있으므로 기업 환경등에서 많이 사용한다.


Reverse Proxy

클라이언트가 example.com 웹 서비스에 데이타를 요청하면 Reverse Proxy는 이 요청을 받아서 내부 서버에서 데이타를 받은 후에 이 데이타를 클라이언트에 전달하게 된다.

내부 서버가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유 중 하나는 보안 때문이다.

보통 기업의 네트워크 환경은 DMZ 라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재하며 이 구간에는 메일 서버, 웹 서버, FTP 서버등 외부 서비스를 제공하는 서버가 위치하게 된다. example.com 사는 서비스를 자바로 구현해서 WAS 를 DMZ 에 놓고 서비스해도 되지만 WAS 는 보통 DB 서버와 연결되므로 WAS 가 최전방에 있으면 WAS 가 털릴 경우 DB 서버까지 같이 털리는 심각한 문제가 발생할 수 있다.

이 때문에 리버스 프락시 서버를 두고 실제 서비스 서버는 내부망에 위치시키고 프락시 서버만 내부에 있는 서비스 서버와 통신해서 결과를 클라이언트에게 제공하는 방식으로 서비스를 하게 된다.

특히 리눅스 환경이라면 리버스 프락시로 아파치 웹 서버를 사용한다면 SELinux 를 켜 놓으면 SELinux 의 기본 정책이 웹 서버는 톰캣의 8080, 8009 포트만 접근 할 수 있으므로 아파치 웹 서버가 해킹당해도 웹 서버 권한으로는 내부망으로 연결이 불가하다. 또한 리버시 프락시를 cluster로 구성해 놓으면 가용성을 높일 수 있고 사용자가 증가하는 상황에 맞게 Web Server 나 WAS 를 유연하게 늘릴 수 있는 장점이 있다.

 

**

Reverse Proxy 로 서비스 제공시 WAS 에서 REMOTE_ADDR 을 가져오면 Reverse Proxy 서버의 IP 를 얻게 되므로 원하는 결과가 나오지 않는다.

Proxy(프락시) 환경에서 client IP 를 얻기 위한 X-Forwarded-For(XFF) http header 를 참고해서 XFF 헤더를 사용하자.


출처 : www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html

 

프록시와 리버스 프록시의 가장 쉬운 접근 방법은 

망 내에서 외부로의 서비스 이용은 (포워드) 프록시
망 밖에서 내부로의 서비스 이용은 리버스 프록시

가 되겠다.

포워드 프록시는 망 내의 이용자(또는 시스템)가 외부 서비스 위치 등을 모르고 이용하고

리버스 프록시는 망 밖의 이용자(또는 시스템)가 내부 서비스 위치 등을 모르고 이용하게 된다.

 

 

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요