라이트세일에서 직접 블로그 서버를 돌리다가 지인의 오라클 클라우드 프리티어로 옮기고 나니 서버관리라든가 비정상적인 접속 차단할 일도 없고 평화롭다. 서버 순단현상도 없다. 오라클 클라우드 프리티어는 테스트 서버를 돌려보려 했으나 라이트세일보다 100배는 어려웠다. H선배는 어려운게 아니라 익숙하지 않아서라고 했지만 아무튼 상당히 곤욕을 치루고 결국은 포기상태다.
꾸준히 해오는 것은, 전에 access.logs에서 어뷰징 기록들을 찾아내고 차단하기위해 AbuseIPDB의 도움을 많이 받았던 터라 대신 NAS의 SSH brute force 접속실패 기록들을 리포팅하고 있다.
애플 뮤직을 맥에서 들으려니 19금 음악이어서 성인인증을 하라고 나온다. 인증 시도 했으나 "확인과정에서 문제가 발생했습니다. 다시 시도하십시오"라며 계속 실패.
로그아웃하거나 재부팅해서도 해결되지 않았다. 혹시나 싶어서 곡을 보관함에 담고 아이폰에서 재생해보니 아이폰에서 인증창이 뜨는데 이제야 제대로 인증이 완료 되었다. 모든 맥 사용자에게 공통으로 해결 방법이 있으면 좋겠지만 일단 아이폰이 있다면 이 방법을 시도해봄직하다.
계속 웹호스팅을 사용하다가 2019년 5월 AWS 프리티어로 이전, 다시 2019년 12월 라이트세일로 이전하고 2년여동안 잘 써왔다. 그리고 오랜 지인인 H선배가 돌리고 있는 오라클 클라우드 프리티어로 어제 이전하였다. 걸출한 백업/복원 플러그인 UpdraftPlus 덕분에 워드프레스 데이타 이전은 원활했고. 만 하루정도 지난 시점에서 살펴보니 한가지 문제가 생겼다.
새 글 작성 또는 기존 글 편집을 위해 글쓰기 모드로 들어가면 구텐베르크 기본 편집기가 열리면서 바로 "the editor has encountered an unexpected error" 라는 에러가 떴다.
모든 플러그인 비활성화, 워드프레스 재설치, 브라우저 쿠키,캐쉬 삭제 등을 해봤는데 해결이 되지 않았다. 일단은 예전 편집기로 되돌려주는 Classic Editor 플러그인을 설치하면 좀 구식이긴 하지만 정상적으로 글쓰기,수정은 가능하다. 구텐베르크 편집기가 가끔 이런 문제들이 보이는거 같은데 버젼업이 되어도 깔끔하게 해결이 안되나보다.
[업데이트]@08:20
해결되었다. https://github.com/WordPress/gutenberg/issues/12655 이 방법이 유효했다고 한다.
[업데이트]@2022.5.19 14:35
AWS에서 중지상태로 두었던 인스턴스를 삭제하고 고정아이피를 반납하였다.
최근 시놀로지 NAS에 로그인 실패시 IP차단 횟수 제한을 5분간 10회에서 3회로 줄였다. 즉 5분 이내에 세번 비번을 틀리게 넣으면 해당 IP의 접근을 자동으로, 영원히 차단한다.
어차피 모든 비밀번호는 Bitwarden이 생성한 비밀번호를 자동입력 하고 있기 때문에 비밀번호를 기억할 수도 없고 (예: 7ZA5%pqhKYjvg2TJE@cjB ) 자동 입력이기 때문에 오타를 내는 경우도 없다. 사람이 외워서 입력하는 경우라면 잘못 외우거나, 한/영 입력 상태가 뒤바뀌거나 caps lock이 켜있거나 키보드를 잘못 눌러 로그인 실패가 될 수도 있겠지만.
DSM이나 FTP나 SSH에 접속하는 유일한 사용자로서 비밀번호를 잘못 입력할 확률이 사실상 0이기 때문에 누군가 비밀번호를 잘못 넣는 경우는 부적절한 접근시도로 보고 바로 차단하는 것이다. 1회만 틀려도 차단시켜도 될 것 같긴한데 A단말에서 비번 변경하고 Bitwarden이 기기간 동기화 되기 전에 빠르게 B단말에서 접근할 때 기존 비번이 들어가는 경우도 있을 수 있기 때문에 1회는 속된 말로 좀 쫄리고하여 3회로 지정하였다.
사실 10회로 지정하건 3회로 지정하건 큰 차이는 없을 것으로 본다. 왜나하면 침입시도자들은
할 때까지 계속 대입해 볼 것이기 때문이다. 그렇더라도 뚫릴 리 없는 ID/PW 무작위 대입법을 침입시도자들이 원하는만큼 시도하도록 내버려둘 수도 없는 노릇이다. 복이 많아보인다고 길거리에서 접근하는 사람이나 피싱 전화를 받았을 때처럼 가급적 대꾸하지 않고 튕겨내버리는 것이 시간과 노력면에서 가장 효과적인 것처럼 부적절한 접근 역시 바로 막아버리는 것이 상책이다. 많진 않겠지만 인바운드 트래픽과 컴퓨팅 자원을 사용하기도 할테고.
아울러 모든 연결이 집안과 회사를 포함해 국내에서만 이루어지기 때문에 해외 아이피, VPN을 통한 접근도 이 기회에 모두 막았다. 예전에 막았던거 같은데 초기화하면서 한번 풀렸는지, 아무튼 다시 잘 지정했다. (via Synology KB > DSM > 보안 > 방화벽)
요즘 access_log 파일 보면서 이상한 짓 하는 IP들 차단하는 소소한 취미생활을 시작하였다, 이러저러한 툴로 IP들을 TextMate에 모아둔 다음에 일괄 차단시키다보니 이 아이피들이 중복된건 아닐까 하는 점이 신경쓰였다.
엑셀이나 구글스프래드 시트에 넣고 조건부서식으로 봐도 되지만 번거롭다. 다행이 TextMate에서 중복행 제거 기능을 제공하고 있었다.
처음에는 라인 소팅만 되도 눈으로 훑어보면서 찾아내면 되겠거니 싶었는데 라인소팅도 가능했고, 중복 행 제거도 가능했고 라인소팅과 중복행 제거 동시처리도 가능했다.
Bundles → Text → Sorting → Remove Duplicates in Document 를 선택하면 중복행이 제거된다.
며칠 전 야간에 전조등을 켜지 않고 운행하는 차량을 발견했다. 신호대기시에 바로 앞차 였는데 멈춰 있을 때는 제동등이 켜져 있어서 몰랐는데 출발하면서 보니 후방 미등과 번호판등이 모두 들어오지 않았다. 차들이 적당히 있었기에 계속 뒤 따라가면서 봐도 계속 켜지 않았고, 귀가 후 제차 신호조작불이행으로 스마트국민제보에 신고했다.
며칠 뒤에 처리결과가 왔는데 이러하다.
교통법규위반 신고를 하여 주셔서 감사드리며 처리결과를 답변 드리겠습니다. 야간에 전조등을 취명하지 않고 주행하는 차량은 음주운전 했을 가능성이 있고 교통사망사고가 발생할 위험성이 큰만큼 추후에는 현장에서 바로 112신고를 하시어 해당차량운전자를 상대로 현장출동 경찰관이 확인 할수 있도록 신고하여 주시면 감사하겠습니다. 귀하께서 제보해주신 영상자료를 확인한 결과, XXㅇXXXX 차량은 도로교통법 제37조 등화점등 조작 불이행 (범칙금 20,000원, 벌점 0점) 에 해당하는 사실을 확인하였습니다. 신고차량은 교통경찰업무관리시스템의 범법차량 관리대상으로 접수하였습니다. 위반자에 대해서는 교통법규위반사항을 고지하여 절차에 따라 처리될 수 있도록 하겠습니다.
신고 영상에는 해당 차량이 약 7킬로미터 구간을 전조등을 켜지 않고 주행하는 모습이 담겨 있었다. 담당 경찰관이 보기에 이런 환경의 도로를 전조등 안켜고 수킬로 주행하는 차량의 모습을 보고 단지 실수로 전조등을 켜지 않은 차량은 아닌거 같다는 느낌이 있었나보다.
사실 요즘은 전조등을 켜지 않아도 계기판에 조명이 들어오고 주간주행등도 밝기 때문에 시가지 구간에서는 전조등을 켜지 않은걸 운전자가 모를 수도 있는데. 만에 하나 이런 차량이 음주운전 차량일 수 있다는 가능성을 열어두고 다음부터는 유심히 살펴보고 신고할 예정이다.
가끔 가다가 블로그 접속이 되지 않을 때가 있다. 이유는 모르겠고. Uptime Robot로 서버가 다운되면 알림이 오도록 해놔서 SSH 접속한 후에 sudo /opt/bitnami/ctlscript.sh restart 를 실행하면 수초내에 접속이 복구되긴하나 컴 앞에 있지 않을 때는 속수무책이었다. 이에, 아이폰으로 서버를 재시작하는 방법을 찾아 보았다.
문제는 여기서 sudo /opt/bitnami/ctlscript.sh restart 명령어를 입력해야 하는데, 길이도 길고 화면 글씨가 작아서 입력이 만만치 않다. alias 를 지정해보기로 합니다.
grep bitnami /etc/passwd (via)로 현재 쉘을 확인해보니 bash.
.bashrc를 적당한 편집기로 열어서 alias rstart sudo /opt/bitnami/ctlscript.sh restart 한줄을 추가하고 저장하고 나온 후 source .bashrc로 적용.
이제부터 아이폰으로 서버에 SSH 접속한 후 rstart 라고만 치면 웹서버를 재시작할 수 있게 되었다.
라이트세일 홈페이지에서 웹 SSH를 사용하다보니 로긴할 때마다 captcha 입력이 번거롭다. iterm2를 이용해서 접속하는 방법을 정리해둔다. iterm2가 설치되어 있고 비트나미 인스턴스 사용을 전제로...
15년 전에 오른쪽 아래 사랑니 뽑은 이후 오늘은 오른쪽 윗 사랑니를 발치했다. 양치할 때 가끔씩 시린 느낌이 있었고, 지난 달엔 그쪽 부근에서 통증이 한번 있었다. 어차피 아래쪽 사랑니가 없었기에 저작기능을 할 수 없는 상태인데다가 맞닿은 어금니에 문제 생기지 않게 미리 발치하라는 이야기를 스케일링 하러 갈때마다 들어왔다.
동네 치과로 갈까 하다가 소심한 마음에, 단대치대병원 행. 처음에는 예방치과로 가라고 해서 진료 받았고, 여기서 상담 후 발치하기로 하고 구강악안면외과로 넘어 갔다. 5층이었는데 전망 좋은 편. ^^;
의료진의 감염병 감염 예방을 위한 검사를 해야한다며 아래 잇몸을 면봉으로 몇번 긁어 갔다. 잠시 후 입술 주변과 코까지 외부 소독 먼저 하고, 소독포 덮고 입안 내부도 소독하고 식염수로 헹구어 주었다. 다음 순서는 마취 주사를 치아 근처에 몇방 놨고, 윗쪽 입천장 쪽 맞을 때는 따끔했다. 견디기 어려울 정도는 아니고 '어허.. 뻐근하구만...' 정도? 마취가 잘 됐는지 이곳 저곳 눌러볼 때 한군데가 약간 시큰하다고 했더니 '더 마취해드릴게요' 하더니 한두방 더 놓았다. 이때는 따끔한 느낌도 없었다.
잠시 후 발치 시작하겠다며 의료진이 바뀌어 들어왔고 아~한 다음에 이를 몇번 흔듭니다. 어느 정도 힘으로 뽑을건지 가늠하는건가? 싶었는데 이때 뽑았던 것. 약간 뿌득 ~ 뿌득 하는 느낌이 있었는데 그게 발치하려고 도구로 힘 주는 거였나보다. 금세 마무리하고 거즈 물고 일어났다. 실제 발치는 1분 정도 걸린 듯.
수술 마치고 바로 마스크 쓰려고 하니 아까 입술 외부에 소독한 약제가 묻어있으니 먼저 닦아내야 한다며 파우더룸으로 안내했다. 세면대 3개가 마련되어 있었고, 거울보니 입가와 코까지 노란 약제가 묻어있었다. 가볍게 세수 한 후에 마스크 착용하고 퇴장.
약 처방은 세파메칠정(항생제)과 잘트론정(소염진통제)을 하루 3회 3일치를 처방받았고 아침용에는 가스티인씨알정(위장운동조절 및 진경제)이 한알씩 추가되었다.
대학병원이라 아마 인턴이나 레지턴트들이 검사,마취,발치 등에 참여했을텐데. 과정별로 역할을 분담해서 과정 시작때마다 지금부터 무엇을, 왜 할것이고 어떤 느낌이 들것인지를 친절하게 설명해주었다.
처음 예방치과 진료에는 1만원쯤 나왔고 발치 후에 다시 4만 얼마쯤 추가로 내고 나왔다. 여기에 약값 6100원.
15년전에도 그랬지만 사랑니 뽑히고 별 통증없는 체질인가보다. 현재 6시간 지났고 다행이 별 통증이나 붓기, 열감은 없다. 두어시간에 한번씩 얼음팩만 댔다가 뗐다가 하는 중이다.
access_log를 보면 웹서버에 자주 + 빠르게 재접속하는 아이피들이 있는데, 이걸 자동으로 찾아주는 명령이 있었다.
Deny Connections From Bots/Attackers Using Apache
cd /opt/bitnami/apache2/logs/
tail -n 10000 access_log | awk '{print $1}'| sort| uniq -c| sort -nr| head -n 10-n 10000은 access_log의 마지막 10000줄에서 찾으라는 이야기이므로 accrss_log의 줄 길이에 따라 적당히 늘려주면 된다.
wc -l accress_log 로 해당 파일의 라인 수를 알 수 있다.
맨 뒤 head -n 10 은 가장 잦은 접근을 한 상위 10개를 뽑아 오는 것이니 이 또한 적당한 숫자를 지정한다.
실제로 뽑아내보니 상위 10개라 하더라도 전체를 차단해서는 안되었다. 1~6위까지는 어뷰징 아이피들이 맞았으나 7~10위는 검색엔진의 봇 이었기 때문이다. 상위 20개정도씩 찾아서 조회해봐야할텐데. 일괄적으로 IP목록 넣으면 어뷰징 아이피와 봇 아이피를 선별해주는 서비스가 있으면 좋겠다.