보안 강화 시 성능 저하 극복
1. 방화벽 설정시 속도 지연 문제에 대해
저도 금번에 iptables 로 방화벽을 구축하면서 이러한 문제가 있었습니다.
특정 포트로의 반응이 느린 문제가 있었는데, 아시다시피 이는
identd 와 관련된 문제이므로 identd의 포트인 113번을 DROP 하지말고 Reject 로
차단하라고 권장하고 있습니다.
iptables -A INPUT -p TCP –syn –dport 113 -j REJECT –reject-with tcp-reset
물론 이 설정을 통해 일정정도의 속도 향상을 가져올 수 있으며 방화벽 구축시
반드시 필요한 룰이라고 생각합니다.
identd 에 대해서는 아래에서 별도로 설명을 드리도록 하겠습니다.
2. 그래도 여전히 특정 포트의 반응이 느린 경우
위 설정을 한 후 다른 포트는 특별히 문제가 없는데, 25번 포트(sendmail 등) 의
반응이 매우 느린 경우가 있습니다. (이런 현상을 호소하는 경우를 자주
보았습니다.)
이는 sendmail 자체에 내장되어 있는 ident 와 관련된 문제인데,
이는 sendmail.cf 파일을 열어
#O Timeout.ident=5s 로 되어 있는 설정을 찾아
O Timeout.ident=0s 로 변경한후 sendmail 을 재가동하면 눈에 보이는 속도
향상을 가져올 수 있습니다.
(sendmail 소스에 default 로 ident가 5초로 설정되어 있는데 이를 0초로
변경하는 것입니다.)
이는 꼭 방화벽이 없다 하더라도 일반 메일 서버에서 설정할 경우 일정 정도의
속도향상을 가져올 수 있으며 대부분의 서버에서 권장 설정사항입니다.
3. 그렇다면 “identd” 의 역할은 무엇인가?
아래는 오래전에 identd 에 대하여 설명된 어떤 문서를 보고 나름대로 제 사견을
포함하여 정리한 글인데, 정확한 출처등은 기억이 나지 않습니다.
참고하시기 바랍니다..
identd 는 inetd(또는 xinetd) 에서 작동하는 데몬으로 tcp/113번 포트에서
리슨하며 인증(AUTH) 데몬이라고도 불립니다. 서버에서 滂옳求?다른 서비스들도
클라이언트 머신들에게 접속을 요청한 유저에 대한 신원 확인을 위해 identd 를
사용할 수 있습니다.
telnet 이나 sendmail 등의 서비스를 하는 서버에 요청이 들어왔을때 인증
서버는 클라이언트의 identd 포트에 “이 서비스를 요청한 프로세스의 소유자가
누구인가”라고 물어보게 됩니다.
만약 클라이언트의 인증데몬이 username@nodename 으로 응답했다면 이 응답은
서버의 syslog 등에 전달되고 연결요청은 telnetd 에게 전달됩니다. 만약 응답이
null 또는 클라이언트에서 인증 데몬이 없을 경우 서버의 auth데몬은
timeout 이 될 때까지 기다린 후 연결을 받아들입니다.
이 때의 지연현상은 레드햇 7.0의 경우 대략 2분정도 소요됩니다.
이때 중요한 것은 응답을 받을때 유효성을 체크하지 않고 또 응답은 전적으로
클라이언트 머신에게 달려 있으므로 username@nodename 는 충분히 위조될 수
있다는 것입니다.
(물론 root 만이 이를 위조할수 있는 권한이 있습니다.)
또한 FreeBSD 나 Windows 와 같은 많은 시스템에서는 root가 아닌 일반 유저도
그들이 원하는 어떠한 identd 를 명시할 수 있습니다.
이 프로토콜은 멀티 유저환경에서 문제가 있는 유저를 찾아내는데 유용하게
사용될 수는 있습니다.
만약 여러분 시스템에 있는 한 유저가 다른 시스템에 문제를 일으켰을때 상대방
시스템 관리자는 여러분에게 문제를 유발한 유저를 찾아 알려줄 수 있습니다.
그렇다면 identd 를 작동하여야 할까요? 이는 전적으로 자신의 판단에 달려
있습니다. 많은 유저가 있는 시스템에서는 유용하지만 소수의 유저일 경우에는
별로 도움을 주지는 않습니다. 때로 어떤 IRC 나 FTP 서버는 identd 가
작동하지 않는 접속을 허용하지 않을 수도 있습니다.
그러나 identd 를 운영할 경우 시스템의 각종 정보를 제공하게 됩니다.
예를 들면 “root 로 작동하고 있는 프로세스는 무엇이 있는가? “,
“어떤 OS가 작동하고 있는가?”, “어떤 username 이 있는가?” 등입니다.
만약 identd 에 -n 옵션을 줄 경우에는 username 대신 username id 를 보내게
됩니다. 기타 identd 에 대한 더 많은 설정은 /etc/identd.conf 에서 설정
가능한데, identd 는 이 프로세스를 죽이거나 tcp wrapper 를 사용하여
차단하거나 또는 방화벽을 이용해 차단 가능합니다.
만약 방화벽을 이용한다면 deny 를 사용하지 말고 reject로 차단하는 것이 좋으며
만약 deny 를 이용한다면 서버에 접속시 매우 많은 시간을 소요하게 됩니다.
(앞에서 말씀드렸죠?)
identd 의 대표적인 관련예는 tcp wrapper 에서도 찾을 수 있습니다.
hosts.deny 에
ipop3d: ALL: (/some/where/safe_finger -l @%h | \\
/usr/ucb/mail -s %d-%h root) &
와 같이 설정하여 사용중인 분들이 많이 계실 것입니다.
hosts.deny 에서 지정한 룰에 해당하는 접속일 경우 우측의 쉘 명령어에서
지정한대로 클라이언트의 접속정보를 root 에게 메일로 통보하도록 하는
설정이지요…
이때 클라이언트의 접속정보는 %u 변수값을 얻어오게 되는데,
identd가 제대로 작동하지 않을 경우에는 신뢰할 수 있는 정보를
얻어올 수 없게 되는 것입니다.
4. 다시 정리를 하면
(1) identd 가 제대로 작동하려면 클라이언트와 서버 모두 identd 가 작동하고
있어야 합니다. 그러나 최근에는 identd 를 서비스 하기보다는 필터링 하는
경우가 대부분이고
(2) 또한 identd 의 정보는 충분히 위조될 수 있으며 서비스를 할 경우 불
필요한 정보를 외부에 제공하게 되므로
(3) 보안과 속도등의 문제를 고려하여 identd 는 서비스를 하지 않는 것이
좋을듯 합니다.