Unix Tip : Process -> ports and viceversa

the basic is :
lsof | grep ldap
lsof | grep firefox

advance:
lsof -i :389
lsof -p pidnumber

>>>>>>>>>>
In linux:
netstat -putanuw

Socket

Sock Application (e.g., Netscape) - OSI layer 7 Application
|
SOCK DLL/library - socket() - binding to a port to make it listen
|
TCP/UDP - OSI layer 4 Transport
|
IP/IPX
|
Modem or Network card
|
Network

Above is also called TCP/IP stack (stack is LIFO - last in first out)

TCP/IP stack is loaded into a memory space.

KERNEL = TCP/IP + NLB driver + network adapter driver

In unix :
driver/module in .so = shared object or .ko = kernel object (related with memory segmentation)
insmod, lsmod, rmmod

Unix Trip : how to get your gateway address

$ arp
Address HWtype HWaddress Flags Mask Iface
d6e-cd-br-cen ether 00:06:d6: C eth0
gate-bro- ether 00:00:0c:07: C eth0

arp -a
d6e-cd-b.com (9.158.) at 00:06:d6:: [ether] on eth0
gate-br.com (9.158.1) at 00:00:0c::: [ether] on eth0

WAS : express, base, ND

Express is like tomcat, only WAR no EJB module. Furthermore single instance for dev-prod to simplify the deployment.

Base, able to handle EJB module. Not support cluster and only support server1 Appserver.
Server1 cant be started or stopped using ISC.

ND, support cluter and multi app servers.

Note :
About ISC :
there is a isclite.ear module in config/cells/node/applications/ if ISC is installed.
In base, you may not install ISC, nor defaultapp (snoop/hello), nor sampleApp(plant)
But you are auto installing the ivtApp.ear and query.ear.
IvtApp.ear is used during the firstStep to verifiy instalation result, like start hem and test the ports.

About trial period:
can be tricked by changing the date of the OS.

Security 3 : websphere, plugin, IHS key database

IHS --> SSLengine ON
Certificate location
keyfile location
chainfile location

Plugin : CMS type=> .kdb
ikeyman tools => generate self-signed cert
extract it to a .arm file
transfer it to a WAS servers to be put it in key (or trust file)
more precisely is "ADD" in signer certificate (not personal certificate)

WAS : jks = javakeystore => a db file of certicates collection (new generated by ikeyman tool)
a. one.jks => private key and trusted certs are here
b. key.jks and trust.jks => private key in key.jks while trusted certs in trust.jks

ikeyman tools ==> generate self-signed cert in personal certs
extract it to a .arm file
transfer it to a Plugin servers to be put it in key.kdb
==> signer certificates => ADD
I wonder why, we need "add" to signer certs as well in WAS side.

If you use LDAPS in WAS, then you "add" also the ldap server certs in that jks file.

Note : 1. dont forget to set the path in ISC to the correct location of jks file
2. ikeyman tools is GUI, gsk7cmd is CLI,
3. keytool can be used as well to read the jks wihtout password
4. during the creation of jks, it prompts password, this password is encrypted in a stash file.
5. .arm = .cer
6. keyring = keystore
7. signer certificate = trust certs = ssl from client side
8. key = private key = ssl from server side

reference : http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.websphere.v4.doc/wass_content/06061801a07.html

Security 2 : certificates, CA, SSL

How browser and SSL web server connected:

1. browsers usually have the "trust root CA" already which means have those public key
2. first it will work in asymmetric method
3. Certificate of web server containing CN/domain name, digital signature CA (result of encrypting priv key CA : maybe with HASH), HASH (or fingerprint), public key of the web server.
4. Pub key in browser will decrypt the dig signature CA
5. It will get the HASH and compare with the HASH in the certificate
This verify if the CA is really the CA, example: this Cert really come form verisign.
6. After browser verify it, it use the public key web server in the certs to encrypt the req along with sessionID
7. Web server got it and decrypt using it priv key.
8. At this point, web server will do the symmetric key encryption using the sessionID as the shared code.

Note : Dont be confused, there are CA key pair and also web server key pair.
Asymmetric encrypt is slower than symmetric.

>>>>>>>>>>>>>>>>>>>>>>>>>>>

In unix use openssl command
First you generate the priv key RSA.
then from that you create a .csr file. CSR : certificate request
which need some input as domain name, etc.....
then you send the .csr to a CA
if it is commercial CZ, they may contact you for verify and to be paid
then CA will send you the .cert files/.arm files
set the cert localtion on the virtual host section of your http
also set the key file location in the same section
also set the SSLCertificateChainFile in the same section.
==> this last file is a plain text file containing the structure intermediate CA up to root CA
==> explain later on in next


>>>>>>>>>>>>>>>>>>>>>>>>>>

CA :
A. private CA
B. commercial CA

1. root CA : the root, issued to and issued by itself, and signed by it self.
2. intermediate CA : the derivatives up to several level, issued by : rootCA/above intermediate CA
issued to : itself. signed by the ROOT CA or above intermCA.

In secure case : root CA is std alone, intermediate CA is in network. You create csr in intermCA, bring it over usb to root CA. you generate the cert, and bring over usb again to intermCA, and install it. Now you have rootCA signed cert at your intermCA.
Now you can create any new certs to be used by web servers.
Remember in web servers, you need set the chain file (in order client browser can auth the intermCA upto the rootCA).

reference: http://usefulfor.com/nothing/2008/03/20/howto-create-an-intermediate-certifica-authority-ca-using-openssl/

chain file looks like:

--BEGIN--
FDARGARGAGAGFDGFDGDCCCC
the intermCA2
DSFSDGDSFHSHSHSD%^GG#TG
--END--
--BEGIN--
the intermCA1
--END--
--BEGIN--
the rootCA
--END--


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

summary : certificate is public key with some info of your data
can be digitally signed by a CA or commercial CA
digitally sign means as written in digital signature workflow

Security 1 : Asymmetric, symmetric, hash, digital signature, email encryption

Symmetric : shared code
Asymmetric: pair key - public & private

Hash : SHA or MD5 ==> algorithm to make a data into short form, use to verify if data altered or not along the way. Example : email + hash = 010101100 (this is called fingerprint)

Digital signature ==> fingerprint + private key encryption

you sent : email + digital signature (for now we ignore the email encryption)

recipient has your pub key!
recipient also has the hash!
==> first it will hash the email and it will get the fingerprint 010101100
==> second it will decrypt the dig signature with the pub key and it will get the fingerprint
==> A. comparing the fingerprint step 1 and 2 above, if not equal then email was altered!!
B. also if the pub key failed to decrypt at step 2, then it means the private key wrong, which could means it was not sent by the real person (bcoz private key is only had by the real)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Now, about email encryption:
the encryption is done by the pub key, and is called RSA method.

Sender has the pub key of recipient and encrypt the email with it.
Recipient will use his priv key to decrypt it.

Note : Even if someone else has recipient pub key, it does not mean he can reverse back the data. Only one who has private key can decrypt it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>