보안 강화 시 성능 저하 극복

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 는 서비스를 하지 않는 것이

좋을듯 합니다.