Having recently converted to a Mac Book Pro, I have been on a quest to locate security tools capable of running on this platform. Here is are the tools I found that I now cannot live without:
KisMAC - This tool is supposed to allow you to do all the cool wireless stuff from OSX. I downloaded it and whil it did look cool, I quickly discovered one huge drawback. It turns out that is monitor/ passive mode is not supported with the Airport Extreme wireless cards in the new Mac Book Pro's. However, I have downloaded the newest Alpha version and found that it now supports passive mode in these cards! The only functionality now lacking is the ability to reinject packets. Hopefully this functionality will be there soon. Packet reinjection is necessary to perform the different Auth/ Deauth flood attacks used to generate more traffic for cracking WEP. This video provides a cool overview of cracking WEP with KisMAC.
Nessus 3.X - New with version 3.x of nessus, the Nessus developers decided to stop distribuing source code. As we have seen, it is possible to get Nessus 3.x running on other platforms. However, it turns out that OSX is now one of the supported platforms. The install and operation of OSX package is seamless. It comes with both the client and the server.
Paros Proxy - Paros proxy is an extremely well designed proxy that is a must for doing web application security testing. Because it is coded in java, it is cross platform. As long as you have JRE installed, Paros proxy functions right out of the box.
Parallels - Think of this as VMWare for MAC, only better. No annoying need to add "vmware" tools into your guest OS, etc. Using Parallels I was able boot all of my favorite Linux-based LiveCD Security Toolkits, such as Backtrack. This gives you instant access to a wealth of security tools (nmap, spike proxy, etc). By editing the CDROM setting to "Use an Image File:", you can now configure Parallels to boot from an ISO file. The only limitation I noticed was that the wireless card is not virtualized. However, since most wireless security tools won't function properly when operating though an abstration layer anyway, this is definately a minor limitation.
VirtueDesktops - Although this application is not actually a security tool, it is unbelievably cool. Its a desktop switching tool that is adds a high level of functionality while adding a super high level of eye-candy as well. Check out this video to see exactly what I am talking about. --Note, this video only shows 2 desktops in a left to right config. You can also add additional desktops on a vertical axis as well.
Just Another Security Blog
Tuesday, August 22, 2006
Wednesday, August 09, 2006
Top 10 DNS Infrastructure Best Practices
(This is something I wrote for my company's public newsletter)..
Top 10 DNS Infrastructure Best Practices
A corporation's Domain Name System (DNS) Infrastructure plays an integral, but often overlooked role, in the overall security posture of the network environment. Not only should these services be configured securely, they should also be designed to provide a very high level of availability and redundancy.
1. "Split Horizon" DNS refers to the practice of separating DNS into an external and internal view. This provides a logical separation between the DNS information available to internal network clients and what is made publicly available to the internet at large. DNS store a wealth of information regarding the configuration of a network. Being able to enumerate this information is an invaluable resource for would-be attackers. By separating the publicly available information from that required by internal clients, adds a very critical layer of protection. Split horizon DNS can be accomplished in several methods, but separation on physical devices is the preferred.
2. Recursion in simple terms is the ability of a DNS server to answer client requests for domains which it is not authoritative for. Using a split horizon DNS deployment model, there are two primary sets of DNS servers, internal and external. Internal servers should be configured to perform recursion to service the requests of the internal network clients. However, external DNS servers should be explicitly configured to deny recursion. External DNS servers should solely answer requests for the domains for which they are the authoritative for. Public DNS servers which allow recursion have been recently exploited in as amplification machines in Distributed Denial of Service (DDoS) attacks. Not only does this consume valuable machine and bandwidth resources, but there also could be legal ramifications for an organization whose servers were exploited.
3. DNS by design has the ability to offer a high level of availability and redundancy. An organization should have two or more primary DNS servers. These devices should be both geographic and carrier diverse. Having multiple DNS servers in the same physical location on the same internet connection provides very limited redundancy. A single carrier outage or fiber cut can instantly isolate all of your DNS servers. Instead, these should be distributed in across different geographical regions utilizing different internet providers. This can be accomplished by placing the servers in either a remote office, a collocation facility, or utilizing a hosted DNS provider. Ideally an organization should have a minimum of two (2) DNS servers with three (3) being the recommended number.
4.The NS records for an organization's domain name provide public DNS servers with the information needed to find the authoritative nameservers for that domain. These records are uploaded from your domain registrar to the Top Level Domain (TLD) DNS servers. As changes are made to your DNS infrastructure, its imperative that your NS records updated to reflect these changes.
5. Lame Delegation is a term that is used to refer to servers that are listed as authoritative for a specific domain but do not answer authoritatively. This can cause delayed responses, increased workload on both an organization's and the TLD DNS servers and is a problem that has plagued the internet for several years now. The extent of this problem can be seen by looking for the "Lame" keyword in the server logs of any active recursive DNS server. This problem can be avoided by keeping the NS and SOA records for your domains accurate and up to date.
6. Zone transfers are the ability for a slave DNS server to pull records from a master server to a slave. This allows you to host all of your zonefiles on a master machine and have them automatically propagate to slave machines after a change is made. The ability to transfer an entire zonefile for a domain also provides a easy way for would-be attackers to enumerate an organizations network. Because of this DNS servers should be configured to limit zone transfer requested to the IP addresses of designated slave machines.
7. MX records are the DNS records that allow your organization to receive email. Each domain should have a minimum of two (2) MX records. These records also have a preference number associated with them. The lower numerical value of the preference translates into the higher priority mail gateway. Therefore, if you have two (2) gateways, a primary and a secondary, then the primary would have a MX preference value of ten (10) and the secondary of twenty (20) so that the primary would be the higher priority mail gateway.
8. All MX records should have a corresponding PTR record. RFC1912 dictates that all mail gateways should have Reverse DNS entries configured. Many mail servers are configured to not accept email from gateways which don't have proper Reverse DNS entries.
9. DNS server versions often provide a would-be attacker with valuable information about the DNS application running on that machine. Published exploits corresponding to that specific version of the application can quickly be located and launched. For this reason, DNS server versions should be modified to obfuscate the actual running version number.
10. Zone file serial numbers are used by master DNS servers to inform the salve servers when a zone file has been changed and needs to be transferred. Every time a change is made to the zone file, the serial number should be incremented. If this is not done, DNS zone data can quickly become out of sync, causing enterprise-wide problems.
1. "Split Horizon" DNS refers to the practice of separating DNS into an external and internal view. This provides a logical separation between the DNS information available to internal network clients and what is made publicly available to the internet at large. DNS store a wealth of information regarding the configuration of a network. Being able to enumerate this information is an invaluable resource for would-be attackers. By separating the publicly available information from that required by internal clients, adds a very critical layer of protection. Split horizon DNS can be accomplished in several methods, but separation on physical devices is the preferred.
2. Recursion in simple terms is the ability of a DNS server to answer client requests for domains which it is not authoritative for. Using a split horizon DNS deployment model, there are two primary sets of DNS servers, internal and external. Internal servers should be configured to perform recursion to service the requests of the internal network clients. However, external DNS servers should be explicitly configured to deny recursion. External DNS servers should solely answer requests for the domains for which they are the authoritative for. Public DNS servers which allow recursion have been recently exploited in as amplification machines in Distributed Denial of Service (DDoS) attacks. Not only does this consume valuable machine and bandwidth resources, but there also could be legal ramifications for an organization whose servers were exploited.
3. DNS by design has the ability to offer a high level of availability and redundancy. An organization should have two or more primary DNS servers. These devices should be both geographic and carrier diverse. Having multiple DNS servers in the same physical location on the same internet connection provides very limited redundancy. A single carrier outage or fiber cut can instantly isolate all of your DNS servers. Instead, these should be distributed in across different geographical regions utilizing different internet providers. This can be accomplished by placing the servers in either a remote office, a collocation facility, or utilizing a hosted DNS provider. Ideally an organization should have a minimum of two (2) DNS servers with three (3) being the recommended number.
4.The NS records for an organization's domain name provide public DNS servers with the information needed to find the authoritative nameservers for that domain. These records are uploaded from your domain registrar to the Top Level Domain (TLD) DNS servers. As changes are made to your DNS infrastructure, its imperative that your NS records updated to reflect these changes.
5. Lame Delegation is a term that is used to refer to servers that are listed as authoritative for a specific domain but do not answer authoritatively. This can cause delayed responses, increased workload on both an organization's and the TLD DNS servers and is a problem that has plagued the internet for several years now. The extent of this problem can be seen by looking for the "Lame" keyword in the server logs of any active recursive DNS server. This problem can be avoided by keeping the NS and SOA records for your domains accurate and up to date.
6. Zone transfers are the ability for a slave DNS server to pull records from a master server to a slave. This allows you to host all of your zonefiles on a master machine and have them automatically propagate to slave machines after a change is made. The ability to transfer an entire zonefile for a domain also provides a easy way for would-be attackers to enumerate an organizations network. Because of this DNS servers should be configured to limit zone transfer requested to the IP addresses of designated slave machines.
7. MX records are the DNS records that allow your organization to receive email. Each domain should have a minimum of two (2) MX records. These records also have a preference number associated with them. The lower numerical value of the preference translates into the higher priority mail gateway. Therefore, if you have two (2) gateways, a primary and a secondary, then the primary would have a MX preference value of ten (10) and the secondary of twenty (20) so that the primary would be the higher priority mail gateway.
8. All MX records should have a corresponding PTR record. RFC1912 dictates that all mail gateways should have Reverse DNS entries configured. Many mail servers are configured to not accept email from gateways which don't have proper Reverse DNS entries.
9. DNS server versions often provide a would-be attacker with valuable information about the DNS application running on that machine. Published exploits corresponding to that specific version of the application can quickly be located and launched. For this reason, DNS server versions should be modified to obfuscate the actual running version number.
10. Zone file serial numbers are used by master DNS servers to inform the salve servers when a zone file has been changed and needs to be transferred. Every time a change is made to the zone file, the serial number should be incremented. If this is not done, DNS zone data can quickly become out of sync, causing enterprise-wide problems.
Nessus 3.0 on Gentoo
With the release of Nessus 3.x, the developers have made the decision to no longer distribute source code. Because of this, nessus binaries will only install on "supported platforms". However, I have recently discovered a way around this severe limitation.
This is a quick and dirty guide to get Nessus 3.0 to install on Gentoo.
First, download Nessus-3.0.3-fc5.i386.rpm from nessus.org
Use rpm2targz Nessus-3.0.3-fc5.i386.rpm to convert the package from RPM format to a gzip'ed tar file.
Move the resulting file to your / directory.
Use tar -zxvf Nessus-3.0.3-fc5.i386.tar.gz to decompress and un'tar the file.
Edit /etc/ld.so.conf and append /opt/nessus/lib to the end of the file.
Run ldconfig to make those changes take effect.
Next, cd into your /usr/lib directory and do the following:
ln -s libssl.so.0.9.7 libssl.so.6
ln -s libcrypto.so.0.9.7 libcrypto.so.6
You can now finish installing nessus as normal (e.g /opt/nessus/sbin/nessus-mkcert). You can also test your installation by running the command: /opt/nessus/sbin/nessusd -d
[UPDATE] You will need to edit /opt/nessus/sbin/nessus-update-plugins . Look for the line reading "gzip=/usr/bin/gzip" and change it to read "gzip=/bin/gzip"
[UPDATE 2] Instead of making the change to /etc/ld.so.conf above, you should create a file in the /etc/env.d/ directory called 08nessus. Then file should only contain the line: LDPATH=/opt/nessus/lib. This change is necessary because the env-update script will overwrite the changes you make directly to /etc/ls.so.conf.
This is a quick and dirty guide to get Nessus 3.0 to install on Gentoo.
First, download Nessus-3.0.3-fc5.i386.rpm from nessus.org
Use rpm2targz Nessus-3.0.3-fc5.i386.rpm to convert the package from RPM format to a gzip'ed tar file.
Move the resulting file to your / directory.
Use tar -zxvf Nessus-3.0.3-fc5.i386.tar.gz to decompress and un'tar the file.
Edit /etc/ld.so.conf and append /opt/nessus/lib to the end of the file.
Run ldconfig to make those changes take effect.
Next, cd into your /usr/lib directory and do the following:
ln -s libssl.so.0.9.7 libssl.so.6
ln -s libcrypto.so.0.9.7 libcrypto.so.6
You can now finish installing nessus as normal (e.g /opt/nessus/sbin/nessus-mkcert). You can also test your installation by running the command: /opt/nessus/sbin/nessusd -d
[UPDATE] You will need to edit /opt/nessus/sbin/nessus-update-plugins . Look for the line reading "gzip=/usr/bin/gzip" and change it to read "gzip=/bin/gzip"
[UPDATE 2] Instead of making the change to /etc/ld.so.conf above, you should create a file in the /etc/env.d/ directory called 08nessus. Then file should only contain the line: LDPATH=/opt/nessus/lib. This change is necessary because the env-update script will overwrite the changes you make directly to /etc/ls.so.conf.
Subscribe to:
Posts (Atom)