Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OSSEC Agent for pfSense ?

    Scheduled Pinned Locked Moved General pfSense Questions
    10 Posts 3 Posters 9.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wq6n
      last edited by

      I have a separate OSSEC server located on the internal Trusted network. I am trying to figure a way to take the syslog output of pfSense and present it to the OSSEC server. Right now the only thing that I can think of is; 1. Load the Syslog-NG package to the host FreeBSD OS, 2. Install the OSSEC-Agent on the host FreeBSD OS and once the OSSEC Agent is connected, 3. pipe the pfSense syslog output to the FreeBSD Syslog-NG server.

      I would like to take advantage of the OSSEC and Kibana features for the enclave.

      Any better ideas? Is there a built in OSSEC Agent for pfSense?

      Best Regards, WQ6N

      1 Reply Last reply Reply Quote 0
      • W
        wq6n
        last edited by

        Well through trial and error, I now have OSSEC-hids-2.8.3-client running on the host FreeBSD-10.3 OS. I had to make use of the Virtual FreeBSD-10.3 image and then tar up the results and port it over to the pfSense OS keeping the original file perms. Created user.group (ossec.ossec) and launched the client. Once the authentication key was applied all is well and the client is now talking to the server.

        Using the native syslogd, I am trying to point the ossec.conf file to a couple of logs (system.log and filter.log) and am not getting anything reporting on the ossec server. Mulling over syslog-ng as a possible solution. The main metric that I would like to collect is the blocked IP's and possibly the blocked ports as well.

        /usr/local/ossec-hids/bin/ossec-control status

        ossec-logcollector is running…
        ossec-syscheckd is running...
        ossec-agentd is running...
        ossec-execd is running...

        <localfile><log_format>syslog</log_format>
            <location>/var/log/system.log</location></localfile>

        <localfile><log_format>syslog</log_format>
            <location>/var/log/filter.log</location></localfile>

        1 Reply Last reply Reply Quote 0
        • W
          wq6n
          last edited by

          We, it appears that I have been living in the past with OSSEC. I still like the simple web enables gui interface for a real time pulse check. I have transitioned most of the enclave over to the ELK solution in which Filebeat is the main secure file shipper. I am reading that there is a Ports Filebeat for FreeBSD.

          For what it's worth, the ossec-control applications have stopped running. I and am now getting a Exec format error (ELF binary type "0" not known) and cannot start the ossec client.

          I have integrated Filebeat onto several workstations, which ship their logs to a central ELK server, and the two main things to install is 'GO' and 'Filebeat'. Reference - https://www.freshports.org/sysutils/filebeat/

          pfSense /var/log/ *.log are perfect for Filebeats prospector and once the Filebeat is running these logs could be easily forwarded to a centralized ELK server for Kibana display. I plan to work this using the FreeBSD-10.3 VM first.

          So the next step is to read up on the FreeBSD Ports and see how it can help me to install GO and Filebeats

          1 Reply Last reply Reply Quote 0
          • W
            wq6n
            last edited by

            https://www.freebsd.org/cgi/ports.cgi?query=filebeat&stype=all

            filebeat-1.2.3
                Collect logs locally and send to remote logstash
                Long description : Changes
                Maintained by: girgen@FreeBSD.org
                Requires: gettext-runtime-0.19.8.1, gmake-4.2.1_1, go-1.7.3,1, indexinfo-0.2.6

            1 Reply Last reply Reply Quote 0
            • W
              wq6n
              last edited by

              More trial and error. Mostly error. I have tried copying portsnap and the whole /usr/ports into the host OS and the end result is that the C compiler is not present (which is good for a production firewall). I then tried to use a completed compiled suite from the VM (both GO and Filebeat) and it will not open the syslog (system.log). So I am stuck until someone with the capability of loading GO and Filebeat onto a package or the native system. Close but no cigar.

              1 Reply Last reply Reply Quote 0
              • ?
                Guest
                last edited by

                There are two different IDS Systems between that we all can Chose the right one matching
                to the criteria´s. One is a net based IDS system likes Suricata or Snort and host based IDS
                systems such OSSec is.

                Because pfSense is a firewall device it should be sorted with snort or suricata and not with
                OSSec! So it might be making no sense to get a working agent on that system!

                I have a separate OSSEC server located on the internal Trusted network. I am trying to figure a way to take the syslog output of pfSense and present it to the OSSEC server.

                This might be not really running! You can easily set up a snort sensor or snort server
                to work fine together but you may be not able to mix it.

                Right now the only thing that I can think of is; 1. Load the Syslog-NG package to the host FreeBSD OS, 2. Install the OSSEC-Agent on the host FreeBSD OS and once the OSSEC Agent is connected, 3. pipe the pfSense syslog output to the FreeBSD Syslog-NG server.

                Let it be!

                I would like to take advantage of the OSSEC and Kibana features for the enclave.

                You should better set up some Snort sensors and one Snort Server for the net based IDS part and
                OSSec agents on the PCs, Servers, NAS and SAN devices and terminate them to the OSSec server.

                Any better ideas? Is there a built in OSSEC Agent for pfSense?

                Set up Snort or Suricata on pfSense and then set up OSSec agents and one OSSec server.
                If available it might be also a good thing to set up an LDAP and Radius Server for the wired
                and wireless devices to secure them better. (FreeRadius & OpenLDAP)

                Older hardware can be often turned into useful new devices such;

                • ALIX hardware for TclMon
                • APU hardware for OSSec server
                • Jetway boards for CentOS and UBNT WiFi Controller
                • Avoton based hardware for Snort or Suricata server
                • Rangeley based hardware for PRTG and/or Nagios2 servers
                • Old PC / Server hardware CentOS with OpenLDAP & Radius Sever
                  (for securing wired and wireless devices)

                Or a smaller server that holds many of them inside of a VM.

                1 Reply Last reply Reply Quote 0
                • E
                  eponymous
                  last edited by

                  @BlueKobold:

                  There are two different IDS Systems between that we all can Chose the right one matching
                  to the criteria´s. One is a net based IDS system likes Suricata or Snort and host based IDS
                  systems such OSSec is.

                  Because pfSense is a firewall device it should be sorted with snort or suricata and not with
                  OSSec! So it might be making no sense to get a working agent on that system!

                  I'm not sure I agree with that. pfSense at the end of the day, can be seen as an operating system running on a box connected to possibly an un-trusted network and may have SSH access.

                  What are y our reasons for having a NIDS protecting the network overall and not a HIDS protecting the box itself?

                  1 Reply Last reply Reply Quote 0
                  • ?
                    Guest
                    last edited by

                    I'm not sure I agree with that. pfSense at the end of the day, can be seen as an operating system running on a box connected to possibly an un-trusted network and may have SSH access.

                    This doesn't matter, all devices that will be pushing and/or transporting network traffic
                    such as switches, routers or firewalls will do should be monitored by NIDS systems and
                    Server and Desktop OS should be observed with HIDS as pure being an OS.

                    What are y our reasons for having a NIDS protecting the network overall and not a HIDS protecting the box itself?

                    pfSense is a firewall and this might be mostly a routing device at the WAN region or at
                    the network edge and there fore it  should be observed by a NIDS and not by a HIDS.

                    Only my personal choice and meaning of that.

                    And for the internal IDS integrated solution it might be the best to take something
                    likes Snort or Suricata for that function.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eponymous
                      last edited by

                      You make an interesting argument - and I'm not saying you're wrong.

                      However, your definition of a "router" vs a "server" seems at odds.

                      For example: what is the difference between a pfSense device running an OpenSSH endpoint vs a server running the same thing?

                      How do you make the judgement in this case as to which device warrants an OSSEC agent?

                      1 Reply Last reply Reply Quote 0
                      • ?
                        Guest
                        last edited by

                        You make an interesting argument - and I'm not saying you're wrong.

                        It is not only an argument, this is more pending on the circumstance that this both
                        IDS systems are doing not the same thing!!!
                        One is watching and sniffing in the network or the network traffic it self and the other
                        one is watching on the host OS of an Server, PC or other devices watching their registry,
                        file system or other elementary or urgent points in that OS.

                        However, your definition of a "router" vs a "server" seems at odds.

                        What here should be better matching is perhaps something such as TripWire or something
                        else similar to that but not a Host IDS (HIDS). One thing is OS related and the other one is
                        network related or pointed. The Server has an OS that is perhaps hardened the firewall or
                        router OS (firmware) must be hardened.

                        For example: what is the difference between a pfSense device running an OpenSSH endpoint vs a server running the same thing?

                        pfSense is a firewall distribution (but here working likes a firmware of an network device) and let
                        us say CentOS & SoftEtherVPN are an OS & Software. Their fore what you are asking for should be
                        matching more well this software or perhaps able to realize combined installed on an appliance;

                        • fail2ban
                        • DenyHost
                        • TripWire

                        How do you make the judgement in this case as to which device warrants an OSSEC agent?

                        Its not me, you should perhaps read the statements and jobs that the software coder where telling
                        their clients and perhaps too you could read about the differences NIDS and HIDS.
                        OSSec getting started

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.