Posts

Showing posts from February, 2021

Ironport - Spoof protection or anti-spam using SPF

 Concept: An SPF record is a DNS record that has to be added to the DNS zone of your domain. In this SPF record you can specify which IP addresses and/or hostnames are authorized to send email from the specific domain. The mail receiver will use the “envelope from” address of the mail (mostly the Return-Path header) to confirm that the sending IP address was allowed to do so. This will happen before receiving the body of the message. When the sending email server isn’t included in the SPF record from a specific domain the email from this server will be marked as suspicious and can be rejected by the email receiver. MX record is for sender to find the receiver's mail server. TXT record s for receiver to find/verify the sender's allowed mail server. https://www.dmarcanalyzer.com/spf/how-to-create-an-spf-txt-record/ https://www.dmarcanalyzer.com/how-to-validate-your-spf-record/

Ironport - Spoof Protection using Forged Email Detection

Image
 Issue: Cousin domain abuse : Sending email from cousin domains that pass Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-Based Message Authentication, Reporting, and Conformance (DMARC) checks. The From value will show a similar sender address that impersonates a real one (for example, using alice@a1pha.com to impersonate alice@alpha.com). Free email account abuse : Using free email (Yahoo, Gmail, etc.) that pass SPF, DKIM and DMARC checks. The From header will show a legitimate sender address with an executive’s name@gmail.com. Solution :   1. Create an entry for the impersonated username in Directory Mail Policies > Dictionaries > Add Dictionary 2. Create an incoming content or message filter Mail Policies > Incoming Content Filters > Add Filter 3. Add  the FED Action 4. Prepend the subject header with: [WARNING Possible Business Email Compromise] Result: 5. Apply the filter to an incoming mail Policy Mail Policies > Incoming Mail Policy

Ironport - Spoof Protection using Sender Verification

 Issue: Envelope sender address is spoofed, looks come from local domain Mail Flow Policy has setting can do DNS verification on envelope sender domain for three situations: domain doesn't exist domain doesn't resolve malformed Mail Flow Policy has another setting called Sender Verification Exception Table, which can be used to bypass above envelope sender DNS verification for specified domain with Allow behavior. It also can be used to reject envelope sender for specified domain with Reject behavior So if we can add the local domain to this Exception Table with Reject behavior, this can drop the spoofed envelop sender email.   Configure Exception Table From the GUI:  Mail Policies > Exception Table > Add Sender Verification Exception... Add the local domain to the Sender Verification Exception Table Set the  Behavior  to  Reject Configure Mail Flow Policy (MFP) For a specific Mail Flow, In  Mail Policies > Mail Flow Policies > [mail flow], s et  Use Sender Verifica

Palo Alto Cli

find command keyword xxxx  1. show system info 2. show routing route 3. show running nat-policy 4. test nat-policy-match  5. ping host  !! From management interface 6. ping source xxxx host yyyy  !!ping from data plane interface test routing fib-lookup virtual-router default ip x.x.x.x show session Run the following command to view the configuration: "set" format:     >  set cli config-output-format set "xml" format:    >  set cli config-output-format xml https://www.shanekillen.com/2014/02/palo-alto-useful-cli-commands.html https://indepthtechnology.org/2022/02/20/palo-alto-show-commands/ https://weberblog.net/cli-commands-for-troubleshooting-palo-alto-firewalls/

Checkpoint S2S VPN to ASA

Image
 Summary 1. Checkpoint GW configuration for S2S VPN 2. Add Interoperable Device for ASA 3. Add VPN Community 4. Add Policy rules. ====================== 1. Checkpoint GW configuration for S2S VPN 1.1 "IPSec VPN" blade is selected. 1.2 Verify network topology 1.3 Network Management > VPN Domain  Or set Specific VPN domain for Gateway Communities (R80.40) 2.  Add Interoperable Device for ASA 2.1 Specify remote peer IP address 2.2 Topology>VPN Domain 3.  Add VPN Community 3.1 Create a Meshed Community, add local and remote gateways to the list 3.2 Configure Phase I and Phase II parameters 3.3 Tunnel Management, select per subnet pair 3.4 Configure Shared Secret 3.5 Advanced section to set life time and disable NAT inside the VPN community   4. Verify VPN ip address by default, main address is selected,  which is the IP in "General Properties" section. 5. Add rule 6. Note in case local IP is NATed before go to VPN tunnel Create NAT rule VPN domain includes both re