Tomcat 보안 개요

Security 2009. 3. 12. 14:39

1. Tomcat 컨테이너 구조

톰켓은 다음그림과 같이 중첩된 컨테이너 구조로 되어 있습니다. Server 라는 컨테이너가 가장 바깥쪽의 컨테이너 이고 그 안에 Service라는 컨테이너가 있으며톰켓은 디폴트로 Catalina Service 컨테이너를 정의하고 있습니다.

Catalina Service 컨테이너에는 다수의 Connector와 하나의 Engine이 정의됩니다. Connector는 외부의 HTTP/HTTPS/AJP 요청을 직접 받아들이는 컴포넌트입니다. 정의된 모든 Connector로부터 수신된 요청은 Engine으로 전달됩니다.

Engine 컨테이너에는 다수의 Host 컨테이너들과 Realm 그리고 Valve들로 구성됩니다.

Host 컨테이너에는 다수의 Context들과 Valve들로 구성됩니다. Valve는 요청 체인의 일부분을 구성하는 컴포넌트로 Engine 컨테이너 및 Host컨테이너에서 정의합니다.

요청 체인의 예를 들면 아마도 다음과 같은 구조일 것입니다.

ConnectoràEngineàValveàValve… àHostà ValveàValve…

àContextàServlet FilteràServlet







설정 파일 예:

Serverport는 서버를 shutdown 시킬 때 사용되는 포트입니다. 8005 포트로 소켓을 열고 “SHUTDOWN”이란 문자열을 전송하면 톰켓이 종료됩니다. , shutdown은 동일 시스템에서만 가능합니다.

<Server port="8005" shutdown="SHUTDOWN">

……

<Service name="Catalina">

……

<Connector port="80" ……/>

……

<Connector port="8443" …… scheme="https" clientAuth="false" sslProtocol="TLS" />

……

<Connector port="8009" …… protocol="AJP/1.3" />

……

<Engine name="Catalina" defaultHost="localhost">

<Valve className="org.apache.catalina.valves.RequestDumperValve"/>

<Realm className="org.apache.catalina.realm.MemoryRealm" />

<Host name="localhost" appBase="webapps" ……>

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

<Context path="/ROOT" … docBase="C:\webroot" />

<Context path="/abc" … docBase="C:\abc" />

</Host>

</Engine>

</ Service>

</Server>

2. Tomcat 인증 메커니즘

톰켓에서 제공하는 인증 방법은 다음과 같이 네 가지가 있습니다. BASIC DIGEST 인증은 브라우저가 보안이 설정된 영역(페이지)에 접근을 시도하면, 웹 서버는 클라이언트 인증을 요청합니다. 브라우저는 이에 대한 응답을 위하여 사용자에게 사용자 인증 정보 입력을 요청합니다. 브라우저가 입력 받은 인증을 위한 정보를 가지고 다시 페이지를 요청합니다. 인증이 성공적으로 수행되면 웹 페이지가 다운로드 됩니다.

- BASIC

- DIGEST

- Form

- HTTPS Client Certification

2.1 BASIC 인증

브라우저에서 다이얼로그로부터 입력 받은 ID/PWD base64로 인코드 하여 서버에 전달합니다. 암호화되지 않은 사용자 비밀번호가 그대로 전달되며 한번 로그인 후에 인증 정보가 브라우저의 Cache에 저장되어 있으므로 브라우저 종료 전에 로그아웃 방법 없습니다.

2.2 DIGEST 인증

브라우저에서 비밀번호의 digest(해쉬) 값을 전달합니다. 비밀번호가 전달되지 않으므로 BASIC 인증 보다 더 안전한 방법입니다. 하지만 톰켓에서는 서버에 비밀번호를 일반 텍스트 문자로 관리해야 합니다. 또한 BASIC 인증과 같이 브라우저 Cache 문제를 가지고 있습니다.

2.3 Form 인증

브라우저가 인증 프로세스에 직접적으로 관여하지 않습니다. 인증은 사용자가 작성한 Html From 페이지를 통하여 인증정보를 전달합니다. 다만 form action 속성 및 사용자 ID, 비밀 번호 입력 필드의 이름이 다음과 같은 규칙을 따르도록 작성하시면 됩니다.

j_security_check : <form> 태그의 action 속성값

j_username : 사용자 이름 입력 필드 태그의 name 속성

j_password : 비밀번호 입력 필드 태그의 name 속성

2.4 HTTPS Client Certification 인증

클라이언트 인증서를 이용하여 인증을 수행합니다.

3. Security Realm

웹 응용프로그램을 위한 Credential 저장소로 웹 어플리케이션 사용자 인증을 위하여 사용하는 사용자이름, 비밀번호 및 각 사용자와 관련된 역할(Role)리스트를 관리하는 데이터베이스입니다. RealmServlet 스팩에 정의된 표준 메커니즘이며, 표준 인터페이스이며 톰켓 5.0에는 다음과 같은 Credential이 구현되어 있습니다.

- File based, in-memory realm

- JDBC Realm

- JNDI-based Realm

- JAAS-based Realm

4. Configuration Authentication

보호되어야 하는 웹 페이지에 대한 접근 제한을 설정합니다. 설정은 WEB-INF 폴더에 있는 web.xml 파일에서 정의합니다.

다음은 웹 응용프로그램 전체에 대하여 user 라는 권한(Role)을 가진 사용자만 접근할 수 있도록 설정한 예 입니다. 사용자 인증을 위하여 사용한 방법은 FORM 인증 방법이고 “/login.jsp” 파일을 로그인 Form 페이지로 설정하고 있습니다. 여기서 realm-name Realm을 가리키는 이름이 아닙니다. 실제로 Realm과 관계가 업습니다. 다만 브라우저가 BASIC DIGEST 인증을 위하여 인증 창을 띄울 때 영역: ” 이라는 텍스트 문구에 보여지는 문자열입니다.

<web-app ...>

<security-constraint>

<web-resource-collection>

<web-resource-name>Entire Application</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<auth-constraint>

<role-name>user</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>FORM</auth-method>

<realm-name>Single Sign-on Example</realm-name>

<form-login-config>

<form-login-page>/login.jsp</form-login-page>

<form-error-page>/notAuthenticated.jsp</form-error-page>

</form-login-config>

</login-config>

5. Configuration Realm

Realmserver.xml 파일의 <Engine> 컨테이너 설정 내에서 정의하며 하나만 정의해야 합니다.

다음 예는 톰켓에서 제공하는 메모리기반 Realm을 설정한 것이며, 인증 관련 정보는 “$CATALINA_HOME/conf/tomcat-users.xml“ 파일에 설정합니다.

메모리기반 Realm의 단점은 수행 중에 변경할 수 없다는 것입니다. 예를 들어 어던 사용자의 권한을 변경하고자 한다면 xml파일을 편집하고 Tomcat을 다시 구동해야 합니다.

<Realm className="org.apache.catalina.realm.MemoryRealm" />

$CATALINA_HOME/conf/tomcat-users.xml :

<?xml version='1.0' encoding='utf-8'?>

<tomcat-users>

<role rolename="tomcat"/>

<role rolename="role1"/>

<role rolename="manager"/>

<role rolename="admin"/>

<user username="tomcat" password=" tomcat " roles="tomcat"/>

<user username="both" password=" tomcat " roles="tomcat,role1"/>

<user username="role1" password=" tomcat " roles="role1"/>

<user username="admin" password=" tomcat " roles="admin,manager"/>

</tomcat-users>

6. 사용자 인증정보 이용

접근제어가 필요한 페이지에 대하여 인증이 성공적으로 수행되면 Servlet JSP 페이지에서 HttpServletRequest 객체의 메소드를 이용하여 로그인한 사용자의 정보를 이용할 수 있습니다.

- public java.lang.String getRemoteUser()

로그인 시 사용한 사용자 로그인 ID를 조회합니다.

- public boolean isUserInRole(java.lang.Stringrole)

로그인한 사용자가 인자로 주어진 role에 해당하는 Role을 가지고 있는지 확인합니다.

- public java.security.Principal getUserPrincipal()

로그인한 사용자의 Principal을 조회합니다.

'Security' 카테고리의 다른 글

웹해킹 분석과 웹쉘 탐지 및 대응방법 2  (0) 2009.04.05
웹 해킹 서버 분석과 웹쉘 대응방법 1편  (0) 2009.04.05
centos5 geoip patch하기  (0) 2008.07.30
MySQL DB 보안(1)  (0) 2007.06.11
FreeBSD 보안 하드닝 Tip  (0) 2007.06.11
, .

centos5 geoip patch하기

Security 2008. 7. 30. 03:06

centos 5 용 geoip 패치 방법 및 커널 커스텀 rpm
간략버젼입니다.
참조에 있는 URL 들을 보시면 됩니다. 단지 기억하기 위한 한글버젼입니다.

참조:http://irdeal.tistory.com/5 CentOS 커널 rpm 빌드하기
위의 글의 원본이자 업데이트 본은
http://wiki.centos.org/HowTos/Custom_Kernel 입니다.

참조:http://www.debian-administration.org/articles/518 Country-based packet filtering with iptables

1. yum groupinstall "Development Tools"
2. yum install kernel-devel
3. yum install rpm-build rpm-libs

이정도로 개발툴은 대충 끝납니다.
커널소스rpm 이 깔렸는지 확인합니다.

/usr/src/redhat/SPECS 디렉에 가서 다음과 같이 실행합니다.
rpmbuild -bp --target=`uname -m` kernel.spec
그러면 /usr/src/redhat/BUILD 디렉토리에 커널소스가 풀리고 패치가 적용됩니다.

커널을 rpm 으로 만들기 위해서 일단 기존의 디렉토리들을 백업해둡니다. ( 패치 파일로 만들기 위해 )

그럼 이제 geoip 를 위해서 소스를 받아봅니다.
커널을 위한 p-o-m 패치와 iptables 를 새로 컴파일 해야합니다.
http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/ 여기서 p-o-m 을 받습니다.
http://ftp.netfilter.org/pub/iptables/ 여기서 iptables를 받습니다.

적절한 디렉토리에 둘다 소스를 풉니다.
p-o-m 을 먼저 깝니다. 디렉토리에 진입후에
KERNEL_DIR=< \
IPTABLES_DIR=< \
./runme --download
를 해줍니다. ( 이부분이 현재 바뀐 부분입니다. )
그러면 geoip등의 패치를 웹에서 받아서 패치 해줍니다.
( download 하지 않을 경우엔 geoip는 패치 안됩니다. )
위와같이 하고 --download 대신에 geoip 를 넣어서 geoip 를 패치해줍니다.

rpm용 커널의 설정파일을 복사합니다.
cd /usr/src/redhat/BUILD/kernel-버젼/linux-버젼
cp /usr/src/redhat/SOURCES/kernel-버젼-아키텍쳐.config .config

커널을 설정합니다.
make menuconfig
위의 부분에서 geoip 만 모듈로 해주었습니다.

패치파일을 만듭니다. diff 사용법은 검색하면 많이 나옵니다.

그리고 .config 파일의 제일 윗 부분에 다음과 같이 적습니다.
# i386 <-- 64비트가 아닌경우
# x86_64 <-- 64비트인 경우만

그리고 아까의 rpm 설정을 반대로 소스에 복사해줍니다.
cp /usr/src/redhat/BUILD/kernel-버젼/linux-버젼/.config /usr/src/redhat/SOURCES/kernel-버젼-아키텍쳐.config

spec 파일을 수정해줍니다.
/usr/src/redhat/SPECS/kernel.spec 파일을 수정해줍니다.
커널 버젼등의 수정은 알아서 하실것이고.
패치파일을 잘 등록합니다. -__-;;; ( 너무 무책임한가.. )
단 이때 spec에서 #define buildxen 0 로 해줍니다.
xen에는 p-o-m 이든 뭔가 안맞는거 같은데.. 필요가 없어서 고려 않해봤습니다.

rpmbuild -ba --target=`uname -m` kernel.spec

으로 빌드하면 됩니다.

출처 : http://kldp.org/node/82983

참고 : http://www.maxmind.com/download/geoip/database/

'Security' 카테고리의 다른 글

웹 해킹 서버 분석과 웹쉘 대응방법 1편  (0) 2009.04.05
Tomcat 보안 개요  (0) 2009.03.12
MySQL DB 보안(1)  (0) 2007.06.11
FreeBSD 보안 하드닝 Tip  (0) 2007.06.11
SSH 보안설정  (0) 2007.06.11
, .

MySQL DB 보안(1)

Security 2007. 6. 11. 10:06
MySQL DB 보안(1)
MySQL은 세계적으로 널리 쓰이는 가벼운 프리소프트웨어 데이터베이스(Free Software Database)이다. 정확하게 말하면 MySQL은 세계적으로 가장 대중적인 SQL이다. MySQL 말고라도 MSQL 같은 소규모 DB, 또는 ASP와 연동하여 쓰이는 MSSQL 등 많은 다른 SQL이 있긴 하지만 MySQL에는 프리라는 이점 때문에 다른 SQL들 보다 널리 사용되고 있다. 우선 MySQL은 Linux, Apache, PHP 등과 같이 오픈 소스를 지향하는 애플리케이션과 궁합이 잘 맞는다. 전 세계적으로 인터넷 상에서 가장 많은 비중을 차지하는 서버는 리눅스이고, 그 중 PHP와 MySQL의 연동은 리눅스 서버의 근간을 이루고 있다.

하지만 이런 이유로 해커에게 가장 많은 타깃이 되는 목표이기도 하다. 이제 MySQL의 기본 보안설정에 대해서 알아보는 시간을 갖도록 하자.

1. Root 계정 패스워드 점검
MySQL설치 시 root 이름을 갖는 계정이 생성되는데 슈퍼유저(superuser) 계정이다. 초기root 계정 패스워드는 비어 있어 누구라도 MySQL 서버에 root - 패스워드 없이 - 로 접속할 수 있다. 이를 이용하여 데이터베이스의 관리자 권한으로 접근이 가능하여 DB의 추가, 삭제, 변경 등의 모든 권한을 갖게 된다.

MySQL Clinet에서 root계정으로 패스워드 입력없이 접근이 되는지 확인한다.


[그림 1] 패스워드 입력없이 root 계정으로 접근


Mysql 이라는 데이터베이스에는 계정 정보를 저장하고 있는 user라는 테이블이 존재하며, 해당 테이블에서 사용자명과 패스워드 설정 유무를 확인할 수 있다.


[그림 2] user 테이블에서 패스워드 설정되어 있지 않는 root 계정 확인


UPDATE를 사용해서 user 테이블을 직접 수정할 수 있다. 아래의 UPDATE 명령문은 유저가 root인 계정의 패스워드를 password()암호화 함수를 이용하여 새로운 패스워드를 할당 하고 있으며, 하나의 패스워드를 두 개의 root 계정 모두에 동시에 할당하고 있다. UPDATE 명령문은 윈도우와 유닉스에 모두 적용된다.
FLUSH PRIVILEGES 명령은 mysql을 다시 시작 하지 않고 바로 권한을 적용 할 수가 있다.



2. 익명 사용자(Anonymous) 계정 패스워드 점검
MySQL 설치 시 root 계정 외에 두 개의 익명 사용자 계정이 생성되고, 사용자 이름이 비어 있는 상태로 만들어 진다. 익명 사용자 계정은 패스워드가 없으며, 따라서 누구라도 이 계정을 사용해서 MySQL서버에 접속할 수 있다. MySQL 5.x부터는 익명사용자가 생성되지 않는다.
유닉스에서는, 두 개 모두가 로컬 호스트에서 접속을 하기 위한 것으로 사용된다. 하나의 계정에 대해서는 localhost 의 호스트 이름을, 또는 다른 계정에 대해서는 실제 호스트 이름 또는 IP 번호를 지정함으로써 로컬 호스트로부터 접속이 이루어져야 한다. 이 계정들은 test 데이터 베이스 및 test_로 시작되는 다른 데이터 베이스를 위한 모든 권한을 가지고 있다.

MySQL Clinet에서 사용자 없이(anonymous사용자) 접근이 되는지 확인한다.


[그림 3] 계정 없이(anonymous사용자) MySQL에 접근


Mysql 라는 데이터베이스에는 계정정보를 저장하고 있는 user라는 테이블이 존재하며, 해당 테이블에서 사용자명과 패스워드 설정 유무를 확인할 수 있다.


[그림 4] mysql.user테이블에서 anonymous사용자 확인


익명 사용자 계정에 패스워드를 할당하기 위해서는, root로 서버에 접속을 한 다음에 SET PASSWORD 또는 UPDATE를 실행한다. 어느 경우에서든지, PASSWORD() 함수를 사용해서 패스워드를 암호화 하도록 한다.
UPDATE를 사용할 경우 Root로 서버에 접속을 한 다음에 UPDATE 명령문을 입력하여 적당한 user 테이블 레코드의 Password 컬럼에 값을 할당한다. 이 과정은 윈도우와 유닉스에서 모두 동일하다.



UPDATE를 사용해서 user 테이블에 직접 패스워드를 갱신한 다음에는, 서버가 FLUSH PRIVILEGES를 통해 Grant 테이블을 다시 읽어 오도록 해야 한다. 그렇게 하지 않으면, 서버를 재 구동 시키기 전까지 서버는 갱신된 내용을 알지 못하게 된다.

패스워드를 설정하는 방법 이외에 아래와 같이 유저를 삭제하는 방법도 있다.



3. USER 테이블 접근 권한 점검
MySQL에서 접근제어(Access Control)는 Grant tabales에 해당하는 User, db, host, tables_priv, columns_priv 테이블에 권한 정보를 저장하고 MySQL서버를 시작할 때 이 테이블에 있는 내용들을 메모리고 읽어들이고, 권한 변경설정 후에도 다시 한번 읽어들인다. 즉, 접근제어 결정은 GrantTable에 메모리 복사본을 기반으로 수행된다.

GrantTalbe중 user 테이블은 HOST, USER, PASSWORD라는 중요 정보를 저장하고 있고 이 테이블에는 사용자 권한 목록 및 사용자 패스워드의 해쉬값등을 포함하고 있다.
이런 중요한 테이블에 대해서는 일반사용자에 대한 접근제어가 이루어져야하며 Select 권한은 DBA(DataBase Administrators)만 사용할 수 있어야 한다.
만약, 웹과 연동되는 DB의 사용자가 USER테이블 접근권한이 있다면 웹과 연동되는 DB의 SQL인젝션 취약성이 있을 경우 DB의 계정 및 인증 정보가 유출될 수 있다.

다음과 같이 Mysql.user테이블에서 전체 DB사용자와 패스워드 해쉬값을 출력할 수 있다.


[그림 5] Mysql.user 테이블에서 DB사용자와 패스워드 출력


3.1 점검 방안

Mysql.user테이블에 대한 접근 권한 또는 Select권한(Select_priv)을 갖고 있는 사용자에 대해 점검한다. Show grants 명령문을 이용하여 각 사용자에게 부여된 권한을 살펴본 후 모든 DB에 접근권한이 있거나 MysqlDB에 접근권한이 있는 사용자들을 살펴본다.


[그림 6] Mysql.user 테이블에서 SELECT권한 확인



[그림 7] munnt계정에 대한 권한 점검


위의 결과는 munnt 사용자에게 모든 DB와 Table에 접근할 수 있는 모든 권한이 부여되어 있다.

① DBA가 아닌 일반사용자에 대해서 mysql.user(mysql 데이터베이스의 user 테이블)에 대한 모든 접근 권한을 제거한다.



또는 ② DBA가 아닌 일반사용자에 대해서 Select권한을 제거한다.



앞에서 설명한 것 이외에도 다음과 같이 mysql을 사용할 때 보안을 위해 알아 두어야 할 사항들이 있으며, 이 부분은 나중에 다시 자세하게 알아보는 기회를 갖도록 한다.

- 샘플 및 테스트 DB 점검
- MySQL 실행 유저 점검
- MySQL 히스토리(history) 파일 점검
- 원격 접근 점검
- MySQL 접속시 보안 방법
- FILE 권한이 승인된 사용자 점검
- 로깅 설정 점검
- GRANT tables에 접근 가능한 사용자 점검
- PROCESS 권한이 부여된 사용자 점검
- SSL(Secure Socket Layer) 설정 점검

[저자] 안랩코코넛 문성태

[출처] 안랩코코넛 SECU-LETTER 2007년 1월호

'Security' 카테고리의 다른 글

Tomcat 보안 개요  (0) 2009.03.12
centos5 geoip patch하기  (0) 2008.07.30
FreeBSD 보안 하드닝 Tip  (0) 2007.06.11
SSH 보안설정  (0) 2007.06.11
[솔라리스 강좌] 설정 변경과 시스템 보안 설정  (0) 2006.06.11
, .
FreeBSD 보안 하드닝 Tip
이번 호에는 인터넷에 무작위로 떠 돌고 있는 FreeBSD 시스템의 하드닝에 관하여 간단히 몇 가지를 정리해 보았습니다.
다른 OS와 다르게 많이 알려지지 않은 탓일까? 리눅스에 비해 발표되는 취약성이 많지 않은 편입니다. 시스템 하드닝을 하기 위해서 손 댈 곳도 많지 않습니다. BSD는 TCP/IP를 먼저 채택한 OS로 알려지며 어느 OS보다 네트워크가 튼실하다고 합니다. 야후가 Fore-End 서버를 BSD로 쓰고 있는 것을 보면 네트워크 하나만큼은 다른 OS에 비해 강력하다고 볼 수 있을 것입니다.

아래 내용들은 버전에 따라 내용이 다를 수 있습니다. 이점 유의 하시기 바랍니다.

1. Startup

1) 목적: 시스템 부팅 시에 시작되는 시작 프로그램에 의해 발생 할 수 있는 해킹 시도를 미연에 방지합니다.

2) 점검 방법
  • /etc/inetd.conf 파일 permission 점검
    inetd.conf내의 설정을 점검하여 불필요한 서비스나 보안상 취약한 서비스가 있는지 점검한다.
    Default 값은 모든 inetd.conf 설정은 disable 되어있다.
  • /etc/defaults/rc.conf내의 설정 상태를 확인 후 /etc/rc.conf의 설정을 비교하여 서비스를 점검한다.


3) 설정 방법
  • inetd를 사용할 경우 inetd.conf에서 사용하지 않는 서비스는 주석처리하고 process를 재 시작 한다.
  • /etc/default 디렉토리의 rc.conf는 수정하여서는 안 된다. 불필요한 서비스가 실행 중이라면 /etc 디렉토리에 있는 rc.conf에서 수정하여야 한다.



다음 표와 같이 설정 값을 확인하고 변경한다.



2. 패스워드 수준

1) 목적: 잘못 설정되어 있는 패스워드 설정을 점검하여 패스워드를 이용한 해킹 시도를 방지한다.

2) 점검 방법
- Password 생성 기본 암화화 방식은 md5로 설정되어 있다. Md5는 암호화 방식이 간단하여 쉽게 crack이 된다.
- Password 생성시 복잡성을 만족하는지 점검한다. 복잡성을 만족하지 않게 설정을 하면 사용자들이 간단하게 password를 설정함으로써 쉽게 crack을 당할 수 있다.
- Password 생성시 최소 암호 길이를 점검한다. 기본값은 5이다. 암호의 길이가 짧으면 crack하기가 쉬워 진다.

3) 설정 방법
- Password의 encryption 방식을 blowfish로 변경한다. Blowfish는 DES이후에 나온 암호화 방식으로 DES보다는 강력한 암호화 방식이다. Password를 생성할 때 복잡성을 만족시키려면 a-z, A-Z, 0-9, 특수문자 등을 포함하여 생성 할 수 있다.
- Password crack 툴들은 8자 단위로 암호를 crack한다. 그러므로, password의 최소 길이를 8자 이상으로 설정한다.
관련 내용을 /etc/login.conf에 설정 변경 또는 추가 한다.
:passwd_format=blf:\
:mixpasswordcase=true:\
:minpasswordlen=8:\

3. 네트워크 무결성

1) 목적: 네트워크 취약성을 이용하여 악용될 소지가 있는 파일과 설정 사항들을 점검한다.

2) 점검방법:
/etc/rc.conf
/etc/rc.conf의 내용을 수정하기 이전에 /etc/defaults/rc.conf 파일을 먼저 살펴 보아야 한다.
시스템에서 쉘 스크립트를 실행 시키는 순서는 /etc/defaults/rc.conf의 내용을 먼저 읽어 들인 다음 /etc/rc.conf 파일의 내용을 읽어 들인다. /etc/rc.conf파일의 내용은 쉘 스크립트 실행여부, 네트워크 설정 등이 포함되어 있다.
/etc/systel.conf
커널 파라멘터의 값을 확인하여 네트워크 파라미터의 설정 값에 취약점이 있는지 점검한다.

3) 설정 방법
/etc/rc.conf
다음과 같이 설정 값을 변경한다



/etc/sysctl.conf
네트워크 파라미터의 값을 수정한 후 시스템을 reboot 한다.



[ Reference ]

- FreeBSD handbook(보안 부분)
http://www.freebsd.org/doc/en_US.ISO8859-/books/handbook/security.html

- FreeBSD Security How-To

http://www.windowsecurity.com/whitepaper/unix_security/FreeBSD_Security_HowTo.html

[저자] 안랩코코넛 SM사업부 권혁철 대리

[출처] 안랩코코넛 SECU-LETTER 4월호

'Security' 카테고리의 다른 글

Tomcat 보안 개요  (0) 2009.03.12
centos5 geoip patch하기  (0) 2008.07.30
MySQL DB 보안(1)  (0) 2007.06.11
SSH 보안설정  (0) 2007.06.11
[솔라리스 강좌] 설정 변경과 시스템 보안 설정  (0) 2006.06.11
, .