azizkhani.net

I know that I know nothing

WEBLOGIC BEA-002616: Failed to listen on channel on listenAddress:port

clock February 11, 2013 18:52 by author Administrator

Technology, KeyWords:

WebLogic Server 10.3, Cluster, Exception; Too many open files, Socket, Linux, SLES

Error Message: <BEA-002616> <Failed to listen on channel "Default"…>

 

Problem:

<Critical> <Server> <BEA-002616> <Failed to listen on channel "Default" on IP_NR:Port, failure count: 1, failing for 0 seconds, java.net.SocketException: Too many open files>

 

Description

Weblogic declaration from: http://docs.oracle.com/cd/E23549_01/apirefs.1111/e14397/Server.html

BEA-002616

Critical: Failed to listen on channel "channel" on listenAddress:port, failure count: fails1, failing for secs2 seconds, e3

 

Description

The server listener will retry the listen after a short delay.

 

Cause

The server got an exception while trying to accept client connections. It will try to backoff to aid recovery.

 

Action

The OS limit for the number of open file descriptor (FD limit) needs to be increased. Tune OS parameters that might help the server to accept more client connections (e.g. TCP accept back log).

 

More detail and Background information:

“Tune OS parameters” depends on OS which you use. For Linux, kernel parameters need adjustment- exact details depend on the distribution. There are individual user limits for open files. You can use `ulimit -a` command to find out the Linux for the user that owns.

You can find information regarding the important parameters e.g. number of "open files" or similar entry. Please consider, in AIX, the user limits apply as well as a system OS configuration for the total number of open files allowed on the host.

 

 

Solution

Here is an example how can you check and isolate the position of error.

 

1-    Check linux configuration (e.g. on host XXX):

> ulimit –a

core file size          (blocks, -c) 1

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 127575

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) 13887980

open files                      (-n) 65600 à OK

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 127575

virtual memory          (kbytes, -v) 17749200

file locks                      (-x) unlimited

 

The open file descriptor limit is at 65600 as recommended by Oracle.

 

2-    Check currently open files

a.    Find PID of Managed Server

> ps -fea|grep myManagedServer

 

b.    Check open files

Please use lsof (list open files) that lists information about files opened by processes

You see list of open files via (e.g.PID is here 1234)

>lsof -p 1234  

 

In order to findour the number of open files:

> lsof -p 1234 | wc –l

 

In this case, we observed that application has 13 thousand connections on "CLOSE_WAIT" status. This usually happens when the application doesn't close the connections properly:



Cross-Site Request Forgery (CSRF)

clock February 5, 2013 23:26 by author Administrator

Nowadays, web application security is one of the most important issues in the information system development process. According to Gartner [1] the 75% of the attacks performed nowadays are aimed to web applications, because operative system security and net level security have increased considerably. As a result, it is considered that the 95% of the web applications are vulnerable to a certain type of attack [2]. In the following chart we can see the list of the most important vulnerabilities published by OWASP (Open Web Application Security Project)

 

Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a type of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have authenticated.

Example: One user, Bob, might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references a script on Bob's bank's website (rather than an image file), e.g.,

CSRF

If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then Bob's browser's attempt to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Mallory's direction.

The following characteristics are common to CSRF:

  • Involve sites that rely on a user's identity
  • Exploit the site's trust in that identity
  • Trick the user's browser into sending HTTP requests to a target site
  • Involve HTTP requests that have side effects

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user that is authenticated by a cookie saved in his web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action.

CSRF attacks using images are often made from Internet forums, where users are allowed to post images but not JavaScript.

Effects

This attack relies on a few assumptions:

  • The attacker has knowledge of sites the victim has current authentication on (more common on web forums, where this attack is most common)
  • The attacker's "target site" has persistent authentication cookies, or the victim has a current session cookie with the target site
  • The "target site" doesn't have secondary authentication for actions (such as form tokens)

While having potential for harm, the effect is mitigated by the attacker's need to "know his audience" such that he attacks a small familiar community of victims, or a more common "target site" has poorly implemented authentication systems (for instance, if a common book reseller offers 'instant' purchases without re-authentication).

Protection

Applications must ensure that they are not relying on credentials or tokens that are automatically submitted by browsers. The only solution is to use a custom token that the browser will not ‘remember’ and then automatically include with a CSRF attack.

The following strategies should be inherent in all web applications:

  • Ensure that there are no XSS vulnerabilities in your application.
  • Insert custom random tokens into every form and URL that will not be automatically submitted by the browser. For example,

    CSRF protection

    and then verify that the submitted token is correct for the current user. Such tokens can be unique to that particular function or page for that user, or simply unique to the overall session. The more focused the token is to a particular function and/or particular set of data, the stronger the protection will be, but the more complicated it will be to construct and maintain.

  • For sensitive data or value transactions, re-authenticate or use transaction signing to ensure that the request is genuine. Set up external mechanisms such as e-mail or phone contact in order to verify requests or notify the user of the request.

  • Do not use GET requests (URLs) for sensitive data or to perform value transactions. Use only POST methods when processing sensitive data from the user. However, the URL may contain the random token as this creates a unique URL, which makes CSRF almost impossible to perform.

  • POST alone is insufficient a protection. You must also combine it with random tokens, out of band authentication or re-authentication to properly protect against CSRF.

While these suggestions will diminish your exposure dramatically, advanced CSRF attacks can bypass many of these restrictions. The strongest technique is the use of unique tokens, and eliminating all XSS vulnerabilities in your application.

It should be noted that preventing CSRF requires that all XSS problems are removed first. An XSS flaw can be used to retrieve the form, then grab the random tokens before submitting the CSRF request. XSS may also be able to spoof the user into entering their credentials, which would allow the CSRF to bypass re-authentication as well.

CSRF has been called the "sleeping giant" of web application security flaws, because it has yet to be exploited widely. It is only a matter of time, web programmers should be making the changes needed to ensure that their sites are not vulnerable.

 

 

 

and now ...... http://hdiv.org/index.htm    :D



About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List

Sign In