View Sidebar

Why are you here?

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.

 

 

Wired Smoke Alarms — Yep, they expire.

Wired Smoke Alarms — Yep, they expire.

Сео услугиFor those of us with a fairly new home, wired smoke alarms are the norm.  A wired alarm acts in a similar fashion to battery smoke alarms.  The big difference between the two is the fact that they get power from an AC source (like your main power feed/breaker box) and they have a shared wired connection to all alarms that allow them to communicate to each other.  This shared connection  allows a single alarm to signal the rest of the devices to alarm as well.  From a safety perspective, this whole-house notification is a great safety feature.

Most wired alarms also have a 9V battery backup in case of loss of power.  In all cases, the traditional low battery “chirp” that all alarms feature will take place at 2 AM, like mine did last week.

I removed the alarm, removed the battery and went back to sleep.  The next morning, during my attempt to replace the battery in the alarm, I read the fine print on the back of the device.

Manufactured 10/2001, Expires 10/2011.

That’s right, my alarms have been expired for over 2 years!  To be honest, I didn’t even know smoke alarms did expire, only that the batteries needed to be replaced.  So, I began the research on suitable replacements.

My current alarms were the Kidde Model 1275.  These were basic alarms, with ionization sensors and a rear battery door.  There are two types of sensors in smoke alarms, ionization sensors and photoelectric sensors.  I’m not going to dig into the pros and cons of each sensor, the Underwriters Laboratories have done that for me.  Read until your heart is content.  I wanted to purchase a Kidde unit again, because they would share the same wiring harness with my old devices.

Fire-Hands-Screensaver_1After much research and two calls to Kidde Customer Service with questions, I decided on the Kidde KN-COSM-IB Hardwire Combination Carbon Monoxide and Smoke Alarm with Battery Backup and Voice Warning as well the Kidde i12080 Hardwire Smoke Alarm with Exit Light and Battery Backup.  Here is why:

  • Carbon Monoxide is the leading cause of accidental poisoning deaths in North America.  It is odorless, tasteless and invisible – it’s a silent killer. The only safe way to know if carbon monoxide is present is to install carbon monoxide detectors on every level of your home and in sleeping areas.  The Kidde KN-COSM-IB Hardwire Combination Carbon Monoxide and Smoke Alarm with Battery Backup is a great solution for this problem.
  • Kidde recommended that I do not install a CO alarm in the room where my heater is installed, which in my home is the finished basement.  This is because there is some amount of CO during the combustion process for the home’s heater.  Not enough to kill you, but enough for the alarm to sound.  So, a normal smoke alarm should be installed in these locations where CO is expected. The Kidde i12080 Hardwire Smoke Alarm with Exit Light and Battery Backup was my choice.

These alarms and not expensive and the upgrade to CO detection is worth the extra cash.  For under $200, I was able to replace all the smoke detectors in my home.  I noticed the Amazon delivery took place today, so I think I know what my weekend is going to look like!

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!

Deckkeeper Tie Downs

Deckkeeper Tie Downs

My deck is raised off the ground by about 4 feet and there is an above ground pool built into the deck.  Every spring and every fall, I struggle to close the pool. The big headache is securing a tarp to cover the pool.

When I had pressure treated decking, I would just screw some hooks into the decking and use some bungee cords to secure the tarp.  I recently replaced the pressure treated boards with composite decking. There is no way I’m going to drill holes into my beautiful boards!

So, I’ve struggled with securing the tarp.  I attached bungies to the railing, I secured it through the boards under the deck, you name it.  All of these solutions took time, effort and were simply not easy.  I had to find a better way!

I heard about these DeckKeeper Tie Down devices from Ask This Old House a few years ago.  They slip between the boards, include bungee cords to attachment and protect the surface of the deck.   I bought them from Amazon and closed the pool this fall using them.  What a difference!  I secured the tarp in the a few minutes, I didn’t have to crawl under the deck.  At only $20 for 4, not a bad deal.

Link to the Peppermill Home — The Manufacturer

 

photo 4 photo 3 photo 2 photo 1