1.0 Red Team Field Manual (RTFM)

When i try to ping from inside lan to firewall DMZ interface IP it is not pingable and but from inside users i am able to ping firewall inside interface IP address.
e.g:
I have following scenario where i am trying to ping from 10.30.1.100 PC to ASA interface 10.20.1.1 not pinging but i can ping 10.20.1.100 so why ASA not allowing to ping distant interfaces?

Solution:
You cannot ping the far interfaces by design. There is nothing you can do to change that behavior, this is done as a security measure by the ASA ( Built-in feature).

The adaptive security appliance only responds to ICMP traffic sent to the interface that traffic comes in on; you cannot send ICMP traffic through an interface to a far interface.
https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/i1.html#wp1697623

“For security purposes the security appliance does  not support far-end interface ping, that is pinging the IP address of  the outside interface from the inside network.”

https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/trouble.pdf

 

Syslog Packet:

The syslog packet size is limited to 1024 bytes and carries the following information:

 

Facility

Severity

Hostname

Timestamp

Message

—

Syslog Port numbers:

When sending messages using UDP the destination port is usually 514

When sending messages using TCP the destination port is usually 1468

—

Syslog Message Format:

Message

This is the text of the syslog message, along with some additional information about the process that generated the message. The syslog messages generated by Cisco IOS devices begin with a percent sign (%) and use the following format:

 

%FACILITY-SEVERITY-MNEMONIC: Message-text

Following is a description of each field:

 

FACILITY— Refers to the source of the message, such as a hardware device, a protocol, or a module of the system software. Note that this FACILITY is Cisco specific and is only relevant within the message string. It is different from the facility defined in RFC 3164 for the syslog protocol.

SEVERITY— This is similar to the severity defined in Table 4-2.

MNEMONIC— This is a device-specific code that uniquely identifies the message.

Message-text— This is a text string that describes the message and can contain details such as port numbers and network addresses.

Following is a sample syslog message generated by a Cisco IOS device:

 

*Mar  6 22:48:34.452 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,

changed state to up

Note that the message begins with a special character (*) and that the timestamp includes the time-zone information. The message was generated by the LINEPROTO facility at severity 5 (Notice). The MNEMONIC UPDOWN along with the message-text describe the event.

—

Facility:

The facility allow administrators to logically separate messages (e.g. write them to separate files, forward them to different destinations, etc.)

Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to 191 and is made up of a Facility value and a Level value.

Facility

Syslog messages are broadly categorized on the basis of the sources that generate them. These sources can be the operating system, the process, or an application. These categories, called facility, are represented by integers, as shown in Table 4-1. The local use facilities are not reserved and are available for general use. Hence, the processes and applications that do not have pre-assigned facility values can choose any of the eight local use facilities. As such, Cisco devices use one of the local use facilities for sending syslog messages.

The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of Unix processes and Daemons.

The priority value is calculated using the following formula:

Priority = Facility * 8 + Level

 

Table 4-1. Facility Values

Facility 0

Kernel messages 1

User-level messages 2

Mail system 3

System daemons 4

Security/authorization messages 5

Messages generated internally by Syslogd 6

Line printer subsystem 7

Network news subsystem 8

UUCP subsystem 9

Clock daemon 10

Security/authorization messages 11

FTP daemon 12

NTP subsystem 13

Log audit 14

Log alert 15

Clock daemon 16

Local use 0 (local0) 17

Local use 1 (local1) 18

Local use 2 (local2) 19

Local use 3 (local3) 20

Local use 4 (local4) 21

Local use 5 (local5) 22

Local use 6 (local6) 23

Local use 7 (local7) 24

—

Severity Level:

The source or facility that generates the syslog message also specifies the severity of the message using a single-digit integer, as shown in Table 4-2.

The higher severity numbers “include” the lower severity numbers.

Table 4-2: The list of severity Levels:

0       Emergency: system is unusable

1       Alert: action must be taken immediately

2       Critical: critical conditions

3       Error: error conditions

4       Warning: warning conditions

5       Notice: normal but significant condition

6       Informational: informational messages

7       Debug: debug-level messages

Recommended practice is to use the Notice or Informational level for normal messages.

 

A detailed explanation of the severity Levels:

DEBUG: Info useful to developers for debugging the app, not useful during operations

INFORMATIONAL: Normal operational messages – may be harvested for reporting, measuring throughput, etc – no action required

NOTICE: Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required

WARNING: Warning messages – not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time

ERROR: Non-urgent failures – these should be relayed to developers or admins; each item must be resolved within a given time

ALERT: Should be corrected immediately – notify staff who can fix the problem – example is loss of backup ISP connection

CRITICAL: Should be corrected immediately, but indicates failure in a primary system – fix CRITICAL problems before ALERT – example is loss of primary ISP connection

EMERGENCY: A “panic” condition – notify all tech staff on call? (earthquake? tornado?) – affects multiple apps/servers/sites…

—

Syslog IDs:

https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog.html

https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs-sev-level.html

—

Event(All event classes) Lists:

Event List can be used to filter syslogs IDs (syslog ID or a range) sent to a logging destination.

—

Logging Filters:

Logging filters are used for logging destinations e.g. Syslog Servers, Email, ASDM, Internal buffers, Console, SSH, SNMP trap and attach the Event List to is as well.

—

Message/Event Class:

Use the message class in order to send all messages associated with a class to the specified output location e.g. auth, config, ha, snmp, vpn, ssl etc.

—

Syslog servers:

Simply define the destination IPs to send the logs (usual port number udp/514).

Scenario 1 – Wrong IPsec IDs are negotiated during IKE Quick Mode:
Symptoms:
“Invalid ID information” log in SmartView Tracker when the Security Gateway initiates a Quick Mode.
“No valid SA” logs in SmartView Tracker when creating IPsec VPN tunnel with an interoperable device.
Remote Access Client cannot access internal resources over the Site-to-Site tunnel with 3rd party VPN peer.

Explanation:
VPN tunnel can be initiated from 3rd party side to the Check Point Security Gateway side, but not from Check Point side to 3rd party side.
During IKE Quick Mode negotiation, the IP addresses, which define the VPN tunnel (also known as IPSec IDs, or traffic selectors) are negotiated. The IP addresses can be a set of discrete IP addresses, or a subnet.
When negotiating a VPN tunnel between Check Point Security Gateway and certain 3rd-party devices, IKE Quick Mode may fail, if the subnets are defined differently on each end of the VPN tunnel. One reason is that Check Point Security Gateway dynamically supernets subnets to reduce the amount of SA overhead.

Solution:
Define the IP ranges that the Check Point Security Gateway should negotiate with this 3rd party peer in the “subnet_for_range_and_peer” table in the relevant “user.def” file on the Security Management Server / Domain Management Server.

The “subnet_for_range_and_peer” table is designed to force Check Point Security Gateway to negotiate IPsec SAs using a specific subnet mask for a given IP address range:

subnet_for_range_and_peer = {
<peerGW_IP, first_IP_in_range1, last_IP_in_the_range1; subnet_mask>,
<peerGW_IP, first_IP_in_range2, last_IP_in_the_range2; subnet_mask>,
… … …
<peerGW_IP, first_IP_in_rangeN, last_IP_in_the_rangeN; subnet_mask>
};

 

Location of user.def file on the management:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239

1.0 How IPsec Site to Site VPN Tunnels Work
1.1 Remembering the 5 Things to Negotiate in IKE Phase 1 (IPsec)
1.2 How to Set Up a Site-to-Site VPN with Check Point Gateways Managed by the same Management Server
1.3 How to set up a Site-to-Site VPN with a 3rd-party remote gateway
1.4 Checkpoint Site to Site VPN (R80)
1. 5 Checkpoint Site to Site VPN (R75/76/77)
2. Connection to the Security Gateway with WinSCP fails
3. Check Point – How To Collect CPinfo – CLI
4. 3rd party VPN/Invalid ID information/No valid SA (Summary subnet sent)
5.0 Check Point R77 Features
6.0 Building a Checkpoint Network
6.1 Checkpoint Installation/SIC/Basic Setup
6.2 Interfaces Configuration and Default Route
6.3 Basic Security Policy and NAT
7.0 Basics of SmartView Monitor

1.0 Creating objects on ASA from a file of IPs and Putting then in an object group (CLI)
2.0 Packet Capture ASA (ASDM/CLI)
2.1 ASA Packet capture (ASDM)
3.0 ASA and ASDM Upgrade (ASDM)
4.0 Syslog (Cisco ASA)
4.1 ASA syslog configuration (ASDM/CLI)
5.0 ASA not allowing ping to distant or far interface IPs
6.0 SNMPv3 Configuration on ASA (ASDM)
7.0 Cisco ASA – Permitting traffic between two interfaces with the same security lev
7.1 Traffic between ASA interfaces of same security level

Power Shell Script (Run it straight from powershell prompt/file must be in the same directory):
foreach( $ip in Get-Content ips.txt ){
Write-Host “object network blacklist_$ip”
Write-Host “host $ip”
Write-Host “object-group network Blacklisted_Domains_IPs”
Write-Host “network-object object $ip”
}