As mentioned in a previous post, last Thursday, I did something I have never done before: I turned in my two week notice!
Basically, through word-of-mouth, and two good interviews, I was offered a postion that is: closer to home, pays a lot more, and doesn't have the headaches of my current position. Anyway, that is enough complaining. I actually HAVE a lot to be grateful for, and to look forward to:
1) My son starts Kindergarten in two-weeks. He will be the only kid running around a Georgia school with Michigan Wolverine and Detroit Tiger shirts on! I LOVE IT!
2) My wife, after years of not being able to due to Army life, is finally in college and starts her first full semester in a couple of weeks. She deserves it!
3) My new job sounds incredible, is a place I have wanted to work for AWHILE, and, it will allow me to focus on what I like: intrusion detection and prevention, and I think some code inspections! I am definitely excited. This job is closer to home, more money, and, so far anyway, better people!
Monday, July 27, 2009
Drop it and Run?
I have never been able to just quit something without a reason. Nor have I been able to walk away from problems unsolved without at least making sure that I have said "my peace." I mention this because I turned in my two-week notice last Thursday, and yet here I am, still trying to solve problems for my current (for the next 8 working days) employer.
Anyway, I will save the complaining for another time but there are two things really standing out to me right now:
1) We (the cyber security section) asked for access to our network scanner over a month ago, for the second time. Finally, after the GM said we were to be given access so that we had oversight and could do our own scans, we were informed that we had access. The problem came with the fact that our normal user accounts were used, through LDAP, to grant this access. This does not allow for oversight, or privileged scanning. I KNOW that the system admins knew this is how they set it up, ignoring the requirement and the GM. However, that is all I am going to say on that for now.
2) Symantec Endpoint Protection 11: Holy Crud! What should be a very simple install has become a pain, for me and the second Symantec tech support guy (who has been A LOT better than the first).
We (my boss and I) started out with getting the pre-req's installed: java, ASP, IIS. We verified all permissions and that the IIS setup was correct. Then we installed SEP11.
The problem we had was that the clients would NEVER talk to the server. So again, at the request of the Syamanted Tech guy, we double and triple-checked the settings for IIS, the communications file (Sylink.xml), the network connectivity, etc. Nada! After the third day, the tech rep asked us to uninstall IIS (no other app was using) and SEP manager. This we did, in addition to removing the symantec client on the server box as well. We went so far as to verify that there was no left over symantec data ANYWHERE on the system.
Unfortunately, after we did all of this, we (this time with the web admin, to cover our rear-ends) set out to re-install IIS and verify its installation. However, it would NEVER install correctly. After hours of digging around on the few error messages we had, I found that this related back to file permissions on the %windir%/Registration folder (an old, MS05-051, issue). So I did the obvious thing and started to manually ensure that the permissions were correct.
However, even before I could make one change, the system froze! I was able to log off and attemp to log on, only to have the system freeze completely! What happened next was BAD!
I waited, and I waited, but the system would just not finish loading. So, I did what I think to be the obvious, and only, option: I did a hard shutdown of the server. This is a Dell PowerEdge 1950, and I already had questions about how the sysadmins set it up...but that's a WHOLE different blog. In any case, what happened was that the Server will NOT, at all, power back up! I have never had a server that had basically nothing on it, (wasn't even in production yet, really) fail to start after a hard shutdown!
To be continued?....
Anyway, I will save the complaining for another time but there are two things really standing out to me right now:
1) We (the cyber security section) asked for access to our network scanner over a month ago, for the second time. Finally, after the GM said we were to be given access so that we had oversight and could do our own scans, we were informed that we had access. The problem came with the fact that our normal user accounts were used, through LDAP, to grant this access. This does not allow for oversight, or privileged scanning. I KNOW that the system admins knew this is how they set it up, ignoring the requirement and the GM. However, that is all I am going to say on that for now.
2) Symantec Endpoint Protection 11: Holy Crud! What should be a very simple install has become a pain, for me and the second Symantec tech support guy (who has been A LOT better than the first).
We (my boss and I) started out with getting the pre-req's installed: java, ASP, IIS. We verified all permissions and that the IIS setup was correct. Then we installed SEP11.
The problem we had was that the clients would NEVER talk to the server. So again, at the request of the Syamanted Tech guy, we double and triple-checked the settings for IIS, the communications file (Sylink.xml), the network connectivity, etc. Nada! After the third day, the tech rep asked us to uninstall IIS (no other app was using) and SEP manager. This we did, in addition to removing the symantec client on the server box as well. We went so far as to verify that there was no left over symantec data ANYWHERE on the system.
Unfortunately, after we did all of this, we (this time with the web admin, to cover our rear-ends) set out to re-install IIS and verify its installation. However, it would NEVER install correctly. After hours of digging around on the few error messages we had, I found that this related back to file permissions on the %windir%/Registration folder (an old, MS05-051, issue). So I did the obvious thing and started to manually ensure that the permissions were correct.
However, even before I could make one change, the system froze! I was able to log off and attemp to log on, only to have the system freeze completely! What happened next was BAD!
I waited, and I waited, but the system would just not finish loading. So, I did what I think to be the obvious, and only, option: I did a hard shutdown of the server. This is a Dell PowerEdge 1950, and I already had questions about how the sysadmins set it up...but that's a WHOLE different blog. In any case, what happened was that the Server will NOT, at all, power back up! I have never had a server that had basically nothing on it, (wasn't even in production yet, really) fail to start after a hard shutdown!
To be continued?....
Monday, July 13, 2009
SSLF/FDCC compliance - The Fun Never Ends
My two biggest focal areas regarding security are: intrusion analysis and secure software programming. After testing two different, but related, security products (SEP 11 and Policy Orchestrator) and then performing the subsequent installations of each, I have come to the conclusion that:
Software installers should automatically verify known registry/GPO settings as necessary, or should at least return the top [five] possible failure mechanisms. I know I am not the first to suggest this requirement. I am also aware that there are some concerns with allowing an installer TOO much access to high-value information on the system. However, I believe that there is a compromise to be had somewhere in the middle.
Of the two products, McAfee's ePolicy Orchestrator (ePO) is used, at least in this instance, for compliance monitoring. It does have some other excellent functionality, and the program is good in general. However, I am not making a sales pitch.
The biggest issues with ePO is that the following settings MUST be made:
- Log on as a service: the accounts listed here must include the account used by ePO. This is somewhat of an obvious requirement. However, an overzealous SysAdmin can cause some heartache for the one installing ePO (as was the case here), as this requirement isn't noticed until half-way through the process.
- NtfsDisable8dot3NameCreation: In general terms, allowing for 8.3 names presents a low risk to the system and can slow down high-use systems. However, it should be noted that "turning on" this setting is an FDCC requirement. The problem with this setting being enabled is that Apache, used by ePO, will not install correctly, or if enable later, will not load properly (roughly 100 core load error messages will display on the initial GUI under the log in section).
The other product, the one that inspired this rant, is Symantec's SEP 11. While this product appears to be an improvement in many ways over version 10, there are still some kinks to work out. However, I believe some of these "kinks" could be mitigated, or at least avoided, if some functionality was tested by the installer, specifically LDAP authentication. Buried in a Symantec Forum was the fact that if:
- LDAP Server Signing Requirements must not be required. If this setting is "required," the SEP Manager will NEVER authenticate to the LDAP. Troubleshooting this issue was easier with Wireshark captures than with searching Symantec (or maybe I just felt like being an uber-geek that day). What I decided to do was to start capturing through Wireshark, with a simple filter set for my source ip address. Once I did that and attempted a couple of authentications, it was obvious that the LDAP server was immediately denying the authentication attempt. This was obvious from the fact that the LDAP server was immediately issuing a RST packet after the Hello packet. With this setting changed, the SEPM could easily import from the LDAP server.
So my conclusions are these:
1) Although documented in both cases above, some of the documentation was "bulky" or timely to locate. A better organization of "known issues" in release documentation would be helpful.
2) If the installer called a method to verify these settings, or attempted to "use" these settings during install, and then returned the appropriate error message(s), troubleshooting would be less time-consuming (read: more cost effective).
3) It is still better to look at what the program is actually trying to do on the network, then sift through pages of help forums. (I should add that, although not suprised, tech support at one of these companies, was not aware of the issue or the fix). I guess I would rather spend time looking at the traffic, reading the packets, and using that to decipher what is happening on the network.
4) The SSLF rearing it's ugly head, again, validates once more that careful testing and understanding of the settings is definitely required.
Software installers should automatically verify known registry/GPO settings as necessary, or should at least return the top [five] possible failure mechanisms. I know I am not the first to suggest this requirement. I am also aware that there are some concerns with allowing an installer TOO much access to high-value information on the system. However, I believe that there is a compromise to be had somewhere in the middle.
Of the two products, McAfee's ePolicy Orchestrator (ePO) is used, at least in this instance, for compliance monitoring. It does have some other excellent functionality, and the program is good in general. However, I am not making a sales pitch.
The biggest issues with ePO is that the following settings MUST be made:
- Log on as a service: the accounts listed here must include the account used by ePO. This is somewhat of an obvious requirement. However, an overzealous SysAdmin can cause some heartache for the one installing ePO (as was the case here), as this requirement isn't noticed until half-way through the process.
- NtfsDisable8dot3NameCreation: In general terms, allowing for 8.3 names presents a low risk to the system and can slow down high-use systems. However, it should be noted that "turning on" this setting is an FDCC requirement. The problem with this setting being enabled is that Apache, used by ePO, will not install correctly, or if enable later, will not load properly (roughly 100 core load error messages will display on the initial GUI under the log in section).
The other product, the one that inspired this rant, is Symantec's SEP 11. While this product appears to be an improvement in many ways over version 10, there are still some kinks to work out. However, I believe some of these "kinks" could be mitigated, or at least avoided, if some functionality was tested by the installer, specifically LDAP authentication. Buried in a Symantec Forum was the fact that if:
- LDAP Server Signing Requirements must not be required. If this setting is "required," the SEP Manager will NEVER authenticate to the LDAP. Troubleshooting this issue was easier with Wireshark captures than with searching Symantec (or maybe I just felt like being an uber-geek that day). What I decided to do was to start capturing through Wireshark, with a simple filter set for my source ip address. Once I did that and attempted a couple of authentications, it was obvious that the LDAP server was immediately denying the authentication attempt. This was obvious from the fact that the LDAP server was immediately issuing a RST packet after the Hello packet. With this setting changed, the SEPM could easily import from the LDAP server.
So my conclusions are these:
1) Although documented in both cases above, some of the documentation was "bulky" or timely to locate. A better organization of "known issues" in release documentation would be helpful.
2) If the installer called a method to verify these settings, or attempted to "use" these settings during install, and then returned the appropriate error message(s), troubleshooting would be less time-consuming (read: more cost effective).
3) It is still better to look at what the program is actually trying to do on the network, then sift through pages of help forums. (I should add that, although not suprised, tech support at one of these companies, was not aware of the issue or the fix). I guess I would rather spend time looking at the traffic, reading the packets, and using that to decipher what is happening on the network.
4) The SSLF rearing it's ugly head, again, validates once more that careful testing and understanding of the settings is definitely required.
Subscribe to:
Posts (Atom)