All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Rituraj Buddhisagar <rituraj@vayana.com>
Cc: linux-audit@redhat.com
Subject: Re: Audisp-remote - connection refused.
Date: Tue, 03 Oct 2017 11:08:57 -0400	[thread overview]
Message-ID: <5167956.shIrRISz9z@x2> (raw)
In-Reply-To: <CAPHnQ1D8x1k6dqsa74g5w2_h31J1a0MbvE6wADTaUuqY=5PEQA@mail.gmail.com>

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@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@guslogs:/etc/audit#
> root@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@guslogs:/etc/audit#
> root@guslogs:/etc/audit# netstat -tanp | grep auditd
> root@guslogs:/etc/audit#
> root@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@guslogs:/etc/audit#
> root@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@guslogs:/etc/audit#
> 
> 
> Best Regards,
> Rituraj B
> 
> On Tue, Oct 3, 2017 at 6:14 PM, Steve Grubb <sgrubb@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@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@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@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



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

  parent reply	other threads:[~2017-10-03 15:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 18:55 Audisp-remote - connection refused Rituraj Buddhisagar
2017-10-02 19:51 ` Rituraj Buddhisagar
2017-10-02 21:58 ` Steve Grubb
2017-10-03  3:31   ` Rituraj Buddhisagar
2017-10-03 12:44     ` Steve Grubb
2017-10-03 12:52       ` Rituraj Buddhisagar
2017-10-03 12:58         ` Rituraj Buddhisagar
2017-10-03 15:08         ` Steve Grubb [this message]
2017-10-03 18:40           ` Rituraj Buddhisagar
2017-10-03 19:08             ` Rituraj Buddhisagar
2017-10-03 20:00               ` Rituraj Buddhisagar
2017-10-03 20:22                 ` Steve Grubb
2017-10-04 14:01                   ` Rituraj Buddhisagar
2017-10-04 15:19                     ` Steve Grubb
2017-10-04 16:02                       ` Rituraj Buddhisagar
2017-10-04 16:28                         ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5167956.shIrRISz9z@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=rituraj@vayana.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.