View Sidebar

Archive for category: Technical

Checkpoint Firewall Upgrade from R67 VSX to R77.10 VS & CIFS Resources

Checkpoint Firewall Upgrade from R67 VSX to R77.10 VS & CIFS Resources

I have some Crossbeam X80 hardware running R67 VSX for some virtual firewalls.  Life is good and everything worked fine.  I planned and executed an upgrade plan for these blades to move to Checkpoint R77.10 VS.  The policy upgrade process and software upgrade process went with zero errors.  When we tried to push the policy to the firewalls, it would fail.  The errors, during a debug, were ambiguous at best.

What was the eventual issue?  CIFS Resources with greater then 25 file shares.  It seems the IPS in R77 has a hard limit of 25 shares in CIFS resources.  We use CIFS resources as an extra level of protection when 3rd Parties access our Windows File Shares.

Most of our CIFS resources had less then 25 file shares, so they needed no change.  But, a single 3rd party accessed quite a few shares.  So, the revert back to a straight CIFS service group on these rules and removal of the CIFS resource in the firewall policy allowed a successful push of the policy to the gateway.

NOTE TO SELF: Keep that one in your back pocket.

Checkpoint Firewall: SecureXL and PPPoE do not play well

Checkpoint Firewall: SecureXL and PPPoE do not play well

I recently had to upgrade an R70 Checkpoint firewall to R77.10.  Due to a variety of issues, this required a nuke and rebuild of the firewall via USB key to upgrade to R77.10.

The upgrade went fine, but during testing the firewall passed no traffic. This was an unusual config, the internet service was a PPPoE connection.

After a fair amount of troubleshooting went into this problem.  It wasn’t until a fw ctl zdebug -m fw + drop  command was run that the problem become obvious.  The following error was displayed:

;[fw4_0];fw_log_drop_ex: Packet proto=6 159.7.34.61:10002 -> 126.246.75.211:80 dropped by cphwd_offload_conn Reason: VPN and/or NAT traffic between accelerated and non-accelerated interfaces or between non-accelerated interfaces is not allowed;

A quick look on Checkpoint’s Support Site gave us Solution ID: sk79880.

SYMPTOMS

Kernel debug shows (fw ctl zdebug -m fw + drop) that traffic is dropped:

‘… is dropped by cphwd_offload_conn Reason: VPN and/or NAT traffic between accelerated and non-accelerated interfaces or between non-accelerated interfaces is not allowed’

CAUSE

No fix is required; the system is functioning as designed.

SecureXL does not support Point-to-Point interfaces (PPP, PPTP, PPPoE). In case a PPP-interface is detected, SecureXL disables itself on that interface (hence the name ‘non-accelerated interface’).

Refer to the following note in any ‘Performance Pack Administration Guide’ (R65, R70, R71, R75, R75.20, R75.40, R75.40VS, R76):

Note: Performance Pack is automatically disabled on PPTP and PPPoE interfaces.

If a connection is detected, which flows through even one such non-accelerated interface, and this connection is NATed and/or sent over VPN, it will be dropped, because SecureXL is not able to handle it: because of NAT (Client Side or Server Side) and/or VPN, some connection parameters are not available – SecureXL is not able to determine how to pass such connection.

SOLUTION

Possible steps:

  1. Change the rulebase, so that the problematic connection is not sent through such non-accelerated interface(s).
  2. Disable NAT on the problematic connection.
  3. Change the rulebase, so that the problematic connection is not sent over VPN.
  4. Disable SecureXL completely (via ‘fwaccel off’ command and via ‘cpconfig’ menu).

We disabled SecureXL and had no problems since.

 

 

Preventing WordPress Brute Force Attacks with Fail2Ban

Preventing WordPress Brute Force Attacks with Fail2Ban

I have been experiencing a high number of brute force attacks on the admin pages of some of my WordPress blogs.  Generally, I don’t worry too much about this.  I utilize multiple levels of security controls to prevent access to the admin sites, but the increase in bandwidth and load on my system during these attacks was a concern and I wanted a clean way to prevent it from happening.

I looked into some type of WordPress Plugin to stop the attacks, but I soon realized it wouldn’t stop my main concern, the bandwidth and CPU load the attacks caused.  I wanted a reactive, IP address block against the offending systems.  I already used Fail2Ban for SSH, FTP and other types of brute force attacks.  Why can’t I used Fail2Ban for WordPress logins as well?

I did some searching and found the following web site that gave me the base for my filter and jail configs (Check that site for all the technical details, I won’t steal directly from him).  But, there were some problems that I had to customize to get it work for on my site.

First, the configs mentioned do not use my preferred method of blocking access, IPTABLES nor does it send an email when a IP is blocked. Second, my hosting server is using cPanel as a management system and it uses multiple access log files for all the different sites.

First Problem — Using IPTABLES and sending email alert
Here is the way I edited my /etc/fail2ban/jail.local file to support the changes I wanted to make.  The most important addition I have is the action line that lists iptables-multiport.  This blocks the IP at the TCP/IP level, never letting them touch the server again during the ban time.  In addition, I added the sendmail-whois line to the action to get the email out the door.   (Note, items in <> were removed by me to prevent private data from going public)

# Added for WordPress Brute Force
[apache-wp-login]

enabled = true
port = http,https
action = iptables-multiport[name=Wordpress, port=”http,https”, protocol=tcp]
sendmail-whois[name=Wordpress, dest=<email>, sender=fail2ban@<host>]
filter = apache-wp-login
logpath = /usr/local/apache/domlogs*/*.*
maxretry = 10
bantime = 86400
findtime = 120

Second Problem — Supporting cPanel multiple log files
As listed above, the logpath command is a tricky one.  Fail2Ban wants a direct path to the Apache access_log file.  Since I use cPanel and it splits out each host/site with it’s own log file, it was tough to set this up.  I could have manually entered each log file.  But, this would have required me to remember to add the log file in for each new host.  By using the logpath line item as listed, I was able to monitor all the log files in the directory, all the time.

logpath = /usr/local/apache/domlogs*/*.*

And that’s it!  I modified the maxretry and bantime (10 attempts and 24 hour ban time) to my preferred settings, restarted fail2ban and tested.  Success!

Fun with MAC Addresses and Crossbeam X80s

Fun with MAC Addresses and Crossbeam X80s

We had a fun little gotcha a few weeks ago while upgrading a Crossbeam X80 CPM from XOS 9.5.X to 9.6.6. As part of security controls we have in place in the perimeter, we implement MAC address filtering on the border switches. We implement very basic ACLs for the MAC addresses.

mac access-list extended mac_gi26
 permit host 0003.d2e0.0101 any
interface GigabitEthernet0/26
 switchport access vlan 901
 switchport mode access
 mac access-group mac_gi26 in
 spanning-tree portfast

So,  post upgrade to XOS 9.6.6 we lost access to many of our zones that previously worked.  After some digging around, we noted that the MAC addresses on the Crossbeam NPMs changed post upgrade.  This change was not noted in the Release Notes (at least I couldn’t find it).

The good news is that Crossbeam allows for the manual changing of MAC addresses on the X-Series Platform.  A simple change of the MAC address cleaned everything up.

[no] mac-addr <MAC_address>
IPSEC S2S VPN via AWS Openswan and Cisco IPSEC Router

IPSEC S2S VPN via AWS Openswan and Cisco IPSEC Router

I was asked to assist on setting up a Site-to-Site (S2S) VPN between an Amazon Web Service AC2 environment and a Cisco IPSEC router.  Instead of working on the customer’s production environment, I decided to setup my Cisco 2821 router as an IPSEC endpoint and try to do it from home.  There is a fair amount of instructions on the internet on how to do this.  But, it seems no matter what I tried, I wasn’t able to get it to work.  The biggest hurdle was the fact that my Cisco IPSEC router was behind a NATing firewall.  Please note, the IP addresses have been changed on my example to some randoms.

I relied heavily on this post titled CONNECTING TO A CISCO ASA VPN VIA AMAZON EC2/VPC to get the basis on how to do this.  It took me about two days to get everything the way I wanted it, so I’m going to tackle the instructions on my own as well.

Here is a quick and dirty diagram:

IPSEC-EC2

Start a Amazon VPC Instance

  1. Go to the VPC tab.
  2. I chose a Ubuntu 64 Bit AMD64 server, micro instance.
  3. Click Network & Security –> Elastic IPs
  4. Allocate New Address, associate the new address to the new micro instance.
  5. I didn’t setup the Amazon firewall initially.
  6. Test SSH into your instance, you should get a UNIX prompt.

Before you begin installing and configuring your Cisco device or Openswan, you need to gather some information:

EC2 Side

Private IP: 10.96.42.55
Elastic IP: 54.235.135.80

Home Side

Private Network: 1.1.1.0/24
Router Public IP: 192.168.1.5
Firewall Public IP: 71.162.211.111

Install and Configure Openswan

  • From the command prompt, run sudo apt-get install openswan openswan-doc ipsec-tools
  • Edit /etc/sysctl.conf:

net.ipv4.ip_forward = 1

  • Run sudo ipsec verify (note any issues)
  • Edit /etc/ipsec.conf

nat_traversal=yes

protostack=netkey

include /etc/ipsec.d/*.conf

  • Run sudo ipsec verify (all issues should be resolved or have N/A,WARNING)
  • Run sudo service ipsec restart

 

Edit /etc/ipsec.d/home.conf (new file)

conn home

left=%defaultroute
leftsubnet=10.96.42.55/32
leftid=54.235.135.80
right=71.162.211.111
rightid=192.168.1.5
rightsubnet=1.1.1.0/24
authby=secret
ike=3des-md5
esp=3des-md5
keyexchange=ike
auto=start

Edit /etc/ipsec.d/home.secrets (new file)

192.168.1.5 54.235.135.80 : PSK “cisco123”

 

Configure the Cisco Router

crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
 lifetime 3600
crypto isakmp key cisco123 address 54.235.135.80
crypto ipsec security-association lifetime seconds 28800
crypto ipsec transform-set AMAZON-TRANSFORM-SET esp-3des esp-md5-hmac
crypto map INTERNET-CRYPTO 11 ipsec-isakmp
 description Amazon EC2 instance
 set peer 54.235.135.80
 set transform-set AMAZON-TRANSFORM-SET
 match address 111
interface GigabitEthernet0/0
 ip address 192.168.1.5 255.255.255.0
 no ip route-cache cef
 no ip route-cache
 duplex auto
 speed auto
 crypto map INTERNET-CRYPTO
interface GigabitEthernet0/1
 ip address 1.1.1.1 255.255.255.0
 duplex auto
 speed auto
ip route 0.0.0.0 0.0.0.0 192.168.1.1
access-list 111 permit ip 1.1.1.0 0.0.0.255 host 10.96.42.55

 

Important Notes:

  • I setup my home router/firewall to create the 192.168.1.5 IP address as a DMZ.  This means that I didn’t need to setup any type of port forwarding or firewall rules, it was forwarding all traffic from my external IP address to the internal IP address.  Your mileage may vary.
  • Note the “right” and “rightid” calls in the home.conf file.  right=external IP at home, rightid=actual Cisco router IP. This is important.  Because I was behind a NATing firewall, these settings came into play.  IPSEC doesn’t play very well in NAT and even though I was using NAT-traversal, those settings were key.
  • This was just a simple IP to network test.  You’ll need to modify the ACLs as appropriate to access your devices.
  • I had a devil of a time matching the isakmp policies and transform-set settings on the Cisco with the Openswan.  Both platforms use different terms for the same thing.  Some commands to know and love:
    • Openswan — sudo ipsec auto –status
    • Openswan — sudo ipsec whack –status
    • Ubuntu Logs — /var/log/auth.log
    • Cisco — debug crypto isakmp
    • Cisco — debug crypto ipsec
    • Cisco — debug crypto isakmp error
    • Cisco — debug crypto ipsec error