Critical System Protection

Issue 1

I'd like to know how to do I prevent FTP access /  Telnet Access on UNIX / AIX servers? Apparently there are some special configurations needed for SCSP prevention to work on UNIX servers as mentioned in the release here :

On UNIX operating systems, the inetd daemon handles the initial network
connection of some services, such as telnet, ftp, and rlogin, before the services
are started. In the IPS policies, you can control the network connections for such
services only by using the inetd pset. You cannot control the network connections
from the service’s own pset. By default, the inbound network rules for the inetd
pset allows connections to the following ports: ftp (21), lp (515), telnet (23),
unix-rexec (512), unix-rlogin (513), unix-rsh (514), and tftp (69).

Thanks.

Update 4/28/2012 - Issue solved.

Solution - We managed to solve this by going into Daemon Options >> Inet Daemon >> Advanced Options >> Network Controls >> Inbound.

We place Telnet and FTP into this hence this work.

Issue 2 (Persistent Red Flag Eventually Deteriorates Agent State to Offline)

We have discovered that a red flag issue happens after IPS is enabled and eventually deteriorates the Agent state to Offline. We have gotten full rights for the system and yet the red flag still appears. This red flag only shows up when we attempt to apply IPS policies to this particular server, whereas IDS policies work fine.

Everytime we reboot the server, the flag goes away. Obviously this is not a solution as we can't expect the customer to reboot everytime a new policy is being deployed. So basically what happens is:

1) Reboot server (No Flag)

2) Apply IPS Policy with the "Disable prevention" option checked (Flag appears)

3) Refresh a couple of times (Flag disappears)

4) Apply IPS policy with the "Disable prevention" option UNchecked (Flag appears)

5) Refresh multiple times (Flag remains)

6) Apply any further IPS policies with or without prevention (Flag remains)

So it seems that we have an issue with Prevention-enabled IPS policies. We have tried the same steps with a different server but it worked perfectly fine (both running on AIX6.1)

You can use the firewall component of SCSP to block both inbound and outbound traffic.  This is how most people take care of network based issues instead of blocking services/daemons.

Hi Chuck,

Thanks for the tip. However I'd like to know where do I configure the firewall component of SCSP? Is it by creating a new policy under the Inbound Network Access and Outbound Network Access? I believe I've done that earlier and it works on the windows agents and it blocks but for AIX/UNIX agents, it don't seem to work.

It still allows TELNET, FTP access on UNIX / AIX Servers though.

Let me know if there's another method. Thanks.

Thanks.

are you using the latesr version?

The firewall component in SCSP prevention policies is listed either globally or for particular services or interactive programs.

In the Strict policy, the inbound rule is to deny all at the global level.

You can also set this on any other policy at Global Policy Options > Network Controls > Inbound > Globally set the default inbound rules to deny

In other policies, the firewall is open until you restrict it.  You can block all, then allow the ports that you want in.

Here are some example locations of where to find this:

Global Policy Options > Network Controls > Inbound > Components 

Global Policy Options > Network Controls > Inbound>  Inbound network rules

Service Options > Network Controls > Inbound>  Inbound network rules

Interactive Program Options > Network Controls > Inbound>  Inbound network rules

So, you can set the rules globally, then granularly add rules below to allow traffic.

Hi there,

I am currently using 5.2.7 version. Is there a version dependency for AIX 5.6 and 6.1 to work? My agent servers are AIX 5.6 and 6.1 Thanks

5.6?

check the supported platform matrix

http://www.symantec.com/business/support/resources/sites/BUSINESS/content/live/DOCUMENTATION/4000/DOC4449/en_US/SCSP_Platform_Feature_Matrix.pdf

Hi Pete.

My mistake. Our AIX agents are 5.3 and 6.1 so it should be supported. We have just upgraded our SCSP to 5.2.8 MP3. However the problem persists. Here is the latest incident.

We have 2 AIX 6.1 servers running and each are demonstrating unique behaviors.

1) On Agent Server A, after we implement the policies, it seems that the policy does not come into place. A red flag appears but doesn't come off. Attached below is a sample.

2) On Agent Server B, we managed to have some policies take into effect. File tampering works, a few things work. However for FTP and Telnet prevention, It doesn't work. We've applied the policy a couple of times, rebooted the agent server but problem persists. I am still able to Telnet and Perform FTP access into the server. File Tampering and other policies work.

Are you able to assist this?

Thanks.

This is something which I've encountered previously in my deployment of SCSP onto AIX 6.1. This is merely a permission issue that is preventing certain policies to take place on your AIX servers. What you need to do is to grant full rights on your /etc/sisips folder on your AIX servers. Without this, your default AIX security policies will override whatever is being written from SCSP.

Let me know if this solves your issue. I reckon that should take care of business.

Best Regards,

Peter.

Hi Guys, Today;s update on these 2 issues.

For Issue 1) On Agent Server A, after we implement the policies, it seems that the policy does not come into place. A red flag appears but doesn't come off. Attached below is a sample

Solution : We have not found a solution yet. The red Flag still appears. Can someone point me out as to why this occurs?

For 2) On Agent Server B, we managed to have some policies take into effect. File tampering works, a few things work. However for FTP and Telnet prevention, It doesn't work. We've applied the policy a couple of times, rebooted the agent server but problem persists. I am still able to Telnet and Perform FTP access into the server. File Tampering and other policies work.

Solution - We managed to solve this by going into Daemon Options >> Inet Daemon >> Advanced Options >> Network Controls >> Inbound.

We place Telnet and FTP into this hence this work.

For Telnet, it seems like its partially block though. When the policy is disabled, when we perform Telnet, we are able to go into the login screen. But when the policy is enabled, when we type in the Telnet command, it goes into cursor mode. Usually if a Telnet is block, a message such as this below should be prompted,

Connecting To localhost...Could not open connection to the host, on port 8080: C
onnect failed

Appreciate your continuous support and suggestions Thank you.

For issue 1, have you tried rebooting the server? Any agents installed has to be rebooted. That is a recommendation. if that doesn't work, it could probably be that your agent is corrupted. Try re-installing the agent and see if that works. I guess I am out of option if the problem still persists. Symantec personnels would know better.

For issue 2, it's great to hear that you've progressed. SCSP does not block Telnet entirely. It prevents users from further accessing. As long the ports are open on the server side, the Telnet command would work but you will not be able to proceed further.

Thats all the advice I can give. I would love to hear other suggestions from other forumers here as well. Your case is pretty challenging.

Best Regards,

Peter

Peter,

I have restarted the service, reinstall the agent and rebooted the server. Nothing seems to work. The flag persistently appears. Problem still persists. When I rebooted the server, prior to the red flag, I get an exclamation mark ! which says  Policy Translation Failed: Driver failed to load new policy

When I apply a null policy on the server, A red flag appears. After a while the server becomes from Green state to Yellow State then finally to RED. The Red flag remains.

I reboot the server again, and the problem sort of recycles.

Note : My policy pack version is relatively new and supported.

I am not sure what would be the cause of this. Has anybody encounter this error before? So far we are having issue just on  1 particular AIX 6.1 server.

Any suggestions is greatly appreciated.

Aidil.

I've seen this (on other os types) but we usually just have to restart the daemons and are good go. Sometimes a reboot is required. Look on the server and see if the policies are actually being applied to the agent:

IDS: /opt/Symantec/scspagent/IDS/system/*.pol

IPS: /etc/sisips/SCSP*.sbp.zip 

It may also be a permission issue. Try running fixowner, reapply and see what happens. http://www.symantec.com/docs/TECH115434

Hi Timl228,

I haven't tried on fixowner yet. Will definitely try that and see if it works. Thanks again for another great contribution. If there are other alternatives, feel free to share. I would like to have more possible solutions I can find.

Thanks!

aidil@my.ibm.com - i was having similar problem on configuring FTP and Telnet on AIX as it didn't seem to work but after you posted your solution by doing this : Solution - We managed to solve this by going into Daemon Options >> Inet Daemon >> Advanced Options >> Network Controls >> Inbound.

I am now able block FTP and Telnet access. Indirectly you have solved my problem.

Thanks! :)

Gonzalez.

Hey Tim

I've tried the solution you provided in here : http://www.symantec.com/business/support/index?page=content&id=TECH115434

but unfortunately that didn't work either. The problem "Policy Translation Failed: Driver failed to load new policy" still persists.

If we were to place a policy onto the server, the red flag comes out. If we reboot the server, then the policy takes effect. But if we were to update the policies, the red flag appears again unless a reboot of server is initiated then the new policy takes effect.

Its weird that this problem is happening on this particular server while the others are running fine.

Any idea why?

Hmm...I at a dead end here but I will see what else I can come up with to assist you. At the mean time, it would good to log an official case with Symantec Support team.

Chuck Edson,

Is there anyone else from Symantec that is able to help Aidil@my.ibm.com? I have plans to upgrade my version to the latest, I foresee this could happen to me when I do it next year. So any solutions would also benefit me greatly for future upgrade.

Hmm..it's amazing to see the users here are more actively involved than the Symantec personnels with the guidance and solutions. I have a very old SCSP version running and it will be upgraded real soon. As a matter in fact it is already in our IT change management process. I fear too on this issue as our current servers are AIX 5.3 64 bit edition. I hope there is some good answer to solve this.

Option 1 : Sisips Group GUID and UID are not the same.

This is known issue of SCSP on AIX 5.3 and 6.1, users must be part of the parimary group sisips to override a protection policy. To do this perform the following :

groupadd -g 500 sisips
useradd -u 500 -c "SCSP User" -d /opt/Symantec/scspagent/IPS -s /sbin/sh -g sisips sisips

Note /opt/Symantec is usually your default agent installation directory.

If the directory is not correctly defined, the agent won't work.

My advice is, do Option 1 first before you install the agent. So that when you install the agent, make sure it is pointed to /opt/Symantec directory.

Option 2 - SISIPS Permission

Run the "sisipsconfig.sh -i" command
Become root and execute the following commands:

  1)  $ add_drv sisips
  2)  $ chgrp sisips /devices/pseudo/sisips*
  3)  $ chmod g+rw /devices/pseudo/sisips*
  4)  Reboot your system

When you create multiple custom policies for UNIX operating systems,you should always start from the sym_unix_protection_spb policy. The unix_application_control_template policy is not supported as a base for custom policies. Please take note on this.

Option 3 : Driver problem

Aidil, try and compare a working server driver with the failed one. It might looks like a driver issue here. What you can do is copy the AIX61 folder (If your agent server is AIX61) entirely from a working server to the non-working one and see if that helps.  Make sure you stop the services first on both working and non-working servers before you copy the files over. Reboot the non-working server and verify.

Thanks Ali for the tip. Wil definitely try this when I get back to work after the weekends

Hi Chuck Edson,

It would be an added privilege if there is a say from Symantec's end. Let me know if you have more information that would assist us in the troubleshooting.

Thank you,

Aidil.

Hi Ali,

We have discovered that the red flag issue is not linked to the permission issue. We have gotten full rights for the system and yet the red flag still appears. This red flag only shows up when we attempt to apply IPS policies to this particular server, whereas IDS policies work fine. The AIX61 folder that we copied were only found under the IDS directory, hence we kinda had a feeling it wouldn't work but we still gave it a shot nonetheless. Unfortunately our assumption came true.

Everytime we reboot the server, the flag goes away. Obviously this is not a solution as we can't expect the customer to reboot everytime a new policy is being deployed. So basically what happens is:

1) Reboot server (No Flag)

2) Apply IPS Policy with the "Disable prevention" option checked (Flag appears)

3) Refresh a couple of times (Flag disappears)

4) Apply IPS policy with the "Disable prevention" option UNchecked (Flag appears)

5) Refresh multiple times (Flag remains)

6) Apply any further IPS policies with or without prevention (Flag remains)

So it seems that we have an issue with Prevention-enabled IPS policies. We have tried the same steps with a different server but it worked perfectly fine (both running on AIX6.1)

Any ideas? We have logged a case with Symantec support and they have been working at it for more than a week now without any success so far.

I scanned through your statements and would like to highlight this :

When I apply a null policy on the server, A red flag appears. After a while the server becomes from Green state to Yellow State then finally to RED. The Red flag remains.

I reboot the server again, and the problem sort of recycles.

Note : My policy pack version is relatively new and supported

Whenever you install SCSP onto your agent server, and would like to enable IPS, always reboot your server. If you install IPS without reboot, the system will be flagged out in Red as what you are getting. A reboot will rid the flag..So if you have other servers that are flagged, make sure it is rebooted.

Now, when you have a server that is flagged, and your state starts to deteroriate (as you have indicated from green, to yellow to red) , there is a problem with either the application, permission or your AIX server. From what I have read, you have already reinstalled the agent, rebooted the server but the problem did not go away. You have also indicated that it is not a permission issue however I still would not rule that possiblity out. If IDS is working, IPS should work unless blocked by some permission or some other security application that is preventing IPS to take effect. How many servers running AIX 6.1 are having this symptom? Have they been rebooted? If they are not before IPS is enabled, reboot them.

If your other AIX 6.1 agent servers are working, then it should work for this server so the way I see it, it could be a server issue.

Please check with your server administrator if there are other security applications or hardening scripts installed on this server.

Also, if you have logged case with Symantec, provide them this IPS zip file.   /etc/sisips/SCSP*.sbp.zip

This is definitely IPS issue. It seems that the policy is not able to get updated into the Prevention mechanism on your AIX. Something is preventing the policy update to take place hence disrupts your agent status from solid state (Green) to offline state (Red state).

Recommendation by Symantec is, when your enabling IPS, make sure you restart your servers and it should solve all pending IPS policies But your case has a state that deteroriates with the flag.

My help would follow what Ali has recommended, verify that there are no security apps that is preventing IPS to take place.

I have pushed this to support. Let's see what they can get back to me on this okay. Hang in there.

Hi Aidil,

I had one of the SCSP TSE's look at your issue. You need to allow the notification port traffic to the AIX servers and back. If that does not resolve the problem, it is a permission issue on the client side.

If you still cannot resolve it by modifying client permissions, I suggest opening a case with Symantec support.

http://www.symantec.com/support/contact_techsupp_static.jsp

Peter.

To go forward with troubleshooting unless you are already working with support is to drop the IPS driver into trace debug to see the TCPSTREAM data for a possible quick fix. Would you like steps on how to drop the IPS driver to trace level debug? From there we can see each connection and the kernel to OS reaction occuring (0xxx<Alpha> or XXXX denied or seg faulting) to find a better solutions in this case. Ensure you follow your companies internal policies and scrub any outputs posted to this public forum.

Hi there,

Thanks a lot for the suggestion.We have logged a case and Support is looking at it. But anyway, for knowledge sake, I would definitely be interested in knowing the steps on how to drop IPS driver to trace level debug.

Thanks!