Tennet port disable on SAN SW

Clone the existing Ipfilter

    Remove the rule to allow traffic on port 23

    Define new rule to deny traffic on Telnet port 23

    Save and activate the new iptables configuration

 

Table of Contents

 

    View existing iptable configuration

    Clone existing configuration

    Modify the cloned ipfilters

    Save configuration and activate ipfilters

    Removing an ipfilter

    Sources

 

View existing iptable configuration

 

To show the current ip filter rules, enter: ipfilter –show

 

STORFOS:FID128:storcom> ipfilter --show

 

Name: default_ipv4, Type: ipv4, State: active

Rule    Source IP                               Protocol   Dest Port         Action

1     any                                            tcp       22            permit

2     any                                            tcp       23            permit

3     any                                            tcp       80            permit

4     any                                            tcp      443            permit

5     any                                            udp      161            permit

6     any                                            udp      123            permit

7     any                                            tcp      600 - 1023     permit

8     any                                            udp      600 - 1023     permit

 

Name: default_ipv6, Type: ipv6, State: active

Rule    Source IP                               Protocol   Dest Port         Action

1     any                                            tcp       22            permit

2     any                                            tcp       23            permit

3     any                                            tcp       80            permit

4     any                                            tcp      443            permit

5     any                                            udp      161            permit

6     any                                            udp      123            permit

7     any                                            tcp      600 - 1023     permit

8     any                                            udp      600 - 1023     permit

 

Clone existing configuration

 

Go ahead and clone both iptable configurations. In the example above, they are named: default_ipv4 and default_ipv6. I will give the clones a new name: BlockTelnet_ipv4 and BlockTelnet_ipv6.

 

ipfilter --clone BlockTelnet_ipv4 -from default_ipv4

ipfilter --clone BlockTelnet_ipv6 -from default_ipv6

 

Save the clones you just created

 

ipfilter --save BlockTelnet_ipv4

ipfilter --save BlockTelnet_ipv6

 

Modify the cloned ipfilters

 

Next, we will remove rule 2 which permits traffic on port 23, then define a new rule that denies traffic on port 23.

 

To remove Rule 2 on the cloned ip tables, enter:

 

ipfilter --delrule BlockTelnet_ipv4 -rule 2

ipfilter --delrule BlockTelnet_ipv6 -rule 2

 

Use the following command to deny traffic on TCP port 23

 

ipfilter --addrule BlockTelnet_ipv4 -rule 2 -sip any -dp 23 -proto tcp -act deny

ipfilter --addrule BlockTelnet_ipv6 -rule 2 -sip any -dp 23 -proto tcp -act deny

 

Save configuration and activate ipfilters

 

To save the modified ipfilter clones, enter:

 

ipfilter --save BlockTelnet_ipv4

ipfilter --save BlockTelnet_ipv6

 

Before you activate, you can double-check the new configuration by entering the command:

 

ipfilter --show BlockTelnet_ipv4

ipfilter --show BlockTelnet_ipv6

 

Finally, you can activate the new ipfilters

 

ipfilter --activate BlockTelnet_ipv4

ipfilter --activate BlockTelnet_ipv6

 

Removing an ipfilter

 

Alternatively, if you think need need to clean up the ipfilter policies, it is very easy to do it. Use the following command:

 

STORFOS:FID128:storcom> ipfilter --delete BlockTelnet_ipv6

This will delete the IP filter policy.

ARE YOU SURE (yes, y, no, n): [no] y

SAN Sw telnet disable

Clone the existing Ipfilter

    Remove the rule to allow traffic on port 23

    Define new rule to deny traffic on Telnet port 23

    Save and activate the new iptables configuration

 

Table of Contents

 

    View existing iptable configuration

    Clone existing configuration

    Modify the cloned ipfilters

    Save configuration and activate ipfilters

    Removing an ipfilter

    Sources

 

View existing iptable configuration

 

To show the current ip filter rules, enter: ipfilter –show

 

STORFOS:FID128:storcom> ipfilter --show

 

Name: default_ipv4, Type: ipv4, State: active

Rule    Source IP                               Protocol   Dest Port         Action

1     any                                            tcp       22            permit

2     any                                            tcp       23            permit

3     any                                            tcp       80            permit

4     any                                            tcp      443            permit

5     any                                            udp      161            permit

6     any                                            udp      123            permit

7     any                                            tcp      600 - 1023     permit

8     any                                            udp      600 - 1023     permit

 

Name: default_ipv6, Type: ipv6, State: active

Rule    Source IP                               Protocol   Dest Port         Action

1     any                                            tcp       22            permit

2     any                                            tcp       23            permit

3     any                                            tcp       80            permit

4     any                                            tcp      443            permit

5     any                                            udp      161            permit

6     any                                            udp      123            permit

7     any                                            tcp      600 - 1023     permit

8     any                                            udp      600 - 1023     permit

 

Clone existing configuration

 

Go ahead and clone both iptable configurations. In the example above, they are named: default_ipv4 and default_ipv6. I will give the clones a new name: BlockTelnet_ipv4 and BlockTelnet_ipv6.

 

ipfilter --clone BlockTelnet_ipv4 -from default_ipv4

ipfilter --clone BlockTelnet_ipv6 -from default_ipv6

 

Save the clones you just created

 

ipfilter --save BlockTelnet_ipv4

ipfilter --save BlockTelnet_ipv6

 

Modify the cloned ipfilters

 

Next, we will remove rule 2 which permits traffic on port 23, then define a new rule that denies traffic on port 23.

 

To remove Rule 2 on the cloned ip tables, enter:

 

ipfilter --delrule BlockTelnet_ipv4 -rule 2

ipfilter --delrule BlockTelnet_ipv6 -rule 2

 

Use the following command to deny traffic on TCP port 23

 

ipfilter --addrule BlockTelnet_ipv4 -rule 2 -sip any -dp 23 -proto tcp -act deny

ipfilter --addrule BlockTelnet_ipv6 -rule 2 -sip any -dp 23 -proto tcp -act deny

 

Save configuration and activate ipfilters

 

To save the modified ipfilter clones, enter:

 

ipfilter --save BlockTelnet_ipv4

ipfilter --save BlockTelnet_ipv6

 

Before you activate, you can double-check the new configuration by entering the command:

 

ipfilter --show BlockTelnet_ipv4

ipfilter --show BlockTelnet_ipv6

 

Finally, you can activate the new ipfilters

 

ipfilter --activate BlockTelnet_ipv4

ipfilter --activate BlockTelnet_ipv6

 

Removing an ipfilter

 

Alternatively, if you think need need to clean up the ipfilter policies, it is very easy to do it. Use the following command:

 

STORFOS:FID128:storcom> ipfilter --delete BlockTelnet_ipv6

This will delete the IP filter policy.

ARE YOU SURE (yes, y, no, n): [no] y

Redhat 8 registerprocess

subscription-manager register --username bankasia --password BankAsia@2018 --auto-attach

Configuring SSL in WebLogic Server 11g and 12c

Configuring SSL in WebLogic Server 11g and 12c In this blog entry we are going to discuss how to set up SSL in WebLogic Server. By default WebLogic Admin and managed servers are configured with demo identity and demo trust certificates. This should be reconfigured to use real certicates (certificates of certifying authority)in production environments. You can also configure self-signed certificates. Before configuring SSL we need to understand what is keystore, identity store, trust store, keytool utilities. Key Store It is used to store the certificates. There are various types of Keystore that WebLogic Server Supports. Most common of them is Java Key Store (JKS) , which is a file based repository with extension .jks Identity Key Store It is used to store the identity certificates(Signed Certificate issued by a Certificate Authority (CA)) which provides the identity for WebLogic Server or site. Trust Key Store It is used to store the trusted certificates or certificates of certifying authority which provides trust for WebLogic Server. keytool This utility is used to generate keypairs, generate the csr, import the certificates, list the certificates, delete the certificates etc., In order to configure SSL, you need to perform the below steps: Generate a key-pair Generate Certificate Signing Request (CSR) Send the CSR to Certificate Authorities to get it singed. Import the Signed Certificate into keystore Configure WebLogic Admin & Managed Servers to use the above certificate keystore Create a directory to hold the keystores $ mkdir certs $ cd certs/ $ export JAVA_HOME=/u01/app/oracle/product/fmw/jrockit-jdk1.6.0_33-R28.2.4-4.1.0/ $ export PATH=$PATH:$JAVA_HOME/bin Generate a key-pair A keystore with a key-pair can be created by executing the below command: $ keytool -genkeypair -alias serverkey -keyalg RSA -keysize 1024 -dname "CN=localhost.localdomain,OU=IT,O=Mastan Inc,L=Hyderabad,S=AP,C=IN" -keystore appIdentity.jks -keypass welcome123 -storepass welcome123 $ ls appIdentity.jks This will generate the appIdentity.jks keystore, which is protected with the password welcome123 and it is valid for 3 months by default. If you want the validity of cert for 1year, you can execute the below command keytool -genkeypair -alias serverkey -keyalg RSA -keysize 1024 -dname "CN=localhost.localdomain,OU=IT,O=Mastan Inc,L=Hyderabad,S=AP,C=IN" -keystore appIdentity.jks -keypass welcome123 -storepass welcome123 -validity 365 You can list the contents of keystore by executing below command: $ keytool -list -v -keystore appIdentity.jks -storepass welcome123 Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: serverkey Creation date: May 27, 2014 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Issuer: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Serial number: 5384cacf Valid from: Tue May 27 22:56:39 IST 2014 until: Mon Aug 25 22:56:39 IST 2014 Certificate fingerprints: MD5: 99:5C:9B:53:D2:37:BC:34:F7:E6:2D:55:99:DE:1B:2B SHA1: 1D:EC:6D:E6:0F:AE:76:69:40:0C:73:C5:79:45:1E:74:31:C4:5F:84 Signature algorithm name: SHA1withRSA Version: 3 ******************************************* ******************************************* The above keystore contains a PrivateKeyEntry with alias serverkey Generate Certificate Signing Request By using the key-pair generate a certificate signing request (CSR) or certification request is a message sent from an applicant to a certificate authority in order to get the signed certificate Execute the below command to generate csr $ keytool -certreq -alias serverkey -file appIdentity.csr -keystore appIdentity.jks Enter keystore password: $ ls appIdentity.csr appIdentity.jks You can view the csr file and it looks like as below: $ cat appIdentity.csr -----BEGIN NEW CERTIFICATE REQUEST----- MIIBsDCCARkCAQAwcDELMAkGA1UEBhMCSU4xCzAJBgNVBAgTAkFQMRIwEAYDVQQHEwlIeWRlcmFi YWQxEzARBgNVBAoTCk1hc3RhbiBJbmMxCzAJBgNVBAsTAklUMR4wHAYDVQQDExVsb2NhbGhvc3Qu bG9jYWxkb21haW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALUhzHv87KMSVIoBssQU38Kv aalNXYy0laYdf4hazn+qa1CDtK5Yow0cPqtvk4W5vOffebX3BYCKXEricFdv5ejRkkAe6tKQgiBt jX2WnIulduEQS/piY95QEGu5MbHoy4/JeLsoaDHr73ooclcKcgQC7N3hKKxVtpwwnagZVGXrAgMB AAGgADANBgkqhkiG9w0BAQUFAAOBgQAWjgUqJf9+mY0sZzFQlHYH0TH8QJkfnXbCfjt8Lz3Jrvzw 0tZuj2LuxcL7supgX3e1DNAmoagJg0rV07kDWxwy3Rafc89R/nFiFo5T71kTnUxxOgjWLDsp6V9G 20cUSFn7wVOezYpPCJcqqXB4VjcJKDwb+PDi8uMIW1nSnRFMAw== -----END NEW CERTIFICATE REQUEST----- Send the above generated csr file to Certificate Authorities to get it singed. Import the Certificates If you have received a signed certificate from a trusted CA, import it to your keystore. An example is demonstrated with the below command: keytool -importcert -trustcacerts -file -alias trustcert -keystore appIdentity.jks -storepass welcome123 For demonstration purpose here, we are using self signed certificate to import it into the key store. Follow the below steps to do the same. $ keytool -exportcert -file selfsign.cer -alias serverkey -keystore appIdentity.jks -storepass welcome123 Certificate stored in file [mastshai@OEL certs]$ ls appIdentity.csr appIdentity.jks selfsign.cer [mastshai@OEL certs]$ $ keytool -printcert -file selfsign.cer Owner: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Issuer: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Serial number: 5384cacf Valid from: Tue May 27 22:56:39 IST 2014 until: Mon Aug 25 22:56:39 IST 2014 Certificate fingerprints: MD5: 99:5C:9B:53:D2:37:BC:34:F7:E6:2D:55:99:DE:1B:2B SHA1: 1D:EC:6D:E6:0F:AE:76:69:40:0C:73:C5:79:45:1E:74:31:C4:5F:84 Signature algorithm name: SHA1withRSA Version: 3 $keytool -importcert -trustcacerts -file selfsign.cer -alias trustcert -keystore appIdentity.jks Enter keystore password: Certificate already exists in keystore under alias Do you still want to add it? [no]: yes Certificate was added to keystore List the certificates in the key-store by executing below command $ keytool -list -v -keystore appIdentity.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Alias name: trustcert Creation date: May 27, 2014 Entry type: trustedCertEntry Owner: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Issuer: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Serial number: 5384cacf Valid from: Tue May 27 22:56:39 IST 2014 until: Mon Aug 25 22:56:39 IST 2014 Certificate fingerprints: MD5: 99:5C:9B:53:D2:37:BC:34:F7:E6:2D:55:99:DE:1B:2B SHA1: 1D:EC:6D:E6:0F:AE:76:69:40:0C:73:C5:79:45:1E:74:31:C4:5F:84 Signature algorithm name: SHA1withRSA Version: 3 ******************************************* ******************************************* Alias name: serverkey Creation date: May 27, 2014 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Issuer: CN=localhost.localdomain, OU=IT, O=Mastan Inc, L=Hyderabad, ST=AP, C=IN Serial number: 5384cacf Valid from: Tue May 27 22:56:39 IST 2014 until: Mon Aug 25 22:56:39 IST 2014 Certificate fingerprints: MD5: 99:5C:9B:53:D2:37:BC:34:F7:E6:2D:55:99:DE:1B:2B SHA1: 1D:EC:6D:E6:0F:AE:76:69:40:0C:73:C5:79:45:1E:74:31:C4:5F:84 Signature algorithm name: SHA1withRSA Version: 3 ******************************************* ******************************************* From the above, you can observe that the self-signed cert is imported into the keystore with the entry trustedCertEntry. Create the custom trust keystore appTrust.jks by making a copy from the Standard Java Trust.$ cp /u01/app/oracle/product/fmw/jrockit-jdk1.6.0_33-R28.2.4-4.1.0/jre/lib/security/cacerts appTrust.jks $ ls appIdentity.csr appIdentity.jks appTrust.jks cacerts selfsign.cer We now have a self-signed certificate in a keystore will the following details, which will be used to while configuring ssl in WebLogic Server Identity Keystore: "/u01/app/oracle/product/fmw/user_projects/domains/test_domain/certs/appIdentity.jks" Trust Keystore: "/u01/app/oracle/product/fmw/user_projects/domains/test_domain/certs/appTrust.jks" Alias: serverkey Key Store Password: welcome123 Key Password: welcome123 Valid for: 90 days SSL Configurations in WebLogic Administration Console You can now continue with Keystores and ssl configurations in WebLogic Administration Console Configure SSL for Admin & Managed Servers This process should be followed for the Admin Server and all managed servers. In the WebLogic Server Administration Console, click on "Servers" in the "Domain Structure" tree. Click on the Admin Server to configure. Click on the "Configuration > Keystores" tab and sub-tab. Click the "Change" button next to the "Keystores" setting Select the "Custom Identity and Custom Trust" option and click the "Save" button. Enter the Custom Identity Keystore: /u01/app/oracle/product/fmw/user_projects/domains/test_domain/certs/appIdentity.jks, Custom Identity Keystore Type: JKS, Custom Identity Keystore Passphrase: welcome123. Enter the Custom Trust Keystore: /u01/app/oracle/product/fmw/user_projects/domains/test_domain/certs/appTrust.jks, Custom Trust Keystore Type: JKS, Custom Trust Keystore Passphrase: welcome123, Confirm Trust Keystore Passphrase: welcome123 and click the "Save" button. Click the "SSL" tab. Enter the Private Key Alias: serverkey, Private Key Passphrase: welcome123, Confirm Private Key Passphrase: welcome123 and Click the "Save" button. Click on the Admin Server Click on the "Configuration > General" tab and sub-tab. Select SSL Listen Port Enabled check-box and enter the SSL Listen Port for example:7002 Repeat the above steps for all managed servers in the domain. Configure Node Manager Change the Node Manager in the to use the custom keystores and the new certificates. Edit the "$WL_HOME/common/nodemanager/nodemanager.properties" file, adding the following entries. The values used reflect the information used to create the keystores above. KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=/u01/app/oracle/product/fmw/user_projects/domains/test_domain/certs/appIdentity.jks CustomIdentityKeyStorePassPhrase=welcome123 CustomIdentityPrivateKeyPassPhrase=welcome123 CustomIdentityAlias=serverkey Restart the node manager. Restart the Admin Server & managed servers In the logs you can see the following

How to Monitor All Failed Login Attempts in solaris 11

How to Monitor All Failed Login Attempts This procedure captures in a syslog file all failed login attempts. Before You Begin You must be in the root role. Set up the /etc/default/login file with the desired values for SYSLOG and SYSLOG_FAILED_LOGINS Edit the /etc/default/login file to change the entry. Make sure that SYSLOG=YES is uncommented. # grep SYSLOG /etc/default/login # SYSLOG determines whether the syslog(3) LOG_AUTH facility should be used SYSLOG=YES # The SYSLOG_FAILED_LOGINS variable is used to determine how many failed #SYSLOG_FAILED_LOGINS=5 SYSLOG_FAILED_LOGINS=0 # Create a file with the correct permissions to hold the logging information. Create the authlog file in the /var/adm directory. # touch /var/adm/authlog Set read-and-write permissions for root user on the authlog file. # chmod 600 /var/adm/authlog Change group membership to sys on the authlog file. # chgrp sys /var/adm/authlog Edit the syslog.conf file to log failed password attempts. Send the failures to the authlog file. Type the following entry into the syslog.conf file. Fields on the same line in syslog.conf are separated by tabs. auth.notice /var/adm/authlog Refresh the system-log service. # svcadm refresh system/system-log Verify that the log works. For example, as an regular user, log in to the system with the wrong password. Then, as superuser, display the /var/adm/authlog file. # more /var/adm/authlog Nov 4 14:46:11 example1 login: [ID 143248 auth.notice] Login failure on /dev/pts/8 from example2, stacey