##############################################
Atomic Protector Troubleshooting Guide
##############################################


Can't connect to Web Console on port 30000
======================================

If you are unable to connect to the AED GUI this can be caused by any number of factors, the service could be down, a firewall could be blocking the connection, an issue exists with the client, etc. To assist with the process of troubleshooting these we have put together this check list. Please run through each step.


**Step 1: Ensure that you have your system configured for AED**

   * Please make sure your system meets and is configured correctly for all the pre-requistes for AED. These are documented on the AED Prerequisites page.


**Step 2: Check to make sure the AED GUI is installed**

   * Run the following command as root:
   
      .. code-block:: console
	  
         rpm -qa | grep asl-web
		 
		 
     If the AED GUI is installed, you will see output similar to the following:
	 
        .. code-block:: console
		
          [root@host ~]# rpm -qa | grep asl-web
                         asl-web-3.0.25-3.el5.art
						 
						 
   \
   
   * To install the AED GUI, run this command as root:
   
      .. code-block:: console
	  
         wget -q -O - https://www.atomicorp.com/installers/asl |sh

     This will re-run the installer. It is safe to run the installer over an existing installation. Please check the installer output for any error messages. Generally the web console is not installed either because it was not selected for installation, or because a core dependency for the web console is missing from your system. The most common problem is attempting to install AED on systems with third party un-supported versions of mysql. Please be sure to check the Supported Versions of Mysql pre-requisites page if the installer is reporting errors with mysql packages.
	 
	 
**Step 3: Check to make sure all AED updates are installed**

   * First, check to make sure a third party product has not excluded any AED packages from installation or upgrade. You will want to check your /etc/yum.conf file to make sure it is not globally excluding things incorrectly. For example, some third party products that do not use software and package management will try to exclude the systems PHP packages from install/upgrade by incorrectly using a regular expression such as "php*" or "*php*". Disable all excludes.

   * Run the following commands as root:
   
      .. code-block:: console
	  
         aum -u 
         yum -y upgrade --disableexcludes=all asl asl-web ossec-hids asl-php*
         asl -s -f 
		 
		 

**Step 4: Check that the GUI service is running**

   * Run the following command as root:
   
      .. code-block:: console
	  
         ps auwww | grep tortixd
		 
		 
   \
   
   * If the service is running, you should any output similar to this (details will vary for your system):

      .. code-block:: console
	  
         tortix    8732  0.0  0.0 220008   148 ?        S    May19   0:00 /var/asl/usr/sbin/tortixd
         root     11227  0.0  0.0  61252   836 pts/10   S+   15:24   0:00 grep tortixd
         root     16369  0.0  0.0 219872   200 ?        Ss   Apr15   2:21 /var/asl/usr/sbin/tortixd
         tortix   22527  0.0  0.0 220992   188 ?        S    May09   0:01 /var/asl/usr/sbin/tortixd
         tortix   22747  0.0  0.0 221232   188 ?        S    May09   0:01 /var/asl/usr/sbin/tortixd
         tortix   22819  0.0  0.0 221492   192 ?        S    May09   0:01 /var/asl/usr/sbin/tortixd
         tortix   24961  0.0  0.0 220988   192 ?        S    May09   0:00 /var/asl/usr/sbin/tortixd	   
		 
		 
     If you do not see the **"/var/asl/usr/sbin/tortixd"** process running as the tortix user, then the AED web console server is not running.

     If the service is not running, you can start it with this command:

        .. code-block:: console

           /etc/init.d/tortixd start


     If you are missing that file, and you installed AED you may have told the installer not to install the GUI or someone may have removed this part of AED from your system. Please re-run the AED installer and reinstall AED. The AED installer is the best tool for installing AED completely.


     If the GUI starts correctly you should see the following:

        .. code-block:: console

           Starting tortixd:          [  OK  ]
		   
		   
     If you get this error:
	 
        .. code-block:: console
		
           Address already in use: make_sock: could not bind to address 0.0.0.0:30000

     .. note:: Continue to step 5 below
	 
	 
     If you get any other message or error, please check to make sure your system is up to date by using yum to update your system. If you do not keep your system up to date you may need to install many updates that are not related to AED. We always recommend you keep up with your vendors updates as many of them fix critical security vulnerabilities and to check with your OS vendors and any third party vendors to ensure these updates will work with your OS and third party products. To upgrade your entire system you would run these commands as root:
	 
        .. code-block:: console
		
           yum upgrade
           asl -s -f
		   
		   
**Step 5: Make sure you dont have something else listening on port 30000**

   * Run the following command as root:
   
      .. code-block:: console
	  
         netstat -anp | grep tortixd | grep 30000

     \
	 
     You should see output like the following:
	 
        .. code-block:: console
		
           tcp 0 0 :::30000 :::* LISTEN 3547/tortixd

		   
     If you do not see the tortixd service listening on port 30000, and see something else listening on that port you will need to disable this other application. Please contact the vendor for that application for assistance with disabling their software.
	 
	 
     If you do see tortixd listening on port 30000, and you got this error in step 4:

        .. code-block:: console
		
           Address already in use: make_sock: could not bind to address [::]:30000

     Or this error:
	 
        .. code-block:: console
		
           Address already in use: make_sock: could not bind to address 0.0.0.0:30000

		   
     Restart the tortixd service by running these two commands as root:

        .. code-block:: console
		
           service tortixd stop
           killall -9 tortixd
		   
     Once the service has been stopped, start the service back again by running the following command:

        .. code-block:: console

           service tortixd start


**Step 6: Check your firewall rules**

   * If you are using any third party firewall management tools, uninstall them and if you can not uninstall them disable them. You will also want to make sure you do not have any pre-existing firewall rules on your system. This is the most common cause of firewall related issues: pre-existing firewall rules.

   \
   
   * Check your tortixd ACLs:

     If you have configured AED to limit access to specific IPs, check this file to ensure your current IP(s) are on the list of custom user defined allowed IPs:

        .. code-block:: console

           /etc/asl/firewall/tortixd-access-list


     If your IP address is not included in this list you will need to add it to the file. Then run this command as root:

        .. code-block:: console

           service asl-firewall restart


   \

   * Check to see if you have any firewall rules:

     Run the following command as root:

        .. code-block:: console

           iptables -L -n

     \

     If you see output like this:

        .. code-block:: console

           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


     The above means you have no firewall rules. The problem is not caused by the firewall on your server, continue to **Step 7**.


   \

   * Check to see if there are third-party firewall rules that are causing a conflict 

     By default AED will generate firewall rules that look like this:

        .. code-block:: console

           Chain INPUT (policy ACCEPT)
           target     prot opt source               destination         
           ASL-GEO-BLACKLIST  all  --  0.0.0.0/0            0.0.0.0/0           
           ASL-BLACKLIST  all  --  0.0.0.0/0            0.0.0.0/0           
           ASL-SMALLPACKETS  ah   --  0.0.0.0/0            0.0.0.0/0           length 0:35 
           ASL-SMALLPACKETS  esp  --  0.0.0.0/0            0.0.0.0/0           length 0:49 
           ASL-SMALLPACKETS  47   --  0.0.0.0/0            0.0.0.0/0           length 0:39 
           ASL-SMALLPACKETS  30   --  0.0.0.0/0            0.0.0.0/0           length 0:31 
           ASL-SMALLPACKETS  icmp --  0.0.0.0/0            0.0.0.0/0           length 0:27 
           ASL-SMALLPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           length 0:39 
           ASL-SMALLPACKETS  udp  --  0.0.0.0/0            0.0.0.0/0           length 0:27 
           ASL-BADPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp option=128 
           ASL-BADPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp option=64 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x37 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x2B 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x1A 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x0A 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x0D 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x1C 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x01 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x29/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x22/0x22 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x11/0x01 
           ASL-FRAGMENTS  all  -f  0.0.0.0/0            0.0.0.0/0           
           DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
           ASL-TORTIXD-ACL  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 state NEW 		
		   
     All rules in the INPUT chain should start with the word "AED", as in the example above, with the exception of the INVALID rule:

        .. code-block:: console

           DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID


   \

   * Check to make sure you don't have your servers IP addresses blocked in your firewall 

      .. note:: If you are using a third party firewall tool, you will need to check with the developers of that application to see if its blocking your servers IP. These instructions will only tell you if AED is currently blocking your servers IPs.

     Run this command script as the root user:

        .. code-block:: console

           for ip in `ifconfig -a | grep inet | awk -F: '{print $2}' | awk '{print $1}'`; do iptables -L -n |grep $ip | grep AED-ACTIVE-RESPONSE; done

     If you do not see any output then AED is not blocking your servers IPs.

     If you get an output similar to this:

        .. code-block:: console

           AED-ACTIVE-RESPONSE all -- 1.2.3.4 0.0.0.0/0

     When 1.2.3.4 is one of your servers IP addresses, then you have not whitelisted your servers IP address in AED.



   \

   * Check to see if there is any reason AED generated firewall rules that are causing a conflict

     The quickest way to detetermine if your AED firewall rules are causing an issue is to flush all your firewall rules:

        .. code-block:: console

           /etc/init.d/asl-firewall stop

     If your firewall rules are flushed, you should see this:

        .. code-block:: console

           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
		   
		   
     If you see anything other than this, you have some third party firewall management product that has modified your firewall rules, or policy defaults. Please contact the developers of this software for assistance removing it, and restoring your firewall policy defaults.
	 
     If you are now able to connect, you had a firewall rule problem. If an AED generated firewall rule caused this issue it will log this. Check your system logs for any AED generated firewall rules, and your IP address. Run this command as root, replacing 1.2.3.4 with your IP address.

        .. code-block:: console

           grep ASL /var/log/messages | grep 1.2.3.4

     \
		   
     If you do not see any log events then an AED generated rule has not caused this issue.
 
     \
 
     If you still can not connect, the problem is not caused by the firewall rules on your server, continue to step 7.

	
   \

   * Reset your firewall rules

     If you have been making modifications to your firewall with the AED firewall manager, you can reset your firewall rules to the defaults by running these commands as the root user (not via sudo):

        .. code-block:: console

           cp /etc/asl/firewall/running.fw /root
           rm /etc/asl/firewall/running.fw
           asl -s -f		
		   
		   
     If you can now connect, then you had configured a firewall rule or rules that were blocking you from accessing the web console.
	 
     If you still can not connect, the servers firewall is not the cause of your issue, continue to step 7.

     .. note:: You can restore your custom firewall rules, only if you used the commands above to clear your firewall rules by running these commands as the root user: 
	 
        .. code-block:: console
		
           cp /root/running.fw /etc/asl/firewall/running.fw
           asl -s -f 
		   
		   
**Step 7: Run up a snifer to make sure the problem is not upstream**

   .. note:: Make sure you set "eth0" below to the interface that has the IP address assigned to it that you are going to test. If you tell the sniffer to watch a different interface, you will not see the traffic.
   
   \

   * Sniffer Option 1: Wireshark 

      * If you do not have it already installed, this command may help you install it. You will want to run this command as root:

         .. code-block:: console

            yum -y install wireshark


        On some patforms, the command to run wireshark is "tethereal" on others it is "tshark". Please try both commands. If these do not work for you, please contact your OS vendor for assistance installing a sniffer on your system.

           .. code-block:: console

              tethereal -i eth0 port 30000


        If you do not have tethereal installed, please try these commands:

           .. code-block:: console

              yum install tethereal

        **OR**

           .. code-block:: console

              yum install wireshark


        If you can not install tetheral, see the "tcpdump" example that follows the tethereal example:

           .. code-block:: console

              Capturing on eth0
              0.000000 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=690440808 TSER=0 WS=7
              0.000055 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=491123062 TSER=690440808 WS=7
              0.047190 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=690440854 TSER=491123062
              0.048117 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [PSH, ACK] Seq=1 Ack=1 Win=5888 Len=114 TSV=690440855 TSER=491123062
              0.048149 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=1 Ack=115 Win=5888 Len=0 TSV=491123074 TSER=690440855
              0.403626 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=1 Ack=115 Win=5888 Len=1448 TSV=491123163 TSER=690440855
              0.403646 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [PSH, ACK] Seq=1449 Ack=115 Win=5888 Len=159 TSV=491123163 TSER=690440855
              0.452383 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [ACK] Seq=115 Ack=1449 Win=8832 Len=0 TSV=690441260 TSER=491123163
              0.454911 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [ACK] Seq=115 Ack=1608 Win=11648 Len=0 TSV=690441262 TSER=491123163
              0.455637 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [PSH, ACK] Seq=115 Ack=1608 Win=11648 Len=198 TSV=690441263 TSER=491123163
              0.455652 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=1608 Ack=313 Win=6912 Len=0 TSV=491123176 TSER=690441263
              0.457887 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [PSH, ACK] Seq=1608 Ack=313 Win=6912 Len=59 TSV=491123176 TSER=690441263
              0.508890 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [PSH, ACK] Seq=313 Ack=1667 Win=11648 Len=565 TSV=690441315 TSER=491123176
              0.547198 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=1667 Ack=878 Win=8064 Len=0 TSV=491123199 TSER=690441315
              1.895139 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=1667 Ack=878 Win=8064 Len=1448 TSV=491123535 TSER=690441315
              1.895160 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [PSH, ACK] Seq=3115 Ack=878 Win=8064 Len=1042 TSV=491123535 TSER=690441315
              1.947302 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [ACK] Seq=878 Ack=4157 Win=17536 Len=0 TSV=690442755 TSER=491123535
              1.947693 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [PSH, ACK] Seq=878 Ack=4157 Win=17536 Len=37 TSV=690442755 TSER=491123535
              1.947715 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [ACK] Seq=4157 Ack=915 Win=8064 Len=0 TSV=491123549 TSER=690442755
              1.948027 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [FIN, ACK] Seq=915 Ack=4157 Win=17536 Len=0 TSV=690442755 TSER=491123535
              1.949539 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [PSH, ACK] Seq=4157 Ack=916 Win=8064 Len=37 TSV=491123549 TSER=690442755
              1.949610 9.8.7.6 -> 1.2.3.4 TCP 30000 > 46910 [FIN, ACK] Seq=4194 Ack=916 Win=8064 Len=0 TSV=491123549 TSER=690442755
              1.997338 1.2.3.4 -> 9.8.7.6 TCP 46910 > 30000 [RST] Seq=916 Win=0 Len=0		   
			  
	
   \   
   
			  
   * Sniffer Option 2: tcpdump
   
      * If you do not have wireshark available for your platform, most OS vendors will include tcpdump by default. If tcpdump is not installed on your system, please run this command as root to install it:

         .. code-block:: console
		 
            yum -y install tcpdump


      \
	  
      * If this does not work for your OS, please contact your OS vendor for assistance installing a sniffer. tcpdump example:
	  
        If you have no problems upstream, you will see something like the following:
		
           .. code-block:: console
		   
              10:34:26.227472 IP 1.2.3.4.54405 > 9.8.7.6.30000: S 3615766533:3615766533(0) win 5840 <mss 1460,sackOK,timestamp 771590282 0,nop,wscale 7>
              10:34:26.227514 IP 9.8.7.6.30000 > 1.2.3.4.54405: S 1843855213:1843855213(0) ack 3615766534 win 5792 <mss 1460,sackOK,timestamp 511410428 771590282,nop,wscale 7>
              10:34:26.274981 IP 1.2.3.4.54405 > 9.8.7.6.30000: . ack 1 win 46 <nop,nop,timestamp 771590329 511410428>
              10:34:26.275774 IP 1.2.3.4.54405 > 9.8.7.6.30000: P 1:147(146) ack 1 win 46 <nop,nop,timestamp 771590330 511410428>
              10:34:26.275806 IP 9.8.7.6.30000 > 1.2.3.4.54405: . ack 147 win 54 <nop,nop,timestamp 511410440 771590330>
              10:34:26.276150 IP 9.8.7.6.30000 > 1.2.3.4.54405: P 1:139(138) ack 147 win 54 <nop,nop,timestamp 511410440 771590330>
              10:34:26.327459 IP 1.2.3.4.54405 > 9.8.7.6.30000: . ack 139 win 54 <nop,nop,timestamp 771590382 511410440>
              10:34:26.329933 IP 1.2.3.4.54405 > 9.8.7.6.30000: P 147:723(576) ack 139 win 54 <nop,nop,timestamp 771590383 511410440>
              10:34:26.369824 IP 9.8.7.6.30000 > 1.2.3.4.54405: . ack 723 win 63 <nop,nop,timestamp 511410464 771590383>
              10:34:26.518491 IP 9.8.7.6.30000 > 1.2.3.4.54405: . 139:1587(1448) ack 723 win 63 <nop,nop,timestamp 511410501 771590383>
              10:34:26.518514 IP 9.8.7.6.30000 > 1.2.3.4.54405: P 1587:2629(1042) ack 723 win 63 <nop,nop,timestamp 511410501 771590383>
              10:34:26.518619 IP 9.8.7.6.30000 > 1.2.3.4.54405: P 2629:2666(37) ack 723 win 63 <nop,nop,timestamp 511410501 771590383>
              10:34:26.518660 IP 9.8.7.6.30000 > 1.2.3.4.54405: F 2666:2666(0) ack 723 win 63 <nop,nop,timestamp 511410501 771590383>
              10:34:26.570119 IP 1.2.3.4.54405 > 9.8.7.6.30000: . ack 2629 win 100 <nop,nop,timestamp 771590625 511410501>
              10:34:26.570586 IP 1.2.3.4.54405 > 9.8.7.6.30000: P 723:760(37) ack 2667 win 100 <nop,nop,timestamp 771590625 511410501>
              10:34:26.570654 IP 9.8.7.6.30000 > 1.2.3.4.54405: . ack 760 win 63 <nop,nop,timestamp 511410514 771590625>
              10:34:26.570760 IP 1.2.3.4.54405 > 9.8.7.6.30000: R 760:760(0) ack 2667 win 100 <nop,nop,timestamp 771590625 511410501>
              10:34:26.617628 IP 1.2.3.4.54406 > 9.8.7.6.30000: S 3610239263:3610239263(0) win 5840 <mss 1460,sackOK,timestamp 771590673 0,nop,wscale 7>
              10:34:26.617660 IP 9.8.7.6.30000 > 1.2.3.4.54406: S 1858764235:1858764235(0) ack 3610239264 win 5792 <mss 1460,sackOK,timestamp 511410525 771590673,nop,wscale 7>
              10:34:26.660089 IP 1.2.3.4.54407 > 9.8.7.6.30000: S 3617695320:3617695320(0) win 5840 <mss 1460,sackOK,timestamp 771590715 0,nop,wscale 7>
              10:34:26.660111 IP 9.8.7.6.30000 > 1.2.3.4.54407: S 1850303361:1850303361(0) ack 3617695321 win 5792 <mss 1460,sackOK,timestamp 511410536 771590715,nop,wscale 7>
              10:34:26.664975 IP 1.2.3.4.54406 > 9.8.7.6.30000: . ack 1 win 46 <nop,nop,timestamp 771590719 511410525>

              (and a lot more)	


        If you dont see a packet exchange, the problem is not with your server - its upstream at some other firewall, or even on your desktop or with your home or office firewall.

        If you do see all of this, and still can't connect - you ARE connecting - check your browser to make sure its not breaking on the connection. For example, if you connect with "http" instead of "https", or you are connecting to the wrong port, port 3000 instead of 30000.			  
		
		
**Step 8: Check to make sure a third party product has not changed AED's permissions**

   * Check that the GUI's php's session path:
   
      .. code-block:: console
	  
         /var/asl/session
		 
		 
     is owned by 'root:apache' with permissions 770.


     The permissions and ownership should be:
	 
        .. code-block:: console
		
           drwxrwx--- 2 root apache


**Step 9: Check to make sure tortix is in the apache group**

   * Run this command as root:
   
      .. code-block:: console
	  
         grep ^apache: /etc/group | grep tortix

   \
   
   * If tortix is not in the group, you will get a blank response. For example:

      .. code-block:: console
	  
         [root@host]# grep ^apache: /etc/group | grep tortix


   \

   * If tortix is in the group, you will see a response similar to this one:

      .. code-block:: console

         [root@host]# grep ^apache: /etc/group | grep tortix


   * If none of this resolves your issue, please contact support.


---------

Not getting any emails from AED
===============================

If you not getting any emails from AED this can be cause by any number of factors, your mail server is down, your have spam filtering software that's blocking AED, you have firewall rules that are blocking the connection, etc. To assist with the process of troubleshooting these we have put together this check list. Please run through each step.

   .. note:: Run all of the commands in the steps below as root. Do NOT use sudo.


**Step 1: Ensure that you have your system configured for AED**

   * Please make sure your system meets and is configured correctly for all pre-requisites for AED.
   
   
**Step 2: Check to make sure the AED is installed**

   * Run the following command:
   
      .. code-block:: console
	  
         asl -v
		 
		 
   \
   
   * If AED is installed, you will see output similar to the following:
   
      .. code-block:: console
	  
         AED Version 3.2.15-33.el5.art: CentOS 5 (SUPPORTED) 

     
     If AED is not installed, you will see output similar to the following:
	 
        .. code-block:: console
		
           bash: asl: command not found...

		   
		   
**Step 3: Check to make sure all AED updates are installed**

   * First, check to make sure a third party product has not excluded any AED packages from installation or upgrade. You will want to check your /etc/yum.conf file to make sure it is not globally excluding things incorrectly. For example, some third party products that do not use software and package management will try to exclude the systems PHP packages from install/upgrade by incorrectly using a regular expression such as "php*" or "*php*". Disable all excludes.

   \
   
   * Run the following commands:
   
      .. code-block:: console
	  
         aum -uf
         asl -s -f 
		 
		 
		 
**Step 4: Check to make sure OSSEC is working correctly**

   * Run the following command:
   
      .. code-block:: console
	  
         ps auxwww | grep ossec
		 
		 
     You should see output similar to the following:
	 
        .. code-block:: console
		
           root      3192  0.0  0.0  50352   112 ?        S    Jun25   0:01 /var/ossec/bin/ossec-execd
           ossecm   19622  0.0  0.0  91360   668 ?        S    Aug04   0:10 /var/ossec/bin/ossec-dbd
           ossecm   19627  0.0  0.0  24520   352 ?        S    Aug04   0:04 /var/ossec/bin/ossec-maild
           ossec    19637  1.5  0.6  47176  6424 ?        S    Aug04 215:45 /var/ossec/bin/ossec-analysisd
           root     19641  0.0  0.0  38600   364 ?        S    Aug04   0:44 /var/ossec/bin/ossec-logcollector
           root     19652  0.1  1.7  99032 17852 ?        S    Aug04  26:48 /var/ossec/bin/ossec-syscheckd
           ossec    19654  0.0  0.0  61520   364 ?        S    Aug04   0:00 /var/ossec/bin/ossec-monitord		


   \

   * If everything is working correctly, you should see all of these processes running:

      * ossec-execd

      * ossec-dbd

      * ossec-maild

      * ossec-analysisd

      * ossec-logcollector

      * ossec-syscheckd

      * ossec-monitord


     If any of these processes are not running, please try running the following command:

        .. code-block:: console

           service ossec-hids restart


**Step 5: Ensure that you have OSSEC configured to send emails**

   * Ensure that you have these settings set to you email address, and that this email address is valid and that you server can resolve the domain.
   
   \
   
   * Check to ensure the domain resolves to a working mail server
   
     Check you server to ensure it can resolve the domain name, and that what is resolving to is the correct server. You can test to make sure the server can resolve the domain by running this command:
	 
        .. code-block:: console
		
           host -t mx yourdomain.com
		   
		   
     Replace "yourdomain.com" with the domain name you used in those settings. 
	 
     If your server can resolve the domain name you will see output similar to the following:
	 
        .. code-block:: console
		
           example.com mail is handled by 10 mail.example.com
		   
		   
     If your server can not resolve the domain name you will see output similar to the following:
	 
        .. code-block:: console
		
           example.com has no MX record
		   
		   
   \
   
   * Check to ensure your server can resolve the mail servers IP address
   
     Then check to make sure your server can resolve the mail servers IP address. You will need to ensure that this resolves to your server, by running the following command:

        .. code-block:: console

           nslookup mail.example.com

     And then you need to ensure that the IP address returned is the correct IP address to send mail to. If this is not correct, you will need to fix your DNS server(s) to return the correct IP address. 


**Step 6: Ensure that you have OSSEC configured to send emails**

   * Set the **OSSEC_NOTIFY** setting to "yes". 

   \

   * Set the **OSSEC_MAX_MSG** setting to 0. This will allow AED to send emails as alerts occur. 


**Step 7: Ensure that OSSEC is enabled**

   * Set **OSSEC_ENABLED** to "yes". 
   
   
**Step 8: Ensure that OSSEC is set to server mode**

   * OSSEC will only send emails if **OSSEC_MODE** is set to "server"
   
   
**Step 9: Ensure the SMTP server is correct**

   * Set **OSSEC_SMTP_SERVER** to 127.0.0.1
   
   \
   
   * Check to make sure you have a mail server running on that system. If you are using 127.0.0.1 as your mail server, you can run the following command as root to see if you have a mail server running on your local system:
   
      .. code-block:: console
	  
         netstat -an | grep LISTEN | grep :25
		 

     If you do not have a mail server running, please contact your mail server vendor. 

     If you do have a mail server running locally, and you can not connect to it, please proceed to Step 10 to check your firewall rules.


**Step 10: Check your firewall rules**

   * Check to see if you have any firewall rules by running the following command as root:

      .. code-block:: console

         iptables -L -n


     If you see output similar to the following 

        .. code-block:: console

           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


     You have no firewall rules and the problem is not caused by the firewall on your server. Proceed to **Step 11**


   \

   * Check to see if there are third-party firewall rules that are causing a conflict

     By default AED will generate firewall rules that look like the following:

        .. code-block:: console

           Chain INPUT (policy ACCEPT)
           target     prot opt source               destination         
           ASL-GEO-BLACKLIST  all  --  0.0.0.0/0            0.0.0.0/0           
           ASL-BLACKLIST  all  --  0.0.0.0/0            0.0.0.0/0           
           ASL-SMALLPACKETS  ah   --  0.0.0.0/0            0.0.0.0/0           length 0:35 
           ASL-SMALLPACKETS  esp  --  0.0.0.0/0            0.0.0.0/0           length 0:49 
           ASL-SMALLPACKETS  47   --  0.0.0.0/0            0.0.0.0/0           length 0:39 
           ASL-SMALLPACKETS  30   --  0.0.0.0/0            0.0.0.0/0           length 0:31 
           ASL-SMALLPACKETS  icmp --  0.0.0.0/0            0.0.0.0/0           length 0:27 
           ASL-SMALLPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           length 0:39 
           ASL-SMALLPACKETS  udp  --  0.0.0.0/0            0.0.0.0/0           length 0:27 
           AED-BADPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp option=128 
           AED-BADPACKETS  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp option=64 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x37 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x2B 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x1A 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x0A 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x0D 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x1C 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x01 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x29/0x29 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x22/0x22 
           ASL-PORTSCAN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x11/0x01 
           ASL-FRAGMENTS  all  -f  0.0.0.0/0            0.0.0.0/0           
           DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
           ASL-TORTIXD-ACL  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 state NEW 		


     All rules in the INPUT chain should start with the word "AED", as shown in the example above with the exception of the INVALID rule:
	 
        .. code-block:: console
		
           DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID

     If you see any rules that do not contain the word "AED", then you have some third party firewall management product that has modified your firewall rules, or policy defaults. 
	 
	 
   \
   
   * Check to make sure you don't have your server's IP address blocked in your firewall
   
     .. note:: If you are using a third party firewall tool, you will need to check with the developers of that application to see if its blocking your servers IP. These instructions will only tell you if AED is currently blocking your servers IPs.
	 
	 Run the following command script as the root user:
	 
        .. code-block:: console
		
           for ip in `ifconfig -a | grep inet | awk -F: '{print $2}' | awk '{print $1}'`; do iptables -L -n |grep $ip | grep AED-ACTIVE-RESPONSE; done


     If you do not see any output then AED is not blocking your server's IP address.
	 
     If you get an output similar to the following:
	 
        .. code-block:: console
		
           ASL-ACTIVE-RESPONSE all -- 1.2.3.4 0.0.0.0/0


     When 1.2.3.4 is one of your servers IP addresses, then you have not whitelisted your server's IP address in AED. 


   \

   * Check to see if there are any AED generated firewall rules that are causing a conflict

     The quickest way to determine if your AED firewall rules are causing an issue is to flush all your firewall rules:

        .. code-block:: console

           /etc/init.d/asl-firewall stop


     If your firewall rules are flushed, you should see output similar to the following:

        .. code-block:: console

           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		
		   
		   
     If you see anything other than the output above, you have some third party firewall management product that has modified your firewall rules, or policy default. Please contact the developers of the software for assistance.
	 
     If you are now able to connect, you had a firewall rule problem. If an AED generated firewall rule caused this issue it will log this. Check your system logs for any AED generated firewall rules, and your IP address. Run this command as root, replacing 1.2.3.4 with your IP address.
	 
        .. code-block:: console
		
           grep ASL /var/log/messages | grep 1.2.3.4
   
   
     If you do not see any log events then an AED generated rule has not caused this issue.
	 
   \
   
   * Reset your firewall rules
   
     If you have been making modifications to your firewall with the AED firewall manager, you can reset your firewall rules to the defaults by running the following commands as the root user:
	 
        .. code-block:: console
		
           cp /etc/asl/firewall/running.fw /root
           rm /etc/asl/firewall.fw /root
           asl -s -f 
		   
		   
     If you can now connect, then you had configured a firewall rule or rules that were blocking you from accessing the web console.
	 
     If you still cannot connect, the servers firewall is not the cause of this issue, continue to **Step 7**.
	 

   \
   
   * Send a test Email
   
     If you have confirmed your firewall rules are not blocking you from sending email to your mail server, send a test email using the method below:
	 
        Step 1: Connect to the mail server by running the following command (replacing 127.0.0.1 with your mail server):
		
           .. code-block:: console
		   
              telnet 127.0.0.1:25
			  
			  

        Step 2: The server will respond with something similar to the following

           .. code-block:: console

              Trying 127.0.0.1...
              Connected to localhost.localdomain (127.0.0.1).
              Escape character is '^]'.
              220 server ESMTP Postfix		   
			  
			  
        Step 3: Send the "helo" response with your server's name, for example
		
           .. code-block:: console
		   
              helo www.example.com
			  
			  
        Step 4: The server will respond with something similar to the following
		
           .. code-block:: console

              250 yourmailserversnames


        Step 5: Send the mail from line using the setting you configured with **OSSEC_FROM**

           .. code-block:: console

              mail from: someuser@atomicorp.com


        Step 6: If your mail server is setup correctly it will respond with the line below. If the server does not respond appropriately you will need to contact your mail server vendor.

           .. code-block:: console

              250.2.1.0 OK		   
			  

        Step 7: Send the rcpt to line using the setting you configured in the **OSSEC_EMAIL** setting
		
           .. code-block:: console
		   
              rcpt tp: someuser@atomicorp.com
			  
			  
        Step 8: If you mail server is setup correctly it will respond with the same line in **Step 6**.
		
		
        Step 9: Now send a quick test message, first type "data" and hit enter. 
		
		
        Step 10: If your mail server is setup correctly it will respond with a similar response as below:
		
           .. code-block:: console
		   
              354 End data with <CR><LF>.<CR><LF>


        Step 11: Type in a quick message and hit enter twice.
		
		
        Step 12: If your mail server is setup correctly it will respond with a similar response as below:
		
           .. code-block:: console
		   
              250 2.0.0 Ok: queued as D5D6A10D8112


**Step 11: Run a sniffer to make sure the problem is not upstream**

   .. note:: Make sure you set "eth0" below to the interface that has the IP address assigned to it that you are going to test. If you tell the sniffer to watch a different interface, you will not see the traffic.


   
   **Sniffer Option 1: wireshark**
   
      * If you do not already have it installed, this command may help you install it. Run the following command as root:

         .. code-block:: console
   
            yum -y install wireshark
			
			
      \
	  
      * On some patforms, the command to run wireshark is "tethereal" on others it is "tshark". Please try both commands. If these do not work for you, please contact your OS vendor for assistance installing a sniffer on your system.

      \
	  
      * Run the following command as root:
	  
         .. code-block:: console
		 
            tethereal -i eth0 port 25 and hostname 1.2.3.4

			
        You should see output similar to the following, if there are no problems with your upstream:
		
           .. code-block:: console
		   
              0.000000    127.0.0.1 -> 127.0.0.1    TCP 50849 > smtp [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=596718574 TSER=0 WS=8
              0.000014    127.0.0.1 -> 127.0.0.1    TCP smtp > 50849 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=596718574 TSER=596718574 WS=8
              0.000025    127.0.0.1 -> 127.0.0.1    TCP 50849 > smtp [ACK] Seq=1 Ack=1 Win=33024 Len=0 TSV=596718574 TSER=596718574
              0.176700    127.0.0.1 -> 127.0.0.1    SMTP S: 220 yourserversname ESMTP Postfix
              0.176713    127.0.0.1 -> 127.0.0.1    TCP 50849 > smtp [ACK] Seq=1 Ack=40 Win=33024 Len=0 TSV=596718751 TSER=596718751
			  
			  
			  
   **Sniffer Option 2: tcpdump**
   
      * If you do not have wireshark available on your platform, most OS vendors will include tcpdump by default.
	  
        If your OS does not have tcpdump installed by default, run the following command as root to install it:
		
           .. code-block:: console
		   
              yum install -y tcpdump

			  
      \
	  
      * Run the following command as root:
	  
         .. code-block:: console
		 
            tcpdump -i eth0 port 25 and hostname 1.2.3.4


      \
	  
      * If there are no problems with your upstream, then you should see output similar to the following:
	  
         .. code-block:: console
		 
            tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
            listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
            13:06:11.808773 IP 1.2.3.4.40930 > 9.8.7.6.smtp: S 3226807163:3226807163(0) win 32792 <mss 16396,sackOK,timestamp 597368964 0,nop,wscale 8>
            13:06:11.808790 IP 9.8.7.6..smtp > 1.2.3.4.40930: S 3784740604:3784740604(0) ack 3226807164 win 32768 <mss 16396,sackOK,timestamp 597368964 597368964,nop,wscale 8>
            13:06:11.808801 IP 1.2.3.4.40930 > 9.8.7.6..smtp: . ack 1 win 129 <nop,nop,timestamp 597368964 597368964>
            13:06:11.950623 IP 9.8.7.6..smtp > 1.2.3.4.40930: P 1:40(39) ack 1 win 128 <nop,nop,timestamp 597369106 597368964>
            13:06:11.950636 IP 1.2.3.4.40930 > 9.8.7.6..smtp: . ack 40 win 129 <nop,nop,timestamp 597369106 597369106>


            (and a lot more)

			
**Step 12: Packets not exchanging**

   * If you dont see a packet exchange, the problem is with the mail server itself. Either your mail server does not accept connections, is not running a mail server, you have an upstream firewall that is blocking you (if you are using a remote mailserver) or you have a network problem that is preventing you from connecting to your mail server. Please contact your mail server vendor for assistance with connections issues with your mailserver.

   \
   
   * If everything is working, and you have confirmed that your mail server is listening, and you can successfully send a test message, then check your mail servers logs. This means that AED is able to send email, and your mail server is just not sending it on your account. Please contact your mail server vendor for assistance with configuring your mail server to send email to your email account.

   \
   
   * If you require additional assistance with this issue, please send us the output of all these steps as we will need this information to assist you. Please do not contact us about issues concerning the correct configuration of your mail server. Please contact your mail server vendor for assistance with their products.
	   
	   
------------

AED Web Console Not Running
===========================

**Step 1: Check to make sure the Web Console is installed**

   * Run the following command as root:
   
      .. code-block:: console
	  
         rpm -qa | grep tortixd
		 
		 
     If you do not see the package installed, then you are missing components of AED. You should run "yum upgrade" and then run the following command:
	 
        .. code-block:: console
		
           wget -q -O - https://www.atomicorp.com/installers/asl |sh



**Step 2: Start the service**

   * Run the following command as root:
   
      .. code-block:: console
	  
         /etc/init.d/tortixd start
		 
		 

**Step 3: Follow the steps above in "Can't connect to Web Console on port 30000" to make sure your firewall and upstream (if any) are configured correctly**

  * You can also re-install the Web Console by running the following command:
  
     .. code-block:: console
	 
        yum reinstall asl-web
		
		
-------------

Empty Web Console
=================

An empty Web Console means that a third party application or user has misconfigured your AED directories to prevent tortixd from opening the files it needs to render the GUI.

   * Check the permissions on the following directory:

      .. code-block:: console
   
         /var/asl/session
	  
     The permissions on the directory above should be:
	 
        .. code-block:: console
		
           drwxrwx--- 2 root apache 4096 Jul 29 14:55 session


     In general, if a third party application or user changes these permissions AED may be able to fix this by running the following command:
	 
        .. code-block:: console
		 
           asl -s -f 
		   
		   
-------------

No Events in AED Web Console
============================

**Step 1: Test AED Web**

   * First check to make sure that AED Web is working. In the Recent Events tab of the Security Events window, set the level filter to 1 so you can see all events. By default AED Web is set to a higher level to filter out lower importance events and to only display attacks and highly supicious events by default. If the AED Web is showing lower level events, you may either not have any attacks or suspicious events to report, or you may have disabled or not installed all of AED protection components.
   
   
**Step 2: Check to make sure AED is up to date**

   * If you are running an older version of AED, please see the article on how to upgrade your AED subscription. 
   
   \
   
   * If you are running the most current version of AED, run the following commands as root:
   
      .. code-block:: console
	  
         /var/asl/bin/aum -u
         /var/asl/bin/asl -s -f
		 
		 
**Step 3: Verify that OSSEC is working correctly**

   * Run the following command as root:
   
      .. code-block:: console
	  
         ps auxwww | grep ossec
		 
		 
     You should see output similar to the following:
	 
        .. code-block:: console
		 
           root      3192  0.0  0.0  50352   112 ?        S    Jun25   0:01 /var/ossec/bin/ossec-execd
           ossecm   19622  0.0  0.0  91360   668 ?        S    Aug04   0:10 /var/ossec/bin/ossec-dbd
           ossecm   19627  0.0  0.0  24520   352 ?        S    Aug04   0:04 /var/ossec/bin/ossec-maild
           ossec    19637  1.5  0.6  47176  6424 ?        S    Aug04 215:45 /var/ossec/bin/ossec-analysisd
           root     19641  0.0  0.0  38600   364 ?        S    Aug04   0:44 /var/ossec/bin/ossec-logcollector
           root     19652  0.1  1.7  99032 17852 ?        S    Aug04  26:48 /var/ossec/bin/ossec-syscheckd
           ossec    19654  0.0  0.0  61520   364 ?        S    Aug04   0:00 /var/ossec/bin/ossec-monitord
	      
     If everything is working correctly, you should see all of these processes running.
	 
     If you do **NOT** see all of the processes above, run the following command as root:
	 
        .. code-block:: console
	
           service ossec-hids restart
		   
		   
**Step 4: Verify that MySQL is working correctly**

   * Check for errors in the MySQL **/var/log/mysqld.log** file. 
   
   \
   
   
   * Make sure MySQL is listening on the IP and port you configured. 
   
     A database that is not listening on a TCP port or the same port that you have configured AED to use. Check to make sure your MySQL server is listening on port 3306 on the IP address you have configured AED to use as its database server.

     Additionally, a database server that is listening on a different IP address from the one configured for AED can cause start up errors. Check to make sure your MySQL server is listening on port 3306 on the IP address you have configured AED to use as its database server.    
	 
     Check the **OSSEC_DATABASE_SERVER** setting and ensure that you can connect to port 3306 on that configured IP or hostname. 
	 
	 
   \
   
   * Check to make sure the tortix MySQL user permissions are correct
   
     If you are receiving an error during database setup similar to this:

        .. code-block:: console
		
           Loading AED Web database schema: ERROR 1227 (42000) at line 27: Access denied; you need the SUPER privilege for this operation
		   
     then you need to check the MySQL permissions. Specifically if the tortix mysql user is either unable to create or is unable to execute triggers, events will not show up properly.  
	 
     To resolve this, follow the steps below:

        Step 1: Log into MySQL as the tortix user by running the following command

           .. code-block:: console

              mysql -u `cat /etc/asl/config | grep OSSEC_DATABASE_USERNAME | awk -F\" '{print $2}'` -p`cat /etc/asl/config | grep OSSEC_DATABASE_PASSWORD | awk -F\" '{print $2}'`

        \
		
        Step 2: Once you have logged in, select the AED database by running the following command

           .. code-block:: console
		   
              use tortix;


        \

        Step 3: Verify that triggers have been created by running the following command

           .. code-block:: console

              SHOW TRIGGERS;


        \

        Step 4: If you do not see any triggers, then the tortix user does not have the correct permissions. Run the following commands

        .. note:: Log into MySQL as the root/admin user.
		   
           .. code-block:: console

              GRANT ALL ON tortix.* TO 'tortix'@'localhost' IDENTIFIED BY '[tortix user's password]';
              GRANT SUPER ON *.* TO 'tortix'@'localhost' IDENTIFIED BY '[tortix user's password]';		   
		

**Step 5: Run AED Web Validation**

   * After any of the corrective actions above, or if none of the above resolved the problem, run the following command:

      .. code-block:: console
	  
         /var/asl/bin/asl --web_validate


    Data will be available in AED Web on the first polling after correction, assuming any new events have come in, it does not require a refresh or relogging. Event data that existed prior to the correction will not be repaired.


-----------

AED Firewall
============

**FTP Not Working?**

   **Background:**

      * FTP is inarguably the most complex protocol in use on the Internet today, if not of all time, it is also the oldest. Unlike other protocols, like SMTP and HTTP, FTP does not work over one port or even a predictable set of ports. FTP uses lots and lots of ports, and it dynamically selects the ports it uses both of the client and server side randomly. You might think FTP just works over port 21, but that's only the tip of the iceberg. FTPs actual "data" connections happen on random dynamically allocated ports that are unique for each client and connection! Which makes it rather difficult for any firewall to support it. To support FTP all firewalls require what are sometimes referred to as "helper" modules. These modules actually look for what appears to be FTP traffic on all those random, dynamic ports. And they have to do this passively, and in real time because the FTP server has no way to tell the firewall what ports it needs open. The firewall has to figure this out as it goes: dynamically opening and closing the ports that FTP needs to use when you are using any firewall. Without these modules FTP simply doesn't work. And, because FTP is unlike any other protocol in use on your system, that's why its important that not only your firewall rules be setup correctly for FTP, but that both your firewall and your operating system support it, understand it and manage the connections in real time correctly. The article below provides a brief overview of how `FTP works`_ 
	  
      .. _FTP works: https://www.centos.org/docs/5/html/Virtual_Server_Administration/s2-ftp-proto-VSA.html


   \
   
   **Proposed Solutions:**
   
      1) **If you are using the AED Kernel** make sure you are not using a third party firewall. 
	  
        Make sure you have port 21 open by setting it in the AED setting **FW_INBOUND_TCP_SERVICES**

        If you are using **passive** mode, you will need to allow in the range of ports you configured your FTP server to use for passive mode.

        If you still cannot access FTP, check to ensure you are not using any third party firewalls, including upstream firewalls which could also be blocking on this port.

      \
		
      2) **If you are not using the AED Kernel** make sure you are not using a third party firewall.

        Check to make sure your third party kernel includes the standard Linux FTP tracking modules. If you do not have these modules, no Linux firewall will work. 

        You can check to see if you have the modules loaded by running the following command:

           .. code-block:: console

              ismod | grep ftp

        You should see the following two modules loaded:

           .. code-block:: console

              nf_nat_ftp
              nf_conntrack_ftp


        If they are **NOT** loaded, you can load them by running the following commands:

           .. code-block:: console
		   
              modprobe nf_nat_ftp
              modprobe nf_conntrack_ftp
			  
			  
      3) **If you are using encrypted FTP**

        As explained above, FTP is a very complex protocol that works over multiple dynamic ports. When Linux is configured to use its kernel based firewall, it uses special "helper" modules to detect the dynamic FTP data connections. These connections do not occur over port 21 or 20, they are dynamic "high ports" (e.g. ports 1024 and higher). The client and server negotiate these (either the client sends the ports it wishes to use, or the server sends the port it wishes to use). When this occurs over an encrypted FTP session Linux can not see this negotiation happen (because its encrypted), and therefore will not dynamically open and close these high port data connections between the server and the client. Therefore, you can not use encrypted FTP with any firewall without permanently opening a range of ports on your firewall(s) for your FTP server(s) to use, and configuring your FTP server(s) to only use that range of ports (this is called "passive mode"), instead of dynamic picking ports (also called "active mode"). Please contact your FTP vendor for assistance with configuring your FTP server. Once you have correctly configured your FTP server, then you will need to permanently open these ports by adding them to your AED firewall configuration.

        Keep in mind that FTP was never designed to be encrypted, and in some cases when faced with multiple firewalls (including desktop firewalls) it may simply not be possible to pass the FTP data connections through successfully. For this reason, other protocols were designed to replace to FTP, such as SSH and HTTPS.

        If you are using ProFTP, please follow the steps below:

           Step 1: Edit **/etc/prodftpd.conf** and add the line below
 
              .. code-block:: console

                 PassivePorts 60000 60500

				 
           Step 2: Add the ports above to the AED setting **FW_INBOUND_TCP_SERVICES**

           Step 3: Restart ProFTP by running the following command

              .. code-block:: console 

                 restart proftp


**Resetting Firewall to Defaults**

To reset the firewall to only those rules generated by AED, follow the steps below:

   1. iptables-save > /etc/asl/firewall/backup.fw

   2. service asl-firewall stop

   3. rm -f /etc/asl/firewall/asl_stop.fw

   4. service asl-firewall start


----------

Additional Information
======================

SELinux policies have been known to interfere with some RPM updates. This is because SELinux policies are not always adjusted for modern platforms and third party packages, such as control panels. This can manifest itself in mysterious failures in %pre and %post macros (confirmed on RHEL4).

AED includes an advanced RBAC system that is more powerful and easier to use than SELinux and we recommend you use that instead of SELinux. However, if you wish to use SELinux AED will work fine with SELinux, however you may need to adjust your SELinux policies for your systems specific needs.

If you encounter any issues with rpm installations on your system, and you are not qualified to adjust your SELinux policies that came with your operating system, we recommend you disable SELinux and use the built in RBAC in AED.

To disable SELinux set:

   .. code-block:: console
   
      selinux=0

in the kernel boot parameters for your system.

setenable 0, setenforce 0 and disabling SELinux with sysctl are not effective. To disable selinux you must boot with selinux=0 set for your system.  
