TCP wrapper의 log가 어디에?

[bong-seok kim]

안녕하세요

많이 시원해줫져..

tcp wrapper가 꼭 필요해서 사용하는데

혹시 log파일이 어디 쌓이는지

아니면 어떻게 하면 쌓을수 있나여..

그러니 hosts.allow에 허가되지 않은 사용자가 접근햇을시

그 사용자의 ip,정보가 어디에 쌓인다던데여?



어떻게 알수 있는 방법 없나여??

누가 접근햇는지...

그래야 그유저를 allow를 하던지 찾던지 할려구요

부탁합니다.

수고하세요

[고광태]

아래내용을 참조하시면 될것 같네요..



http://hpux.connect.org.uk/hppd/hpux/Networking/Admin/tcp_wrappers-7.6/readme.html



위사이트에 내용을 참조하세요..자세하게 설명이 되어있네요~



3.1 - How it works

------------------



Almost every application of the TCP/IP protocols is based on a client-

server model. For example, when a user invokes the telnet command to

connect to one of your systems, a telnet server process is executed on

the target host. The telnet server process connects the user to a login

process. A few examples of client and server programs are shown in the

table below:



client server application

--------------------------------

telnet telnetd remote login

ftp ftpd file transfer

finger fingerd show users



The usual approach is to run one single daemon process that waits for

all kinds of incoming network connections. Whenever a connection is

established, this daemon (usually called inetd) runs the appropriate

server program and goes back to sleep, waiting for other connections.



The wrapper programs rely on a simple, but powerful mechanism. Instead

of directly running the desired server program, the inetd is tricked

into running a small wrapper program. The wrapper logs the client host

name or address and performs some additional checks. When all is well,

the wrapper executes the desired server program and goes away.



The wrapper programs have no interaction with the client user (or with

the client process). Nor do the wrappers interact with the server

application. This has two major advantages: 1) the wrappers are

application-independent, so that the same program can protect many

kinds of network services; 2) no interaction also means that the

wrappers are invisible from outside (at least for authorized users).



Another important property is that the wrapper programs are active only

when the initial contact between client and server is established. Once

a wrapper has done its work there is no overhead on the client-server

conversation.



The simple mechanism has one major drawback: the wrappers go away after

the initial contact between client and server processes, so the

wrappers are of little use with network daemons that service more than

one client. The wrappers would only see the first client attempt to

contact such a server. The NFS mount daemon is a typical example of a

daemon that services requests from multiple clients. See the section on

related software for ways to deal with such server programs.



There are two ways to use the wrapper programs:



1) The easy way: move network daemons to some other directory and fill

the resulting holes with copies of the wrapper programs. This

approach involves no changes to system configuration files, so there

is very little risk of breaking things.



2) The advanced way: leave the network daemons alone and modify the

inetd configuration file. For example, an entry such as:



tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot



When a tftp request arrives, inetd will run the wrapper program

(tcpd) with a process name `in.tftpd'. This is the name that the

wrapper will use when logging the request and when scanning the

optional access control tables. `in.tftpd' is also the name of the

server program that the wrapper will attempt to run when all is

well. Any arguments (`-s /tftpboot' in this particular example) are

transparently passed on to the server program.



For an account of the history of the wrapper programs, with real-life

examples, see the section below on related documents.



3.2 - Where the logging information goes

----------------------------------------



The wrapper programs send their logging information to the syslog

daemon (syslogd). The disposition of the wrapper logs is determined by

the syslog configuration file (usually /etc/syslog.conf). Messages are

written to files, to the console, or are forwarded to a @loghost. Some

syslogd versions can even forward messages down a |pipeline.



Older syslog implementations (still found on Ultrix systems) only

support priority levels ranging from 9 (debug-level messages) to 0

(alerts). All logging information of the specified priority level or

more urgent is written to the same destination. In the syslog.conf

file, priority levels are specified in numerical form. For example,



8/usr/spool/mqueue/syslog



causes all messages with priority 8 (informational messages), and

anything that is more urgent, to be appended to the file

/usr/spool/mqueue/syslog.



Newer syslog implementations support message classes in addition to

priority levels. Examples of message classes are: mail, daemon, auth

and news. In the syslog.conf file, priority levels are specified with

symbolic names: debug, info, notice, ..., emerg. For example,



mail.debug /var/log/syslog



causes all messages of class mail with priority debug (or more urgent)

to be appended to the /var/log/syslog file.



By default, the wrapper logs go to the same place as the transaction

logs of the sendmail daemon. The disposition can be changed by editing

the Makefile and/or the syslog.conf file. Send a `kill -HUP' to the

syslogd after changing its configuration file. Remember that syslogd,

just like sendmail, insists on one or more TABs between the left-hand

side and the right-hand side expressions in its configuration file.



Solaris 2.x note: the syslog daemon depends on the m4 macro processor.

The m4 program is installed as part of the software developer packages.



Trouble shooting note: when the syslogging does not work as expected,

run the program by hand (`syslogd -d') and see what really happens.

[bong-seok kim]

고광태님..

그내용을 봐도 어떻게 해야 되는지 잘 안나와있는데여..

HP-UX에서 syslog.conf에 뭘 등록하라는 얘긴가여?

[고광태]

제가 보기에 syslog.conf 에 등록해서 syslog.log에서 보는 방식이 맞을것 같네요

[bong-seok kim]

네 그건 아는데요..

syslog.conf에 어떻게 등록해야 한다는건가여?

번거럽게 해서 죄송하네여>