-1.4 C
New York
금요일, 12월 26, 2025

Buy now

Home Blog Page 235

웹서버 에러 – [emerg] bind() to [::]:443 failed (98: Address already in use)

0

요즘 서버가 불안정하면서 평소에 접해보지 못하던 희귀한 사례들을 만나게 되었습니다. 이중 NGINX의 443 포트 메모리가 이미 사용중이라서 NGINX 구동 불가하는 웹서버 에러를 만나 대처한 이야기를 풀어보고자 합니다.

이 현상은 멀웨어에 감염된 사이트를 지우고 다시 설치하는 가운데 만났습니다. 아마 해커가 교묘하게 사이트에서 얼웨어를 제거하면 웹서버가 작동되지 않토록 장난을 친것으로 추정하고 있는데요.

아무튼 멀웨어를 치료 후 서버를 다시 시작하면 시스템이 죽어버립니다.

그럴 겨우 보통 NGINX 웹서버를 체크 시 nginx -t 옵션을 사용해 점검합니다. 그러면 NGINX 세팅 중 문제 없는지를 체크해 이상이 없으면 OK 메세지를 보내는데요.

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Code language: PHP (php)

그리고나서 NGINX 웹서버를 다시 구동시키면 아무런 문제가 없이 작동합니다.

문제 상황

그런데 이 경우는 nginx -t에서는 아무런 문제가 없다가 service nginx restart 명령을 받아 NGINX 웹서버를 다시 가동하려면 에러 메세지를 내면서 NGINX 웹서버를 가동시키지 못합니다.

아래 메세지처럼 ‘systemctl status nginx.service’로 점검하라고 메세지 나오며, systemctl status nginx.service를 이용해 점검해보면

  • NGINX 활성화할 수 없으며
  • 80포트를 이미 사용하고 있다고 합니다.
# service nginx restart 
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

# systemctl status nginx.service
● nginx.service - nginx - high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2020-07-02 16:37:00 KST; 28s ago
       Docs: http://nginx.org/en/docs/
    Process: 1109 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)


Jul 02 16:36:57 etrend systemd[1]: Starting nginx - high performance web server...
Jul 02 16:36:57 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 02 16:36:58 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 02 16:36:58 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 02 16:36:59 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 02 16:36:59 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 02 16:37:00 etrend nginx[1109]: nginx: [emerg] still could not bind()
Jul 02 16:37:00 etrend systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jul 02 16:37:00 etrend systemd[1]: nginx.service: Failed with result 'exit-code'.
Jul 02 16:37:00 etrend systemd[1]: Failed to start nginx - high performance web server
Code language: PHP (php)

net-tools로 원인 파악

그러면 누가 이미 address를 사용하고 있는지 점검하기 위해 netstat를 점검해 봅니다.

먼저 net-tools을 설치하구요.

apt install net-toolsCode language: PHP (php)

다음으로 아래 명령어로 네트워크 상황을 점검해 봅니다.

netstat -tulpNCode language: PHP (php)

그랬더니 아래와 같이 http로 apache2가 이미 사용하고 있다고 합니다. 여기는 NGINX 웹서버이므로 hhtps는 NGINX가 사용해야 정상이겠죠.

# netstat -tulpN
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 localhost:6010          0.0.0.0:*               LISTEN      1185/sshd: root@pts 
tcp        0      0 localhost:mysql         0.0.0.0:*               LISTEN      958/mysqld          
tcp        0      0 localhost:submission    0.0.0.0:*               LISTEN      1315/sendmail: MTA: 
tcp        0      0 0.0.0.0:*****           0.0.0.0:*               LISTEN      687/sshd: /usr/sbin 
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN      585/systemd-resolve 
tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN      1315/sendmail: MTA: 
tcp6       0      0 localhost:6010          [::]:*                  LISTEN      1185/sshd: root@pts 
tcp6       0      0 [::]:http               [::]:*                  LISTEN      702/apache2         
tcp6       0      0 [::]:*****              [::]:*                  LISTEN      687/sshd: /usr/sbin 
udp        0      0 localhost:domain        0.0.0.0:*                           585/systemd-resolve 
udp        0      0 45.77.96.212.vul:bootpc 0.0.0.0:*    Code language: PHP (php)

어떤 상황에서 나타나는가

어떤 상황에서 이러한 문제가 발생하는지 점검해 보았는데요.

확실한 것 중의 하나는 certbot 명령을 dry run 옵션과 같이 사용 시 반드시 이 문제가 나타납니다.

Let’s encrypt SSL 인증 갱신 명령 옵션에 –dry-run이 있습니다. 이는 SSL 인증 완료 시기가 아니라도 종료 상황을 만들어 적절하게 갱신이 되는지를 시뮬레이션할해 볼 수 있는데요.

/usr/bin/certbot renew --dry-run >> /var/log/letsencrypt/renew.logCode language: PHP (php)

이 옵션을 사용해 certbot new 명령을 실행 결과입니다.

~# /usr/bin/certbot renew --dry-run >> /var/log/letsencrypt/renew.log
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for happist.com
http-01 challenge for www.happist.com
nginx: [error] invalid PID number "" in "/var/run/nginx.pid"
Waiting for verification..
Cleaning up challengesCode language: PHP (php)

그리고 다시 nginx를 구동시키면 구동되지 않습니다. 그래서 systemctl status nginx.service 명령으로 상황을 파악해보면 위에서 소개한 것처럼 이미 address가 사용 중이라고 나옵니다.

~# systemctl status nginx.service
● nginx.service - nginx - high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2020-08-08 12:49:38 KST; 3min 9s ago
       Docs: http://nginx.org/en/docs/
    Process: 2257 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)

Aug 08 12:49:37 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Aug 08 12:49:37 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Aug 08 12:49:37 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Aug 08 12:49:37 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Aug 08 12:49:38 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Aug 08 12:49:38 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Aug 08 12:49:38 etrend nginx[2257]: nginx: [emerg] still could not bind()
Aug 08 12:49:38 etrend systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 08 12:49:38 etrend systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 08 12:49:38 etrend systemd[1]: Failed to start nginx - high performance web server.
Code language: PHP (php)

해결 방안

이 문제의 근본적인 해결 방안, 즉 이런 문제가 나타나지 않토록 만드는 방법은 아직 확인하지 못했습니다.

다만 임시로 nginx 웹서버에서 다른 프로그램이 address를 먼저 사용한다는 문제를 해결을 위해서는 대략 두가지 방법이 있습니다.

apache2 stop 명령

우분투 설치 시 기본으로 apache2가 설치되어 있기 때문에 이 apache2 stop 명령을 사용하면 이 문제가 일시적으로 해소됩니다.

sudo /etc/init.d/apache2 stop 

sudo service nginx restartCode language: PHP (php)

fuser -k 80/tcp 사용

저는 apache2를 없애버리면 이 문제가 해소될 것으로 보고 apache2를 삭데햌ㅆ는데요. 그럼에도 불구하고 이문제는 계속 발생했습니다. apache2가 이 문제 원인은 아니라는 것이죠.

아마 위에서 지적한 대로 SSL 인증 과정에서 80주소를 일부 어플리케이션이 사용하고 되돌려주지 않는 버그가 있는 것 같습니다.

apsche2가 없는 경우는 아래 명령을 사용합니다.

sudo fuser -k 80/tcpCode language: PHP (php)

그러면 아래와 같이 80/tcp address를 kil합니다.

~#  sudo fuser -k 80/tcp
80/tcp:               2240  2249Code language: PHP (php)

그리고 nginx를 구동하면 제대로 작동합니다.

SSL 갱신 스크립트 개선

이런 문제를 반영하여 SSL 갱신 스크립트를 아래와 같이 변경합니다. nginx를 구동하기 전에 fuser -k 80/tcp 명령을 추가하는 것입니다.

/etc/init.d/nginx stop
/usr/bin/certbot renew --dry-run >> /var/log/letsencrypt/renew.log
fuser -k 80/tcp
/etc/init.d/nginx start Code language: PHP (php)

PHP 에러 대응 – PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback

워드프레스 운영을 위해 다양한 커스텀 코드를 적용하다보면 PHP 에러를 만나게 됩니다.

이러한 PHP 에러중에는 치명적인 것도 있지만 대부분은 워드프레스 사이트가 다운될 정도로 심각한 경우가 아니므로 무시하게 마련입니다.

그러나 PHP 에러 대응이 적절하지 않으면, 서버에서는 끊임없이 서버 에러 메세지를 발송하면서 궁극적으로 시스템 자원을 약화시키는 경우가 있습니다.

여기에서는 대수롭지 않게 넘기기 쉽운 PHP 에러 중 PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback에 대해서 알아봅니다.

이 글은 PHP 에러 대응 사례-PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback를 기반으로 조금 내용을 수정한 것입니다.

PHP 에러 메세지 사례

오늘 소개하는 PHP 에러 대응 -PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback도 이러한 예의 하나인데요.

보통 이런 에러가 발생하면 아래와 같은 에러 메세지를 보냅니다. 이는 서버의 error.log에서 발견할 수 있습니다.

웹서버로 NGINX를 사용한다면 /var/log/nginx 폴더에 있는 error.log에서 확인할 수 있습니다. 하나의 실예를 들기 위해 에러 메세지를 그대로 가져와 봤습니다.

2020/07/04 13:33:50 [error] 2739157#2739157: *149426 FastCGI sent in stderr: "PHP message: PHP Warning:  call_user_func_array() expects parameter 1 to be a valid callback, function 'child_enqueue_styles' not found or invalid function name in /home/사이트 이름/wp-includes/class-wp-hook.php on line 287", client: 220.64.101.2, server: 사이트 이름.com, request: "GET /571441/ HTTP/1.1", host: "사이트 이름.com"Code language: PHP (php)

에러 메세지의 원인

이러한 메세지가 나오는 것은 대부분 워드프레스 차이드 테마의 hunctions.php에 다음과 같은 형식의 커스텀 코드가 있는 경우가 발생한다고 합니다.

add_action( 'wp_enqueue_scripts', 'custom_scripts', 9999 );Code language: PHP (php)

저의 경우에는 다음과 코드가 있었습니다.

add_action( 'wp_enqueue_scripts', 'child_enqueue_styles', 15 );Code language: PHP (php)

문제 해결

오랜만에 서버가 제대로 작동하는지 확인하면서 NGINX 웹서버가 끊임없이 이런 메세지를 내고 있다는 것을 발견하고 토요일 오전 내내 구글링을 통해서 문제 해결 방법을 찾았습니다.

그러나 좀처럼 이 문제 해결 방안을 찾을 수 없었는데 근 5시간이상의 구글링끝에 이에 대한 해결책을 제시하는 글을 찾았습니다.

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function ‘custom_scripts’ not found or invalid function name in /home/.sites/149/site5056863/web/web/wp-includes/class-wp-hook.php on line 286

위 글에 따르면 문제 원인이 커스텀 코드에서 발생하고 있기 때문에 문제 해결은 이 커스텀 코드를 삭제함으로 가능합니다.

저의 경우 차일드 테마를 별도로 만들지 않고 MU-PLUGINS에서 별도 php 파일을 만들면서 상기 커스텀 코드를 적용했는데요. 굳이 필요한 컷텀 코드는 아니었나 봅니다.

이 커스텀 코드 삭제 후 별다른 이슈가 없었고, 오히혀 에러 메세지는 사라졌습니다.

WWDC 20이 보여준 애플 미래 전략의 핵심, AR/VR 비즈니스

0

코노라 팬데믹으로 애플 비지니스 환경이 그리 우호적이지 않음에도 불구하고 애플 주가는 사상 최고를 기록하며 승승 장두하고 있습니다. 애플 주가를 그렇게 끌어 올리는 애플 미래 전략이 궁금한 일이 아닐 수 없습니다.

그래서 애플 미래 전략에 대한 관심을 가질 필요가 있는 지점이기도합니다. 그러는 가운데 최근 애플의 연례 행사인 WWDC에서는 iOs 업그레이드를 비롯한 다양한 내용이 발표디었습니다.

애플 미래 전략에 대한 많은 분석 중 애플이 이 모든 준비들은 애플 미래전략으로 AR/VR 비즈니스를 겨냥하고 있다는 것에 주목해 애플 미래 전략을 분석한 박시용님의 페북글이 있어 허락을 받아 여기에 소개합니다.

박시용님은 <WWDC에서 일관되게 가르키는 단 한가지. 바로 AR/VR 비즈니스>라는 글을 통해서 이번 WWDC의 주제는 1.방해하지 않는 UX 2.플랫폼 대통합 3.측위기술의 3가지로 보고 각 내용을 분석하면서 이러한 모든 것의 종착역은 미래 준비로서 AR/VR 비즈니스에 대해 주목하고 있습니다.

https://www.facebook.com/lemon119/posts/3233833476674950

WWDC에서 일관되게 가르키는 단 한가지. 바로 AR/VR 비즈니스

이번 애플 WWDC 2020을 곱씹어 보면서 계속 들었던 생각은 ‘얘네들, 노골적으로 AR/VR 시장을 준비하는구나.’ 였는데, 외신을 비롯하여 아무도 AR/VR과 연결지어 분석한 내용이 없는것 같아 한판 정리해봅니다.

올해 WWDC에서는 기존과는 다르게 하드웨어 발표는 하지 않고 지나갔습니다. 각 디바이스들의 OS의 발표를 마치고 ARM기반의 새로운 프로세서 자랑을 한 뒤 마무리 지었죠. 하지만 한번 더 살펴보면 이 모든것의 끝에는 AR/VR 비즈니스가 있었습니다.

얼마전 프로 유출러 Jon Prosser 내용에 따르면 애플은 Apple Glass라는 이름으로 AR디바이스를 준비중이며, 사생활 침해를 막기 위해 카메라는 부착하지 않고 이번 아이패드 프로에 부착된 라이다센서를 달았다고 합니다. 발표는 내년 상반기, 출시는 2년후라고 예측했습니다.

애플 글래스 특허 도면, apple glass things-you-should-know-2

그럼 WWDC로 돌아가서 다시 살펴볼까요. 이번 발표를 관통하는 주제는 크게 3가지입니다. 1.방해하지 않는 UX 2.플랫폼 대통합 3.측위기술

방해하지 않는 애플 UX

iOS, iPadOS, MacOS의 UX가 매우 많이 바뀌었습니다. 특히나 iOS의 경우에는 앱서랍이나 위젯등을 도입함으로써 원하는정보에 빠르게 다가갈 수 있게되었습니다.

또한 사용중에 전화가 오는 경우 기존에는 화면 전체가 전화 화면으로 전환되었지만 이제는 위에서 콜바 하나만 작게 내려와서 기존 작업을 방해받지 않게 되었죠.

그룹메시지에서도 누가 말을 하는지 작게 말풍선으로 표시되게 되었고 시리 화면도 전체를 가리지 않게 되었습니다.

이거 안드로이드에서는 십년전부터 있던 기능들입니다. 그 기능들은 애플은 왜 이제서야 적용을 한다고 하는 걸까요? 전세계 시총 1위인 회사가 설마 기술이 없어서 구현 못했을리는 없고요.

수년간 욕을 먹으면서도 바꾸지 않았던 UX를 이렇게 ‘방해하지 않는 UX’로 전환을 꾀하는건 이유가 있어서일겁니다.

항상 애플의 문법은 동일했습니다. First Mover보다는 기술이나 유저들의 경험치가 어느정도 무르익은 다음 극한의 ux완성도를 들고 제품을 출시하였습니다.

몇년전 애플워치가 출시하기도 이전에 제가 웨어러블 업체 발굴을 위해서 심천에 간 적이 있었는데, 그 당시 판매가(공급가 말고) 3만원 미만의 제품들이 수백종류가 넘었습니다. 그러나 애플워치가 햅틱엔진을 달고 나오자 시장의 판도는 다 바뀌었죠. 제가 만났던 그 업체들, 아직까지 제품을 만들고 있지는 않을것 같습니다.

몇년째 욕을 먹으면서도 수신전화 화면을 전체화면으로 유지하는대신 아이폰을 사용하지 않을때는 밀어서 받기, 사용중에는 버튼으로 받기를 나눠놓을정도로 디테일한 ux팀이, 이번에 방해받지 않는ux로 대대적인 개편을 한 이유는 앞으로 AR의 시대가 도래했을때의 유저들이 경험할 사용성에 대한 준비라고 생각됩니다.

이번 iOS에서 pip가 적용되었는데 기존의 안드로이드와는 다르게 팝업으로 떠있는 동영상 창을 바깥으로 밀어놓았다가 사용할때는 화살표를 살짝 당겨오는 방식을 도입했습니다. 이것도 ar글라스를 사용할때 꼭 필요한 ux이며, 유저들에게는 ar글라스 출시 이전부터 익숙하게 경험할 수 있게 하는 장치라고 보여집니다.

플랫폼 대통합

이번 발표의 원모어띵은 ARM기반의 Apple Silicon 칩셋이었습니다.

2005년 파워PC에서 인텔로 전환할때의 wwdc에서는 인텔이라는 회사를 특히 강조했지만 이번에는 어디에서도 ARM이라는 이야기는 들리지 않았습니다. 오로지 ‘우리는 칩셋까지 자체 설계하고 모든 프로그램이 원활히 돌아갈 수 있도록 하겠다.’에 초점을 두었죠.

외부의 칩셋을 쓰지 않고 자체적으로 칩셋을 설계하는경우, 디바이스 업데이트 주기를 칩셋의 스케줄에 맞출 필요도 없고 제품 원가도 유의미하게 낮아질 수 있습니다.

그러나 큰 허들이 있는데 이 경우에는 기존에 사용하던 레거시 프로그램들을 전부 ARM 커스텀 칩셋에 맞추어 컴파일하거나 가상화 머신을 사용해야 하는 단점이 발생합니다.

그러나 이런 과도기가 지나가게 되면 기존의 ARM칩셋 위에서 돌아가던 iOS, iPadOS의 어플들을 자유롭게 맥에서도 교차 사용 가능하게 됩니다.
이는 디바이스의 제한 없이 기존의 레거시 프로그램, 수많은 개발자들이 앱스토어에 등록한 어플들을 사용할 수 있다는 뜻입니다.

또한 애플의 A프로세서는 고성능, 저전력의 특징을 갖고 있습니다.

위의 애플글라스의 경우 1세대 기기에서는 독자적인 프로세싱보다는 아이폰과 연결되어 아이폰에서 연산작업이 주로 이루어지겠지만 시간이 지나면 결국 AR/VR 디바이스 자체에서 프로세싱하게 될겁니다.

애플은 스마트스피커인 홈팟에도 아이폰6에 들어가는 A8프로세서를 탑재했고 심지어는 조만간 출시될 무선충전기인 Airpower에는 아이폰X에 들어가는 A11칩셋을 사용한다는 루머가 있습니다.

이는 애플글라스에서도 A칩셋을 사용할것이며 이 위에서 돌아가는 서비스들은 아이폰, 아이패드, 맥 상관없이 모든 플랫폼에서 seamless하게 경험할 수 있다는 장점이 있습니다.

위의 애플글라스 유출내용에 따르면 2년후에 출시 예정이라고 합니다. 그리고 이번 wwdc의 발표에 따르면 2년후에는 모든 맥은 Apple Silicon 기반으로 출시된다고 합니다. 무섭도록 맞아떨어지는 스케줄이죠.

측위 기술

이번 wwdc의 발표 중 별것 아닌것처럼 스리슬쩍 빠르게 넘어간 것들 중 아주아주 중요한것들이 있습니다.

우선 Apple Car Key 시연 중 소개되었던 u1칩셋의 모습, 손 씻을때 애플워치가 자동으로 손씻는 모션을 알아채고 가이드 해주는 기능, 마지막으로 에어팟 프로의 펌웨어 업데이트로 공간음향을 구현하는 기능입니다.

위의 기능들은 모두 사용자의 모션과 위치를 측정하는 측위기술들이 뒷받침 되어야 합니다.

작년 아이폰11 발표때 애플은 아이폰11의 가장 큰 기술적 혁신인, UWB(초광대역)칩인 u1칩을 내장하고도 별다른 언급을 하지 않았습니다.

그러나 u1칩은 센티미터 단위의 위치탐색 능력 및 벽과 인체등의 장애물에 방해받지 않는 특성을 이용하여 애플 카 키, 홈킷 시스템과 더불어 앞으로 출시될 애플글라스에서 가장 중요한 역할을 하게 될 겁니다.

앞으로 애플워치, 애플글라스를 비롯하여 모든 디바이스에 u1칩셋이 확실시 됩니다.

이렇게 아이폰, AR글라스, 애플워치등이 전부 U1칩을 탑재하고 있다면 서로의 위치를 파악해 미묘한 손이나 얼굴의 움직임 만으로 가상물체를 조종하게 될 수 있을것이고요.

그렇다면 엔드유저가 꼭 일반적인 소비자가 아닐수 있고, 이는 가상물체의 세밀한 원격조정이 필요한 B2B로의 비즈니스 확장을 기대해 볼 수도 있습니다.

또한 에어팟 프로의 공간음향 기능 추가로 소리에도 방향성을 표현할 수 있게 되었으니, 인간의 오감 중 미각이랑 후각과 관련된 기능만 붙여서 출시하면 완벽한 VR세상이 도래하겠네요.

마치며

정리해보자면, 애플은 이번 WWDC에서 ‘앞으로 2,3년동안 사용자들에게 새로운 UX를 습득시키고 그 후에 본격적인 AR/VR 디바이스를 출시하면서 시장을 지배하겠다.’ 라는 내용을 발표한것과 다름이 없습니다.

가을에 새롭게 출시될 아이폰 및 다른 디바이스들이 이런 방향과 얼마나 부합하는지 찾아보는것도 재미있는 일이 될겁니다.

결론: 애플 주식은 오늘이 가장 저렴합니다.

참고

애플과 페이스북의 고객 데이타 확보 경쟁, 반목속에 실질적 동맹 가능성

최근 애플이 WWDC에서 발표 내용 그리고 페이스북에 대한 광고 보이콧등이 경영 환경이 빠르게 변하고 있습니다. 이런한 변화 가운데 고객 데이타 확보를 위한 애플과 페이스북 경쟁속에 숨어있는 애플과 페이스북 전략에 대해 제품 혁신 이론으로 유명한 톰 벤슨의 글이 있어 소개합니다.

소비자 대상 하드웨어와 소프트웨어 상품을 대표하는 애플과 페이스북이 서로 치열하게 반목하고 있지만, 실질적으로는 각각의 경제적 해자를 강화하는 선에서 동반자 측면도 있다는 분석입니다.

  • 글쓴이는 애플 혁신 가능성 논란이 있을 때부터 애플의 경제적 해자는 사용자를 중심에 두고 관련 사용성을 극대화하면서 다른 업체들과 차별화한 것에서 애플의 지속적인 성장 가능성을 가져왔다고 보고 있습니다.
    .
  • 그러면서 이번 애플이 WWDC에서 발표한 내용 중에는 쿠키 사용과 같은 개인 정보 추적을 거의 무력화시킨 것이 있는데 이는 페이스북을 비롯한 상당수 인터넷 비지니스 업체들를 흔들 수 있는 요소라고 보고 있습니다.
    .
  • 그러나 애플의 이러한 정책은 애플의 서비스 수익 강화 방침에 따라 앱스토어 강화 방침의 하나라고도 해석할 수 있지만, 실상 앱스토어를 확대하고 수익 확대에는 페이스북이 지대한 역활을 했으며, 앞으로도 페이스북의 역활을 무시할 수 없을 것으로 예상합니다.

    애플이 고객 데이타 확보를 막는 것은 대다수 소비자 데이타 기술에 의존하는 업체들에게 큰 위협이 되지만 페이스북처럼 독보적인 기술로 극복하면 오히려 더 큰 기회를 가질 수 있다고…
    .
  • 또한 페이스북은 애플이 쿠키 활용을 극히 제한하면서 쇼피파이와 같은 후발 주자들이 새로게 부상하는 것을 막고 이미 기술을 확보한 페이스북이 새로운 기회를 잡는데 큰 기여를 하고 있다고 분석합니다. 이러한 분명한 예로 페이스북 샵을 들고 있습니다.
    .
  • 페이스북으로서는 현재 진행되고 있는 코로나 팬데믹, 기존 업체들의 광고 보이코트등이 장기적인 성장에 큰 상처를 주지 않으며, 오히려 데이타 확보 및 이용등에서 타의 추종을 불허하는 기술력을 가지고 있기 때문에 오리혀 기회가 될 것으로 보고 있습니다.

    페이스북 광고 보이코트를 주도하고 있는 유니레버와 같은 기존 대기업들은 페이스북에서 차지하는 비중은 20%로 생각보다 높지않고, 페이스북은 롱테일에 의지하기 때문에 다른 광고주로 대체될 것이며, 더우기 기존 대기업들은 가장 낮은 광고비를 책정받아 왔는데 이게 없어지면서 평균적인 광고 단가는 높아질 것으로 봅니다.
    .
  • 결론적으로 애플과 페이스북은 치열하게 경쟁하면서도 알게 모르게 서로의 비지니스 모델을 강화해주는 역활을 하는 실질적인 동맹이라고도 해석할 수 있습니다.

이 글에서는 제품 혁신이론으로 유명한 톰 벤슨이 최근 애플과 페이스북 움직임과 발표들을 기반으로 그들의 전략에 대해 정리한 Apple and Facebook를 번역 소개하고 있습니다.

어려운 내용이라 의역도 많고 부족한 부분이 있을 것이지만 이해해 주시고영어 공부 겸해서 번역을 해봤는데요.

어려운 내용이라 의역에 의존하기도 했고 구글의 힘을 빌리기는 했지만 부족한 부분이 있을 것이지만 이해해 주시고, 수정 사항을 알려주시면 좋겠습니다.


4대 소비자 대상 기술 회사 중 구글과 아마존은 누구나 이해하기 쉬운 경제적 해자를 가지고 있었습니다. 최근 마이크로소프트가 소매점 폐쇄를 결정한 것은 소비자 대상 비지니스에서 5년 만에 이루어진 후퇴입니다.

구글은 고객 접점을 제어함으로써 데이터 및 인프라 분야에서 큰 이점을 확보하고 있습니다(안드로이드를 완전히 소유하고 다른 플랫폼에 디폴트 배치(프리로드)토록 강제합니다).

아마존은 쇼핑 소비자들이 1순위로 접속하는 아마존닷컴에서 상품 검색부문을 제어함으로써 인프라와 데이터에서 큰 이점을 가지고 있습니다. 경쟁자들이 아마존과 싸우는 것은 매우 힘들고 심지어는 불가능하기까지 합니다.

애플의 경제적 해자

하지만 애플은 아이폰의 급격한 성공 이후에도 수년동안 사업의 지속가능성에 대한 의문에 직면했습니다.

Stratechery(이 글을 쓴 톰 벤슨이 운영하는 블로그)가 인기를 얻을 수 있었던 주제 중 하나가 아이폰의 지속 가능성이었습니다. 당시 Clayton Christensen 교수를 포함한 많은 사람들의 아이폰이 제대로 된 혁신을 이어가지 않기 때문에 몰락할 것이라는 주장햇습니다.

그러나 저는 2014년 글에서 당시 애플 접근 방식이 지속 가능한 이유를 설명했습니다.

게다가 통합 솔루션(intergrated solution)은 사용자 환경에 있어 항상 우수합니다. 모든 것을 같이 만들면, 모든 것이 함께 잘 작동하도록 보장할 수 있기 때문에, 표준과 상호 연결 시 나올 수 있는 불가피한 어려움과 최적화의 부족을 피할 수 있습니다.

그러나 핵심은 사용자들이 이러한 통합과 경험을 중요시한다는 것입니다. 그것이 바로 제가 크리스텐슨의 파괴적인 혁신 이론에 대한 비판의 핵심입니다. 사용자 경험 관점에서 제품 구매자가 사용자일 때에 중요합니다.

사용자들은 사용자 경험에 대해 관심을 가지지만(놀라움운 일이지요!) 실제 사용자가 아닌 구매자(대부분의 비즈니스 대 비즈니스 제품 및 모든 Christensen의 예처럼)들은 그렇지 않습니다.

저는 이것이 크리스텐슨이 애플에 대해 맹점을 갖게 된 뿌리라고 믿습니다. 한 달 전 헨리 블로젯과의 인터뷰에서 다음과 같이 말했습니다.

만약 애플이 그러한 특별한 사용자 경험을 가지고 있다면, 여기에 모듈로 참여하는 사람들은 (이를 구현하려고) 노력할 것이라는 것을 충분히 예측할 수 있습니다.
또 그들은 이것을 어떻게 구현해야하는지 이해하려는 강력한 동기를 가질 것이라는 것을 예상할 수 있습니다.

그리고 궁극적으로 한계를 가지고 있는 한, 애플은 어느 순간 한계에 부딪힙니다. 따라서 다른 제품 카테고리나 독점적인 제품을 개발하려고 합니다.
왜냐하면 그들은 실제로 독점적인 제품을 개발하는 데 능숙하기 때문입니다.
대부분의기업은 제한된 운영 체제에 대한 통찰력을 가지고 있지만, 한 번 최고점에 도달한 후 쇠락하게 됩니다.

하지만 이 사용자 경험 품질에는 한계가 없다는 것입니다. 다른 거의 모든 산업의 소비자들이 보여주듯이, 최고 제품과 그밖의 제품 사이에 명확히 차이를 설명할 수 있는 것이 있다면, 사용자 기반 일부는 최고 수준의 프리미엄을 지불할 것입니다.

그것이 애플 미래의 열쇠입니다. 애플은 2년마다 완전히 새로운 제품을 필요로 하지 않습니다. 그들은 단지 그들의 카테고리에서 가장 좋은 제품을 계속 만들기만 하면 됩니다. 쉬워요, 그렇죠?

물론 쉽지는 않지만, 특히 하드웨어에 관한 한, 애플의 리더쉽은 그 어느 때보다도 큽니다. 이는 탁월한 시스템 온 칩 덕분입니다. 2020년 WWDC를 보도하는 헤드라인 뉴스에는 애플이 이러한 특별한 이점을 Mac으로 확장하고 있다고 알려주고 있습니다.

물론 최고 기기를 제공하는 것만으로는 역시 충분하지 않습니다. 많은 사람들에 따르면 이것이 애플이 영원히 불운했던 또 다른 이유라고 합니다. 다시 2013년 Business Insider에 소개된 Blodget을 소개하겠습니다.

스마트폰과 태블릿이 플랫폼이 아니었다면(제품의 가치와 고객의 구매 결정 시 중요한 것이 제품 그 자체였다면) 애플의 시장 점유율 하락은 별 차이가 없을 것입니다. 애플 옹호자들이 중요한 것은 애플 “시장 점유율”이 아니라 “이익 점유율”이라고 우쭐대며 주장할 때 그것은 정확한 지적이엇습니다.

하지만 스마트폰과 태블릿은 하나의 플랫폼입니다. 써드 파티 기업들이스마트폰 및 태블릿 플랫폼에서 실행할 앱과 서비스를 구축하고 있습니다.

이와 같은 애플리케이션과 서비스는 플랫폼을 더욱 가치 있게 만들고 있습니다. 소비자들은 스마트폰과 태블릿 플랫폼에서 실행되는 앱과 서비스를 중심으로 자신의 삶을 표준화하고 있습니다.

이러한 “네트워크 효과” 때문에 플랫폼 시장에서 시장 점유율이 우세한 것은 큰 경쟁 우위입니다.

플랫폼 시장에서는 종종 생각하기조차 싫지만 항상 미친 듯이 강력한 마이크로소프트가 PC 시장에서 수십 년 동안 보여주었듯이, 대부분의 힘과 이익은 결국 시장 점유율 선두 업체에 귀속됩니다.

사실, 애플이 사용자 경험을 우선시하는 것은 어떤 일종의 해자가 아니라 애플이 필요로 하는 것보다 훨씬 더 애플을 필요로 하는 개발자들의 지렛대이기도 했습니다.

따라서 지난 2주 동안 두 번째로 큰 이슈는 애플의 앱 스토어 정책입니다.

애플이 서비스 매출 증대를 위해 노력하면서 애플은 지난 몇년동안 (앱 스토어관련) 불문율 규정을 대폭 강화해 왔습니다.

소규모 업체의 개발자이든지, 대형 업체의 개발자이든지 , 모든 개발자들은 아이폰 제조업체, 애플의 요구에 응할 수 밖에 없습니다.

그것은 애플이 사용자가 사용할 아이폰 앱 제공에 있어서 누구도 피해갈 수 없는 게이트 키퍼로 작용하는 가장 가치있는 로열티와 앱 리뷰를 결합했기 때문입니다.

빌 게이츠 라인

한편, 페이스북은 종종 애플과 반대로 생각되는데, 애플은 제품을 팔고, 페이스북은 광고를 판매합니다. 애플은 데이터 수집을 최소화하고 페이스북은 이를 최대화합니다. 애플은 플랫폼이고, 페이스북은 앱일 뿐입니다.

하지만, 두 기업이 공유하는 것은 실리콘 밸리의 영원한 회의론입니다. 페이스북은 설립에서부터 야후의 인수 제의를 거절한 결정, IPO 이후의 주가 폭락까지 지속적으로 (성공을) 의심 받아왔습니다.

트위터, 스냅챗, 틱톡에 이르기까지 모든 새로운 소셜 미디어 앱들은 페이스북을 끌어내려 마침내 제2의 마이스페이스로 만들어 버릴 수 있을 것이라는 기대를 받았었습니다.

하지만 사실은 많은 면에서 페이스북은 애플보다 플랫폼에 가깝습니다. 2018년에 저는 페이스북에 대한 비판으로 가득찬 빌 게이츠 라인(The Bill Gates Line)이라는 글을 썼습니다.

지난 몇 주 동안 저는 플랫폼과 애그리게이터(aggregators) 사이에 어떤 차이가 있는지 탐구해왔고, 세밀 샤와의 인터뷰에서 샤맛 팔리하피티야(Chamath Palihapitiya)의 대답이 떠올랐습니다.

Semil Shah: 페이스북에 보낸 시간과 페이스북 플랫폼과 연결간 어떤 유사점이 있을까요? 그리고 우버가 플랫폼에서 많은 돈을 벌 수 있었을까요?

샤맛 팔리하피티야 : 둘 다 플랫폼이 아닙니다. 둘 다 우선순위를 N번째에 두는 우스꽝스러운 노력과도 비슷합니다.
저는 페이스북 플랫폼을 담당했습니다. 우린 그게 무슨 대단한 일인것처럼 의기양양했습니다.
그리고 빌 게이츠로부터 투자를 유치했을때를 기억합니다. 당시 우리는 투자 유치를 500만 달러, 83만 달러, 5억 달러, 그리고 150억 달러로 늘릴 수 있었습니다.

빌게이트로부터 150억 달러 투자 유치한 후 빌 게이츠가 하는 소리를 들었습니다.

“그건 쓰레기 같은 소리예요. 이건 플랫폼이 아닙니다. 플랫폼은 그것을 사용하는 모든 사람들의 경제적 가치가 그것을 창조하는 회사의 가치를 초과할 때입니다.그래야 플래폼이라고 부를 수 있어요.”

이러한 정의대로 윈도우즈(Windows)는 실제로 궁극적인 플랫폼이었습니다. 마이크로소프트는 윈도우즈 에코시스템 전체 가치 중 극히 일부만을 차지했다고 자랑하던 회사입니다.

그리고 이 운영 체제의 확실한 후계자는 Amazon Web Services와 Microsoft의 Azure Cloud Services입니다. 세 가지 사례 모두 견고하고 지속 가능성이 뛰어난 비즈니스를 가지고 있습니다.

플랫폼 비지니스 도면 - 써드파티가 고객을 유치
플랫폼 비지니스 도면 – 써드파티가 고객을 유치합니다.

그러나 일단 플랫폼이 빌게이츠 라인(Bill Gates Line) 아래로 빠지면, “플랫폼”을 기반으로하는 비즈니스의 장기적인 잠재력이 떨어지기 시작합니다.

예를 들어, 애플 앱스토어는 플랫폼의 모든 기능을 가지고 있지만 애플은 아이폰 수익성과 앱스토어 경제성 장악을 위해 에코시스템 전체를 확실하게 틀어쥐고 있습니다.

그로인해 앱스토어에서 강력하고 내구성있는 비즈니스가 부족한 것은 자연스런 결과입니다.

애플이 앱스토어 에코시스템을 통제하는 플랫폼 비지니스 도면
애플이 앱스토어 에코시스템을 통제하는 플랫폼 비지니스 도면

애플의 개발자 경제 통제 능력은 개발자와 고객 사이의 관계를 중개하는 데서 비롯됩니다.

이 이야기에서 빠진 것은 바로 그 모든 개발자들이 어떻게 앱스토어에서 돈을 벌었는가 하는 것입니다.

네, 의심할 여지 없이, 그것의 큰 부분은 아이폰의 폭발적인 성장과 어떻게 앱스토어가 쉽고 안전하게 앱을 설치할 수 있게 만들었는지에 있었습니다. 하지만 이것에 큰 역활은 페이스북이 했습니다.

페이스북 플랫폼

페이스북의 모바일 관련 초기 실패는 잘 알려져 있습니다. 페이스북은 초기에 웹 기반 앱에 베팅한 회사입니다. 페이스북 iOS 앱은 공개된 후에도 완전히 다시 개발되었습니다.

즉, 모바일이 폭발적으로 증가하는 시점에 모바일 앱은 제대로 작동하지 않았기 때문에 데스크톱 광고 제품과 플랫폼을 기본으로 할 수 밖에 없었습니다.

페이스북 모바일 앱 재 설계는 단순히 회사를 살리는 것 뿐만이 아니라 실제로 업계를 크게 변화시켰습니다. 이 페이스북 모바일 앱의 혁신적 기능 중 하나는 앱 설치 광고였습니다.

2012년 TechCrunch에서 다음과 같이 보도하고 있습니다.

페이스북은 앱 경제에 엄청난 베팅을 하고 있으며, 앱스토어 외부의 최고 검색 소스가 되고 싶어합니다.

페이스북 모바일 앱의 모바일 앱 설치 광고를 통해 개발자는 자신의 앱을 홍보하는 타일을 페이스북 모바일 뉴스 피드에서 구입할 수 있습니다. 이를 탭하면 사용자가 앱을 다운로드할 수 있도록 애플 앱스토어 또는 구글 플래이로 즉각 이동합니다.

페이스북 광고가 이미 잘 작동하고 있었습니다. 광고 클라이언트인 TinyCo는 다른 설치 채널에 비해 클릭율과 전환률이 50% 더 높았습니다.

페이스북 광고는 또한 더 많은 사용자들을 불러들였습니다. 광고 기술 스타트업체 Nanigans 고객은 페이스북 모바일 앱 설치 광고를 구입해 기존 기존 모바일 광고보다 8배~10배 더 많은 도달(reach)을 달성했습니다. AdParlor는 1-2%의 클릭율(click through rate)을 일관되게 유지했습니다.

페이스북의 App Install 제품은 사용자 획득에 가장 중요한 채널이 되었습니다.

특히 애플 인앱 구매 API로 수익을 창출한 게임의 경우, 페이스북 데이터가 앱 설치당 예상 가치에 대한 개발자의 정교한 이해와 결합되어 앱 스토어 매출의 폭발적 증가를 초래했습니다.

그럼에도 불구하고, 이마저도 페이스북을 의심하는 이유로 여겨졌습니다. 2015년에 저는 저명한 벤처 투자자들의 페이스북 회의론에 대해 썼습니다:

앱 설치 광고에 대한 비판의 상당 부분은 회사와 소비자 사이의 지배적인 상호 작용대신 앱을 재미있는 값싼 도구로 보는 구식 가정에 있습니다.

사용자와의 연결 시 웹 페이지나 다른 형태의 상호 작용보다 앱이 더 중요하다는 전제에서 시작한다면, 앱 설치를 위한 주요 채널이 되는 것이 훨씬 안전합니다.

물론, 페이스북 매출 중 적어도 일부는 게임용 앱 설치 광고에서 나올 것입니다. 그렇지 않나요? 물론이죠! 하지만 그마저도 세 가지 이유로 인해 비평가들이 생각하는 것보다 덜 위험합니다.

  • 벤처기업들이 돈을 헤프게 쓰는 경향이 있다고 해서 앱 설치 광고비 지출이 ‘스프레이 앤 프레이(spray-and-pray), 스프레이 뿌리듯 아무렇게나 광고를 집행하고 어느 하나 걸리기를 기도하는 것’에 불과하다고 보는 것은 실수입니다.

    사실, 앱 설치 광고는 직접 마케팅일 뿐만이 아니라 추적하기가 훨씬 쉽습니다. 특히 페이스북 앱 설치 광고는 가장 데이터 집약적인 광고 형식 중 하나입니다.
    .
  • 그렇기는 하지만, 제가 굴리(Gurley) 같은 벤처 투자가라면, 저는 모바일 게임에 대해서는 다소 조심스럽게 접근할 것입니다.

    거기에는 투자 유치 심지어는 기업 공개(IPO)를 위해서 이런 1회성 깜짝 성과를 내는 놀라운 사례들이 많이 있습니다.
    이후 그들은 초기 성공을 재현하기 위해 발버둥칠 뿐입니다. 정말 투자하기 어려운 분야라고 생각합니다.

    그러나 페이스북은 특정 게임 회사가 성공하든 실패하든 신경 쓸 필요가 없습니다. 왜냐하면 그들은 어떤 게임 회사에도 노출되지 않기 때문입니다. 그들은 산업 전반에 노출되어 있습니다.
    그리고 그 점에 대해서 다음과 같이 말씀드리겠습니다.
    .
  • 모바일 게임 분약 매출은 일시적인 성공이 아닙니다.(flash-in-the-pan은 프라이팬 속의 불꽃이라고 직역할 수 있는데, 이는 일시적인 성공이나 용두사미적인 계획이라는 의미로 사용됨)

    비디오 게임 조사 회사인 뉴저지에 따르면, 올해 전 세계 모바일 게임 매출이 콘솔 게임 매출을 초과할 것으로 예상된다고 합니다.
    흥미롭게도, 콘솔 게임 매출은 아마도 여전히 북미에서 우세할 것이므로, 미국 기반 관찰자들은 여기에서 맹점을 들어낼 것입니다.
    모바일 게임 비중은 아시아 지역에서 절대적으로 높아질 것입니다.

…결국, 거품이 생기면 페이스북을 포함한 모든 사람이 피해를 입을 것입니다. 하지만 큰 그림으로 볼 때 저는 그 회사가 실리콘밸리에서 가장 저평가된 회사라고 생각합니다.

  • 페이스북은 그들의 수익화 능력을 거의 드러내지 않았고,
  • 브랜드 광고는 아직 TV에서 이동하지 않았으며,
  • 인스타그램은 여전히 수익화되지 않았으며,
  • 페이스북 사용자는 여전히 증가하고 있습니다.

이 발췌문은 모바일 게임에 관한 것이지만, 이 분석은 페이스북에서 성장한 소비자 직접 연결하는 이커머스회사와 같은 수많은 업계에 적용됩니다.

  • 페이스북 타겟팅은 온라인으로 전환되는 회사들에게 특히 강력한 조합입니다.

    실제로 회사를 평가하면서 제가 저지른 가장 큰 실수는 브랜드 광고 잠재력을 과대평가하고 소비자 직접 대응 기회(direct response opportunity)가 얼마나 큰지를 과소평가한 것입니다.
    .
  • 이와 관련, 페이스북이 새로운 직접 대응 기반 기업( direct response-based companies)의 탄생 여건을 조성했기 때문에 직접대응 기회( direct response opportunity)가 매우 커졌습니다.

    앱의 경우 애플 및 구글(안드로이드)과 함께 이 기회를 만들었고, 이커머스의 경우 Shopify와 함께 이 기회를 만들었습니다.

    두 사례의 공통점은 페이스북 광고가 인터넷에 국한된 새로운 사업을 창출하는 데 결정적인 요소였다는 점입니다.
    .
  • 모바일 게임만이 아닙니다. 인터넷의 변혁적 영향이 이제 막 감지되기 시작했습니다.

    다시말하면 장기적으로 볼 때 전통적인 기업들은 이제라고 디지털을 채택하는 것이 기존 비지니스가 모두 쓸모없어 지는 것보다는 나을 것입니다.
    이러한 예로 제가 가장 좋아하는 회사가 바로 CPG 회사들입니다.

페이스북의 강점, Facebook’s Anti-Fragility

2016년에 쓴 ‘TV광고의 놀라운 강점과 필연적인 몰락, TV Advertising’s Surprising Strength — And Inevitable Fall‘을 인용해 보죠.

텔레비전 광고 기관은 광고주, 그들이 판매하는 상품, 그리고 그들이 사고 파는 방식과 얽혀 있습니다.

그리고 텔레비전 광고사 경영진들에게 끔찍한 사실은 텔레비전 광고들이 TV 시청 자체와 똑같이 인터넷으로 부터 위협 받고 있다는 것입니다.

CPG는 완벽한 예입니다. “house of brands”을 구축하면 P&G와 같은 회사가 규모를 활용하여 R&D에 투자하고, 제품 비용을 낮추며, 가장 중요한 유통 채널(즉, 소매 유통 진열 공간)을 장악해 인구 통계학적 그룹을 타깃으로 삼을 수 있습니다.

한편 소매업체들은 자체적으로 규모가 크기 때문에 협상 테이블에서 대규모 공급업체와 맞짱뜰 수 있을 뿐만 아니라 물류, 재고 관리, 매장 개발 등으로 확장할 수 있습니다.

반면 자동차 회사들은 CPG 회사들과 다릅니다. 그들은 생산 및 유통 규모의 혜택을 누리면서 다양한 인구 통계에 맞추기 위해 “house of brands”를 운영합니다.

가장 큰 차이점은 시간이 지남에 따라 여러 번의 작은 구매 대신 한 번의 큰 구매로 돈을 버는 것입니다.

이와 유사한 원칙이 이 목록에 있는 다른 기업에도 적용됩니다. 즉, 모든 기업은 기껏해야 무딘 타겟팅으로 가능한 한 많은 소비자에게 다가가고 있으며, 규모에 따라 혜택을 받고 있으며, 모든 기업은 소비자로부터 상당한 평생 가치를 창출할 것으로 기대하고 있습니다.

그리고, 그러한 기대에 따라 엄청난 TV 광고 비용을 부담할 수 있습니다. 실제로 미국 200대 광고주들은 전체 광고의 51%(그리고 디지털 광고의 41%)에 불과함에도 불구하고 TV 광고의 80%를 차지할 정도로 TV 광고를 매우 좋아합니다.

이는2019년 1분기 기준 페이스북 100대 광고주들이 페이스북 광고 매출의 20% 미만을 차지했던 것과 매우 다른 양상입니다. 작년에 페이스북이 번 697억 달러의 대부분은 800만 광고주의 롱테일에서 나온 것입니다.

페이스북의 완전 자동화된 광고 구매 시스템 때문에 이러한 롱테일(long-tail) 집중이 가능하므로 이는 코로나 팬데믹 동안의 경제 침체 시 엄청난 자산이 되었습니다.

페이스북은 2020년 1분기 실적 발표에서 다음과 같이 설명했습니다.

이 첫 번째 부분은 월스트리트저널 기사의 잘못된 점을 지적합니다. 단순히 브랜드 광고가 감소하는 동안 (페이스북) 직접 광고가 강력하게 유지된 것이 아니라 브랜드 광고가 감소했기 때문에 직접 반응 광고를 많이 받았다는 것입니다.

하지만, 한정된 광고를 위해 경쟁하던 광고주들 일부가 광고 구매를 중단하는 코로나 팬데믹에서 발생하는 상황을 주목해 보십시오.

모바일 게임 회사들은 광고 예산을 줄이지 않습니다. 광고 예산을 줄이면 회사를 죽이는 것이 될 것입니다! – 하지만 실제로는 더 효율적인 광고 집행을 하게 됩니다.

갑자기 앱 설치 광고 단가가 앱 설치당 0.75달러로 떨어졌습니다. 그래서 이 모바일 게임 회사는 2만달러로 26,667개의 앱 설치를 기대할 수 있습니다. 이것으로 6,667달러 예상 수익을 올렸습니다.

이는 분명히 페이스북에게는 부정적입니다. 즉, 추가적으로 6,000달러의 이윤이 페이스북의 주머니에서 빠져나간다는 것입니다. 하지만 동시에 모바일 회사들이 광고비 지출을 줄이지 않았기 때문에 손실이 상쇄됩니다.

물론, 이러한 기회가 점점 더 많은 기업들에게 돌아가면서, 결국 페이스북 이익은 재고량에 따라 결정됩니다. 이는 페이스북 플랫폼 사용량이 증가하고 있다는 점을 감안하면 정상으로 회복되고 더 나아가 더 많은 광고 매출이 발생할 수 있습니다.

이는 대형 CPG 기업들이 페이스북을 보이콧한다는 소식이 재정적인 관점에서 큰 문제가 아닌 이유입니다.

예를들어 유니레너 미국 광고 지출액 1,180만 달러는 절대적으로 없어지지 않을 페이스북 타임라인 컨텐츠에서 자동화된 효율성으로 다른 광고로 대체됩니다.

게다가, 페이스북은 광고 매출 최상위 기업들을 잃겠지만, 이들은 페이스북 광고 경매 시스템에서 가장 낮은 가격으로 수주해 왔기 때문에 전반적으로 평균 광고 단가가 올라갈 수 있습니다.

이러한 방식으로 페이스북은 구글조차 가지고 있지 못한 강점을 가지고 있습니다.

페이스북의 많은 사업들은 페이스북을 중심으로 만들어진 인터넷 네이티브 회사들의 롱테일에서 비롯됩니다. 코로나 팬데믹 사태나 현재와 같은 불매운동은 실제로는 페이스북 에코시스템을 강화시키는 역활을 합니다.

페이스북 취약점, 애플

그러나 페이스북도 취약성을 가지고 있습니다. 바로 애플입니다. AdAge 기사를 보시죠.

애플은 곧 출시될 iOS 14 소프트웨어에 대한 새로운 개인 정보 보호 변경 사항을 발표했는데, 이는 미디어 구매자와 브랜드가 소비자를 타켓팅하고 측정하고 찾는 방법을 크게 방해할 것입니다.

  • 이러한 변경으로 앱이 서로 다른 앱과 웹 사이트에서 iOS 사용자를 추적하기가 더 어려워질 것입니다.
  • 또한 어떤 마케팅 전술이 판매 또는 전환에 기여했는지 판단하기가 더 어려워질 것입니다.

월요일 애플의 WWDC(Worldwide Developers Conference)에서 발표된 변경 사항은 사용자의 모바일 장치에 고유 번호를 할당하는 애플의 IDFA(Indentifier for Advertisers)에 적용됩니다. 광고주들은 이 기능에 접근하여 광고 타겟팅, 유사 잠재 고객 구축, 고객 특성 파악 및 앱 다운로드 촉진 등에서 이 기능을 사용할 수 있습니다.

IDFA는 기본적으로 앱 업체 및 광고주와 공유되지만, iOS 14가 올 가을에 출시되면 변경될 것입니다. 변경되면 앱 게시자는 다른 앱 및 웹 사이트에서 해당 앱 정보를 추적하거나 타사와 공유할 수 있도록 팝업을 띄워서 사용자로부터 명시적 권한을 이임받아야 합니다.

페이스북은 IDFA(및 안드로이드에서 이와 같은 개념인 구글 Advertising ID)의 왕이었습니다. 이는 페이스북의 앱 설치 비즈니스의 기반이 되었습니다.

페이스북은 사용자가 게임에서 일정 금액을 소비했을 시점을 파악하여 유사한 사용자를 찾아 해당 게임에 대한 앱 설치 광고를 표시하고 그 효과를 측정할 수 있었습니다.

사실, 지난 몇 년 동안, 페이스북은 광고주들에게 단지 그들의 페이스북 광고 달성 목표를 명시해 달라고 요청해 왔습니다. 그리고 페이스북은 사용자들에게 얼마나 많은 광고를 표시할 것인지 등등 정보를 파악하는 모든 작업을 합니다. 전체 과정은 자동화되어 있습니다.

이 부분은 많이 달라질 것 같습니다. 애플은 매우 영리하게 접근하고 있습니다. 반경쟁으로 해석될 수 있는 IDFA를 죽이는 대신, 애플은 단순히 사용자들에게 추적당하고 싶은지 물어보도록 만들어, IDFA를 쓸모없게 만들고 있습니다.

지금도 미국 아이폰 사용자들 중 30%가 자신의 IDFA를 꺼버리고 사용하고 있으며, 페이스북은 이들에게는 앱 설치 광고조차 보여주지 않고 있습니다. 이제 이러한 IDFA 적용 여부는 예전의 옵트아웃(Opt-out) 대신 옵트인(Opt-in)으로 제공될 것입니다.

추가로 설명하면 이전에는 IDFA 적용이 기본이었고 사용자가 IDFA 사용하지 않겠다고 추가 옵션 설정하면 중지되는 옵트아웃 방식이었다면, 이제는 사용자가 사용하겠다고 동의하기 전에는 적용되지 않는 옵트인 방식으로 변경되는 것입니다.

그래도 저는 페이스북을 무시할 수 없습니다.

데이타 수집과 디지탈 광고 표시 측면에서 페이스북보다 우월하지 못하는 대부분 다른 디지탈 기술 광고 회사들은 훨씬 더 힘든 환경에 처할 것으로 보이며, 페이스북이 상처를 입을 정도로 디지탈 에코 시스템과 관련된 광고가 사라질 것으로 보이지 않습니다.

사실, GDPR과 마찬가지로, 안전한 방법은 역경속에서도 성과를 낼 수 있는 능력을 가진 회사입니다. 특히, 앱 설치 광고 캠페인에 대한 애플의 대안인 SKAdNetwork는 너무 제한적이어서 페이스북같이 자동화된 캠페인을 만들 수 있는 회사는 엄청난 가치가 있을 것입니다.

또한 제가 지난 달에 설명한 것처럼, 애플의 웹 쿠키 단속이 페이스북에도 도움이 되었다는 점도 주목할 필요가 있습니다.

애플의 이러한 정책은 써드파티 결제 제공업체가 원활한 서비스를 제공하는 것을 더욱 어렵게 함으로써, 페이스북이 D2C 기업에 대한 페이먼트 서비스를 제공할 수 있는 기회의 열어주고 있습니다.

페이스북 샵은 이에 대한 완벽한 예입니다.

페이스북 샵은 쇼피파이를 이용하는 판매자들에게도 좋기 때문에 성공할 것이지만, 쇼피파이가 결제 문제를 스스로 해결할 수 없도록 애플과 페이스북이 효과적으로 협력했기 때문에 페이스북이 결제 부분을 차지할 수 있었습니다.

이것이 애플-페이스북의 역동성을 매우 매력적으로 만들어 줍니다. 페이스북의 가장 큰 기회는 애플이 매번 페이스북을 반대하는 것처럼 보이는데도 불구하고 애플의 플랫폼 제안의 허점을 메우는 데서 옵니다.

애플과 페이스북의 위험 공유

특히 주목할 점은 두 회사 사이의 갈등이 그들의 가장 큰 자산을 어떻게 위협하느냐 하는 것입니다.

애플

쿠키와의 싸움과 IDFA의 효과적인 폐지는 한 가지 관점에서 사용자에게 초점을 맞추고 있지만, 서비스 수익 확대를 위한 애플의 전략 집중을 무시할 수는 없습니다.

웹을 덜 유용하게 만드는 것은 애플이 그 몫을 차지할 수 있는 앱들을 더 유용하게 만듭니다. 마찬가지로, 애플이 업계의 제품들을 무력화시키면서까지 자체적인 앱 설치 제품을 확장하고 있다는 것은 주목할 만합니다.

문제는 이러한 서비스 수익 극대화를 위한 시도가 사용자 경험 또는 애플의 수익에 부합하는지 여부입니다.

애플은 사용자 경험 확대가 수익으로 이어진다는 것을 기억해야 합니다.

페이스북

한편 페이스북은 이미 페이스북 샵 발표에서 볼 수 있듯이 최고의 파트너로부터 비즈니스를 이끌어 낼 수 있는 가능성을 보고 있습니다.

공급 업체가 자체 앱에서 장치 ID를 가져올 수 있도록하는 IDFV (공급 업체 식별자)를 여전히 사용할 수 있다는 점에서 IDFA와 비슷한 유혹을 받을 수 있을 것입니다.

페이스북은 자사의 비즈니스 모델을 다른 앱 광고 플랫폼에서 가장 인기 있는 게임과 서비스를 위한 WeChat과 같은 퍼블리싱 모델로 전환하는 것을 고려할 수 있을까요?

페이스북은 또한 주의해야 합니다. 롱테일 서비스는 애플보다 빌게이츠 타입의 플랫폼으로 만들었을 뿐만 아니라 위기를 극복할 회사의 힘의 근간이기도 합니다.

그럼에도 불구하고, 그 어느 때보다 분명해 보이는 것은 이 두 회사, 즉 애플과 페이스북이 이 산업을 주도하고 있다는 것입니다.

그들의 접근 방식이 매우 다르다는 것은 실제로는 그들이 가장 중요한 전략적 동반자가 될 수 있는지를 설명해 줍니다.

리눅스 백신 ClamAV 스캔 결과 메일로 받아보기

0

일전에 서버 및 워드프레스 보안을 위한 무료 리눅스 백신 ClamAV 이용 및 문제 해결법에 대해 포스팅 했습니다. 그 후 리눅스 서버에서 정기적으로 멀웨어가 있는지 ClamAV 스캔 후 그 결과를 관리자 메일로 보내는 방법을 고민해 봤습니다.

여기서는 리눅스 서버에서 ClamAV 스캔 후 멀웨어가 있는 경우와 없는 경우로 나우어 서버 관리자에게 메일로 알려주는 방법에 대해서 살펴보도록 하겠습니다.

우선 무료 리눅스 백신 ClamAV 사용법에 대해서는 아래 글을 참조하시기 바랍니다. ClamAV 설치 및 기본 이용 방법에 대해서는 이 글을 참조하시라고 별도로 설명하지는 않겠습니다.

ClamAV 멀웨어 스캔 결과를 메일로 보내는 방법

다행히 우분투 서버에서 ClamAV 스캔 후 메일로 보내는 방법들이 소개되어 있어 이를 기반으로 오류를 수정해 우분투 서버에 적용할 수 있었습니다.

비교적 자세히 설명된 자료는 아래를 참고하시기 바랍니다.

Configure Clamav for daily system scans and email notification on Debian

저도 이 사용법대로 사용해 봤는데 잘 안되어서 몇가지를 수정했습니다.

메일 발송 시스템

우선 저는 서버 메일 발송 시스템으로 지메일 릴레이 기능을 이용했다는 점을 밝히고 싶습니다. 메일 발송 시스템에 따라서 설정이 달라질 수 있다는 생각입니다.

이전 포스팅에서도 밝혔지만 제가 선택한 지메일 이용은 지메일에서 제공하는 릴레이 기능을 활용하므로 안전하고 스팸 메일로 분류될 가능성이 아주 적습니다. 다만 하루 500통 정도로 메일 발송횟수가 제한된다는 한계는 있습니다.

그렇기때문에 ClamAV로 스캔 후 메일 보낼 시 SMTP 메일 발송 옵션을 명기해 지메일 SMTP로 메일이 갈 수 있도록 했습니다.

아래와 같은 내용을 추가합니다.

# ClamAV 검사 및 메일 보내기
smtp_server=smtp.gmail.com:587
smtp_auth=Yes
smtp_pass=지메일 웹 비밀번호
smtp_ssl=YesCode language: PHP (php)

바이러스 데이타베이스 업데이트

스캔전에 ClamAV가 가지고 있는 바이러스 데이타베이스를 업데이트해야 하는데요.

저의 경우는 일부 에러가 나타나서 아래와 같이 강제적으로 바이러스 데이타베이스 업데이트하도록 만들었습니다.

# 바이러스 데이타베이스 업데이트
lsof /var/log/clamav/freshclam.log 
pkill -15 -x freshclam 
/etc/init.d/clamav-freshclam stop  
freshclam 
/etc/init.d/clamav-freshclam startCode language: PHP (php)

ClamAV로 바이러스 스캔 및 결과 이메일로 보내기

여기서는 ClamAV로 바이러스 감염여부를 스캔한 후 감염 파일이 있는지 아닌지에 따라 다른 내용의 메일을 보내는 방법을 설명합니다.

먼저 앞부분에서 로그파일 위치, 이메일 주소, 스캔할 폴더 등을 지정해 줍니다.

LOGFILE="/var/log/clamav/clamav-$(date +'%Y-%m-%d').log";
EMAIL_FROM="발송 이메일 주소";
EMAIL_TO="수신 이메일 주소";
DIRTOSCAN="ClamAV가 스캔할 폴더";Code language: PHP (php)

다음으로 ClamAV로 스캔 및 그 결과를 메일로 보내는 쉘 스크립터를 작성합니다. 이는 쉡 스크립터에서 사용하는 if – then – else – fi 명령을 사용합니다.

이 스크립트에서 제가 아는 범위내에서 설명을 추가했으니 참고하시기 바랍니다.

for S in ${DIRTOSCAN}; do
 DIRSIZE=$(du -sh "$S" 2>/dev/null | cut -f1);
 
 echo "Starting scan of "$S" directory.
 Directory size: "$DIRSIZE".";
 # 스캔한 폴더 용량 표시, 다른 표현 명령 Amount of data to be scanned is "$DIRSIZE".";
 
 clamscan -ri "$S" >> "$LOGFILE";
 # 감염 파일을 옮기는 경우 다음 명령 사용, clamscan -ri --remove "$S" >> "$LOGFILE";
 
 # 멀웨어 등에 감염된 라인이 있는 지 확인, get the value of "Infected lines"
 # find /var/log/clamav/ -type f -mtime +30 -exec rm {} \;
 MALWARE=$(tail "$LOGFILE"|grep Infected|cut -d" " -f3);
 
 # 멀웨어 감염 파일이 0이 아니라면, 즉 감염 파일이 있다면 멀웨어가 발견되었다는 메세지와 함께 로그 파일 첨부해 메일 발송, 
 # if the value is not equal to zero, send an email with the log file attached
 if [ "$MALWARE" -ne "0" ];
 	then
        # using heirloom-mailx below	
        echo "오늘 ClamAV로 서버를 스캐닝했습니다. 그 결과 오늘 스캔한 $DIRTOSCAN에서 멀웨어가 발견되었습니다. 자세한 내용은 첨부 로그 파일을 참조하시기 바랍니다."|mail -A "$LOGFILE" -s "멀웨어가 발견되었습니다!!" -r "$EMAIL_FROM" "$EMAIL_TO";
    else
        echo -e "오늘 ClamAV로 서버를 스캐닝했습니다. 그 결과 다행히 아무런 멀웨어가 발견되지 않았습니다. 따라서 오늘 스캔한 $DIRTOSCAN 부분은 안전하다고 할 수 있습니다. 자세한 내용은 첨부 로그 파일을 참조하시기 바랍니다."|mail -A "$LOGFILE" -s "스캔 결과 다행히 감염 파일은 없었습니다!!" -r "$EMAIL_FROM" "$EMAIL_TO";

 fi
done
 
exit 0Code language: PHP (php)

최종 자동 실행 시키기

위에서 정리한 내용을 토대로 리눅스 서버 크론탭에서 자동으로 실행되도록 만들겠습니다.

우선 실행 파일을 만듭니다. 실행 파일은 clamav.sh로 정하죠. 편집기를 열어 파일 편집 준비를 합니다.

nano clamav.shCode language: PHP (php)

이 파일에 위에서 정리한 내용을 추가합니다. 그리고 저장해야죠.

#!/bin/sh

# 바이러스 데이타베이스 업데이트
lsof /var/log/clamav/freshclam.log 
pkill -15 -x freshclam 
/etc/init.d/clamav-freshclam stop  
freshclam 
/etc/init.d/clamav-freshclam start

# ClamAV 검사 및 메일 보내기
smtp_server=smtp.gmail.com:587
smtp_auth=Yes
smtp_pass=지메일 웹 비밀번호
smtp_ssl=Yes

LOGFILE="/var/log/clamav/clamav-$(date +'%Y-%m-%d').log";
EMAIL_FROM="발송 이메일 주소";
EMAIL_TO="수신 이메일 주소";
DIRTOSCAN="ClamAV가 스캔할 폴더";
 
for S in ${DIRTOSCAN}; do
 DIRSIZE=$(du -sh "$S" 2>/dev/null | cut -f1);
 
 echo "Starting scan of "$S" directory.
 Directory size: "$DIRSIZE".";
 # 스캔한 폴더 용량 표시, 다른 표현 명령 Amount of data to be scanned is "$DIRSIZE".";
 
 clamscan -ri "$S" >> "$LOGFILE";
 # 감염 파일을 옮기는 경우 다음 명령 사용, clamscan -ri --remove "$S" >> "$LOGFILE";
 
 # 멀웨어 등에 감염된 라인이 있는 지 확인, get the value of "Infected lines"
 # find /var/log/clamav/ -type f -mtime +30 -exec rm {} \;
 MALWARE=$(tail "$LOGFILE"|grep Infected|cut -d" " -f3);
 
 # 멀웨어 감염 파일이 0이 아니라면, 즉 감염 파일이 있다면 멀웨어가 발견되었다는 메세지와 함께 로그 파일 첨부해 메일 발송, 
 # if the value is not equal to zero, send an email with the log file attached
 if [ "$MALWARE" -ne "0" ];
 	then
        # using heirloom-mailx below	
        echo "오늘 ClamAV로 서버를 스캐닝했습니다. 그 결과 오늘 스캔한 $DIRTOSCAN에서 멀웨어가 발견되었습니다. 자세한 내용은 첨부 로그 파일을 참조하시기 바랍니다."|mail -A "$LOGFILE" -s "멀웨어가 발견되었습니다!!" -r "$EMAIL_FROM" "$EMAIL_TO";
    else
        echo "오늘 ClamAV로 서버를 스캐닝했습니다. 그 결과 다행히 아무런 멀웨어가 발견되지 않았습니다. 따라서 오늘 스캔한 $DIRTOSCAN 부분은 안전하다고 할 수 있습니다. 자세한 내용은 첨부 로그 파일을 참조하시기 바랍니다."|mail -A "$LOGFILE" -s "스캔 결과 다행히 감염 파일은 없었습니다!!" -r "$EMAIL_FROM" "$EMAIL_TO";

 fi
done
 
exit 0Code language: PHP (php)

다음으로 크론탭에 이 실핼 파일을 정기적으로 작동하라고 명령합니다.

다 아시겠지만 크론탭 명령을 등록 편집하는 것은 crontab -e 옵션을 사용합니다.

crontab -eCode language: PHP (php)

크론탬 명령을 추가합니다. 저는 매일 새벽 3시 15분에 실행하도록 했습니다. 다른 명령과 겹치다보니 이 시간이 나왔네요.

15 03 * * * clamav.shCode language: PHP (php)

크론탭 명령을 추가했으면 크론을 재 실행시킵니다.

service cron startCode language: PHP (php)

실행 후 이런 메일이 날라오는군요. 다행히 멀웨어에 걸린 워드프레스 파일들은 없다고요.

무료 리눅스 백신 Clamav 실핼 시킨 후 결과 메일

워드프레스 보안 진단 WPScan 사용법 및 이메일로 결과 받아보기

워드프레스 테마, 플러그인 등 워드프레스 전반에 걸쳐 취약점을 스캐닝할 수 있는 워드프레스 보안진단 툴인 WPScan 사용법을 정리해 보고, 이 스캔 결과를 이메일로 받아 볼 수 있는 방법에 대해 살펴봅니다.

워드프레스는 전 세계 CMS 사이트의 30%이상을 차지하는 가장 널리 사용되는 CMS 중 하나입니다. 그렇게 많이 사용하는만큼 해킹에 대한 시도가 끊이지 않는데요.

워드프레스 테마, 플러그인 그리고 워드프레스 코어 파일등이 멀웨어 감염되어 있는지 업데이트가 제대로 되어 있지 않은지 등을 워드프레스 보안 진단 툴인 WPScan으로 검사해 볼 수 있습니다.

여기서는 WPScan을 설치하고, 간단한 사용법을 토대로 정기적으로 워드프레스 취약점을 스캐닝하고 이 결과를 메일로 받아볼 수 있도록 만들어 보도록 하겠습니다.

WPScan이란

WPScan은 2011년 보안 전문가와 워드프레스 블로그 관리자들이 모여서 워드프레스 보안 취약성 데이타베이스를 구축하면서 시작했습니다.

WPScan는 워드프레스 취약점 데이타베이스를 API를 받아와 웓프레스 사이트를 스캐닝하면서 아래와 같은 사항을 점검합니다.

  1. 워드프레스 설치 버젼 체크 및 관련 취약성 점검
  2. 설치 플러그인 및 취약성 점검
  3. 설치 테마 및 취약성 점검
  4. 워드프레스 사용자 리스트
  5. 워드프레스 사용자중 암호화가 약한 암호를 가진 사용자 점검
  6. 백업 및 공개 액세스 가능한 파일이 있는지 점검
    wp-config.php 파일 포함
  7. 공개 액세스 가능한 데이터베이스가 있는지 점검
  8. 워드프레스 플러그인으로 인한 오류 로그 노출 여부.
  9. 미디어 파일 리스트
  10. 취약한 Timthumb 파일 여부
  11. 워드프레스 readme 파일 존재 여부
  12. WP-Cron 활성화 여부
  13. 사용자 등록 활성화 여부
  14. 워드프레스 전체 경로
  15. 디렉터리 목록

WPScan 사용법에 대해서는 아래 사용자 매뉴얼을 참조해 보시기 바랍니다.

WPScan User Documentation

WPScan 설치

워드프레스에서 WPScan을 사용하는 방법은 가장 간단한 방법은 WPScan 플러그인을 사용하는 방업입니다.

WPScan – WordPress Security Scanner

아마 쟁쟁한 워드프레스 보안 플러그인들이 많기 때문에 WPScan 플러그인 사용자는 그리 많지는 않습니다.

워드프레스 테마, 플러그인 등 위약점 진단은 워드프레스 보안 플러그인의 여러 분야 중 하나이기 때문에 대부분 워드프레스 보안 플러그인에서 제공하고 있는 기능이기도 하기 때문입니다.

그러나 저는 플러그인보다는 서버에서 직접 스캐닝하는 것을 원하고, 더우기 서버에서 스캐닝 시 여러 개의 워드프레스 사이트를 동시에 스캐닝할 수 있기 때문에 서버에서 사용하려고 합니다.

우분투에서 WPScan 설치

우선 우분투 서버를 업데이트하고 WPScan 설치 및 운영에 필요한 제반 프로그램을 설치합니다.

sudo apt update

sudo apt install curl git libcurl4-openssl-dev make zlib1g-dev gawk g++ gcc libreadline6-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 autoconf libgdbm-dev libncurses5-dev automake libtool bison pkg-config ruby ruby-bundler ruby-dev -y libsqlite3-dev sqlite3 autoconf libgdbm-dev libncurses5-dev automake libtool bison pkg-config ruby ruby-bundler ruby-dev -yCode language: PHP (php)

이제 WPScan을 설치합니다. WPScan은 Ruby로 작성되었기 때문에 Ruby의 gem 설치기를 사용합니다.

gem install wpscanCode language: PHP (php)

CentOS 8/RHEL 8/Fedora에서 설치

먼저 ruby를 설치합니다.

sudo dnf install rubyCode language: PHP (php)

WPScan 설치 및 운영에 필요한 제반 프로그램을 설치합니다.

sudo dnf group install "Development Tools"
sudo dnf install git gcc ruby-devel libxml2 libxml2-devel libxslt libxslt-devel libcurl-devel patch rpm-buildCode language: PHP (php)

WPScan을 설치합니다.

sudo gem install wpscanCode language: PHP (php)

WPScan 사용법

먼저 데이타베이스를 업데이트합니다.

wpscan --updateCode language: PHP (php)

이러면 아래와 같은 메세지를 볼 수 있습니다.

_______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

         WordPress Security Scanner by the WPScan Team
                         Version 3.8.2
                               
       @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[i] Updating the Database ...
[i] Update completed.
Code language: PHP (php)

이 상태에서 바로 사이트 점검을 할 수 있습니다. “–url=” 다음에 사이트 주소를 넣어 스캔토록 합니다.

wpscan --url=https://happist.comCode language: PHP (php)

그러면 이런 화면을 볼 수 있습니다.

______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

         WordPress Security Scanner by the WPScan Team
                         Version 3.8.2
       Sponsored by Automattic - https://automattic.com/
       @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[+] URL: https://happist.com/ [141.164.48.62]
[+] Started: Mon Jun 29 06:38:26 2020

Interesting Finding(s):

[+] Headers
 | Interesting Entries:
 |  - server: nginx
 |  - x-ua-compatible: IE=edge
 |  - referrer-policy: origin
 |  - content-security-policy: script-src 'self' 'unsafe-inline' inicis.com ; frame-ancestors 'self';
 |  - access-control-allow-origin: *
 |  - x-debug-whats-going-on: on
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] https://happist.com/robots.txt
 | Interesting Entries:
 |  - /wp-login.php
 |  - /xmlrpc.php
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] The external WP-Cron seems to be enabled: https://happist.com/wp-cron.php
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 60%
 | References:
 |  - https://www.iplocation.net/defend-wordpress-from-ddos
 |  - https://github.com/wpscanteam/wpscan/issues/1299

[+] WordPress version 5.4.2 identified (Latest, released on 2020-06-10).
 | Found By: Rss Generator (Passive Detection)
 |  - https://happist.com/feed/, <generator>https://wordpress.org/?v=5.4.2</generator>
 |  - https://happist.com/comments/feed/, <generator>https://wordpress.org/?v=5.4.2</generator>

[+] WordPress theme in use: generatepress
 | Location: https://happist.com/wp-content/themes/generatepress/
 | Latest Version: 2.4.2 (up to date)
 | Last Updated: 2020-03-17T00:00:00.000Z
 | Style URL: https://happist.com/wp-content/themes/generatepress/style.css
 | Style Name: GeneratePress
 | Style URI: https://generatepress.com
 | Description: GeneratePress is a lightweight WordPress theme built with a focus on speed and usability. Performanc...
 | Author: Tom Usborne
 | Author URI: https://tomusborne.com
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | Version: 2.4.2 (80% confidence)
 | Found By: Style (Passive Detection)
 |  - https://happist.com/wp-content/themes/generatepress/style.css, Match: 'Version: 2.4.2'

[+] Enumerating All Plugins (via Passive Methods)
[+] Checking Plugin Versions (via Passive and Aggressive Methods)

[i] Plugin(s) Identified:

[+] content-views-query-and-display-post-page
 | Location: https://happist.com/wp-content/plugins/content-views-query-and-display-post-page/
 | Latest Version: 2.3.2 (up to date)
 | Last Updated: 2020-03-27T08:24:00.000Z
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | Version: 2.3.2 (20% confidence)
 | Found By: Query Parameter (Passive Detection)
 |  - https://happist.com/wp-content/plugins/content-views-query-and-display-post-page/public/assets/css/cv.css?ver=2.3.2
 |  - https://happist.com/wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js?ver=2.3.2

[+] embed-any-document-plus
 | Location: https://happist.com/wp-content/plugins/embed-any-document-plus/
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] gp-premium
 | Location: https://happist.com/wp-content/plugins/gp-premium/
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] lazy-loading-responsive-images
 | Location: https://happist.com/wp-content/plugins/lazy-loading-responsive-images/
 | Latest Version: 6.0.1
 | Last Updated: 2020-05-01T15:42:00.000Z
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] otter-blocks
 | Location: https://happist.com/wp-content/plugins/otter-blocks/
 | Latest Version: 1.5.5
 | Last Updated: 2020-06-22T22:22:00.000Z
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] pt-content-views-pro
 | Location: https://happist.com/wp-content/plugins/pt-content-views-pro/
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] sassy-social-share
 | Location: https://happist.com/wp-content/plugins/sassy-social-share/
 | Latest Version: 3.3.10 (up to date)
 | Last Updated: 2020-05-14T06:16:00.000Z
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | Version: 3.3.10 (30% confidence)
 | Found By: Query Parameter (Passive Detection)
 |  - https://happist.com/wp-content/plugins/sassy-social-share/public/css/sassy-social-share-public.css?ver=3.3.10
 |  - https://happist.com/wp-content/plugins/sassy-social-share/admin/css/sassy-social-share-svg.css?ver=3.3.10
 |  - https://happist.com/wp-content/plugins/sassy-social-share/public/js/sassy-social-share-public.js?ver=3.3.10

[+] searchwp-live-ajax-search
 | Location: https://happist.com/wp-content/plugins/searchwp-live-ajax-search/
 | Last Updated: 2020-04-23T12:09:00.000Z
 | [!] The version is out of date, the latest version is 1.4.6.1
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | Version: 1.4.6 (10% confidence)
 | Found By: Query Parameter (Passive Detection)
 |  - https://happist.com/wp-content/plugins/searchwp-live-ajax-search/assets/styles/style.css?ver=1.4.6

[+] stackable-ultimate-gutenberg-blocks-premium
 | Location: https://happist.com/wp-content/plugins/stackable-ultimate-gutenberg-blocks-premium/
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | The version could not be determined.

[+] Enumerating Config Backups (via Passive and Aggressive Methods)
 Checking Config Backups - Time: 00:00:01 <=============================> (21 / 21) 100.00% Time: 00:00:01

[i] No Config Backups Found.

[!] No WPVulnDB API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 50 daily requests by registering at https://wpvulndb.com/users/sign_up

[+] Finished: Mon Jun 29 06:38:47 2020
[+] Requests Done: 91
[+] Cached Requests: 7
[+] Data Sent: 17.227 KB
[+] Data Received: 792.266 KB
[+] Memory used: 188.879 MB
[+] Elapsed time: 00:00:20Code language: PHP (php)

위 결과에 따르면 WP cron을 활성화되어 있어 60% 신뢰도를 보이고, sassy-social-share 플러그인는 업데이트가 필요하고, 30% 신뢰도를 보인다고 지적합니다.

저는 이 sassy-social-share 플러그인의 일부 파일을 수정해 한국 소셜 미디어를 추가했기 때문에 이런 지적이 나오는 것 같습니다.

단 주의할 점은 서버에서 사이트 주소를 리다이렉트했으면 리다이렉트한 주소를 입력해야 합니다.

워드프레스 요소별로 스캔하려면

워드프레스 전체가 아니라 요소별로 스캔하려면 아래와 같은 옵션을 사용합니다.

[Scan installed plugins]
wpscan --url https://happist.com --enumerate p

[Scan vulnerable plugins]
wpscan --url https://happist.com --enumerate vp

[Scan installed themes
wpscan --url https://happist.com --enumerate t

[Scan vulnerable themes]
wpscan --url https://happist.com --enumerate vt

[Scan user accounts:]
wpscan --url https://happist.com --enumerate u

[Scan vulnerable timthumb files:]
wpscan --url https://happist.com --enumerate ttCode language: PHP (php)

WPVulnDB API 사용법

기본적으로 WPScan은 알려진 보안 취약성이 있는지 여부만 알려줍니다.

발견된 세부 취약점이 무엇인지를 알려면 WPVulnDB를 이용해야 합니다.

위에서 언급한대로 https://wpvulndb.com/users/sign_up에 등록하시면 일일 50건 요청이 가능한 무료 API 토큰을 받으실 수 있습니다.

여기서 계정을 등록 후 API 토큰을 발급받으면 아래와 같은 명령으로 WPScan 설정 파일에서 API 토큰을 등록할 수 있습니다.

nano ~/.wpscan/scan.ymlCode language: PHP (php)

이 설정 파일에서 아래 코드를 추가합니다.

cli_options:
    api_token: 발급받은 API 토큰Code language: PHP (php)

위에서도 설명했듯이 WPScan은 무료 및 비상업적 용도로 제공됩니다.

그러나 워드프레스 사이트 스캔 시 보다 자세한 취약점을 분석하려면 워드프레스 취약성 데이타베이스 API에 접속해서 보다 자세한 정보를 받아야 하는데요.

이 세부 취약성 데이타는 횟수에 따라서 과금하고 있습니다. 즉 하루 50회까지는 무료로 사용가능하며 그 이상 서비스를 원하는 경우 비용을 지불하는 시스템입니다. WPScan 팀 운영을 위해서는 어쩔 수 없는 일이 아닐까 합니다.

아마 사이트 보안을 위해 실시간으로 사이트를 점검한다면, 물론 이러려면 엄청난 시스템 자원이 필요하겠지만 점검 시간을 짧게 가져가려면 API 접속 횟수를 늘려야하기 때문에 유료 플랜 사용이 필요합니다.

수없이 등장하는 수많은 워드프레스 플러그인, 자주 업데이되는 워드프레스 코어 및 각종 테마들을 테스트하고 데이타베이스로 구축하는 것은 재능 기부로 해결할 수는 없을 듯합니다.

워드프레스 보안진단 툴 WPScan Vulnerability Database API 가격표
워드프레스 보안진단 툴 WPScan Vulnerability Database API 가격표

WPWatcher, 스캔 결과를 이메일로 받아보기

WPScan 결과를 이메일로 받아보려면 가장 간단하게는 위에서 설명한 워드프레스 플러그인을 설치하면 쉽습니다.

그러나 서버에서 작동시키는 것이 목적이기 때문에 우분투를 비롯한 리눅스 서버에서 메일로 보내줄 수 있는 방법이 필요합니다.

이러한 니즈를 잘 충족시키는 것이 바로 WPWatcher인데요. 여기서는 WPWatcher를 이용해서 이메일 송부 방법에 대해 살펴보도록 하겠습니다.

WPWatcher 설치 방법

WPWatcher를 설치, 사용하기 위해서는 당연히 WPScan이 필요하고, 파이썬 3가 필요합니다.

먼저 PyPi로 WPWatcher를 설치 및 업그레이드 합니다.

pip3 install wpwatcher
pip3 install wpwatcher --upgradeCode language: PHP (php)

WPWatcher 설정

WPWatcher 설정을 위해서는 설정 파일을 복사해 옵니다.

wpwatcher --template_conf > ./wpwatcher.confCode language: PHP (php)

WPWatcher 설정 파일을 편집합니다.

nano ./wpwatcher.confCode language: PHP (php)

저는 아래와 같이 설정을 구성했습니다.

[wpwatcher]
wpscan_path=wpscan
wpscan_args=[   "--format", "json",
                "--no-banner",
                "--random-user-agent",
                "--disable-tls-checks",
                "--api-token", "API 토큰" ]

# Sites (--url or --urls)
wp_sites=   [ {"url":"happist.com"}]

# Notifications
send_email_report=Yes
email_to=["받을 이메일 주소"]

send_infos=Yes
send_errors=Yes
send_warnings=Yes
attach_wpscan_output=Yes
resend_emails_after=1d
Code language: PHP (php)

# Email server settings
from_email=WordPressWatcher@happist.com
smtp_server=smtp.gmail.com:587
smtp_auth=Yes
smtp_user=email address
smtp_pass=password(gmail app password)
smtp_ssl=Yes
Code language: PHP (php)

# Sleep when API limit reached (--wait)
api_limit_wait=YesCode language: PHP (php)

제가 이전에 지메일을 활용한 메일 세팅에 대해 포스팅했는데요. 이를 참조하시면 좋을 것 같네요.

자동 수행을 위한 크론탭 설정

설정에 따라 일정 시간이 되면 자동으로 실행되도록 크론탭을 설정합니다.

crontab -eCode language: PHP (php)

크론탭에 아래와 같은 명령을 추가합니다. WPWATCHER는 루트에서만 실행되기 때문에 먼저 cd 명령을 이용해 루트로 이동 후 wpwatcher를 실행토록 합니다.

40 3 * * * cd && wpwatcher --conf wpwatcher.conf  --quietCode language: PHP (php)

원래 위와 같은 크롭탭 설정이 생각외로 작동하지 않아서 저는 조금 더 확실하게 스크립트 실행 파일(sh)을 만들어 작동하도록 만들었습니다.

cd /bin   # /bin 폴더로 이동 장 확률이 높았기에.
nano wpwatcher.shCode language: PHP (php)

이 스크립트 파일에는 아래와 같은 내용을 추가합니다.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

cd /root/
wpwatcher --conf wpwatcher.conf
Code language: PHP (php)

그리고 스크립트 파일이 실행 가능토록 만듭니다.

그 다음에는 이 파일에 권한을 부여합니다.

chmod +x wpwatcher.shCode language: PHP (php)

그 다음에는 크론에 이 파일 실행을 추가해야 겠죠?
이는 아시다시피 crontab -e 명령을 사용합니다.

crontab -eCode language: PHP (php)

크랜탭에서 아래 내용을 추가해 줍니다. 매일 새벽 4시 40분과 오후 6시 35분에 정의한 wpwatcher.sh를 실행하라는 명령입니다.

40 04 * * * wpwatcher.sh
35 18 * * * wpwatcher.shCode language: PHP (php)

크론을 다시 시작합니다.

service cron restart Code language: PHP (php)

크론이 제대로 작동하는지 한번 확인해 봅니다.

service cron statusCode language: PHP (php)

그러면 아래와 같이 크론이 active되고 있다고 나오면 OK입니다.

n# service cron status
● cron.service - Regular background program processing daemon
     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-07-12 13:12:24 KST; 7s ago
       Docs: man:cron(8)
   Main PID: 2732171 (cron)
      Tasks: 1 (limit: 9451)
     Memory: 384.0K
     CGroup: /system.slice/cron.service
             └─2732171 /usr/sbin/cron -f

Jul 12 13:12:24 fashionseoul.com systemd[1]: Started Regular background program processing daemon.
Jul 12 13:12:24 fashionseoul.com cron[2732171]: (CRON) INFO (pidfile fd = 3)
Jul 12 13:12:24 fashionseoul.com cron[2732171]: (CRON) INFO (Skipping @rebootCode language: PHP (php)

페이스북 샵이 쇼피파이에게 재앙인 이유와 쇼피파이 전략 by Ben Thompson

얼마전 페이스북이 중소기업들을 지원한다는 명분을 내세워 무료로 사용할 수 있는 페이스북 샵을 출시한다고 밝혔습니다. 여기에는 쇼피파이나 카페24와 같은 이커머스 플랫폼업체들이 파트너로 참여하는데요.

이러한 페이스북 샵에 파트너로 참여하는 업체들, 특히 아마존 대항마로 부상하고 있는 쇼피파이(Shopify)에게는 어쩌면 재앙일 수 있다는 분석이 있습니다.

이는 실리콘밸리 혁신 이론중의 하나인 제품 혁신론을 주장하는 톰 벤슨이 그의 블로그에서 주장한 내용인데요.

빠르게 변화하는 이커머스를 비롯한 인터넷 환경 변화를 파악하는데 좋은 인사이트를 주는 글이기 때문에 시간을 내서 번역,. 소개해 봤습니다

Platforms in an Aggregator World

제가 The Anti-Amazon Alliance이란 글을 쓴지 한달이 안되어 이러한 동맹의 중요한 두 주요 참여 기업에서 중요한 발표를 했습니다.

– 쇼피파이의 숍 앱(Shop App) 발표
쇼피파이 숍앱, Shopify Shop App, Shop better(Universal Standard)
– 페이스북의 페이스북 샵 발표
페이스북 샵(Facebook Shops), Image from Facebook

페이스북 샵, 아마존 공략 위한 페이스북의 이커머스 전략 무기

많은 사람들은 쇼피파이와 페이스북의 이러한 발표가 서로 관련이 있다고 주장해 왔습니다. 쇼피파이(Shopify)는 페이스북이 가지고 있는 고객을 얻기 위해서 고객용 애플리케이션을 구축해야 하는데, 페이스북 숍은 그런 필요를 충족해줄 수 있다는 것입니다.

저는 이와 다르게 해석합니다. 저는 쇼피파이가 직접 최종 고객을 얻는데 많은 시간과 투자를 해서는 안된다고 생각하는데 그것을 증명해주는 것이 페이스북 숍이라고 생각합니다.

반(反)아마존 동맹 부활

저는 The Anti-Amazon Alliance에서 오프라인 유통은 상품의 탐색(discovery)와 배포(Distribution)의 두 가지 기능을 제공한다고 언급했습니다.

그러나 인터넷에서는 이러한 기능이 두 개의 서로 다른 가치 사슬로 분할되었습니다. 페이스북은 탐색(discovery)에서 가장 중요한 위치를 차지하고 있으며, 아마존은 탐색(discovery)에 기반한 배포(Distribution)를 지배하고 있습니다.

그 포스팅은 구글이 PTP(Pay-To-Play)에서 벗어나 구글 쇼핑에 집중, 검색엔진에서 상품 리스트를 보여주는 방향으로 선회함으로써 반 아마존 연합에 가입했다는 뉴스를 듣고 정리한 것입니다.

Amazon을 제외하고 가치 체인 작동에서 가장 중요한 회사 중 하나는 쇼피파이입니다. 그리고 쇼피파이는 애그리게이터(여러 회사의 상품이나 서비스를 한군데 모아서 보여주는 서비스)가 아니라 플랫폼입니다.

구글과 페이스북은 고객을 모을 수 있지만 판매자들이 실제로 온라인으로 상품을 판매할 수 있는 인프라를 제공하는 것은 쇼피파이(및 우커머스, 오픈 소스 경쟁업체)입니다.

쇼피파이는 또한 제가 Shopify and the Power of Platforms에서 언급했듯이 쇼피파이 Fulfillment Network를 통해 판매 상품들이 고객에게 제대로 전달되도록 돕기 위해 노력하고 있습니다.

지난 주  Reunite Conference에서 쇼피파이는 현재 미국 전역에 7개 물류 창고를 운영하고 있으며, 물류 창고 운영을 개선하기 위한 R&D 센터를 설립했으며, 주문 이행(warehouse operations)에 도움을 주기 위해 “Chuck” 로봇을 6개의 리버 시스템을 통합했다고 발표했습니다.

쇼피파이 Fulfillment Network의 한 가지 유용한 구성 요소는 쇼피파이 웹 사이트 템플릿은 컴스텀 패키지로 완벽하게 변환된다는 점입니다.

즉 여러분이 쇼피파이로부터 패키지를 받으면(이는 전 세계 어디에서나 이틀 정도 소요됩니다.) 이는 쇼피파이 템플릿이 아닌 완전히 해당 판매자 용으로 커스터마이제이션한 것처럼 변신합니다.

이는 플랫폼의 일부가 되는 것이며 쇼피파이 플랫폼의 선물입니다. 고객이 비록 쇼피파이 존재를 의식하지 못해도 플랫폼을 이용하고 있는 고객이 승리하면 쇼피파이가 승리하는 것입니다.

이러한 이유로 쇼피파이가 상품 배송 과정을 추적하는 앱을 쇼피파이 앱으로 다시 브랜드화하기로 한 결정에는 동의하지 않았습니다. 쇼피파이 앱은 판매자들을 쇼피파이 자체와 비교해 격을 낮추어 버립니;다. (그리고 브랜드 가치를 유지하려는 시도는 사용자 경험을 혼란스럽게 만듭니다.)

페이스북 숍

쇼피파이 숍 앱에 대한 제 의견에 동의하지 않은 사람들은 일반적으로 페이스북을 비롯한 소셜 미디어와 소비자가 직접 만나는 공간에서 점점 더 많은 가치를 포착하고 있다는 사실을 언급합니다.

저는 올해 초 Email Addresses and Razor Blades에서 이러한 현상이 발생하는 이유에 대해 다음과 같이 설명햇습니다.

문제는 마케팅을 구글과 페이스북에 의존하는 과정에서 DTC(Direct To Consumer) 기업들이 가치 사슬에서의 계획했던 통합과 관련 수익을 페이스북과 구글에 넘겨 버렸다는 점입니다.

페이스북 샵이 쇼피파이에게 재앙인 이유와 쇼피파이 전략 by Ben Thompson 1

실제 (가치 사슬) 통합 업체인 구글과 페이스북은 고객과 연구 개발을 통합하여 마케팅을 지배합니다. DTC는 온라인 소매 영업을 할 수 있지만, 이는 가치 사슬의 일부로서 모듈화되어 상품화된 것입니다. 한편, 아마존은 소매와 물류를 통합하는 과정에 있었습니다.

그러나 쇼피파이가 고객을 직접 획득하는 것에 대해 책임을 지는 것은(판매자에게 도움을 주는 도구를 구축하는 것이 아니라) 가치 사슬에서 쇼피파이의 역활과 맞지 않을 뿐만 아니라, 쇼피파이가 이 일을 판매자들보다 더 잘할 것이라고 믿을만한 특별한 이유는 없습니다.

페이스북이 고객 확보 측면에서 탁월한 역량을 가지고 있기 때문에 페이스북은 그것에 프리미엄을 부과할 수 있는 것입니다.

쇼피파이가 더욱 더 신경을 써야하는 것은 페이스북이 꺼꾸로 페이스북 숍 뒷단을 통합할 수 있는 가능성입니다. 페이스북은 뉴스룸에서 아래와 같이 이야기 합니다.

페이스북 숍을 통해 기업은 고객이 페이스북과 Instagram에서 모두 액세스할 수 있는 온라인 숍을 쉽게 개설할 수 있습니다. 페이스북 숍을 만드는 것은 무료이며 간단합니다.

기업은 카탈로그에서 원하는 제품을 선택한 다음 자신 브랜드를 보여주는 커버 이미지와 액센트 색상으로 가게의 모양과 느낌을 사용자 정의할 수 있습니다.즉, 규모나 예산에 관계없이 모든 판매자는 언제 어디서나 편리한 시간에 비지니스를 온라인으로 전환하고 고객과 만날 수 있습니다.

사람들은 기업 페이스북 페이지나 인스타그램 프로필, 페이스북 스토리 또는 페이스북 광고를 통해 페이스북 숍을 찾을 수 있습니다.

여기서 전체 컬렉션을 검색하고, 관심 있는 제품을 저장하고, 주문할 수 있습니다. 미국의 경우 체크아웃을 활성화 놓았다면, 비즈니스 웹 사이트 또는 앱을 떠나지 않고도 주문을 완료할 수 있습니다.

또한 오프라인 매장에서에 누군가에게 도움을 요청하는 것처럼 페이스북 숍에는 WhatsApp, Messenger 또는 Instagram Direct를 통해 브랜드에게 메시지를 보내 질문하고, 지원을 받고, 배송 과정을 추적할 수 있습니다.

또한 앞으로는 WhatsApp, Messenger 또는 Instagram Direct에서 채팅을 통해 왓츠앱, 메신저 또는 인스타그램 다이렉트 채팅에서 비즈니스 숍을 살펴보고 바로 구매할 수 있습니다.

이는 쇼피파이에게 안 좋은 소식이죠? 다만 마지막 단락은 다음과 같습니다.

또한 쇼피파이, BigCommerce, WooCommerce, ChannelAdvisor, CedCommerce, 카페24, Tienda Nube 및 Feedomics와 같은 파트너와 더욱 긴밀히 협력하여 중소기업에 필요한 지원을 제공하고 있습니다.

이러한 조직은 기업가가 비즈니스를 시작하고 운영하며 온라인으로 전환할 수 있도록 지원하는 강력한 도구를 제공합니다.

이들은 이제 중소기업들이 페이스북 숍을 구축 및 성장시키고 다른 이커머스 도구를 사용하는 데 도움을 줄 것입니다.

쇼피파이도 블로그에서 페이스북 숍에 대한 전했지만, 이 파트너십은 Reunite Conference 키노트에서 단 18초만 언급되는데 그쳤습니다. 이 파트너쉽에 대해서 쇼피파이가 흥분할 대단한 이유를 느낄 수 없습니다.

쇼피파이 비즈니스 모델

쇼피파이의 원래 비즈니스 모델은 “Subscription Solutions”입니다. 판매자들은 쇼피파이 플랫폼을 사용하기 위해 구독료를 지불하며(한 달에 29달러에서 299달러까지) 원하는 페이 제공업체를 사용할 수 있습니다.

페이스북 샵이 쇼피파이에게 재앙인 이유와 쇼피파이 전략 by Ben Thompson 2

쇼피파이가 기업공개(IPO) 시 발표한 자료에 따르면 쇼피파이의 Subscription Solutions가 분기 매출 6700만 달러의 60%를 차지했습니다.

하지만 지난 5년 동안 쇼피파이 자체 페이 숄류션을 사용하는 “Merchant Solutions” 매출 비중이 꾸준히 증가해 지난 분기엔 분기 매출 4억 7천만 달러의 60%를 차지했습니다.

쇼피파이 비즈니스 모델에서 이러한 변화르 보면 쇼피파이의 페이스북과 “파트너십”이 불편한 요소를 가지고 있습니다.

물론, 페이스북 숍 통합은 쇼피파이의 Subscription Solutions 입장에서는 플러스 요인이지만 페이스북 숍에서는 페이스북 결제 솔류션을 이용해야 하기 때문에 쇼피파이 Merchant Solutions 매출은 부정적이 요인으로 작용할 것입니다.

이는 판매자 솔류션 매출이 없다는 것을 의미하며, 나아가서는 판매자들의 성장 트랜드에 참여하지 않는다는 것을 의미합니다.

이것이 쇼피파이에게는 특히 씁쓸한 이유는 페이스북의 움직임이 판매자들에게 정말 좋은 기회라는 점입니다. 그리고 페이스북 숍은 외부 서비스와 통합되지 않고 지나치게 복잡했던 인스타그램 쇼핑 베타보다 훨씬 더 나은 해결책입니다.

이 시점에서 저는 인스타그램에서 제품 구매 경험한 사람들이 아직 구매하지 않은 사람들보다 더 많으며, 실제로 인스타그램에서 구매 경험은 상당히 비참한 경험이었다고 알고 있습니다. 때로는 그냥 구매를 포기해 버리는 것이 더 쉬운 선택일때가 많았습니다.

반면에 페이스북에서 체크아웃은 몇분이 걸리는 것이 아니라 몇초만에 구매가완료될 수 있습니다.

결국, 여러분이 누구인지 아는 사람이 있다면, 그것은 바로 페이스북입니다! 이는 페이스북과 인스타그램 광고에서 특히 더 많은 변화를 의미할 것이며 쇼피파이가 성장할 여지가 보이지 않을 것입니다.

소방관과 방화범

페이스북은 실제로는 자기들이 만들어 낸 문제에 대한 솔류션 제공자로 자리매김하고 있다는 점을 주목할 필요가 있습니다.

iOS를 구체적으로 살펴보면 Apple은 결제 문제에 대해서는 사용자 친화적인 애플페이를 제공합니다.

그러나 애플페이는 Safari 및 SFSafariViewController로 구현한 개체로 제한됩니다. 후자는 개발자가 애플리케이션에 브라우저를 추가하는 가장 간단한 방법입니다. 이는 Safari와 유사하며 오른쪽 하단에 Safari에서 페이지를 로드할 수 있는 버튼이 있습니다.

사파리 브라우저와 인스타그램에서 구현된 SFSafariViewController 웹 뷰를비교, 대조해 봅니다.

사파리 브라우저와 인스타그램에서 구현된 SFSafariViewController 웹 뷰를비교, shopify-webviews
사파리 브라우저와 인스타그램에서 구현된 SFSafariViewController 웹 뷰를비교

인스타그램은 기본적으로 인스타그램 내에 그들만의 브라우저를 만들었습니다. 여기서는 여전히 iOS의 요구사항인 WebKit 엔진을 사용합니다. 이는 Chrome도 WebKit를 사용한다는 의미입니다.

그럼에도 애플은 이들 내부 브라우저를 통제하지 않습니다. 애플은 여기에 애플페이를 적용하지 않기로 했습니다.

이는 즉, 인스타그램과 페이스북에서 구매 경험이 페이스북이 (애플페이가 가능한) SFSafariViewController를 적용하거나 애플이 애플페이 적용 정책을 완화했을 때보다 사용 경험이 좋지 않다는 것을 의미합니다.

특히, 페이스북과 애플 모두 동전의 양면에서 동기부여를 받고 있습니다. 페이스북은 자체 브라우저를 사용합니다. SFSafariViewController에서 가능한 한 많은 데이터를 캡처할 수 있기 때문입니다. 한편,

Apple은 사용자 데이터를 타사 개발자가 쉽게 접근하지 못하도록 막을 목적으로 SFSafariViewController 부변에 샌드박스를 설치하는 동시에 SFSafariViewController를 훨씬 더 사용하기 쉽게 만들고, 애플페이 통홥과 같은 이점을 제공하면서 사용을 장려합니다.

여러분 중 많은 분들이 이미 애플의 정책에 감사하고 페이스북의 정책에는 짜증 날것이라고 확신합니다. 결국, 애플은 사용자 편의성을 추구하고, 페이스북은 사용자를 이용하려고만 합니다. 그렇죠?

사실 그것보다 좀 더 복잡한데 쿠키가 좋은 예입니다.

인스타그램 광고는 쇼피파이 플랫폼을 이용하는 판매자들의 광고라는 것을 기억하세요. 이 모든 웹사이트들은 동일한 (쇼피파이) 인프라에서 호스팅됩니다.

사용자가 (쇼피파이 플랫폼을 이용하는) 웹 사이트에서 구매 후 (쇼피파이 플랫폼을 이용하는) 다른 웹 사이트를 방문했을 때 쇼피파이가 쿠키를 설정할 수 있다면 그 사이트에서는 이미 모든 결제 준비가 완료된 상태로 로그인되어 있는 경우를 생각해 보죠.

특히 쇼피파이는 숍페이(ShopPay)라고 불리는 이러한 페이 인프라를 구축했지만 이는 모든 쇼피파이 웹 사이트에 로그인해야 사용 가능하다는 점에서 주목할 필요가 있습니다.

이런 이야기를 시시콜콜하는 이유는 지난 3년 동안 애플은 이러한 제3자 쿠키를 없애기 위해 노력해 왔기 때문입니다.

여기에는 특히 광고를 위해 로드되는 제3자 쿠키 추적기 제거라는 그럴싸한 이유가 있습니다. 그러나 그 와중에 쇼피파이와 그 플랫폼을 이용하는 판매자들은 실질적인 피해자가 되고 있습니다.

저는 작년에 Privacy Fundamentalism라는 글에서 이러한 트레이드오프에 다음과 같이 적었습니다.

기술은 좋은 것과 나쁜 것 모두를 위해 사용될 수 있지만, 나쁜 것을 없애는 것을 서두르면서 좋은 것을 망각하기 쉽습니다.

예를 들어, Manjoo는 구독을 통해 대부분 수익을 거두는 뉴욕 타임즈를 위해 일합니다. 이 점을 감안하면, 그들이 저 자신의 구독 사업을 지원하는 Stratechery의 제 3자 콘텐츠에 반대하지 않는다고 가정할 수 있습니다.

이것은 제 모든 부분에 적용됩니다. 왜냐하면 정보는 경제적 이득을 노리고 수많은 회사들이 구축해 놓은 인프라를 통해 인터넷에서 아주 쉽게 퍼지기 때문입니다. 저는 이 기사를 제 집에서 쓸 수 있습니다. 그리고 여러분은 여러분의 집에서 읽으실 수 있습니다.

이것이 놀랍지도 않다는 것은 우리가 인터넷을 당연시 여기기 때문입니다. 세계 어느 곳의 사이트든 누구나 접속할 수 있습니다. 인터넷은 데이터를 자유롭고 쉽게 이동하기 때문입니다.

불행히도, 이것은 2020년보다는 2017년 세계를 더 잘 정의하는 표현일 수 있습니다.

예, 웹 사이트는 여전히 자유롭게 액세스할 수 있습니다. 그렇지만 쇼피파이와 같은 중요한 플랫폼((내 경우에는 워드프레스와 스트라이프)에서 이러한 사이트들을 지원하는 것은 점점 더 어려워졌습니다.

프라이버시는 좋은 것이지만, 기업가 정신과 경쟁도 마찬가지로 중요합니다. 다른 사람들을 고려하지 않고 하나를 최대화하면 의도하지 않은 결과가 초래된다.

페이스북 샵은 이러한 완벽한 예입니다. 페이스북 샵은 쇼피파이 플랫폼을 이용하는 판매자들에게 좋기 때문에 성공할 것입니다.

그러나 쇼피파이 판매자들에게 좋은 이유는 페이스북과 애플이 효과적으로 협력해 쇼피파이가 결제 솔류션 문제를 해결할 수 없도록 만들었기 때문입니다.

이것은 저를 슬프게 합니다.

제가 인터넷을 낙과적으로 바라본 이유는 쇼피파이, 스트라이프 그리고 서브스택(Substack)과 같은 플랫폼들 때문입니다. 이 플랫폼들은 개인 기업가들이 원하는 대로 세계적 수준의 도구를 사용해 자신만의 비지니스를 구축할 수 있도록 만들 수 있기 때문입니다.

그런데 (페이스북과 애플등이) 이러한 도구 사용을 어렵게 만들고 있기 때문에 기존 회사들과 기존 앱들에게 유리한 상황으로 퇴보하고 있습니다.

쇼피파이 플랫폼 전망

쇼피파이와 애그리게이터(Aggregator)로 가치 사슬(Value Chain)에서 경쟁하는 모든 기업에게 이는 가혹한 현실입니다.

특히 인프라 공급업체들이 점점 더 직면하고 있는 기술적 한계를 감안할 때 이 게임에서 페이스북을 이길 수는 없습니다.

결국 페이스북의 고객 확보 기술을 극복하는 일은 판매자 스스로 책임져야 합니다.

즉, 웹이 존재하는 한 항상 작동하는 법칙은 아주 매력적인 무언가를 만들어내어 사람들이 여러분에게 몰려들도록 만드는 것입니다.

그래서 제가 쇼피파이의 Fulfillment Network에 대해 계속 흥분하는 이유입니다.

저는 쇼피파이의 접근에 완전히 매료되지는 않았습니다. 저는 쇼피파이가 자체 물류 서비스를 구축하는 대신 판매자들과 독립적인 3PL 제공업체간 상호 작용할 수 있는 공통 인터페이스를 만드는 것이 더 합리적일 수 있다고 생각했습니다(그러나 제가 잘못 알고 있을 수도 있습니다).

하지만 저는 이 분야에 막대한 투자를 하고 있는 이 회사를 전적으로 지지합니다.

첫째, 이 서비스는 어떤 판매자도 자체적으로 구축할 수 없는 서비스이기 때문입니다.

이는 플랫폼이 생태계를 위한 무언가를 어떻게 만들 수 있는지를 보여주는 완벽한 예입니다.

게다가 이것은 특히 작년에 제가 지적했듯이 아마존의 경쟁사로서의 쇼피파이의 약속을 이행하기 위해 필요한 것입니다. 사용자들이 쇼피파이로 가는 것을 선택해서가 아니라 쇼피파이가 존재한다는 것을 알 이유가 없기 때문입니다.

둘째로, 이것은 페이스북 샵들을 더 가치 있게 만들어 줄 서비스이기 때문입니다. 페이스북 체크아웃으로 인해 매출이 증가하는 모든 상인들은 여전히 그들의 상품을 배송해야 합니다. 그리고 페이스북이 현실 세계에 통합될 가능성은 전혀 없습니다.

셋째, 이 서비스는 다른 누구도 구축하지 않을 서비스입니다. 네, 이행 센터를 짓고 로봇을 개발하고 많은 노동자를 고용하는 것은 매우 어렵습니다.

하지만 그 어려움 속에 경쟁으로부터의 벗어날 수 있는 해자가 되고, 장기적으로 지속 가능한 수익을 낼 수 있는 훨씬 더 신뢰할 수 있는 방법입니다.

쇼피파이가 은행 및 금융 서비스로 전환하는 것에 대해서도 낙관적입니다.

예, 여기 스트라이프(Stripe)와 같은 쇼피파이 파트너와의 경쟁은 더욱 치열합니다. 하지만 이 영역은 Aggregator가 플랫폼 공급자에게 결코(그리고 절대로) 이치에 맞지 않는 위험을 감수하는 또 다른 영역입니다.

구축 필요성

Marc Andreessen의 에세이 It’s Time to Build에 대한 제 답변에서, 저는 기술 산업이 더 많은 차이를 만들 수 있는 세 가지 다른 방법을 제안했습니다. 이 중 두 번째는 다음과 같습니다.

둘째, 소프트웨어를 가지고 하드웨어에서 차별화하기 위해 투자하는 실제 기업(real-world companies)에 투자합니다.

이 하드웨어는 공장이나 공장 자체를 위한 기계일 수도 있고, 새로운 형태의 교통수단이나 방어시스템일 수도 있습니다.

최소한 90%의 총 마진 요구를 포기하면 그 가능성은 무궁무진합니다.

그것은 최근 쇼피파이 실적 보고서의 다음과 같은 두 가지 “경고”가 떠올랐습니다.

– 당사는 쇼피파이 Fulfillment Network와 6 River Systems Inc.(“6RS”) 개발에 따라 단기적으로 가맹점 솔루션( merchant solutions) 총 마진율이 감소할 것으로 예상됩니다.
– 가맹점 솔루션(merchant solutions)의 지속적인 성장은 매출총이익률의 하락을 초래할 수 있다고 예상합니다.

간단히 말해서, 이행 센터를 짓고 로봇을 개발하고 많은 직원을 고용하는 것은 이윤을 위해 좋지 않습니다.

그렇지만 적어도 쇼피파이가 운영하는 경쟁이 치열한 시장에서는 해자를 만들기에 좋습니다. 이것은 분명히 아마존이 오래 전에 발견한 것입니다;

저는 2018년에 Amazon Go and the Future에서 다음과 같이 썼습니다.

이러한 투자 의지는 Amazon을 진정으로 차별화하는 것이며, 그 보상은 어마어마합니다. 저는 이전에 통신 회사들에 대해 언급한 적이 있습니다.
그들의 경제적 파워는 막대한 자본 지출에서 직접 나오며 그 경제적 파워는 차별화 부족으로 제한됩니다.

그러나, 소프트웨어 기반 수평 모델과 네트워크 기반 차별화를 통해 Amazon은 수직 계열화 구축에 착수했을 뿐만 아니라 이를 위해 막대한 비용을 지출했습니다.

이러한 지출은 단기적으로는 고통스럽지만(대부분의 소프트웨어 회사들이 이를 기피하는 이유이기도 하져), 이는 대규모 해자를 제공합니다.

이런 관점에서, 실제 세계에 건설한 건축의 위상은 그 과정이 얼마나 어려운가에 달려 있습니다.

우리가 “The End of the Beginning”에 도달했다는 것은 어쩌면 우리가 도달 가능한 가장 높은 위상일지도 모릅니다.

참고

DDoS 취약 기능 XMLRPC 사용 중지로 워드프레스 보안 강화하기

오늘은 워드프레스 사용 기능 중 DDoS 공격에 취약하다는 XLMRPC 사용 중지로 워드프레스 보안을 강화하는 방안에 대해서 살펴봅니다.

이전 포스팅에서 무작위적인 ID와 비밀번호 대입으로 워드프레스 로그인 시도에 대한 대응으로 워드프레스 로그인 주소 변경하고, Fail2Ban으로 워드프레스 로그인 시도 IP를 블락하는 정책을 세웠습니다.

https://happist.com/573644/fail2ban%ec%9c%bc%eb%a1%9c-%ec%9b%8c%eb%93%9c%ed%94%84%eb%a0%88%ec%8a%a4-%ed%95%b4%ed%82%b9-%eb%b0%a9%ec%a7%80%ed%95%98%ea%b8%b0/

이러한 정책외 XMPRPC는 2007년 도입때무터 해커들의 공격에 취약하다는 문제를 가지고 있었습니다.

그렇지만, 워드프레스 관리자들 대부분이 이러한 위험에 무신경함으로서 최근 몇년간 해커들의 주요 공격 포인트가 되면서 경각심이 높아진 기능이기도 합니다.

여기서는 XLMRPC란 무엇이며, 워그프레스에서 이 기능을 사용하지 않으려면 어떻게 해야하는지 그 몇가지 방법을 살펴봅니다.

xmlrpc란 무엇인가?

서버와 서버간 또는 서버와 클라이언트간 통신을 표준 문서 형식인 XML을 이용한 원거리 전송 규약으로 서버 메소드에 직접 접근 가능한 방법입니다.

XML를 이용해 서버에서 멀리 떨어진 서버 또는 클라이언트의 서브 프로그램(Procedure)를 불러 작동 또는 작용하도록 만드는 것(Call)이란 의미로 XMLRPC라고 부릅니다.

XMLRPC는 이런 특성때문에 워드프레스나 블로그에서는 외부에서 글을 작성 후 사이트로 보내면 자동으로 포스팅이 되는 기능에 활용되기도 했습니다.

블러그가 한창 인기가 있을 때는 메일 본문에 글을 작성해 메일을 보내면 이를 자동으로 블러그 포스팅이 되는 기능이 활성화 되기도 했습니다.

또는 워드에서 글을 저장하면 이를 블러그로 보낼 수 있기도 했습니다. 이는 XML 규격을 활용해 그 포맷을 그대로 블러그 포스팅으로 저장할 수 있기 때문에 가능한 기능이었습니다.

지금은 이런 기능은 보안 이슈 등등으로 전부 없어지고 대신 REST를 사용하는 방향으로 전환되었습니다.

워드프레스에서는 핑백(pingback) 기능 때문에 사용 중 – 핑백을 사용하지 않으면 어느 정도 문제 해결 가능

또 현재 워드프레스에서 글을 인용 시 핑백(pingback) 기능 때문에 xmlrpc가 남아 있다고 합니다.

그러나 이 핑백 기능을 이용한 DDoS 공격도 많아지면서 점ㅂ차 핑백 기능을 사용하지 않는 사이트들이 증가하면서 유명무실해지고 있습니다.

XMLRPC 사용 중지 방법

그러면 어떻게 XMLRPC를 절대로 사용하지 않토록 만들까요? 이를 위한 여러가지 방법이 있습니다.

서버 설정이 가능한 경우

SFTP나 SSL을 통해서 서버 접속이 가능하고, 서버 설정 변경 권한이 있는 경우는 서버 설정을 변경하는 것이 좋습니다.

아파치를 웹서버로 사용하는 경우는 아래와 같은 명령어를 사용합니다.

<Files xmlrpc.php>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>Code language: PHP (php)

NGINX를 웹서버로 사용한다면 서버 설정 파일에 아래와 같은 코드를 추가합니다.

location ~* (xmlrpc)\.php$ {
    allow from xxx.xxx.xxx.xxx
    deny all;
    access_log off;
}Code language: PHP (php)

서버 설정이 어려운 경우

서버에 접속하기 위해 SFTP나 SSL사용이 어려운 경우는 XMLRPC 사용 중단을 위해서 플러그인을 사용할 수 있습니다.

사실 XMLRPC 사용 중단은 워드프레스 구성 파일 중 xmlrpc.php 파일 하나와만 연관되어 있기 때문에 굉장히 복잡한 작업은 아닙니다.

그렇기 때문에 굳이 플러그인까지 설치할 필요가 있을까하는 생각이 들 수 있습니다. 저처럼 가능하면 플러그인 사용을 자제하려는 경우에는 더욱 그러겠죠.

그러나 니즈가 있는 곳에 플러그인이 있다는 말처럼 워드프레스에서 XMLPC 사용 중지를 위한 플러인인드링 많이 있고 실제로도 많이 사용하고 있습니다.

  • 서버 접속이 어려운 경우
  • 서버 접속이 번거롭고, 굉장히 어렵게 느껴지는 경우
  • 플러그인 설치 및 적용이 생각보다 간단히 가장 편한 기능이기 때문

어떤 플러그인?

워드프레스에서 XMPRPC를 비활성화하는 플러그인도 생각외로 여러가지가 있지만 Disable XML-RPC 플러그인이 가장 많이 추천되고 있네요. 현재 약 10만명이 설치했했습니다.

다만 이 플러그인은 지난 1년동안 업데이트가 없어서 조금 주의 깊게 살펴볼 필요가 있습니다.

워드프레스 XMLRPC 플러그인들

Iptables 방화벽 연계 Fail2Ban 설정 방법, 워드프레스 해킹 방지

근래들에 멀웨어 감염되는 등 사이트에 심각한 문제가 했길래 서버 보안 및 사이트 보안에 대해 추가 조치를 하고 있습니다. 이중 워드프레스 로그인 시도를 제한해 워드프레스 해킹 방지하는 Fail2Ban 설정을 Iptables 방화벽과 연계 설정 방법에 대해서 알아보겠습니다.

Fail2Ban은 로그를 분석해 의심스러운 사이트 접근을 막는 방법으로 SSH, Apache, Nginx, FTP 등의 의심스러운 접근을 차단할 수 있습니다.

또한 워드프레스 로그인 실패 로그 기록을 기반으로 워드프레스 관리자 로그인 시도 등을 막을 수도 있습니다.

Fail2Ban에 대한 소개나 사용법에 대한 소개 자료는 많이 있지만 이중에서 워드프레스 해킹 방지 방법에 대해서는 조금 낮선 것 같아서 이번 사이트 보안 대책 수립하면서 자세하게 확인해 보았습니다.

특잏 이러한 Fail2Ban 설정을 Iptables 방화벽과 연계해 보안을 강화하는 방법까지 살펴보겠습니다.

워드프레스 로그인 감시를 위한 Fail2Ban 설정 – 필터 정의

Fail2Ban에서 워드프레스 관리자 로그인으로 워드프레스 해킹하려는 시도를 막기 위해서는 우선 워드프레스 로그인 실패를 모니터링할 수 있는 필터를 추가합니다.

Fail2Ban 필터는 /etc/fail2ban/filter.d 폴더에 존재하는데요. Fail2Ban에는 워드프레스 로그인 시도를 모니터링할 필터가 없기 때문에 수작업으로 만들어 줍니다.

필터 이름은 구분하기 적당하게 지으면 되는데요. 설명 자료등에서 wordpress를 많이 사용하고 있기 때문에 저도 wordpress 이름을 사용해 wordpress.conf 파일에 필터 옵션을 추가했습니다.

nano /etc/fail2ban/filter.d/wordpress.confCode language: PHP (php)

wordpress 필터에는 다음과 같은 내용이 들어갑니다.

[Definition]
failregex = ^<HOST> .* "(GET|POST) /wp-login.php
                  ^<HOST> .* "(GET|POST) /xmlrpc.phpCode language: PHP (php)

워드프레스 로그인 감시 옵션

그 다음에는 위에서 정의한 Fail2Ban 필터를 기반으로 워드프레스 로그인을 감시하고 조치할 옵션을 정의합니다.

이는 /etc/fail2ban/jail.d 폴더 내 적절한 이름 + .conf 형식으로 로그인 감시 옵션을 추가합니다. 별도 파일을 만들지 않고 local.conf와 같은 파일안에 모든 종류 옵션을 추가해도 좋을 것입니다.

nano /etc/fail2ban/jail.d/local.confCode language: PHP (php)

여기에 아래와 같은 내용을 주가합니다. 하루 24시간동안 3번 로그인 실패하면 IP를 영구 금지시키는 다소 엄격한 조건을 설정했습니다.

[wordpress]
enabled  = true
port     = http,https
filter   = wordpress
action   = iptables-multiport[name=wordpress, port="http,https", protocol=tcp], %(action_mw)s
logpath  = /var/log/nginx/access.log
maxretry = 3
findtime  = 86400
bantime  = -1Code language: PHP (php)

위 내용을 항목별로 해석해 보죠.

  1. enabled = true : 워드프레스를 모니터링하라는 옵션, 반드시 true로 설정되어야 모니터링을 시작함
  2. port = http,https : SSL이 적용된 443 포트나 일반 80 포트로 들어와서 시도되는 행동들을 모니터링
  3. filter = wordpress : 사용할 필터
  4. action = iptables-multiport : 문제를 감지 시 어떻게 할지는 iptables-multiport에서 정의한 대로 조치
  5. logpath = /var/log/nginx/access.log : Fail2B이 참조해야하는 로그 파일
  6. maxretry = 3 : 3번 이상 시도해서도 실패 시 조치를 취함
  7. findtime = 86400 : 로그인 실패등이 일어났는지 확인할 시간, 86400은 1일로 로그를 검색해 조치 여부 판단
  8. bantime = -1 : 조치를 지속하는 시간, -1은 무기한 금지

검색 봇 조치

구글 등의 검색 엔진의 봇들이 사이트를 돌아다니다 파일들을 테스트하면서 잘못해 구글 봇 ip가 블락될 가능성도 있기 때문에 robots.txt에 아래 내용을 추가해 줍니다.

User-agent: *
Disallow: /wp-login.php
Disallow: /xmlrpc.phpCode language: PHP (php)

Fail2Ban 설정 결과

위와같이 Fail2Ban 설정에 wordpress 옵션을 추가한 1일 후 아래처럼 264개 ip가 블럭당했음을 볼 수 있습니다.

# fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
|  |- Currently failed:	87
|  |- Total failed:	2282
|  `- File list:	/var/log/nginx/access.log
`- Actions
   |- Currently banned:	264
   |- Total banned:	264
   `- Banned IP list:	139.59.43.196 162.241.29.139 167.71.139.8 178.116.22.137 178.128.82.148 178.135.93.158 212.116.102.246 213.5.78.240 45.55.135.88 159.89.110.45 51.15.180.70 70.113.11.186 67.205.161.59 62.210.88.90 165.22.191.129 49.145.70.15 107.179.19.68 134.122.120.74 139.99.121.6 142.4.22.236 178.62.33.222 159.203.36.107 213.149.103.132 128.199.158.182 103.83.36.101 166.62.80.109Code language: PHP (php)

저의 경우 SSL 공격은 많지 않은데요. 아마 포트를 22번이 아닌 별도의 포트를 사용하기 때문이 아닐까 싶습니다. 워드프레스 로그인을 통한 공격이 굉장히 많다는 점에 놀랬습니다.

한때는 보안 플러그인 워드펜스(wordfence)를 같이 사용했는데요. 워드펜스에서 막는 것보다 Fail2Ban에서 막는 것이 훨씬 더 많더군요. 워드프레스 로그인 보안 관련해서는 Fail3Ban을 활용하는 것이 훨씬 낫다는 생각을 했습니다.

Fail2Ban 설정을 Iptables 방화벽과 연계 방법

그러면 이렇게 Fail2Ban 설정을 통해서 막았던 ip들을 Iptables 방화벽에게 알려주어 보다 근본적으로 서버 접근 자체를 막아버리는 방법에 대해서 살펴보도록 하겠습니다.

여기서 목적은 Fail2Ban에서 IP 금지 리스트에 등록되면 Iptables 방화벽에도 자동으로 등록, 방화벽에서 ip를 금지 시키도록 변경하고 나중에 Fail2Ban을 다시 설치해도 Block ip list를 활용할 수 있도록 만드는 것입니다.

아시다시피 Fail2Ban은 다시 시작하면 기존에 막았던 ip 리스트들은 전부 초기화됩니다. 그때부터 다시 ip를 관리하기 시작합니다.

이를 막기 위해서는 아래와 같이 Fail2Ban 액션을 추가합니다.

nano /etc/fail2ban/action.d/iptables-repeater.confCode language: PHP (php)

여기에 아래와 같은 내용을 추가합니다.

# Fail2Ban configuration file
# Author: WireFlare
# https://wireflare.com/blog/permanently-ban-repeat-offenders-with-fail2ban/

[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-
               iptables -A fail2ban- -j RETURN
               iptables -I  -p  -j fail2ban-
               # Establish chain and blocks for saved IPs
               iptables -N fail2ban-ip-blocklist
               iptables -A fail2ban-ip-blocklist -j RETURN
               iptables -I  -p  -j fail2ban-ip-blocklist
               cat /etc/fail2ban/ip.blocklist. |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-ip-blocklist 1 -s $IP -j REJECT --reject-with icmp-port-unreachable; done

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D  -p  -j fail2ban-
              iptables -F fail2ban-
              iptables -X fail2ban-
              # Remove chain and blocks for saved IPs to prevent duplicates on service restart
              iptables -D  -p  -j fail2ban-ip-blocklist
              iptables -F fail2ban-ip-blocklist
              iptables -X fail2ban-ip-blocklist

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
 actioncheck = iptables -n -L  | grep -q 'fail2ban-[ \t]'

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = VERIFY="*"
             ADD="        # fail2ban/$( date '+%%Y-%%m-%%d %%T' ): Perma-Banned"
             FILE=/etc/fail2ban/ip.blocklist.
             grep -q "$VERIFY" "$FILE" || iptables -I fail2ban-  1 -s  -j DROP
             grep -q "$VERIFY" "$FILE" || echo "$ADD" >> "$FILE"

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = # Do nothing becasuse their IP is in the blocklist file

# To manually unban from the ip blocklist file run this command:
# Be warned that if the ip is in log rotated files it must be whitelisted
#
# sed -i '/^/d' /etc/fail2ban/ip.blocklist.repeatoffender
#

[Init]
# Default name of the chain
#
name = default

# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp
#
protocol = tcp

# Option:  chain
# Notes    specifies the iptables chain to which the fail2ban rules should be
# added
# Values:  STRING  Default: INPUT
chain = INPUTCode language: PHP (php)

이러한 설정을 적용하려면 Fail2Ban을 다시 시작합니다.

sudo service fail2ban restartCode language: PHP (php)

[참고] 이메일로 받아보기

Fail2Ban에서는 사이트 공격으로 IP가 블락되면 이를 이메일로 알려주라고 설정할 수 있습니다.

이를 위해서는 두가지 조치가 필요합니다. 하나는 어떤 이벤트가 발생 시 이메일로 알려다오라고 설정하는 것이고, Fail2Ban에게 이메일 주소를 알려주어야겠죠.

물론 서버에서 외부로 메일을 보낼 수 있는 상태가 되어 있어야 합니다. 이는 구글 지메일 이용 우분투 메일 서버 구축하기라는 포스팅을 참조해 보시기 바랍니다.

먼저 action에서 %(action_mw)s를 추가하는 것인데요. [DEFAULT] 섹션에서 추가할 수도 있고 [wordpress]와 같은 특정 필터를 커스텀 정의하는 섹션에서 추가할 수도 있습니다.

마찬가지로 메일 주소를 destemail과 sender로 나누어 이메일 주소를 세팅해 줄 수 있습니다. 아래는 제가 세팅한 모습니다.

[DEFAULT]
ignoreip  = ***.***.***.*** ***.***.***.*** ***.***.***.*** 
bantime   = -1
findtime  = 86400
maxretry  = 5

action = %(action_mw)s

# Mail
destemail = *****@gmail.com
sender    = YYYYY@gmail.comCode language: PHP (php)

그러면 IP가 블럭되었을 때마다 아래와 같은 이메일을 받을 수 있습니다. 이메일을 받으면 별도 조치는 할 수는 없지만 경각심을 가질 수 있겠죠.

Fail2Ban 설정, Fail2Ban IP 블락 후 이메일 알람

참고

해킹 시도 악성 IP 차단 리스트 관리 방법 – NGINX 기준

도쿄 리젼과 비교해 본 Vultr 서울 리젼 사용기

가성비가 뛰어난 Vultr 가상서버호스팅(클라우드호스팅,VPS) 사용기

Vultr 가상서버호스팅의 새상품 High Frequency 사용기

가상 서버를 운영하고픈 勇者에게 전하는 가상 서버 운영 입문 노하우 – Vultr 가상서버호스팅(VPS)를 중심으로

해외 가상서버호스팅(VPS)이 국내 호스팅보다 빠르다? – 아이비호스팅과 해외 가상서버호스팅 VULTR간 비교

사이트 운영을 위한 안내 – 웹서버 세팅에서 워드프레스 설치까지(우분투 17.10, NGINX 1.13.6, Marian DB 10.2, PHP7.2)

워드프레스 최적화를 위한 18개월간의 고민, 그 노하우를 담다.