Tuesday 22 October 2019

Netstat command



 Below netstat commands are helpful while troubleshooting the Socket timeout issue. 


  • ·         netstat -ie                          -- to show all interfaces
  • ·         netstat –r                            -- show current rounting table
  • ·         netstat –C                           -- show the current active connection
  • ·         netstat -at                            -- show all the current connection,
  -l    -- listen on local machine
  -p  -- processes

  • ·         netstat -tanp | grep PID
  • ·         netstat -nap | grep :Port
      Most of the 11 TCP states are easy to understand and most programmers know what they mean:
CLOSED: There is no connection.
LISTEN: The local end-point is waiting for a connection request from a remote end-point i.e. a passive open was performed.
SYN-SENT: The first step of the three-way connection handshake was performed. A connection request has been sent to a remote end-point i.e. an active open was performed.
SYN-RECEIVED: The second step of the three-way connection handshake was performed. An acknowledgement for the received connection request as well as a connection request has been sent to the remote end-point.
ESTABLISHED: The third step of the three-way connection handshake was performed. The connection is open.
FIN-WAIT-1: The first step of an active close (four-way handshake) was performed. The local end-point has sent a connection termination request to the remote end-point.
CLOSE-WAIT: CLOSE_WAIT means the operating system knows that the remote application has closed the connection and waits for the local application to also do so.
FIN-WAIT-2: The remote end-point has sent an acknowledgement for the previously sent connection termination request. The local end-point waits for an active connection termination request from the remote end-point.If the count is high then may be there is some issue, application is not closing the connection properly. Lots of FIN-WAIT-2 connection ead to a memory overflow.
LAST-ACK: The local end-point has performed a passive close and has initiated an active close by sending a connection termination request to the remote end-point.
CLOSING: The local end-point is waiting for an acknowledgement for a connection termination request before going to the TIME-WAIT state.
TIME-WAIT: The local end-point waits for twice the maximum segment lifetime (MSL) to pass before going to CLOSED to be sure that the remote end-point received the acknowledgement

Thursday 26 September 2019

Secure WebLogic Cookie





A common Web security problem is session stealing. This happens when an attacker manages to get a copy of your session cookie, generally while the cookie is being transmitted over the network. This can only happen when the data is being sent in clear-text; that is, the cookie is not encrypted.
WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:
<WebServer Name="myserver" AuthCookieEnabled="true"/>
Setting AuthCookieEnabled to true, which is the default setting, causes the WebLogic Server instance to send a new secure cookie, _WL_AUTHCOOKIE_JSESSIONID, to the browser when authenticating via an HTTPS connection. Once the secure cookie is set, the session is allowed to access other security-constrained HTTPS resources only if the cookie is sent from the browser.
Thus, WebLogic Server uses two cookies: the JSESSIONID cookie and the _WL_AUTHCOOKIE_JSESSIONID cookie. By default, the JSESSIONID cookie is never secure, but the _WL_AUTHCOOKIE_JSESSIONID cookie is always secure. A secure cookie is only sent when an encrypted communication channel is in use. Assuming a standard HTTPS login (HTTPS is an encrypted HTTP connection), your browser gets both cookies.
For subsequent HTTP access, you are considered authenticated if you have a valid JSESSIONID cookie, but for HTTPS access, you must have both cookies to be considered authenticated. If you only have the JSESSIONID cookie, you must re-authenticate.
With this feature enabled, once you have logged in over HTTPS, the secure cookie is only sent encrypted over the network and therefore can never be stolen in transit. The JSESSIONID cookie is still subject to in-transit hijacking. Therefore, a Web site designer can ensure that session stealing is not a problem by making all sensitive data require HTTPS. While the HTTP session cookie is still vulnerable to being stolen and used, all sensitive operations require the _WL_AUTHCOOKIE_JSESSIONID, which cannot be stolen, so those operations are protected.
You can also specify a cookie name for JSESSIONID or _WL_AUTHCOOKIE_JSESSIONID using the CookieName parameter defined in the weblogic.xml deployment descriptor's <session-descriptor> element, as follows:
<session-descriptor>
    <cookie-name>FOOAPPID</cookie-name>
</session-descriptor>
In this case, Weblogic Server will not use JSESSIONID and _WL_AUTHCOOKIE_JSESSIONID, but FOOAPPID and _WL_AUTHCOOKIE_FOOAPPID to serve the same purpose, as shown in Table 3-1.