Audisp-remote - connection refused.

Steve Grubb sgrubb at redhat.com
Tue Oct 3 15:08:57 UTC 2017


On Tuesday, October 3, 2017 8:52:48 AM EDT Rituraj Buddhisagar wrote:
> Hi Steve,
> 
> I did check IPtables and I am not having any rules in there. I have allowed
> the connections in /etc/hosts.allow. But then I do not see auditd listening
> on port 60.
> It just shows "ESSTABLISHED" connection on the aggregating server - which
> is itself!

You should not enable audisp-remote on the aggregating server. Auditd handles 
incoming connections itself.

-Steve

> root at guslogs:/etc/audit# lsof -i :60
> COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> audisp-re 2146 root    3u  IPv4  20368      0t0  TCP 192.168.103.7:60->
> 192.168.103.7:60 (ESTABLISHED)
> root at guslogs:/etc/audit#
> root at guslogs:/etc/audit# netstat -pan | grep 60
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
>      1260/sshd
> tcp    10491   1360 192.168.103.7:60        192.168.103.7:60
>  ESTABLISHED 2146/audisp-remote
> tcp6       0      0 :::22                   :::*                    LISTEN
>      1260/sshd
> unix  2      [ ACC ]     STREAM     LISTENING     16055    1925/0
>    /tmp/ssh-h0brbTMA4a/agent.1925
> unix  3      [ ]         STREAM     CONNECTED     13777    1260/sshd
> 
> unix  2      [ ]         DGRAM                    17760    1897/systemd
> 
> unix  3      [ ]         STREAM     CONNECTED     16036    1897/systemd
> 
> unix  2      [ ]         DGRAM                    20360    2136/auditd
> 
> unix  3      [ ]         STREAM     CONNECTED     13260    1/init
>    /run/systemd/journal/stdout
> root at guslogs:/etc/audit#
> root at guslogs:/etc/audit# netstat -tanp | grep auditd
> root at guslogs:/etc/audit#
> root at guslogs:/etc/audit# iptables -L
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> root at guslogs:/etc/audit#
> root at guslogs:/etc/audit# cat /etc/hosts.allow
> # /etc/hosts.allow: list of hosts that are allowed to access the system.
> #                   See the manual pages hosts_access(5) and
> hosts_options(5).
> #
> # Example:    ALL: LOCAL @some_netgroup
> #             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
> #
> # If you're going to protect the portmapper use the name "rpcbind" for the
> # daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
> #
> 
> ALL: ALL
> root at guslogs:/etc/audit#
> 
> 
> Best Regards,
> Rituraj B
> 
> On Tue, Oct 3, 2017 at 6:14 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Monday, October 2, 2017 11:31:15 PM EDT Rituraj Buddhisagar wrote:
> > > P
> > > ​lease see inline-
> > > 
> > > regards
> > > ​
> > > 
> > > On Tue, Oct 3, 2017 at 3:28 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > > On Monday, October 2, 2017 2:55:51 PM EDT Rituraj Buddhisagar wrote:
> > > > > Hi
> > > > > 
> > > > > I tried my best to configure the audisp-remote.
> > > > > I am getting below error on the client machine in /var/log/syslog.
> > > > > 
> > > > > Oct  2 14:41:15 xxxxxx audisp-remote: Error connecting to
> > 
> > 192.168.103.7:
> > > > > Connection refused
> > > > 
> > > > On the server, what do you get for:
> > > > 
> > > > ausearch --start recent -m DAEMON_ACCEPT -i
> > > > 
> > > > The server side records some information about why it did not allow a
> > > > connection.
> > > 
> > > ​I dont see any info in here.
> > > 
> > > # ausearch --start recent -m DAEMON_ACCEPT -i
> > > <no matches>
> > 
> > Then its not connecting at all. Maybe your firewall is blocking it. Maybe
> > selinux is blocking it? Once auditd sees its socket is readable, it calls
> > accept(2) and there is no path through the code that doesn't log an event
> > with
> > a reason. Every possible failure logs a distinct reason why the connection
> > failed.
> > 
> > > I tried without --start & -i options as well.
> > 
> > --start today if you didn't connect within 10 minutes of running the
> > command.
> > 
> > > But when I do a tcpdump on central server, I do see requests coming in.
> > 
> > (I
> > 
> > > changed port to 60).
> > > # tcpdump -i eth1 '( port 60 )'
> > > 08:53:56.597946 IP gusm1.60 > 192.168.103.7.60: Flags [S], seq
> > 
> > 4076269451,
> > 
> > > win 29200, options [mss 1460,sackOK,TS val 207316 ecr 0,nop,wscale 7],
> > > length 0
> > > 08:53:56.597980 IP 192.168.103.7.60 > gusm1.60: Flags [R.], seq 0, ack
> > > 4076269452, win 0, length 0
> > > 08:53:56.598843 IP gusm1.60 > 192.168.103.7.60: Flags [S], seq
> > 
> > 4076287474,
> > 
> > > win 29200, options [mss 1460,sackOK,TS val 207316 ecr 0,nop,wscale 7],
> > > length 0
> > > 08:53:56.598858 IP 192.168.103.7.60 > gusm1.60: Flags [R.], seq 0, ack
> > > 18024, win 0, length 0
> > > 08:53:56.599164 IP gusm1.60 > 192.168.103.7.60: Flags [S], seq
> > 
> > 4076300652,
> > 
> > > win 29200, options [mss 1460,sackOK,TS val 207316 ecr 0,nop,wscale 7],
> > > length 0
> > > 08:53:56.599175 IP 192.168.103.7.60 > gusm1.60: Flags [R.], seq 0, ack
> > > 31202, win 0, length 0
> > > 08:53:56.599657 IP gusm1.60 > 192.168.103.7.60: Flags [S], seq
> > 
> > 4076306151,
> > 
> > > win 29200, options [mss 1460,sackOK,TS val 207316 ecr 0,nop,wscale 7],
> > > length 0
> > > 
> > > I think the service is only listening locally and not for remote
> > > connections?
> > 
> > It opens a socket on all addresses.
> > # netstat -tanp | grep auditd
> > tcp        0      0 0.0.0.0:60              0.0.0.0:*               LISTEN
> > 893/auditd
> > 
> > > root at logs:/etc/audit# lsof -i :60
> > > COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> > > audisp-re 1713 root    3u  IPv4  17433      0t0  TCP 192.168.103.7:60->
> > > 192.168.103.7:60 (ESTABLISHED)
> > > 
> > > 
> > > How do I see that I am using libwrap?
> > 
> > It should have a config line in auditd.conf. If you do not, it defaults to
> > yes. That means it looks in /etc/hosts.allow and hosts.deny to decide.
> > Odds
> > are you put nothing there and the connection proceeds. If I were to guess,
> > I'd
> > say iptables is blocking your connection.
> > 
> > > I have enable_krb5=no in the
> > > auditd.conf on the aggregative server.
> > 
> > Good. Cause doing a krb5 connection without setting that up will cause it
> > to
> > fail also. I'd bet on iptables being the problem.
> > 
> > -Steve
> > 
> > > > > 192.168.103.7 is the IP address of the central log server.
> > > > > 
> > > > > Notes: My settings are below:
> > > > > 
> > > > > on server as well on client:
> > > > > /etc/audisp/audisp-remote
> > > > > 
> > > > > remote_server = 192.168.103.7
> > > > > port = 6999
> > > > > local_port = 6999
> > > > > transport = tcp
> > > > > queue_file = /var/spool/audit/remote.log
> > > > > mode = immediate
> > > > > queue_depth = 2048
> > > > > format = ascii
> > > > > network_retry_time = 100
> > > > 
> > > > This is probably not your problem but managed is the normal setting
> > > > for
> > > > format. And do you have enable_krb5 set to no?
> > > > 
> > > > > I have enabled name_format=HOSTNAME only in one place (in
> > > > > /etc/audisp/audispd.conf - and not in /etc/audit/auditd.conf
> > > > > 
> > > > > entries in auditd.conf:
> > > > > 
> > > > > rtcp_listen_port = 6999
> > > > > tcp_listen_queue = 5
> > > > > tcp_max_per_addr = 10
> > > > > tcp_client_ports = 0-65535
> > > > > tcp_client_max_idle = 0
> > > > 
> > > > What do you have for use_libwrap and enable_krb5?
> > > > 
> > > > The ausearcn info from the aggregating server should tell the reason
> > 
> > why
> > 
> > > > the
> > > > connection is rejected.
> > > > 
> > > > -Steve
> > > > 
> > > > > I see the server is listening on the port 6999 as below but its not
> > > > > accepting client request.
> > > > > root at logs:/etc# lsof -i :6999
> > > > > COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> > > > > audisp-re 9091 root    3u  IPv4  33671      0t0  TCP
> > 
> > 192.168.103.7:6999
> > 
> > > > ->
> > > > 
> > > > > 192.168.103.7:6999 (ESTABLISHED)
> > > > > 
> > > > > 
> > > > > 
> > > > > Best Regards,
> > > > > Rituraj B






More information about the Linux-audit mailing list