Tuesday, April 30, 2013

ASA Smart Call Home common uses and periodic monitoring

ASA Smart Call Home common uses and periodic monitoring

 

Purpose of this document

Smart Call Home is a feature introduced into the ASA firewalls in version 8.2 that allows for periodic monitoring of the firewall device. This document how to leverage this feature to monitor and troubleshoot network issues.

Configuring Smart Call Home

To configure Smart Call Home, use the following document:
https://supportforums.cisco.com/docs/DOC-12801

Common Uses

Configuration Backups

Gathering configuration backups  periodically is useful in case of device replacement or change control.  It helps to identify the last working configuration and archives changes  made to the firewall.

hostname (config)# service call-home
hostname (config)# call-home
hostname (cfg-call-home)# contact-email-addr [email protected]
hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1 hostname (cfg-call-home)# profile ConfigBackup-1 hostname (cfg-call-home-profile)# destination address email [email protected] hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group configuration export full periodic monthly

The configuration alert-group (as configured above with the export full, non-default option) includes the commands:
- show call-home registered-module status | exclude disabled
- show running-config
- show startup-config
- show access-list | include elements

In the above example, the firewall will send these outputs to the email address [email protected] monthly.

Network Profiling using Snapshots

Network profiling is an important process that allows a network administrator to understand current utilization levels of their network. This is important for monitoring current load, feature usage as well as anamolous behaviour. Having good archived historical network profile data helps to troubleshoot the most complex networking problems such as oversubscription and load issues. Additionally, it provides an early warning system to help net admins to understand when their network is reaching capacity.

Snapshots are a Smart Call Home feature that allows the user to customize which commands are sent by the ASA.

In the below example, the network administrator is interested in understanding the network utilization of their ASA. As a result, the snapshot profile is built to gather outputs relevant to network utilization:
hostname (config)# service call-home
hostname (config)# call-home
hostname (cfg-call-home)# contact-email-addr [email protected]
hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1
hostname (cfg-call-home)# alert-group-config snapshot
hostname (cfg-call-home-snapshot)# add-command "show traffic" hostname (cfg-call-home-snapshot)# add-command "show interface detail" hostname (cfg-call-home-snapshot)# add-command "show perfmon"
hostname (cfg-call-home-snapshot)# add-command "show conn count" hostname (cfg-call-home-snapshot)# add-command "show xlate count"
hostname (cfg-call-home-snapshot)# add-command "show service-policy"
hostname (cfg-call-home)# profile NetworkProfiling-1 hostname (cfg-call-home-profile)# destination address email [email protected] hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120

These outputs will be gathered periodically every 120 minutes as emails, which the network adminstrator can then parse and format into graphs or charts. In the above example, the network administrator will be able to graph the current traffic rate through all the interfaces, the current rate of connection as well as the current connection and xlate counts. Additionally, the net admin was interested in knowing how much traffic through the firewall was being sent through the service-policy, which is the last output included in the snapshot.

Device Oversubscription Issues

Networking profiling is very useful to monitor the current status of a network. But, when there is a network load related issue, snapshots can be used to more efficiently isolate the problem.

When a network adminsitrator suspects that the firewall is reaching a load limit, they can leverage Smart Call Home and the snapshot feature to provide very specific data that helps to isolate the oversubscription related issues. For more information regarding this specific issue, please refer to the following document:
https://supportforums.cisco.com/docs/DOC-12439

Specific to Smart Call Home, the following snapshot profile will help to gather the necessary data:
hostname (config)# service call-home
hostname (config)# call-home
hostname (cfg-call-home)# contact-email-addr [email protected]
hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1
hostname (cfg-call-home)# alert-group-config snapshot
hostname (cfg-call-home-snapshot)# add-command "show cpu detailed"
hostname (cfg-call-home-snapshot)# add-command "show processes cpu-usage"
hostname (cfg-call-home-snapshot)# add-command "show processes cpu-hog"
hostname (cfg-call-home-snapshot)# add-command "show interface detail | i line|overrun|no buffer"
hostname (cfg-call-home-snapshot)# add-command "show memory detail"
hostname (cfg-call-home)# profile Oversubscription-1 hostname (cfg-call-home-profile)# destination address email [email protected] hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120
By using the document linked above, the net admin understands that oversubscription can be primarily caused by cpu utilization and network load. Since the net admin is already gathering network profile information, the only additional information required is with regards to device level utilization. The snapshot profile above gathers information regarding cpu utilization, interface oversubscription and memory levels.

The Smart Call Home information gathered in both the network profiling and device oversubscription can be graphed to better understand whether the oversubscription behaviour is periodic or consistent. A consistent problem may indicate a network attack or infected host, while a periodic behaviour tends to be caused by network load.

VPN Utilization

Since VPN features are licensed on the ASA platforms, it is important for a network administrator to understand utilization levels of the VPN deployment. This will help to forecast VPN expansion requirements to accomodate network growth.

Below is a profile that provides the necessary VPN information:
hostname (config)# service call-home
hostname (config)# call-home
hostname (cfg-call-home)# contact-email-addr [email protected]
hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1
hostname (cfg-call-home)# alert-group-config snapshot
hostname (cfg-call-home-snapshot)# add-command "show vpn-sessiondb"
hostname (cfg-call-home-snapshot)# add-command "show crypto ipsec sa"
hostname (cfg-call-home-snapshot)# add-command "show crypto isakmp sa"
hostname (cfg-call-home-snapshot)# add-command "show webvpn statistics"
hostname (cfg-call-home-snapshot)# add-command "show crypto protocol statistics all"
hostname (cfg-call-home)# profile VPNUtilization-1 hostname (cfg-call-home-profile)# destination address email [email protected] hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120

found at: https://supportforums.cisco.com/docs/DOC-14958

Thursday, April 25, 2013

PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module.so'

This problem happens with CentOS 6.4 
 
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module.so' - /usr/lib/php/modules/module.so: cannot open shared object file: No such file or directory in Unknown on line 0
 
and is related to mcrypt lib, so for now only one solution is 
 
yum downgrade php-mcrypt 
 

Monday, April 22, 2013

autocomplete commands with sudo

How to enable autocomplete when using sudo command?

Edit  the ".bashrc" hidden file from your home folder.

sudo vim ~/.bashrc

Then paste this at the bottom of the file:
 
if [ "$PS1" ]; then
complete -cf sudo
fi

Then type this in a terminal to reload:
bash


Now try the example in the beginning of the file "sudo ser" and press TAB.
It should now work.


found at: http://www.webupd8.org/2010/03/how-to-autocomplete-commands-preceded.html

Wednesday, April 17, 2013

Bash Trap Control+C


Do you want to catch control-c keyboard interrupts in your Bash program? Use the Bash builtin trap command to catch system signals. The following runs control_c() when a user interrupts the main() section with a Control-C (SIGINT)


#!/bin/bash

cleanup()
# example cleanup function
{
  rm -f /tmp/tempfile
  return $?
}

control_c()
# run if user hits control-c
{
  echo -en "\n*** Ouch! Exiting ***\n"
  cleanup
  exit $?
}

# trap keyboard interrupt (control-c)
trap control_c SIGINT

# main() loop
while true; do read x; done


found at: http://hacktux.com/bash/control/c

Installing RHEL EPEL Repo on Centos 5.x or 6.x

How to install RHEL EPEL repository on Centos 5.x or 6.x

The following article will describe how to configure a CentOS 5.x-based or Centos 6.x-based system to use Fedora Epel repos and third party remi package repos. These package repositories are not officially supported by CentOS, but they provide much more current versions of popular applications like PHP or MYSQL.

Install the extra repositories

The first step requires downloading some RPM files that contain the additional YUM repository definitions. The instructions below point to the 64-bit versions that work with our Cloud Server instances.

Centos 5.x

wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
sudo rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Centos 6.x

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
sudo rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm

Once installed you should see some additional repo definitions under the /etc/yum.repos.d directory.

$ ls -1 /etc/yum.repos.d/epel* /etc/yum.repos.d/remi.repo
/etc/yum.repos.d/epel.repo
/etc/yum.repos.d/epel-testing.repo
/etc/yum.repos.d/remi.repo

Enable the remi repository

The remi repository provides a variety of up-to-date packages that are useful or are a requirement for many popular web-based services. That means it generally is not a bad idea to enable the remi repositories by default.
First, open the /etc/yum.repos.d/remi.repo repository file using a text editor of your choice:

sudo vim /etc/yum.repos.d/remi.repo


Edit the [remi] portion of the file so that the enabled option is set to 1. This will enable the remi repository.

name=Les RPM de remi pour Enterprise Linux $releasever - $basearch
#baseurl=http://rpms.famillecollet.com/enterprise/$releasever/remi/$basearch/
mirrorlist=http://rpms.famillecollet.com/enterprise/$releasever/remi/mirror
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi
failovermethod=priority
 
You will now have a larger array of yum repositories from which to install.

found at http://www.rackspace.com/knowledge_center/article/installing-rhel-epel-repo-on-centos-5x-or-6x

Tuesday, April 16, 2013

CentOS - change to Japanese

Change to Japanese environment in CentOS
[1] Install packages for Japanese
yum -y groupinstall "Japanese Support"
[2] Change charset
vi /etc/sysconfig/i18n
 
# change

LANG="ja_JP.UTF-8"


source /etc/sysconfig/i18n

echo $LANG

>ja_JP.UTF-8

Friday, April 12, 2013

Install Fail2ban (Intrusion Prevention) System on RHEL/CentOS 6.3/5.8, Fedora 17/12

Fail2ban is an open source free intrusion prevention framework developed in python programming language. Fail2ban operates by monitoring log files such as /var/log/pwdfail, /var/log/auth.log, /var/log/secure etc. and bans the IP address after too many password failure attempts. It used to update iptable firewall rules to reject the IP address for a specified amount of time.
This article shows you how to install and configure Fail2ban under RHEL 6.3/6.2/6.1/6.0/5.8 CentOS 6.3/6.2/6.1/6.0/5.8 and Fedora 17,16,15,14,13,12 systems. Fail2ban runs as a daemon that uses python scripts to parse log files for system intrusion attempts and adds a custom rules to iptables configuration file to ban the access to certain ip addresses.

Before heading up for installation and configuration of Fail2Ban, I would like to tell you that most of the attackers trying to gain root access via SSH. So, I recommend you to pay close attention to things such as disable ssh root logins and use pair of ssh keys for authentication etc.

Installing Fail2Ban in RHEL, CentOS and Fedora

By default Fail2Ban is not available under Linux systems, so you will need to add and enable third party RPMForge repository or EPEL repository in your Linux box. Once you’ve added repository, install it using following YUM command.
# yum install fail2ban

Configuring Default section for Fail2Ban

The master Fail2Ban configuration file is located under /etc/fail2ban/jail.conf. So, open it using VI editor or any editor that you feel comfortable.
# vi /etc/fail2ban/jail.conf
Now, you will see default section with some basic rules that are followed by fail2ban itself. If you want to add some extra layer of protection to your server, then you can customize the each rule section as per your needs.
[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1

# "bantime" is the number of seconds that a host is banned.
bantime = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 3
Let me describe each rule section with their description and what purpose we use these rules.
  1. ignoreip : IgnoreIP section allows you to white list certain IP addresses from blocking. Here, you can specify list of IP addresses with space separated and make sure you include your address.
  2. bantime : The number of seconds that a host would be banned from the server. The default is set for 600 (600 seconds = 10 minutes), you may increase this to an hour or higher if you like.
  3. findtime : The amount of time that a host has to log in. The default is set to 10 minutes, it means that if a host attempts, and fails, to log in more than the maxretry number of times, they will be banned.
  4. maxretry : The number of failed login attempts before a host is blocked for the length of the ban time.

Configuring ssh-iptables section for Fail2Ban

The following section is the default ssh-iptables section and it is turned on by default. So, you don’t need to make any changes to this section,
[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, [email protected]]
logpath  = /var/log/secure
maxretry = 5
You can find the details of each rule described below.
  1. enabled : This section refers that SSH protection is on. You can turn it off by changing the word “true” to “false“.
  2. filter : This section by default set to sshd and refers the config file (/etc/fail2ban/filter.d/sshd.conf) containing the rules that fail2ban uses to find matches.
  3. action : This action tells the fail2ban to ban a matching IP address once a filter matches in the /etc/fail2ban/action.d/iptables.conf file. If your server have mail setup, you can add email address, where fail2ban sends you a email alerts whenever it bans an IP address. The sender section refers to file /etc/fail2ban/action.d/sendmail-whois.conf file.
  4. logpath : The log path is the location of logs where fail2ban will track.
  5. maxretry : The max retry section is the same definition as the default option that we discussed above.

Restarting Fail2Ban Service

Once you’ve made the changes to the fail2ban config file, then always make sure to restart Fail2Ban service.
# chkconfig --level 23 fail2ban on
# service fail2ban start
Starting fail2ban:                                         [  OK  ]

Verifying Fail2Ban iptables rules

Check the rules that fail2ban added in effect within the IP table section.
# iptables -L
I have made some failed login attempts from one of our server to the server where fail2ban installed and it works. You see the banned IP address of my server.
Message from [email protected] at Nov 23 13:57:53 ...
fail2ban.actions: WARNING [ssh-iptables] Ban 15.13.14.40
iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp multiport dports 5901:5903,6001:6003
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-SSH (1 references)
target     prot opt source               destination
DROP all -- 15.13.14.40 anywhere
RETURN     all  --  anywhere             anywhere

Watch Failed SSH login attempts

To see the current ssh failed login attempts, run the following command it will display a list of failed attempts attempted by hosts.
# cat /var/log/secure | grep 'Failed password' |  sort | uniq -c
1 Nov 19 16:53:37 tecmint sshd[28185]: Failed password for root from 172.16.25.125 port 1302 ssh2
1 Nov 23 13:57:43 tecmint sshd[19079]: Failed password for root from 115.113.134.40 port 57599 ssh2
1 Nov 23 13:57:46 tecmint sshd[19079]: Failed password for root from 115.113.134.40 port 57599 ssh2
1 Nov 23 13:57:50 tecmint sshd[19079]: Failed password for root from 115.113.134.40 port 57599 ssh2
1 Oct 18 14:11:58 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:03 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:11 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:16 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:22 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:28 tecmint sshd[8711]: Failed password for root from 172.16.18.249 port 4763 ssh2
1 Oct 18 14:12:47 tecmint sshd[10719]: Failed password for root from 172.16.18.249 port 4774 ssh2

Remove IP Address from Fail2Ban

To remove the banned IP address from the fail2ban iptable rules. Run the following command.
# iptables -D fail2ban-ssh 1
For any additional information, please visit Fail2ban official page. If you are having any questions any comments about this article, please tell us via comments.

If you can see errors like this:

fail2ban.actions.action: ERROR  iptables -N fail2ban-SSH#012iptables -A fail2ban-SSH -j RETURN#012iptables -I INPUT -p tcp --dport ssh 
-j fail2ban-SSH returned 300

It means SELinux problem - so please run this command 
 
restorecon -R -v /sbin/
 
and restart fail2ban service and should work :) 
 
 


found at:http://www.tecmint.com/install-fail2ban-on-rhel-centos-fedora/

Thursday, April 11, 2013

Multiple tail via ssh

I just wrote simple script to remotely monitor logs of many servers and log files and display on screen with colors depends on event. You can also add parameter to receive emails when event occurs.

Script will automatically login into server via ssh and start tail.

Another great tool CHIP 

Also I use sshpass for automatic login (for security reason you can write password in separate file)

#!/bin/bash
sleep 120 &
pid="$!"
sleep 120 &
pid="$pid $!"
echo "my process pid is: $$"
echo "my child pid list is: $pid"

/usr/bin/sshpass -p PASSWORD /usr/local/bin/chip -f -m2='LOG-EVENT-1' -s2='YELLOW on_blue' -m3='LOG-EVENT-2' -s3='WHITE' -s1 [email protected]:'/var/log/LOGFILE'

/usr/bin/sshpass -p PASSWORD /usr/local/bin/chip -f -m2='LOG-EVENT-1' -s2='YELLOW on_blue' -m3='LOG-EVENT-2' -s3='WHITE' -s1 [email protected]:'/var/log/LOGFILE'

trap 'echo I am going down, so killing my processes..; kill $pid; exit' SIGHUP SIGINT  SIGQUIT SIGTERM

Selinux problems - how to solve access issues or disable/change mode

Creating Custom SELinux Policy Modules with audit2allow


Sometimes there are occasions when none of the above methods deal with a given situation and we need to extend the SELinux policy by creating a custom policy module to allow for a certain set of conditions. For example, consider the postgrey service add-on for an smtp mail server. Our smtp server needs to communicate with postgrey over a Unix socket and that is something the default SELinux policy for our smtp server does not allow. Consequently the service is blocked by SELinux. This is an issue that can not be fixed by changing or restoring file type security contexts and isn't something that has a boolean value we can toggle to allow. We could disable SELinux protection of the smtp server through a boolean, which would be better than disabling SELinux completely, but that is still far from ideal.
If we switch SELinux into Permissive mode and run our mail server for a set period of time, we can log SELinux issues whilst still permitting access. Checking our logs, we see the following SELinux AVC messages:
type=AVC msg=audit(1218128130.653:334): avc:  denied  { connectto } for  pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1218128130.653:334): avc:  denied  { write } for  pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file 

Then we can use 'audit2allow' to generate a set of policy rules that would allow the required actions. We can generate a local postgrey Type Enforcement policy file (postgreylocal.te):
# grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
# cat postgreylocal.te
module postgreylocal 1.0;
require {
        type postfix_smtpd_t;
        type postfix_spool_t;
        type initrc_t;
        class sock_file write;
        class unix_stream_socket connectto;
}
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
allow postfix_smtpd_t postfix_spool_t:sock_file write; 

Above we see that we can grep the audit.log file for issues relating to our smtp server and pipe those issues to audit2allow which generates a set of rules that it thinks would permit the actions currently denied by the SELinux policy. Reviewing these rules we see our smtp server wants to connect and write to a Unix socket which we see from out logs is the Unix socket that the postgrey service is listening on. As this seems perfectly reasonable, we can go ahead and use audit2allow to make a custom policy module to allow these actions:
# grep smtpd_t /var/log/audit/audit.log | audit2allow -M postgreylocal 

We then load our postgrey policy module using the 'semodule' command into the current SELinux policy:
semodule -i postgreylocal.pp 

which will add our postgrey policy module to /etc/selinux/targeted/modules/active/modules/postgreylocal.pp. We can check the policy module loaded correctly by listing loaded modules with 'semodule -l'.
We can then continue to monitor our SELinux log files to check that our custom policy module works and once we are satisfied we can re-enable SELinux Enforcing mode and again benefit from SELinux protection of our now fully functional smtp server. 

To temporary disable or change :

Get SELinux mode:
# getenforce
Output:
Enforcing

or

#sestatus
Output:
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Set SELinux mode to permissive mode
# setenforce 0
# getenforce
Output:
Permissive

or

#sestatus
Output:
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          permissive
Policy version:                 24
Policy from config file:        targeted
 


 


found at: http://wiki.centos.org/HowTos/SELinux/

Understanding Cisco ASA AnyConnect Licensing

This post will try to help understand the differences between anyconnect premium and anyconnect essentials licenses.

Note: You cannot have both Essentials and Premium running at once.
Note: Cisco ASA 8.3+ no longer requires both the Active and Standby unit to each have a license. The active license is shared between the failover units. This should not be confused with the ‘shared premium license’.



Source of this image: Cisco’s Partner Education center – ASA Licensing Webex.

To enable AnyConnect essentials:

Purchase the license (L-ASA-AC-E-55xx= it costs $100-$500).
Apply the license to the ASA using the ‘activation-key’ command. This does not require a reboot.
Apply the config:
webvpn
 anyconnect-essentials
Now your firewall will be licensed to have up to however many connections that are on the “Total VPN Connections”. For instance if your show version says this:
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Enabled        perpetual
Other VPN Peers                   : 250            perpetual
Total VPN Peers                   : 250            perpetual
You will now be licensed to accommodate 250 anyconnect connections.

To enable AnyConnect Premium

Buy the license. You must purchase a license for a specific number of users (L-ASA-SSL-10= costs around $800).
Apply the license to the ASA using the ‘activation-key’ command. This does not require a reboot.
Configure the ASA:
webvnp
  no anyconnect-essentials
If you’ve already licensed this ASA for Essentials in the past then it will still show as an enabled license.
Once this is complete your ASA will be licensed to accept however many Anyconnect connections as you have Premium Licenses for. So if your ‘show version’ looks like this:
AnyConnect Premium Peers          : 10             perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 250            perpetual
Total VPN Peers                   : 250            perpetual
Then your ASA can have 10 Anyconnect users at once.
Note: The name “Anyconnect Premium” has changed a lot in different versions. Here are the different naming schemes.
7.1(1) known as “ssl vpn”
8.2(1) name changed to “anyconnect premium ssl vpn edition”
8.3(1) name changed to “anyconnect premium ssl vpn”
8.4(1) name changed to “anyconnect premium”

AnyConnect for Mobile

This license allows AnyConnect connections from mobile devices. There is current support for iPhone, iPad, Android IceCream Sandwich, rooted Androids and Samsung Galaxy’s.
The mobile license is on or off and not tied to a number of users. It costs between $100-$500.
This license is applied by simply using the ‘activation-key’ command. A reboot is not needed. There is no further configuration needed after that.

Advanced Endpoint Assessment

Advanced Endpoint Assessment includes all of the Endpoint Assessment features, and lets you configure an attempt to update noncompliant computers to meet version requirements.
This license is applied by simply using the ‘activation-key’ command. A reboot is not needed.

Shared Premium License

New to ASA 8.3+ code is the ability to share licensing. This is only for Anyconnect Premium. It allows for one ASA to have a shared license which other ASAs can use.
This configuration requires two extra licenses. A license is needed for the shared server which indicates how many shared licenses there are and there also is a need for any participating ASAs.
After buying a shared participant license and applying it with the ‘activation-key’ command, configure it with a command similar to this:
license-server address 10.15.0.15 secret SeKreTkey
The ‘show version’ on the participant ASA will show this:
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 5000           perpetual
Total VPN Peers                   : 5000           perpetual
Shared License                    : Enabled        perpetual

Now buy the shared premium license for the server for the amount of users you wish to have.
Apply the license using the ‘activation-key’ command. Then apply the following config:
license-server secret SeKreTkey
license-server enable inside
The ‘show version’ at this point looks like this:
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 5000           perpetual
Total VPN Peers                   : 5000           perpetual
Shared License                    : Enabled        perpetual
Also you can see the ‘show shared license‘ output:
Shared license utilization:
  AnyConnect Premium:
    Total for network :     5000
    Available         :     4900
    Utilized          :      100
  This device:
    Platform limit    :     5000
    Current usage     :       50
    High usage        :      100
  Messages Tx/Rx/Error:
    Registration    : 441798 / 441789 / 9
    Get             : 28 / 28 / 0
    Release         : 27 / 27 / 0
    Transfer        : 0 / 0 / 0

  Client ID           Usage   Hostname
  JMX1111             50      vpn-asa-01
 
found at: 
http://tunnelsup.com/tup/2012/08/08/understanding-cisco-asa-anyconnect-licensing/  

Wednesday, April 10, 2013

Cisco ASA shunned connection

Shunning Traffic

Sometimes it might be possible for malicious hosts to open connections into the protected network. This could occur if the inbound access list policies aren't configured correctly or tightly. As soon as these connections are noticed (after they are built), you might want to react by blocking connections coming from the malicious source address.
To do this, you could edit the access list each time the source of an attack is discovered . This would deny any future connections; xlate entries would also need to be cleared to drop existing connections. This would also quickly become an administrative burden .
A more efficient alternative is the shun command. When a shun is activated, all current connections from a malicious host can be dropped and all future connections blocked.
Connections are shunned regardless of the firewall interface being traversed. The firewall examines the connection table and the connection building process to identify and shun the specified connections.
Shuns can be configured through the firewall CLI or through an automatic action from a Cisco Intrusion Protection System. After shuns are configured, they remain in place until they are removed.
Shuns are dynamic in nature and are not stored as part of the firewall configuration. If the firewall loses power or reloads , any active shuns are lost. As well, shuns are not maintained in a failover firewall pair. If the units fail over, any active shuns are lost.
You can follow these steps to configure a shun:
1.
Manually shun connections:

FWSM 2.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]] [ vlan_id ]
PIX 6.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]]
PIX 7.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]] [ vlan_id ]

You can shun any new connections (any IP protocol) passing through the firewall originating from source address src_ip . This is most useful to stop an attack that is in progress from the source address to many destinations. Any existing connections stay up, however. Those must idle out of the xlate and conn tables normally, or you can clear any related xlate entries to manually kill the connections.

For more granular shunning, you can also identify the destination address dst_ip , the source and destination ports sport and dport , and the protocol . You can define only one shun entry per source and destination address pair. When a shun is defined, all existing and future connections are blocked until the shun is later removed.

2.
Display active shuns:

Firewall#

show shun

[

src_ip

]

The output from this command displays all active shuns. If a specific source address src_ip is given, only shuns involving that address are shown.

For example, the following output displays the four shuns that are currently active. In PIX 7.0, the source interface is automatically determined and shown too:

Firewall#

show shun

shun (outside) 172.21.104.93 0.0.0.0 0 0
shun (outside) 172.21.196.50 0.0.0.0 0 0

shun (inside) 192.168.198.24 0.0.0.0 0 0 0

shun (outside) 10.10.1.1 172.21.4.19 0 80 6
Firewall#

Notice in the shaded output line that an inside host has been the target of a shun. Shuns can be used on any host located on any interface. In this case, the inside host played the role of the malicious user , attacking hosts on the outside of the firewall.

3.
(Optional) Remove an existing shun:

Firewall(config)#

no shun


src_ip


This command removes any active shuns for source address src_ip from the firewall.

TIP
You can monitor the activity of each active shun with the show shun statistics command, which displays each of the firewall interfaces, along with the current shun activity. The firewall looks at its routing information to determine the interfaces where shun source addresses can be found. These interfaces are shown as "ON." A cumulative count of shunned connections is also shown.
Each configured shun is listed with its source address, a cumulative count of shunned connections, and the total elapsed time since the shun was enabled.
In the following example, a firewall is configured with a long list of shun commands. Notice that the outside interface, where malicious hosts on the public Internet were discovered, has had 17,184,951 shunned connections. The inside interface has had even more! In this case, a number of inside hosts have been discovered to be compromised and participating in malicious activity toward the outside network. Until these hosts can be cleaned, they have been "quarantined" through the use of firewall shuns.
Firewall#

show shun statistics

stateful=OFF, cnt=0
dmz2=OFF, cnt=0

outside=ON, cnt=17184951


inside=ON, cnt=255823449

Shun 172.21.96.89 cnt=32502918, time=(112:04:34)
Shun 172.21.61.83 cnt=0, time=(112:04:32)
Shun 172.21.24.79 cnt=0, time=(112:04:35)
Shun 172.21.108.68 cnt=0, time=(112:04:35)
Shun 192.168.93.16 cnt=0, time=(112:04:34)
Shun 172.21.184.106 cnt=21277328, time=(112:04:33)
Shun 192.168.97.9 cnt=0, time=(112:04:34)
Shun 172.21.184.107 cnt=21264263, time=(112:04:33)
Shun 192.168.228.11 cnt=0, time=(243:35:21)
Shun 192.168.228.12 cnt=0, time=(243:35:18)
Shun 192.168.228.13 cnt=0, time=(243:35:16)
Shun 172.21.184.108 cnt=21311395, time=(112:04:33)
Shun 192.168.228.14 cnt=0, time=(243:35:12)
Shun 192.168.228.15 cnt=0, time=(243:35:10)
Shun 172.21.72.99 cnt=334699, time=(112:04:34)
[output omitted]

To avoid sifting through long lists of shun statistics to find a single source address, you can filter the output by using the include or grep commands. In the following example, only the shun for source address 172.21.72.99 is needed. It is shown to have blocked 334,699 packets, and it has been active for 112 hours, 13 minutes, and 19 seconds:
Firewall#

show shun statistics


include 172.21.72.99

Shun 172.21.72.99 cnt=334699, time=(112:13:19)
Firewall#


Shun Example

A host at 172.21.4.8 is discovered to be involved in malicious activity. (In this example, only a Telnet connection is shown for simplicity.) A shun is configured on the firewall to stop any current or future connections involving that host.
First, look at an active connection involving 172.21.4.8:
Firewall#

show conn

1 in use, 3 most used
TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:00:04 Bytes 138 flags UIOB
Firewall#

That host does have at least one active connection, so a shun is put into place:
Firewall#

shun 172.21.4.8

Shun 172.21.4.8 successful
Firewall#

show conn

1 in use, 3 most used
TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:04:25 Bytes 138 flags UIOB
Firewall#

Indeed, the current connection has become unresponsive from 172.21.4.8 (as shown by the increasing idle time), and it is also unable to start new sessions through the firewall. But why is the connection still shown in the firewall's connection table?
First, look at the buffered Syslog information on the firewall. Hopefully it will show something interesting:
Firewall#

show logging

Syslog logging: enabled
    Facility: 20
    Timestamp logging: enabled
    Standby logging: disabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: level informational, 3523423 messages logged
    Trap logging: level informational, 3523423 messages logged
        Logging to outside 192.168.199.10 (EMBLEM format)
    History logging: disabled
    Device ID: hostname "Firewall"

401002: Shun added: 172.21.4.8 0.0.0.0 0 0

111008: User 'enable_15' executed the 'shun 172.21.4.8' command.

401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside


401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside


401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside


401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside


The Syslog record shows that the shun was put into place and that it is actively shunning new packets. Why didn't the active connection drop immediately? The answer is this: As soon as the shun became active, the firewall began dropping packets involving 172.21.4.8. The TCP connection shown in the connection table was already established, after a three-way handshake. As soon as packets started being dropped, the TCP connection became isolated; each host in the connection no longer could hear from the other end.
As a result, the TCP connection becomes a " half-open " or "half-closed" connection until either it times out or both endpoints handshake with a FIN flag. The firewall keeps the shunned connection in its table until its own half-closed timer expires . You can see this by verifying the timer value and the shun statistics:
Firewall#

show conn

1 in use, 3 most used
TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:06:48 Bytes 138 flags UIOB
pix-f#

sh timeout

timeout xlate 3:00:00
timeout conn 1:00:00

half-closed 0:10:00

udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
Firewall#

show shun statistics

outside=ON, cnt=13
inside=ON, cnt=0
dmz=OFF, cnt=0

Shun 10.1.1.1 cnt=0, time=(121:03:07)
Shun 192.168.200.199 cnt=0, time=(119:52:22)
Shun 172.21.4.8 cnt=13,

time=(0:03:58)

Firewall#

Indeed, the half-closed timer is 10 minutes, and the active connection has been shunned for only 3 minutes 58 seconds. After 10 minutes has elapsed, the TCP connection is deleted from the firewall's table. 

Free infographics online

Easy to create and looks beautiful 

Found at: http://infogr.am/

SNMP Logging Flooding into /var/log/message

Another problem I have been facing with default installation of SNMP is the /var/log/message will be flooding with snmpd log as example above. To overcome this, add following line into /etc/sysconfig/snmpd using text editor:
OPTIONS="-LS 5 d"
Save and restart SNMPD to get affected. To verify, just run following command and make sure the options value is included:
$ ps aux | grep snmpd
root   32382   0.0   0.1   197160   5076   ? S   13:04   0:00        /usr/sbin/snmpd -LS 5 d
This options will log from level 0 to 4 based on log level below:
0 – Emergencies – System is unusable
1 – Alerts – Immediate action needed
2 – Critical – Critical conditions
3 – Errors – Error conditions
4 – Warnings – Warning conditions
5 – Notifications – Informational messages
6 – Informational – Normal but significant conditions
7 – Debugging – Debugging messages

Found at: http://blog.secaserver.com/2012/08/snmpd-connection-udp-refused/

Easy access

its better to know if you are safe or not...

http://www.shodanhq.com/

Lost grand options in mysql

If the GRANT ALL doesn't work, try:
  1. Stop mysqld and restart it with the --skip-grant-tables option.
  2. Connect to the mysqld server with just: mysql (i.e. no -p option, and username may not be required).
  3. Issue the following commands in the mysql client:
    UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE User='root';
    FLUSH PRIVILEGES;
After that, you should be able to run GRANT ALL ON *.* TO 'root'@'localhost'; and have it work.

Found at: http://stackoverflow.com/questions/1709078/how-can-i-restore-the-mysql-root-users-full-privileges

Cybermap

Internet Storm Center Infocon Status

Internet Storm Center Infocon Status
Internet Storm Center Infocon Status