client 의 IP 나 MAC, hostid 등을 등록해서 간단히 필터링할 수도 있지만.. 이런거는 상횡에 따라 우회하기 쉬우니..
pre-shared key 나 인증서로 상호 인증하고, 키교환 프로토콜 붙여서 암호키 생성해서 암호화 하면..
어느 정도 되지 않을까 싶네요..
키 생성 알고리즘이나 방법이 공개되지 않으면, PSK 나 인증서가 유출되더라도 어느 정도는 버틸 수 있을테고..
혹시 MITM 이 염려스러우시면, SSL 로 한번 더 커버하면 될 것 같네요.
단순히 패킷 복제해서 던지는 경우에는, 프로토콜에 sequence number 붙여서 처리하는 정도..?
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』
음 ..
client 의 IP 나 MAC, hostid 등을 등록해서 간단히 필터링할 수도 있지만.. 이런거는 상횡에 따라 우회하기 쉬우니..
pre-shared key 나 인증서로 상호 인증하고, 키교환 프로토콜 붙여서 암호키 생성해서 암호화 하면..
어느 정도 되지 않을까 싶네요..
키 생성 알고리즘이나 방법이 공개되지 않으면, PSK 나 인증서가 유출되더라도 어느 정도는 버틸 수 있을테고..
혹시 MITM 이 염려스러우시면, SSL 로 한번 더 커버하면 될 것 같네요.
단순히 패킷 복제해서 던지는 경우에는, 프로토콜에 sequence number 붙여서 처리하는 정도..?
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』
답변 감사드립니다. 보안관련된 것도 신경써서
답변 감사드립니다.
보안관련된 것도 신경써서 잘해야하는군요..ㅠ
음 ..
대충 쓰다보니 MITM 에 오해의 소지가 있게 쓴 것 같네요..
SSL 로 커버한다기 보다는.. 그냥 귀차니즘을 한 번 더 보태는 정도에 가깝습니다.
SSL 디코딩 하고 그걸로 다시 프로토콜 분석해야 할테니 난이도가 조금은 올라가겠죠.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』
똑같은 패킷타입일 경우 n번 이상 받을경우 접속을 끊어버리는 방법도 있습니다.
일정시간동안 똑같은 패킷타입일 경우 n번 이상 받을경우 접속을 끊어버리는 방법도 있습니다.
그러나, 특정 패킷에 따라서는 일정 시간에 빠르게 들어오는 패킷도 존재할 수 있으므로, 해당하는 패킷들에 대해선 예외 처리를 해주면 프로그램단에서 어느정도 막을수 있습니다.
댓글 달기