Almost a week ago I got an call for problem which is related to log4j and weblogic. Due to some instruction for making an application SOX compliant one devlopment team has intigrated lots of process to be logged through a log4j .
Application is java base and deployed in weblogic. But soon after starting the application and after very few transaction application stopped responding . After a very hard diagonis to catch a real problem we get to know that the poroblem is actually is of File Descriptor. (A file descriptor is a handle created by a process when a file is opened. A new descriptor is created each time the file is opened. It is associated with a file object which includes information such as the mode in which the file was opened and the offset pointer where the next operation will begin. This information is called the context of the file. File descriptors are retired when the file is closed or the process terminates. Opens always choose the lowest-numbered file descriptor available.)
On Solaris, each user account has a certain limited number of file descriptors. Use the ulimit command to print or set resource limits. A resource limit is a pair of values that specify the current (soft) limit and the maximum (hard) limit. You can modify the hard limit in /etc/system. You must reboot your machine anytime you modify /etc/system.
Note: Do not change the default soft limit. It has the potential to affect many processes on the server and will not affect WebLogic Server.
You must have adequate permissions to use the ulimit command. Any user may lower a hard limit. Only a super-user may raise a hard limit.
To view and adjust file descriptor limits:
1. Use the ulimit command to print current resource limits.
ulimit
2. Set the hard limit value in /etc/system, according to your needs. For example:
set rlim_fd_max=4096 /* hard limit */
3. Restart WebLogic Server.
A message will appears in the startup log.
SightQuest : Computer Security - Antivirus aides, virus threats, online protection, patches, and information.
Sunday, November 27, 2005
Best practices for implementing spam control
Spam-catching is a tricky game. It's a dimension more difficult than antivirus. An antivirus laboratory makes a binary decision: Is it a virus? Is it not a virus? Yes. No. And we want the lab to be right every time.
The antispam game, however, is triage. There are messages that can be clearly identified as spam, and messages that can be clearly identified as not-spam, and then there is a pile of messages left over that are neither black nor white; they are gray. What are we going to do with the gray pile? What is in it, and why is it so tricky?
"Good guys" vs. "bad guys"
There are four categories of spam:
- No. 1: Confidence games, pornography, and unethical senders
- No. 2: Chain letters, hoaxes, and urban legends
- No. 3: Legitimate offers from legitimate senders
- No. 4: "Occupational spam" from your colleagues
The job at the boundary is to sort out the good guys (No. 3 and No. 4) from the bad guys (No. 1 and No. 2). If a message is from one of the bad guys, you can request removal from their mailing list ("unsubscribe"), but your request will serve only to validate your address, and you will receive more spam. If it's from one of the good guys, they should be practicing ethical permission-based marketing: In other words, you can safely unsubscribe and the sender should politely stop sending additional messages.
Best practices for controlling spam
Tuning for the business
You can't just look for specific banned words and expect to make the right decisions every time. For example, if you have a department working on a cure for prostate cancer or designing bicycle seats, there may well be some anatomical terms that will come up in the normal course of doing business that might also be on the dirty-words list. Rules that perform some contextual analysis can help: if the word "breast" is in the same sentence or paragraph with the word "cancer," then it's okay.
Spicy language
It's one thing to ask your employees not to use spicy language when corresponding with a client, but it's hard to ask your clients not to use it. If an angry client writes a fiery message full of inappropriate language, should this be identified as spam and quarantined, or should it be handled in some other way? The answer is a business decision.
Foreign words and phrases
One group of attorneys was experiencing rejection of their messages sent to a number of clients until they finally realized it was because they had a lot of smart people on staff who had graduated magna cum laude. There's a Latin word in there that also happens to appear on the dirty-words list. Another client with offices in Sweden discovered that the word "slut" in Swedish means to complete the project. The enterprise had to adjust its filters to permit this word.
Rate of false positives
Some clients are asking what the rate of false positives is for a given product. A false positive is a message that's captured, or flagged, as spam, that was a bona fide message you don't want to lose. You should be able to tune the capture rate of a product and work with it to reduce false positives. But that will mean you will have false negatives. Because this is not a perfect science, it may well require human review to make the final determination.
Formula to calculate spam capture
The capture rate (CR) and false positive rate (FP) are related by a quotient based on the efficiency of the filter system. As CR increases, so does the FP. No product can achieve CR=100 and FP=0. If the vendor makes this claim, it does not fully understand the complexity of the game. You can approach FP=0 by tolerating a lower CR, or you can maximize CR by tolerating an elevated level of FP, but you can't have both.
The best antispam products have the highest rates of confidently identifying spam (for example, we've seen it before). No matter how elegant, systems that examine the header and body will not always be right, but they should tell you how confident they are that this is spam (for example, 85 percent sure vs. 55 percent sure that this is spam). When dealing with the "gray pile," you will need tools to tune the system for your business. Based on the point scale or confidence rating, you can participate in deciding how a given message should be handled. Through 2003, e-mail spam capture rates in excess of 85 percent will result in false positive rates of 5 percent or greater.
Developing a comfort level
When you implement any antispam product or service, you should never begin deleting flagged messages on Day 1. You should stage the implementation and enroll your users in the validation process. Keeping an open and courteous channel of communication with your employees is an essential part of any spam-control program.
Reporting
You can use reporting to help size the problem and possibly test the rules. If you were to turn on this rule set today, how many messages would have been deleted? How many would have been quarantined? How many would require human review? How many staff members would be required to do the human review?
Marking headers
The second step is to turn on the rules but only mark the headers. At this point, you can see the decision-making in action, and you can evaluate whether you agree. Again, you are not yet stopping messages but are evaluating in combination with the reporting what level of effort would be required if you were to stop these messages.
Quarantine
As a third step, quarantine the most egregious messages, those with the highest point score or confidence rating (most probably spam). For example, quarantine all messages with confidence ratings greater than 85 percent. Let that run for a week or so and validate with the users how that looks. Gradually increase the number of messages quarantined by using a lower confidence threshold: 80 percent confident, then 75 percent confident, then 70 percent confident, possibly putting the newest 5 percent into a separate pile so that you can review it closely and watch for false positives. By creating an additional rule, you may prevent the false positives you find, as in the examples above.
As you approach midrange, you need to decide what approach to use for the messages with confidence ratings of 45 percent to 65 percent. What do you do with these? Clearly, the automated system cannot make the final decision. You need to make the decision that's right for your environment. Often, our clients simply mark the header, note that there is a possibility this is spam, show the reasons for that concern, and let the end user decide. At this point, the most offensive messages should have been deleted, and the possibility that this is a legitimate message is high.
Choices for this group are:
- Mark and pass through.
- Mark, pass through, and send a copy to a collection for review. You may find that with some additional rules, you could change the odds.
Directory Add URL-Free.com
Design your Active Directory tree with security in mind
Successfully designing an Active Directory (AD) tree is no small feat. AD has many different components and concepts that can easily confuse and intimidate a new Windows 2000 administrator. When designing your tree, you must consider business needs, site locations, administrative overhead and, most importantly, security. In this Daily Drill Down, I’ll show you how to design an AD tree that takes into account all of these needs—especially security.
Why use Active Directory?
The main benefit of using AD is that you can centralize the management of your entire Windows network. AD is designed to support millions of objects within the database. With AD, you canget rid of your legacy resource domains, which will allow you to reclaim the hardware required to keep these domains active while also eliminating the administrative headaches.
You can use AD to create increased policy-based desktop security and software distribution with the tools included with Windows 2000 server. AD allows you to delegate administrative control to personnel for simplified tasks, such as DHCP and the addition of new systems to the network. You can also search for printers and other shared resources, which simplifies installation and increases usefulness to the client user.
AD integrates with other programs and features that add security and manageability. Group policies can make the management of your users and resources easier by providing policy-based administration. Exchange 2000 adds a layer of messaging to your AD setup. With the ability to add MSN Messenger and e-mail information, Exchange 2000 adds to the schema of AD.
Although not originally included with the AD install, integrated public key infrastructure (PKI) services available from third parties allow you to use public cryptography keys for securing your infrastructure. AD is based on Kerberos, an open standard for using authentication and encryption. Adding PKI services to AD gives you that extra bit of data security.
By using AD as the core of your network management system, you’ll have the ability to scale the system, while still keeping your security concerns manageable. If you need to add further security to AD beyond what Microsoft ships with Windows 2000, Microsoft also recommends some third-party management applications that add more granular features to AD. You can find out more about these third-party applications at Microsoft’s Active Directory Deployment and Administration Web site.
AD provides a granular security model so you can dish out rights only to the people who need them. The best way to set up a secure AD is to evaluate your existing policies and create a plan to alter them based on the new AD abilities.
Start with forest planning
Creating a detailed plan for your forest schema before you begin building an AD tree will save you from having to reorganize your AD users and resources later. A forest is the top of the chain when it comes to administrative control. In total, AD consists of a schema, configuration information, a global catalog, and trusts with domains in the forest.
Your schema contains the information and attributes about everything stored in the forest. The schema is a template for which information is stored in the database. A schema in an AD installation is replicated to every domain controller in your forest.
Configuration objects are like the cells in an Excel spreadsheet. The configuration containers have data defining the infrastructure, such as domains, sites, and site links. Just like the schema, the configuration containers are also replicated throughout your network to all the domain controllers.
Because networks contain a lot of information, you don’t want queries to each database/domain controller every time someone searches for a printer. This is where the global catalog comes in. The global catalog keeps a scaled-down version of the AD information that is most often searched. This increases the speed of the system, especially if you have slow links throughout your organization. Every domain controller that is running the global catalog in the forest, regardless of the domain to which it belongs, has an exact copy of the current global catalog.
The AD database is very scalable—well into the millions of objects. Because of this scalability, there is no technical reason for you not to use a single forest. Some organizations choose to separate their forests for administrative reasons. One of the first steps in AD design is to choose which of the three acceptable models of AD you want to use:
- Single forest design: This is the most simple of the three models. All directory objects are in a single AD database and have one root domain. With one forest, your administrative costs are lower than with multiple databases. Microsoft recommends you use the single forest design if at all possible.
- Subscription forest design: This is a blend of the single and multiple forest design concepts. This design is sometimes used when an organization is phasing AD into multiple units within the same business. If some business units have already started adopting AD, they can begin creating their forest and then integrate it into the main corporate forest later. Then, in the exterior forests, the administrators can manage security and shared information in their own forest without being concerned with what is going on in the main forest.
- Multiple forest design: This model is best used when the business units have their own administrators and must manage their systems and security away from the rest of the organization. This the most complex configuration, and your administrative overhead is the greatest because you need to administer each forest independently and apply security and policies on each subsystem.
If AD already exists in your organization, you have the choice of participating in the existing structure or going it alone and creating your own forest. If you have your own forest, you gain the ability to control your data in the way that your unit requires, and you aren’t limited to the greater control of a system-wide administrator. However, if you have a single administrative group, a shared forest with domains gives you the same controls.
When you use a single forest to share all your domains, managing the entire network becomes much easier. Any schema changes you make become global, affecting all domains in the forest. Configuration and security changes will affect all resources in your organization. You’ll have one global catalog for all of your users, and you won’t have to troubleshoot any issues with the systems taking affinity to another catalog. And, best of all, security trust relationships will be automatic between the domains that are in your forest.
There is only one technical reason that may limit your ability to have a single forest. If you’ve deployed a network address translation (NAT) firewall between your domain controllers, and you can’t use a VPN to connect the two sites, you must have independent forests that have trusts set up.
The problems of working with multiple forests
When you have more than one forest in the same organization, a couple of caveats can give you headaches as an administrator. Not the least of these is the fact that having multiple AD forests will greatly increase your administrative overhead and cost.
One of the key things you lose when you use multiple forests is the automatic trust relationship between servers. Domains and servers within a single forest inherently trust one another. If you want to access resources in another forest, you must manually create the trust between the two forests. Beyond trust issues, some of the other complications created by multiple forests include the following:
- Kerberos authentication will not occur between the two forests. Each forest contains its own Kerberos encryption key for the root domain, which can’t be passed between forests.
- Client systems can belong to only one forest at a time.
- Multiple forests dictate multiple global catalogs, which increases complexity and the chance of failure.
- You have to use additional applications to replicate the information across the forest boundary.
In short, to maximize security and minimize network administrative overhead, create a single forest.
Logical domain design
Within a forest, you create domains to prevent data from replicating to every point in the network, and to segment users and resources into logical groups. This allows easier administration and reduces the replication bandwidth needed for data transfer. You also gain scalability by segmenting your network into smaller slices, allowing the network to grow to an almost unlimited size.
A domain is also used for authentication of your users and the resources that they require, groups they are organized into, and computers that are allowed to log into the network. Within the domain, you can assign policies to users, groups, and even computers, and standardize the system configurations across your organization. This helps reduce the cost of managing your workstations. You can also assign some additional policies to users, such as passwords and logon policies.
Domains can also serve as a repository of information about resources, such as printers, SQL servers, and mail servers. This gives users the ability to search for resources with a simple search entry instead of having to browse through the network, thereby reducing the calls for help to add printers and other resources.
The first domain in your forest is assigned the role of the root domain. All other domains in the forest will be built upon this root domain to define the AD hierarchy. Two groups are contained in the root domain: the Enterprise Administrators and the Schema Administrators. These groups will give access to a select few superadministrators to manage your entire forest and all the domains that are contained therein.
It’s best to keep other users out of this root domain and create all of your objects in a subdomain. By having a dedicated domain, you have fewer administrators with the ability to make forest-wide changes. Since the root domain can never be changed, you can move subdomains around without affecting the root. So if a unit or your business changes its name, you don’t have to set up an entirely new forest. You just change the domain instead.
Domain name services
With AD comes a new way to search and find resources. Domain name services (DNS), adopted from the Internet DNS, replace NetBIOS names via Windows Internet Name Service (WINS). DNS is a highly scalable design that's the backbone service mapping names to IP addresses.
For security reasons, I recommend having an internal, private DNS server for use with your Active Directory. If the DNS server is compromised or becomes unavailable, the entire AD system and your network will come to a complete stop. After setting up AD, there will be a new option within the DNS control panel that activates DNS integration with AD and stores DNS objects in the AD schema. You should always have more than one DNS server, as well as a domain server for each domain. Having multiple DNS servers prevents interruptions of service in case one DNS server fails.
Organizational units in Active Directory
Organizational units (OUs) are containers within the domain that contain users, groups, computers, and other OUs. This allows you to nest OUs for management purposes.
With OUs, a department can manage its own resources within the domain. This delegation allows for distributed management of the network resources, which reduces administrative costs for the overall network. This lets the forest and domain administrators manage the directory service, while delegating smaller tasks to regional personnel.
With the OU structure, you set up delegation of administrative tasks. Place the users, systems, and other objects in an OU, and then delegate that OU to the user or other OU that you want to manage that group. Doing so will help reduce the number of administrators with high-level access, and it will provide the right amount of control to the users who need to manage a smaller number of people without full administrative control.
OUs also allow you to set up effective group policies that can help you secure your entire network. You can apply policies to an OU, thereby managing logon, password, and Kerberos policies. Group policies cannot be applied to the default Users And Computers container. Although it may appear to be an OU, it’s not.
Controlling replication with site topology
Domains allow you to control which AD data is replicated to which locations. For remote sites, you don’t want your entire directory going off-site. This is where your site topology is helpful. You can define your sites and what domains are replicated to other sites for authentication or disaster recovery purposes. Doing so can reduce the amount of network connectivity that is needed at each domain site.
Only the beginning
Defining policies, setting up domains, and creating your forests are sizable tasks. Once you get started, you’ll see that this project will take weeks to plan—if you do it correctly—but only about 30 minutes to set up. When you take time in advance to include security as a part of your AD design, you’ll end up with a more secure and easily administered network.
Reduce vulnerability by limiting your network's reach
Large blocks of networks have recently taken advantage of zero-day exploits to steal financial data. Attackers manipulated an exploit to transmit an individual's financial information to a country with a poor record of tracking and prosecuting Internet criminals.
I won't mention the name of the country, but these networks are beyond the law enforcement boundaries of most civilized nations. How do you prevent hackers from performing such an attack on your organization's network?
You can regain control of your network by answering a few questions about the purpose of your organization's network:
- Do we have a global business?
- Is our business local or regional?
- Do our internal users need access to every network on the planet?
Answering these questions can greatly limit your company's exposure to attacks beyond the reach of law enforcement in your country. If your business is local or regional, you only need to worry about who else is in your area of the world.
Do your research
The Internet is a big place, and one organization runs it: the Internet Assigned Numbers Authority (IANA). It divides all public IP addresses among the Regional Internet Registries (RIRs) to distribute blocks of IP addresses.
There are four RIRs:
- Asia Pacific Network Information Centre (APNIC) for Asia and the Pacific region
- American Registry for Internet Numbers (ARIN) for North America, parts of the Caribbean, and sub-equatorial Africa
- Latin American and Caribbean Internet Addresses Registry (LACNIC) for Latin America and parts of the Caribbean
- RIPE Network Coordination Centre (RIPE NCC) for Europe, the Middle East, Central Asia, and African countries above the equator
By performing a little bit of detective work at each site, you can determine which IP addresses originate from each country or region.
Combining this information with your answers to the questions about the purpose of your organization's network, you can begin to diminish your vulnerability to hostile networks and concentrate on serving your organization's target communities.
Limit network exposure
Let's look at an example. If a business network serves only the European community, then you could block every IP address at the network boundary that doesn't originate from this area. For example, you would block everything except the following networks:
62.0.0.0 - 62.255.255.255
80.0.0.0 - 80.255.255.255
81.0.0.0 - 81.255.255.255
82.0.0.0 - 82.255.255.255
83.0.0.0 - 83.255.255.255
84.0.0.0 - 84.255.255.255
85.0.0.0 - 85.255.255.255
86.0.0.0 - 86.255.255.255
87.0.0.0 - 87.255.255.255
88.0.0.0 - 88.255.255.255
193.0.0.0 - 193.255.255.255
194.0.0.0 - 194.255.255.255
195.0.0.0 - 195.255.255.255
196.200.0.0 - 196.207.255.255
212.0.0.0 - 212.255.255.255
213.0.0.0 - 213.255.255.255
217.0.0.0 - 217.255.255.255
Apply this block or access list to both inbound and outbound traffic. In addition, integrate this strategy into any existing blocks or filters for services you already have in place.
Subscribe to:
Posts (Atom)