It’s time for ShmooCon 2011, YEAH!!! This is my first time attending and I am very excited. I would like to release a few maintenance releases of my Nessus Vulnerability XML Parser v8 and Cisco ACL Parser v0.05.
Nessus Vulnerability XML Parser v8 – There was a bug in the creation of the TEXT File report generation. The issue was cause by a variable I called in a foreach loop, if the variable was not an array, but a hash the script would fail. No other changes were made.
The Cisco ACL Parser v0.05 – In the ASA a type of ACL used for the SSL Any-Connect Portal is called a WEBACL. There was a problem in the parsing of these ACL types. Also I changed the name of the output file to be the device hostname-output.csv “fw01-output.csv” instead of “hostname fw01-output.csv”.
These downloads can be found at Cody's blog at www.melcara.com.
I hope everyone enjoys the scripts and I hope to see you at ShmooCon.
Thursday, January 27, 2011
Thursday, January 20, 2011
Where did all the IP addresses go?
IANA owns the Internet. We'll, at least they manage who gets what IP addresses and guess what?!?!? We are running out. Check out Greg Ferro's posting at http://etherealmind.com/ipocalypse-what-next/ to get more of the scoop. The short story is that we are almost out of unallocated IP addresses requiring the move to IPv6. Now I don't have anything against IPv6 personally but I do know that a wholesale migration to a new IP addressing scheme will likely break one or two things and that's not something I'm looking forward to. That's why Greg's posting was interesting. He provided a link to an IANA web page that lists all of the IP address assignments (in terms of /8 networks). Curious, I checked it out.
I found a lot of what you'd expect - a bunch of /8 ranges assigned to ARIN, RIPE NCC, LACNIC, etc. That's not that interesting. I did find something that was, to me, more interesting. Over 20 /8 ranges were assigned to private companies such as GE, IBM, Xerox HP, DEC, Apple, MIT, Ford, Halliburton, Eli Lily, Bell North, Prudential Securities, Merck and duPont. Also, the Defense Information Systems Agency (DISA) has at least 4 that I counted. IANA has 2 allocated to themselves.
This got me thinking. Does any single company actually need over 16 million public IP addresses? I mean, in the age of NAT, PAT and RFC1918 what do you do with that many public networks. The 13 companies I listed above actually have over 200 million public IP addresses between them. To me, that's a little much.
Don't get me wrong. I'm not saying that these companies don't have a right to the IP addresses they registered. I'm not saying that these companies should be forced to give them up. I'm just wondering if DEC or Xerox even have 16 million computers, let alone the need for 16 million public addresses.
Wait! Stop! Hold on a minute! I'm thinking about this all wrong. Just think of the new security concerns there will be when we move to IPv6 in full. OK, so never mind what I was saying. The the IPv6 insanity begin!!!
I found a lot of what you'd expect - a bunch of /8 ranges assigned to ARIN, RIPE NCC, LACNIC, etc. That's not that interesting. I did find something that was, to me, more interesting. Over 20 /8 ranges were assigned to private companies such as GE, IBM, Xerox HP, DEC, Apple, MIT, Ford, Halliburton, Eli Lily, Bell North, Prudential Securities, Merck and duPont. Also, the Defense Information Systems Agency (DISA) has at least 4 that I counted. IANA has 2 allocated to themselves.
This got me thinking. Does any single company actually need over 16 million public IP addresses? I mean, in the age of NAT, PAT and RFC1918 what do you do with that many public networks. The 13 companies I listed above actually have over 200 million public IP addresses between them. To me, that's a little much.
Don't get me wrong. I'm not saying that these companies don't have a right to the IP addresses they registered. I'm not saying that these companies should be forced to give them up. I'm just wondering if DEC or Xerox even have 16 million computers, let alone the need for 16 million public addresses.
Wait! Stop! Hold on a minute! I'm thinking about this all wrong. Just think of the new security concerns there will be when we move to IPv6 in full. OK, so never mind what I was saying. The the IPv6 insanity begin!!!
Monday, January 17, 2011
Small Business Security 101 - Overview
Security is mandatory. This statement applies whether you are a fortune 50 global mega-corporation or a small business with 25 employees. As long as you rely on computers and connect to the Internet, you face computer-related risks. Actually, even if you don't connect to the Internet, those risks are present. Infection by a virus, worm or spyware, compromise by an external attacker, malicious insiders, careless employees and even hardware failures are threats that organization of all sizes must face. Large organizations have resources to deal with these threats but small and medium-sized business don't often that the money, technology, skills or experience necessary to affect reasonable levels of security. This is the first in a series of posting designed to provide an overview of how organizations with limited time, limited budget and limited personnel can achieve necessary security and, as necessary, regulatory compliance. The focus will be on "cost effective security" that introduces a minimum of operational overhead at a minimum of cost.
This first posting is going to address some of the myths about security and small to medium-sized businesses so let's get right down to business.
Myth 1: My business is too small to be targeted.
This often (but not exclusively) comes up when discussing security with organizations that have only a few employees. The thought is that "hackers" will target big companies and will ignore small ones. This seems to make sense. Big companies have more to steal, they have a larger footprint and they are far more well known. This, however, assumes that all attackers are intentionally targeting their victims - a fact that is not always true. There are plenty of "target of opportunity" attackers out there. Viruses and worms, for the most part, don't care who they infect and if an attacker finds your vulnerable system during random scanning of the Internet, they will be happy to compromise you. Making things worse, your users are browsing the Internet, taking advantage of wireless hot spots at airports, hotels and Starbucks and placing their laptops behind Best Buy purchased broadband routers with the default configuration when they work from home. All of these put your users and your organization at risk. Some studies have shown that a random computer gets compromised if placed unprotected on the Internet after 15 minutes. There are 96, 15-minute blocks per day, 672 per week and 34,944 per year. That's a lot of time for a compromise to happen.
Myth 2: I don't have anything of value so there's no reason I'd be compromised.
This statement simply highlights some misunderstandings or ignorance about what is considered valuable. To a bad buy hacker, any business is ripe with valuable targets. They want your processing power, Internet bandwidth and hard drive space for storing and distributing porn, stolen credit card numbers and other contraband. They also want your systems to use as Spam relays and bot-net zombies.
More personally, employees have access to bank accounts (corporate and personal), Facebook accounts and and even World of Warcraft. Recently, a "friend" on Facebook contacted me via Facebook IM stating that he got mugged outside his hotel in London and that he needed money to get home. His account had been compromised. I didn't send any money but how many people would have - particularly if it was a close friend. I'll also admit to the fact that I had a World of Warcraft account (yes I'm a nerd) that I stopped using for around a year or so get compromised. These things happen all the time.
Finally, bad guy hackers also want personal information such as names, addresses and social security numbers. Identity theft is real and can create havoc in the lives of the victims. And if you think that one of your employees suffering identity theft has nothing to do with you business, wait until it happens and see how their performance and productivity are affected.
Myth3: I have a firewall and anti-virus so I'm secure.
This myth was not limited to the SMB space until fairly recently. This was a common belief until significant, publicized breaches and comprehensive regulatory requirements swayed many large (and regulated) organizations over to a more comprehensive security program mentality. Unfortunately, it still rings true for many organizations. It is, in fact, quite false for a number of reasons. First, the fact is that anti-virus technology is not perfect. Every time testing is done, testers find that some AV products catch some malware and some miss. I've not seen any solid statistics but the number that rings fairly true is that the average AV product is between 60 and 70% effective. Anti-virus is not the answer (although it is part of the answer).
Firewalls are even more of a problem. In the past firewalls were set up to block all inbound traffic and that was good. Then organizations decided it would be a good thing to receive email and host web sites - and holes were created in the firewall. Then organizations went from web sites to mission critical web applications and more holes were created. Today, it is not uncommon to find firewalls with dozens or ports and protocols allowed in, each and every one of which represent a risk. Making things worse, most firewalls are configured to block (at least some) inbound access but to allow all outbound access. This means that users all allowed to establish outbound connections to any IP address on the Internet using any port - and the firewall will allow the responses back in. All an attacker need to do is trick one user into opening a file, click on a link or visit a malicious site and your firewall is now, effectively useless.
Myth 4: Small businesses have simple IT environments.
This isn't something that people often say but rather something that people often assume. Along with that assumption is that security is, as a result, easy. While this may be the case for some organizations, it is not uncommon for even fairly small organizations to have VoIP phone systems, virtualization, wireless, storage (either SAN or NAS), wide area network connections, VPN (site-to-site, IPSec and SSL) tunnels and Active Directory (or other LDAP). These are complex and sophisticated technologies that each bring with them a unique set of security concerns. Particularly in smaller organizations, knowledge of these security risks and the skills necessary to address them is not available making security all the more difficult.
Summary
We've discussed some of the myths about security for small to medium-sized businesses. Hopefully, it is fairly obvious that in the SMB space, while organizations may have fewer employees, they require every bit as sophisticated a security program as their larger counterparts. Consider the following:
The question faced by these organzations, and by may others is how can we achieve these security goals with minimal staff, minimal budget and minimal resources. That is the question that will be answered by upcoming postings. In future postings we will discuss each of a variety of security topics and how they can be addressed by the average SMB. We'll be discussing the following:
This first posting is going to address some of the myths about security and small to medium-sized businesses so let's get right down to business.
Myth 1: My business is too small to be targeted.
This often (but not exclusively) comes up when discussing security with organizations that have only a few employees. The thought is that "hackers" will target big companies and will ignore small ones. This seems to make sense. Big companies have more to steal, they have a larger footprint and they are far more well known. This, however, assumes that all attackers are intentionally targeting their victims - a fact that is not always true. There are plenty of "target of opportunity" attackers out there. Viruses and worms, for the most part, don't care who they infect and if an attacker finds your vulnerable system during random scanning of the Internet, they will be happy to compromise you. Making things worse, your users are browsing the Internet, taking advantage of wireless hot spots at airports, hotels and Starbucks and placing their laptops behind Best Buy purchased broadband routers with the default configuration when they work from home. All of these put your users and your organization at risk. Some studies have shown that a random computer gets compromised if placed unprotected on the Internet after 15 minutes. There are 96, 15-minute blocks per day, 672 per week and 34,944 per year. That's a lot of time for a compromise to happen.
Myth 2: I don't have anything of value so there's no reason I'd be compromised.
This statement simply highlights some misunderstandings or ignorance about what is considered valuable. To a bad buy hacker, any business is ripe with valuable targets. They want your processing power, Internet bandwidth and hard drive space for storing and distributing porn, stolen credit card numbers and other contraband. They also want your systems to use as Spam relays and bot-net zombies.
More personally, employees have access to bank accounts (corporate and personal), Facebook accounts and and even World of Warcraft. Recently, a "friend" on Facebook contacted me via Facebook IM stating that he got mugged outside his hotel in London and that he needed money to get home. His account had been compromised. I didn't send any money but how many people would have - particularly if it was a close friend. I'll also admit to the fact that I had a World of Warcraft account (yes I'm a nerd) that I stopped using for around a year or so get compromised. These things happen all the time.
Finally, bad guy hackers also want personal information such as names, addresses and social security numbers. Identity theft is real and can create havoc in the lives of the victims. And if you think that one of your employees suffering identity theft has nothing to do with you business, wait until it happens and see how their performance and productivity are affected.
Myth3: I have a firewall and anti-virus so I'm secure.
This myth was not limited to the SMB space until fairly recently. This was a common belief until significant, publicized breaches and comprehensive regulatory requirements swayed many large (and regulated) organizations over to a more comprehensive security program mentality. Unfortunately, it still rings true for many organizations. It is, in fact, quite false for a number of reasons. First, the fact is that anti-virus technology is not perfect. Every time testing is done, testers find that some AV products catch some malware and some miss. I've not seen any solid statistics but the number that rings fairly true is that the average AV product is between 60 and 70% effective. Anti-virus is not the answer (although it is part of the answer).
Firewalls are even more of a problem. In the past firewalls were set up to block all inbound traffic and that was good. Then organizations decided it would be a good thing to receive email and host web sites - and holes were created in the firewall. Then organizations went from web sites to mission critical web applications and more holes were created. Today, it is not uncommon to find firewalls with dozens or ports and protocols allowed in, each and every one of which represent a risk. Making things worse, most firewalls are configured to block (at least some) inbound access but to allow all outbound access. This means that users all allowed to establish outbound connections to any IP address on the Internet using any port - and the firewall will allow the responses back in. All an attacker need to do is trick one user into opening a file, click on a link or visit a malicious site and your firewall is now, effectively useless.
Myth 4: Small businesses have simple IT environments.
This isn't something that people often say but rather something that people often assume. Along with that assumption is that security is, as a result, easy. While this may be the case for some organizations, it is not uncommon for even fairly small organizations to have VoIP phone systems, virtualization, wireless, storage (either SAN or NAS), wide area network connections, VPN (site-to-site, IPSec and SSL) tunnels and Active Directory (or other LDAP). These are complex and sophisticated technologies that each bring with them a unique set of security concerns. Particularly in smaller organizations, knowledge of these security risks and the skills necessary to address them is not available making security all the more difficult.
Summary
We've discussed some of the myths about security for small to medium-sized businesses. Hopefully, it is fairly obvious that in the SMB space, while organizations may have fewer employees, they require every bit as sophisticated a security program as their larger counterparts. Consider the following:
- A collections company that maintains a database with the personal information of over 11 million people including, in some cases, credit card and bank account data
- A private equity fund company that manages over $3 billion in assets
- A web application development company that focuses on providing health care data to pharmaceutical companies
- A business that provides data center services to credit unions
The question faced by these organzations, and by may others is how can we achieve these security goals with minimal staff, minimal budget and minimal resources. That is the question that will be answered by upcoming postings. In future postings we will discuss each of a variety of security topics and how they can be addressed by the average SMB. We'll be discussing the following:
- VoIP – network design, 802.1x & NAC
- IDS/IPS
- Endpoint - anti-malware, encryption, application control (blacklisting/whitelisting), integrity verification
- Smart phones
- Network design
- Web app vulnerability scanning, web app firewall
- Firewalls and VPN
- Authentication – user provisioning, good passwords, tokens, rights assignment, admin rights
- SEIM/Central Monitoring
- Network Device Hardening
- Active Directory – design, GPO
- Vulnerability Scanning, Patch Management
- Virtualization
- Wireless network design, authentication/802.1x/WPA2, etc.
- Wireless client attacks, bluetooth, keyboards, etc.
- Wireless IDS
- Data Leakage Protection
- Media Sanitization
- Data Classification, Risk Assessment, Security Awareness, Acceptable Use, Incident Response, Change Control
- Physical Security
- Regulatory Compliance, Policies
Tuesday, January 4, 2011
Auditing Access Control Lists
During assessments NWN regularly reviews the configurations of many different types of systems and devices ranging from firewalls, routers, switches and servers. Many of these devices, particularly routers, switches and firewalls, have Access Control Lists or ACLs that provide critical security controls. Unfortunately, the process of auditing these ACLs can sometimes be very time consuming. Until now there has not been an open source or free tool to assist with this type of auditing. Fortunately, member of the NWN STAR team, Cody Dumont, has created a tool - the ACL2CSV parser.
ACL2CSV parser is a PERL script, which reads Cisco router, switch, and firewall (PIX, and ASA) configuration files that have been exported from the device in flat text format. It parses the ACLS and object groups (PIX and ASA only) and generates an easy to understand CSV file. This file can them be opened in Microsoft Excel or other spreadsheet software for easy viewing or additional analysis. The ACL2CSV tool expands all object groups and places them into the correct location as if the ACL did not use object groups. The object group expansion works for all object group types. The ACL2CSV parser is extremely fast and easy to use.
For instructions on the use of ACL2CSV, visit Cody’s personal blog at http://www.melcara.com and select the link for Cisco ACL2CSV parser. If PERL is not installed on your system, you will need to do so. PERL can be found at http://www.activestate.com or http://www.perl.com. Once PERL is installed no additional modules are needed. The script assumes PERL is installed at “/usr/bin/perl”, and only uses the “strict” and “Getopt::Std” modules. After the script is copied into a folder found in your system path, you should also modify the permissions to allow the script to be executable. On a Unix, Linux or Mac computer, this can be accomplished via the chmod command.
Once the script is executed and installed, you can run the script. The script requires a file name as an argument, so if you simply type ./acl2csv.pl you will receive the following message:
The command requires a File Name as a command line argument
acl2csv.pl c:\old_pix_config.txt
To check the version, add the “-v” or “v” as the command line argument.
ACL Parser for Cisco IOS, PIX & ASA
DEVELOPED AND OWNED BY Cody Dumont - NWN Security Testing Assessment and Response (STAR)
Licensed to Planet Earth.
I used some code for another tool of this type from James Bly AT mangeek.com
http://mangeek.com/portfolio/pixparser.html
Also Anthony contributed by doing some testing and verification
Version Number 0.04 - Dec 2010
"For Questions Please Contact Cody Dumont - CDumont@nwnit.com "
To run the script, use the following command:
/foo/bar/acl2csv.pl fw_config.txt
Once the script is finished, a completion message will be displayed. There should be no other messages. In the event you receive a PERL array or HASH error message, this means that Cody did not do enough testing. If you get such an error, follow the PERL debugging steps or contact Cody at CDumont@nwnit.com and he’ll be happy to fix the error.
The output of the script will look something like the following.
NAME,LINE,TYPE,FUNCTION,PROTOCOL,SOURCE NET,SOURCE_PORT,DEST NET,DEST PORT,TIME,INACTIVE,LOG,REMARK,ORIGINAL
test441,1,extended,permit,tcp,any,,any,eq 44 ,,,,,access-list test441 extended permit tcp any any eq 44
test442,1,extended,permit,tcp,any,eq 44,any,eq 44 ,,,,,access-list test442 extended permit tcp any eq 44 any eq 44
test443,1,extended,permit,tcp,any,eq 44,any, ,,,,,access-list test443 extended permit tcp any eq 44 any
The definitions of each field are listed below.
NAME – The name of the ACL
LINE – The line in sequential order of the ACL. Please note if the ACL uses Object-Groups, then each Object-Group will have the same index number. The idea is to provide the user with same output of the “show access-lists” command. Please note “REMARK” ACL entries are not counted in this test.
TYPE – This is the TYPE of ACL, the options are standard, extended, webtype.
FUNCTION – The “permit” or “deny” entry.
PROTOCOL – The Layer 3 protocol controlled by the ACL entry.
SOURCE NET – The source network and subnet mask. If the entry is a host, then “host” will be displayed. However if “255.255.255.255” is found in the ACL entry, then “255.255.255.255” will be displayed. The script does not check the validly of the mask, and the assumption is the config is a direct output from “show running-configuration” or “show startup-configuration”.
SOURCE_PORT – If a source port is defined, then the source port is displayed. If no source port is defined this field will be empty.
DEST NET – Same as the SOURCE NET, but the destination section of the ACL entry is displayed.
DEST PORT - Same as the SOURCE PORT part of the ACL, but the destination section of the ACL entry is displayed.
TIME – ACLs can be time sensitive using the “time-range” command. If a time-range is defined, the name of the “time-range” is displayed, however the details of the “time-range” are not displayed. This might be added in a future release.
INACTIVE – If an ACL entry is listed as “INACTIVE”, the entry is left in the configuration, but is not an active rule. Other parsing tools often ignore this, but if “YES” is found in this field then the ACL enter is not an active rule. If the field is empty then the ACL entry is an active rule.
LOG – If log settings are configured, the settings are displayed in this cell. Two examples are “interval 5” and “notifications”.
REMARK – The “REMARK” section is a little harder to deal with. The configuration files currently put the “REMARK” in an ACL entry just above the ACL entry the “REMARK” is connected to. So in the parsing of the ACL, the script will check to see if the preceding entry was a remark, if so this field will be filled with “REMARK” statement. However some ACL’s might have more than one line as a remark, the script will not detect this case. The script will only detect the “REMARK” in the preceding line only.
ORIGINAL – The original ACL entry unmodified. The “REMARK” ACL entries are not displayed.
When the script is finished, open the file using any spreadsheet application. Then you can create filters, freeze panes, etc. You could also import the newly created ACL file into a database.
This tool can save a network administrator, security professional or auditor a lot of time sorting through ACLs. We at NWN STAR hope the security community will find this tool useful and will enhance the overall security of your information system.
ACL2CSV parser is a PERL script, which reads Cisco router, switch, and firewall (PIX, and ASA) configuration files that have been exported from the device in flat text format. It parses the ACLS and object groups (PIX and ASA only) and generates an easy to understand CSV file. This file can them be opened in Microsoft Excel or other spreadsheet software for easy viewing or additional analysis. The ACL2CSV tool expands all object groups and places them into the correct location as if the ACL did not use object groups. The object group expansion works for all object group types. The ACL2CSV parser is extremely fast and easy to use.
For instructions on the use of ACL2CSV, visit Cody’s personal blog at http://www.melcara.com and select the link for Cisco ACL2CSV parser. If PERL is not installed on your system, you will need to do so. PERL can be found at http://www.activestate.com or http://www.perl.com. Once PERL is installed no additional modules are needed. The script assumes PERL is installed at “/usr/bin/perl”, and only uses the “strict” and “Getopt::Std” modules. After the script is copied into a folder found in your system path, you should also modify the permissions to allow the script to be executable. On a Unix, Linux or Mac computer, this can be accomplished via the chmod command.
Once the script is executed and installed, you can run the script. The script requires a file name as an argument, so if you simply type ./acl2csv.pl you will receive the following message:
The command requires a File Name as a command line argument
acl2csv.pl c:\old_pix_config.txt
To check the version, add the “-v” or “v” as the command line argument.
ACL Parser for Cisco IOS, PIX & ASA
DEVELOPED AND OWNED BY Cody Dumont - NWN Security Testing Assessment and Response (STAR)
Licensed to Planet Earth.
I used some code for another tool of this type from James Bly AT mangeek.com
http://mangeek.com/portfolio/pixparser.html
Also Anthony
Version Number 0.04 - Dec 2010
"For Questions Please Contact Cody Dumont - CDumont@nwnit.com "
To run the script, use the following command:
/foo/bar/acl2csv.pl fw_config.txt
Once the script is finished, a completion message will be displayed. There should be no other messages. In the event you receive a PERL array or HASH error message, this means that Cody did not do enough testing. If you get such an error, follow the PERL debugging steps or contact Cody at CDumont@nwnit.com and he’ll be happy to fix the error.
The output of the script will look something like the following.
NAME,LINE,TYPE,FUNCTION,PROTOCOL,SOURCE NET,SOURCE_PORT,DEST NET,DEST PORT,TIME,INACTIVE,LOG,REMARK,ORIGINAL
test441,1,extended,permit,tcp,any,,any,eq 44 ,,,,,access-list test441 extended permit tcp any any eq 44
test442,1,extended,permit,tcp,any,eq 44,any,eq 44 ,,,,,access-list test442 extended permit tcp any eq 44 any eq 44
test443,1,extended,permit,tcp,any,eq 44,any, ,,,,,access-list test443 extended permit tcp any eq 44 any
The definitions of each field are listed below.
NAME – The name of the ACL
LINE – The line in sequential order of the ACL. Please note if the ACL uses Object-Groups, then each Object-Group will have the same index number. The idea is to provide the user with same output of the “show access-lists” command. Please note “REMARK” ACL entries are not counted in this test.
TYPE – This is the TYPE of ACL, the options are standard, extended, webtype.
FUNCTION – The “permit” or “deny” entry.
PROTOCOL – The Layer 3 protocol controlled by the ACL entry.
SOURCE NET – The source network and subnet mask. If the entry is a host, then “host” will be displayed. However if “255.255.255.255” is found in the ACL entry, then “255.255.255.255” will be displayed. The script does not check the validly of the mask, and the assumption is the config is a direct output from “show running-configuration” or “show startup-configuration”.
SOURCE_PORT – If a source port is defined, then the source port is displayed. If no source port is defined this field will be empty.
DEST NET – Same as the SOURCE NET, but the destination section of the ACL entry is displayed.
DEST PORT - Same as the SOURCE PORT part of the ACL, but the destination section of the ACL entry is displayed.
TIME – ACLs can be time sensitive using the “time-range” command. If a time-range is defined, the name of the “time-range” is displayed, however the details of the “time-range” are not displayed. This might be added in a future release.
INACTIVE – If an ACL entry is listed as “INACTIVE”, the entry is left in the configuration, but is not an active rule. Other parsing tools often ignore this, but if “YES” is found in this field then the ACL enter is not an active rule. If the field is empty then the ACL entry is an active rule.
LOG – If log settings are configured, the settings are displayed in this cell. Two examples are “interval 5” and “notifications”.
REMARK – The “REMARK” section is a little harder to deal with. The configuration files currently put the “REMARK” in an ACL entry just above the ACL entry the “REMARK” is connected to. So in the parsing of the ACL, the script will check to see if the preceding entry was a remark, if so this field will be filled with “REMARK” statement. However some ACL’s might have more than one line as a remark, the script will not detect this case. The script will only detect the “REMARK” in the preceding line only.
ORIGINAL – The original ACL entry unmodified. The “REMARK” ACL entries are not displayed.
When the script is finished, open the file using any spreadsheet application. Then you can create filters, freeze panes, etc. You could also import the newly created ACL file into a database.
This tool can save a network administrator, security professional or auditor a lot of time sorting through ACLs. We at NWN STAR hope the security community will find this tool useful and will enhance the overall security of your information system.
Subscribe to:
Posts (Atom)
Posts
