Nginx에서 sub-directory에 proxy pass 설정하기

btsync 서버를 띄우면 기본적으로 0.0.0.0:8888에 Web UI가 바인딩 되는데 아무리 http basic auth를 지원한다지만 어차피 평문으로 전송되기에 별 의미는 없다. 그래서 nginx에 있는 reverse proxy 기능을 이용해서 /btsync/에 물려보기로 했다. 이러면 https로 통신하니 조금 안전해지기 때문이다.
설정은 대충 아래와 같다.

location /btsync/ {
    proxy_pass http://localhost:8888/;
    proxy_redirect / /btsync/;
}

처음에 proxy_redirect를 써주지 않았는데 이러면 btsync에서 처음에 302 redirect를 주는데 이걸 nginx에서 그대로 전달하기 때문에 /btsync/gui/로 가야 할 것을 /gui/로 가게 된다. 그래서 저렇게 써야 하는데 왜 nginx는 저렇게 설계했나 모르겠다. 저 정도는 써주지 않아도 알아서 잘 동작해야 하는 것 아닌가.

nginx로 넘어오고나서 저렇게 중복해서 적어줘야 하는 게 많은 것 같아 아쉽다.

Yasager – Karma on the Fon이 아직도 통할까?

Wi-Fi 관련 공격방법 중에 Yasager(독일어로 대충 Yes man쯤 된다)라는 게 있다. 이게 어떤 공격이냐면 Wi-Fi 클라이언트들은 켜지는 순간 자기가 가지고 있던 AP들의 SSID가 근처에 존재하는지 모두에게 물어보게 된다. 굳이 Beacon frame(AP에서 자신의 SSID를 알리는 행위)이 발생하기까지 기다리지 않도록 하기 위함이다. 예를들어 RealAP라는 AP목록이 저장되어있을 때 Wi-FI를 켜면 RealAP라는 SSID를 가진 AP가 존재하는지 물어보게 된다.

제대로 만들어진 AP라면 자신의 SSID가 RealAP일 때만 응답을 하겠지만 Yasager는 실제 자신의 SSID가 FakeAP라 할지라도 무조건 맞다고 응답한다. 그러면 클라이언트는 그걸 검증할 방법이 없기때문에 접속을 하게 된다. 원래의 AP가 더 가까이 있어야 성공하기 쉽기 때문에 추가적으로 Aireplay등을 통해 Yasager가 아닌 AP에 대해서는 Deauth 패킷을 날려주는 방법도 같이 쓴다.

당연하겠지만 원래 저장된 AP 설정에 암호가 있다면 그 클라이언트는 Yasager에게 암호와 함께 접속 요청을 한다. 내 기억상 이 Yasager는 WEP 보안까지는 어떻게 하나 모르겠지만 WPA 이상으로 넘어가면 그냥 접속이 안된다. 그래서 암호가 걸리지 않은 AP를 대상으로 Spoofing을 해서 원본 AP가 아닌 Fake AP로 접속하게 만드는 공격이다.

예전엔 암호가 걸리지 않은 AP가 많았고 그래서 효과는 굉장했지만(Facebook의 피싱사이트만 만들어서 제공해도..) 지금은 집에서도 다들 WPA 이상의 암호를 걸어서 사용하기 때문에 공격할 수 있는 곳은 근처 카페 AP정도가 될 것이다. 그런데 카페 Wi-Fi 정도면 그냥 같이 접속해서 ARP spoofing 공격을 하는 걸로도 충분하다. 오픈된 AP가 밀집된 지역에서라면 좀 쓸모가 있을지도 모르겠지만 요즘 그런 곳이 흔하지는 않다.

그래서 내 생각에는 통신사들의 오픈된 AP들(T-WiFi, olleh, u+zone)을 한꺼번에 타깃으로 잡는 것 이외에는 그다지 활용할 곳이 없을 것 같다.
이번 해킹캠프때 네트워크 보안에 대한 이것저것을 발표하려 하는데 이것도 간략히 넣어야겠다 하고 자료를 만들다가 생각나서 써봤다.

When dokku asking for password

I installed Docker and dokku for fun.
It is correctly works on my sub-laptop when I copy ~/.ssh/id_rsa.pub and run sudo sshcommand acl-add dokku <nickname> but not on my server.
I did same progress on my server, but git, ssh says require password.

So I thoght a few hours. then I relized I changed my ssh daemon’s configuration. I block all users who is not in the ssh group. so I add dokku account to ssh group and tried again. and FAILED.

Finnaly I set password to dokku account. and tried again. ssh and git works WITHOUT PASSWORD.
Maybe the ssh client has failed to login with ssh-key so ask me a password. so I opened /etc/shadow file to find out what happened.
Only the root and dokku has ! on password field. and other non-password account have * on it.

I don’t know what it is for. but it works when I changed ! to *.


심심해서 Docker를 설치하고 dokku까지 설치해봤다.
그런데 실험삼아 서브노트북에 설치한 dokku는 ~/.ssh/id_rsa.pub을 복사해서 sudo sshcommand acl-add dokku <nickname> 해주면 git push 명령도 잘 먹고 ssh [email protected]<hostname> 해주면 정상적으로 접속이 끊기지만 서버컴에 설치한 dokku는 아무리 id_rsa.pub 파일을 집어넣어도 자꾸 패스워드를 물었다.

무슨 차이일까 가만히 생각하다가 내가 서버에는 SSH 데몬의 설정을 건드린 것이 생각났다. 특정 그룹에 있지 않으면 SSH 접속조차 막아뒀다. 그래서 dokku 계정을 ssh 그룹에 추가해줬는데도 결과는 마찬가지였다.

결국 포기하는 마음으로 dokku 계정에 패스워드를 설정하고 접속해봤다. 그런데 마법같이 패스워드를 묻지도 않고 접속이 되었다. 아마 패스워드가 없는 계정은 접속을 막았는데 클라이언트에서 ssh-key로 접속이 안되니 패스워드를 물어본 것 같다. 그래서 /etc/shadow 파일을 잠깐 열어보니 패스워드가 없는 계정은 패스워드 부분에 적힌 값이 두 가지로 나뉘어 있었다. 하나는 *이고 하나는 !인데 다른 계정들은 대부분 *을 사용했는데 root와 dokku만 !를 사용했다. 그래서 혹시나 하고 *로 바꿔보았는데 잘 작동이 되었다.

*!의 차이를 찾아봤는데 다들 기능적으로 똑같다고만 말하고 !는 보통 패스워드가 있던 계정을 사용 못하게 할 때, *는 패스워드가 지정된 적이 없는 계정에 그렇게 적는다고 말한다. 하지만 dokku를 사용해보니 실제로 차이가 있었다.