지난 9월, Google Chrome 의 Canary 업데이트로 HTTP/3의 표준이 시험적으로 지원되었습니다. 아직 HTTP/2에 대한 표준이 나온지도 겨우 4개월밖에 안되었는데, 새로운 표준이 빠르게 업데이트 되었습니다.
이번 Apache2 모듈 업데이트로 HTTP/2를 지원하도록 몇가지 수정사항을 반영했습니다. 결과적으로 Load Time을 보면 약 50±20ms의 차이가 나는 것을 볼 수 있었습니다.
HTTP/2 프로토콜은, HTTP/1.1이 Plaintext인데 반해, Binary의 형식을 가지고 있다고 합니다. 추가적으로 궁금한 점이 있다면 [HTTP] HTTP 2의 탄생 배경과 특징을 참조해주세요. 개인적으로 좋은 글인 것 같네요.
인증서를 갱신한다는 것을 잊고 있었네요. 오늘자로 갱신했습니다! 이제 2월까지 걱정이 없군요.
이번에는 사이트에 스팸성 게시글들이 올라온다는 제보를 주셔서 확인해봤습니다. 일부 국내/외 봇들이 남긴 글인데, 각 게시판에 쓸수 있는 사용자 권한 설정이 잘못 되어있었던 듯 합니다. 패턴으로 정상/스팸성 글을 구분해서 해당 기간내 글이나 댓글을 작성하셨던 회원님의 게시물은 삭제되지 않고 남아있습니다!
처리한 내용을 바탕으로 해당 IP들과 Title의 데이터는 csv로 첨부해놓았습니다. (스팸 데이터 분석에는 좋을것 같네요.) 정리된 내용들이니 column의 맨위 header 참조하여 사용하시면 될것같습니다.
이번 문제를 계기로 사이트내 스팸 차단 정책과 보안을 다시 확인했습니다. 현재 모든 서비스가 정상적으로 작동되고 있습니다! 또다른 문제 발견시 임원진에게 연락주세요. 그럼 다들 시험 잘보세요-!
집컴을 원격으로 쓰다보니까 동방PC에 접속할 일이 거의 없네요. 오랜만에 관리차 들어와서 이것저것 찾아보던중 이런 사이트를 발견했습니다.
Qualys SSL Lab의 서버 SSL Test: https://www.ssllabs.com/ssltest/
여기서는 서버 내 SSL의 상태를 점검할 수 있었습니다. 그래서 한번 돌려봤는데, 신기하게도 “DNS CAA”라는게 눈에 띄는군요. 해당 내용을 검색해보니 다음과 같았습니다.
DNS CAA는 DNS Certification Authority Authorization (CAA) 라고 되어 있습니다. DNS CAA는 RFC6844 에 정의되어 있습니다. CAA 레코드를 만든 목적은 특정 도메인의 CA (Certificate Authority) 가 어디인지를 알려주기 위한 목적이 있습니다. [출처: RSEC.KR]
SSL을 발급해준 인증기관(CA라고 합니다. Certificate Authority)이 내가 실제로 발급받은 기관인지를 DNS에 명시해주는 기능입니다.
얼마전(이라고는 하지만 아마 두 글 정도 뒤 쯤?)에 DNS 서버를 dnsever.kr에서 자체 DNS 서버로 변경했습니다. 속도도 훨씬 빠르고, 관리 측면에서도 월등히 좋아서 bind9 DNS 서버를 현재까지 이용하며 관리중입니다.(그래서 인수인계는?) 여튼 그래서, DNS 서버도 있겠다. 한번 적용해봤습니다.
다를게 없습니다. 다만 다른 누군가 침입자가 타 CA로부터 blending.kr의 인증서를 발급받았다고 하더라도, 블렌딩은 안전한겁니다.
안전에 안전. 그뿐이네요. 좀더 편한 마음으로 사이트 방문하시면 되겠습니다(?????)
현재 블렌딩 전 페이지에 HSTS(자세히 보기/RSEC.KR)가 적용이 되어있는데, Policy를 조금 업데이트해서 더 Strict하게 바꿨습니다 (큰 의미가 있진 않지만). 그리고 Preload List에 Submit했네요. 이제 SSL없어서는 안되는 사이트가 되었습니다. 그래도 보안 하나는 최고인거같네요!
오랜만에 휴가나와서 동방에 있는 서버PC 랜선 교체해줬습니다. 퍼랭이는 건드리면 안돼요!
<수정 사항>
이번엔 Wiki를 새단장했습니다. 새로운 테마인 bootstrap3을 이용해서 아-주 깔끔하게 바뀌었습니다. 여러가지 모듈도 함께 설치해서 기능도 풍-부해졌습니다. 많은 이용 바랍니다(?).
이번에는 이메일을 보낼 수 없는 문제를 확인하기 위해 Postfix 서비스 상태를 확인해봤습니다.
● postfix.service - LSB: Postfix Mail Transport Agent
Loaded: loaded (/etc/init.d/postfix; bad; vendor preset: enabled)
Drop-In: /run/systemd/generator/postfix.service.d
└─50-postfix-$mail-transport-agent.conf
Active: inactive (dead) since 금 2017-12-15 23:53:13 KST; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 15980 ExecStop=/etc/init.d/postfix stop (code=exited, status=0/SUCCESS)
12월 15 23:15:16 blending.kr systemd[1]: Started LSB: Postfix Mail Transport Agent.
12월 15 23:15:17 blending.kr postfix/master[3739]: daemon started -- version 3.1.0, configuration /etc/postfix
12월 15 23:18:13 blending.kr systemd[1]: Started LSB: Postfix Mail Transport Agent.
12월 15 23:53:13 blending.kr systemd[1]: Stopping LSB: Postfix Mail Transport Agent...
12월 15 23:53:13 blending.kr postfix[15980]: * Stopping Postfix Mail Transport Agent postfix
12월 15 23:53:13 blending.kr postfix[16000]: Postfix is running with backwards-compatible default settings
12월 15 23:53:13 blending.kr postfix[16000]: See http://www.postfix.org/COMPATIBILITY_README.html for details
12월 15 23:53:13 blending.kr postfix[16000]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
12월 15 23:53:13 blending.kr postfix[15980]: ...done.
12월 15 23:53:13 blending.kr systemd[1]: Stopped LSB: Postfix Mail Transport Agent.
확인결과 Postfix가 실행조차 하지 않았다는 것을 발견하고, 부팅 스크립트 /etc/rc.local을 확인해보았습니다.
rc-local.service를 journalctl -u로 로그 확인한 결과, 이번에는 /data 파티션의 파일 시스템인 zfs를 설정하던 중 문제가 발생한 것으로 파악되었습니다. 해당 라인은 지워버리고 나니, 그 다음줄 스크립트가 실행되지 않는 문제가 해결되어서 이제는 정상적으로 Postfix가 시작되는 것을 확인했습니다.
이번에는 TC(Trsffic Control)을 이용하여 들어오는 패킷에 대한 트래픽 제어를 시도했지만 실패했습니다. 여기(https://serverfault.com/questions/557573/incoming-ingress-traffic-shaping-on-linux-bw-is-lower-than-expected)에 따르면, 들어오는 패킷을 제어하는 것은 소방차의 호스에 구멍난 판자를 갖다 대는 것과 마찬가지이다라는 지문처럼 불가능에 가깝다는 것을 다시한번 느꼈습니다…
Trying to limit incoming bandwidth is basically trying to limit the flow of a firehose by holding up a board with a hole drilled in it: You will reduce the amount of water that hits you, but you’re still being hit by the firehose.
Carrying the firehose analogy further, if you need 100 gallons of water but limit the rate at which it’s getting to you (by holding up the board with the hole in it) you’re still bearing the brunt of the force of the firehose (traffic coming down your pipe), but not getting most of that water (because only what happens to go through the hole reaches you — The rest is dropped on the floor by your
firewallboard).The effect of blocking all that water is that it takes longer to fill your 100 gallon bucket.
The effect of blocking TCP packets with a firewall is a little worse, because you trigger the remote host’s congetion control algorithm which in an ideal world makes it turn down the pressure on the firehose, sometimes substantially lower than you would like it to.Incidentally this is also why a local firewall can’t save you from DoS attacks – you still have to deal with all the traffic, even if it’s just to make the decision to ignore it. A DoS attack is unlikely to honor congestion control procedures for obvious reasons.
다만, Outgoing Traffic에 대해서는 Control이 가능하여 이를 수행하였습니다(하지만 20Mbps Incoming/Outgoing Traffic Control이라는 목적은 결국 달성하지 못했군요)
2017/12/15 수정: tc의 ingress policing이라는게 있는 것 같습니다. 이걸로 무언가 해결할 수 있을 것 같지만 당장은 힘들겠군요(너무 복잡하네요. TC에 대해서 제대로 배운 뒤 나중에 시도해 봐야겠습니다.)
빼빼로데이-!
모든 SSL이 적용된 HTTPS 주소를 8443번 포트로 변경하였습니다. 변경하면서 기존의 .htaccess와 Apache configuration file들을 정리하는 과정이 있었습니다. 결과적으로, 기존 HTTPS 주소로 들어오게 되어도 새로운 주소로 리다이렉팅 됩니다. 실제 사용에는 지장이 전-혀 없습니다.
사유는, 기존 443번 포트로 서비스하던 HTTPS 웹 페이지에서 2s 이상의 Connection을 유지할 수가 없는 문제가 확인되었습니다. 아무래도 강대 내부에 있는 정책 때문인건지, 큰 파일을 다운로드 하거나 업로드 하는데 문제가 되는 것으로 보입니다.
또한 초당 2개 (.5초당 1개)의 Packet drop이 발생되는 것이 확인되었습니다. 어떤 패킷이 지속적으로 드랍되는건지는 확인이 어렵습니다만 큰 문제는 아니고, 위 443번 포트와도 연관이 있는것 같아 보입니다. 첫 사이트 접속시에도 HTTPS 443번 포트로 접속하는것은 지양하시길 부탁드립니다 (이 문제로 인해 접속에 실패할 가능성이 있습니다.). 일반 HTTP 주소로 접속하시거나, 8443번 HTTPS로 접속해주시면 됩니다.
추후에 문제 발견되면 수정하겠습니다.
기타 문제 발생시나 건의사항 댓글로 남겨주시면 확인해드리겠습니다.
블렌딩 동아리방을 212호에서 1층으로 옮기는 과정에서 문제가 있었던 것 같습니다. (이유는 아무래도 HDD가 문제였던것 같네요.)
OS마저 처음부터 새로 설치했습니다. 시간이 꽤나 걸리더군요. 지난 10월 11일부로 정상 운용중입니다.
현재 아래 해당하는 모든 서비스들이 정상 작동하고 있습니다. Performance 문제 해결을 위해서 PHP의 APCu, apcu_bc, Redis를 이용하여 성능을 크게 향상시켰습니다(11월 8일).
GitLab 10.1.1
XpressEngine 1.8.45
Dokuwiki Release 2017-02-19e “Frusterick Manners”
Wordpress 4.8.3
ownCloud X 10.0.3
… (기타 시스템 관리 Apps)
이제 한시름 놓았습니다. 모든 데이터 디스크도 ZFS를 이용하여 성능이 크게 향상되었을 것입니다. 더이상 더 좋아질 것이 없겠군요. (그리고 또 서버는 발전합니다)