More frequently, than expected, CheckPoint LOM cards stop responding to HTTPS connections, or even to pings. This is how they can be reset from GAIA CLI:
service ipmi start ipmitool mc reset cold service ipmi stop
More frequently, than expected, CheckPoint LOM cards stop responding to HTTPS connections, or even to pings. This is how they can be reset from GAIA CLI:
service ipmi start ipmitool mc reset cold service ipmi stop
To make the log format predictable, create /etc/fw/conf/logexport.ini with the following
For R70 (Secuplat):
[Fields_Info] included_fields=num,date,time,src,dst,proto,service,action,xlatesrc,xlatedst,peer gateway,<REST_OF_FIELDS>
For R77 (GAIA):
[Fields_Info] included_fields=date,time,src,dst,proto,service,action,xlatesrc,xlatedst,peer gateway,<REST_OF_FIELDS>
Create a directory for the converted logs:
mkdir /var/log/2019.txt
Run the following command to convert all logs, for example, for January 2019:
for i in $FWDIR/log/2019-01-*.log; do echo $i; fwm logexport -n -p -i $i | gzip -c - > /var/log/2019.txt/$i.txt.gz; done
Provided all route metrics are zeroes:
cat /etc/sysconfig/netconf.C | tr '(' ' '| tr ')' ' ' | tr '"' ' '| tr ':' ' ' | tr '\t' ' '| tr -s ' '| sed -e 's/^ //' | sed 's/routes//' | awk '/route/ {printf("set static-route ");} /dest/ {printf("%s ",$2);} /via/ {printf("nexthop gateway address %s ",$2);} /metric/ {print "on"}'
The result:
set static-route 10.13.198.160/27 nexthop gateway address 10.12.12.1 on set static-route 10.13.198.192/27 nexthop gateway address 10.12.12.1 on set static-route 192.168.112.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.113.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.114.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.115.0/24 nexthop gateway address 10.12.12.1 on set static-route default nexthop gateway address 10.0.0.1 on
Update: fixed in v19.0beta (at least v19.0b1 build3 looks good):
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (19b1 does not save sessions, though 😉
Firefox 18 (all betas and 18.0) crashes on Solaris 11 and OpenSolaris. The workaround is to set the following variables to “false”:
browser.cache.disk.enable browser.cache.memory.enable browser.cache.disk_cache_ssl
See bug 827971.
Sometimes you do not need a detailed log-analysis but several simple one-liners that you can adjust without too much thinking how it works, what you did last time, etc. The examples below are absolutely NOT optimal, but rather modular for easy line-editing.
1. Allowed traffic:
cat asa.log | grep permitted | grep access-list |
sed -e 's/^.*permitted//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' | less
Result:
tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
tcp outside/10.2.8.35 -> inside/10.1.140.137(13000)
udp outside/10.2.8.25 -> inside/10.1.9.14(137)
udp outside/10.2.8.25 -> inside/10.1.81.15(137)
tcp outside/10.2.8.44 -> inside/10.1.140.137(13000)
tcp outside/10.2.8.31 -> inside/10.1.140.149(13000)
Noticed the “permitted” strings?
2. Denied traffic:
cat asa.log | grep denied | grep access-list |
sed -e 's/^.*denied//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' | less
Result:
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
tcp inside/10.3.241.116 -> outside/10.2.8.251(1541)
tcp inside/10.3.241.116 -> outside/10.2.8.251(1547)
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
3. The most popular permitted traffic:
cat asa.log | grep permitted | grep access-list |
sed -e 's/^.*permitted//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' |
awk ' {conn[$0]++;} END { for ( i in conn ) print conn[i]," ",i;}' | sort +0nr | less
Result (the first column is the amount of corresponding log entries):
21170 tcp outside/10.2.8.40 -> inside/10.1.140.149(13000)
18023 tcp outside/10.2.8.34 -> inside/10.1.140.149(13000)
17981 tcp outside/10.2.8.31 -> inside/10.1.140.149(13000)
11034 tcp inside/10.1.140.251 -> outside/10.2.8.68(10001)
10652 tcp outside/10.2.8.43 -> inside/10.1.140.137(13000)
10628 tcp outside/10.2.8.44 -> inside/10.1.140.137(13000)
10484 tcp outside/10.2.8.47 -> inside/10.1.140.137(13000)
10437 tcp outside/10.2.8.23 -> inside/10.1.140.137(13000)
7618 tcp outside/10.2.8.25 -> inside/10.1.140.137(13000)
7550 tcp outside/10.2.8.27 -> inside/10.1.140.137(13000)
7515 tcp outside/10.2.8.49 -> inside/10.1.140.137(13000)
7496 tcp outside/10.2.8.29 -> inside/10.1.140.137(13000)
6826 tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
6011 tcp outside/10.2.8.35 -> inside/10.1.140.137(13000)
5896 tcp outside/10.2.8.40 -> inside/10.1.141.23(8080)
5809 tcp outside/10.2.8.30 -> inside/10.1.140.137(13000)
4. Modification for versions 8.2+:
cat asa.log | grep Deny | grep access-group | sed -e 's/^.*Deny//' -e 's/by.*$//' | sed -e 's/dst/ ->/' -e 's/src//' | less
You can use this method to generate a policy based on the current traffic.
Additional “greps” will allow you to filter for specific ports or IP-addresses.
Replace “permitted” with “denied” and you’ll get the “most popular denied traffic”.
… and the WordPress for Android application.
It works and I like it 😉
Recently I’ve stumbled upon a strange looking site-to-site (CheckPoint R70 to Cisco VPN3k) VPN problem:
Connections from some networks were dropped with the following error:
Encryption failure: Received a cleartext packet within an encrypted connection
The first step was to check the encryption domains for the tunnel. In both GUI and /etc/fw/conf/user.def the encryption domain was the whole class B network, assigned to the company.
Next step was tracing.
Continue reading “Encryption failure: Received a cleartext packet within an encrypted connection”
Updated on Apr 07, 2011 @ 02:54:
If you made the change below for 3.1RC-3.1 and/or used manually created tag/category links in 3.1RC-3.1 and just upgraded to 3.1.1, you may find that the links are broken. The reason is that in 3.1.1 the tag and category links returned to the 3.0 style with the word “archives” in the URL.
To make it work you can change .htaccess to the following:
RewriteEngine On RewriteBase / #or where your blog root is #RewriteRule archives/category/(.*) category/$1 [L,R=301] #RewriteRule archives/tag/(.*) tag/$1 [L,R=301] RewriteRule ^category/(.*) archives/category/$1 [L,R=301] RewriteRule ^tag/(.*) archives/tag/$1 [L,R=301]
Posted on Feb 25, 2011 @ 00:22:
In WordPress 3.1 the link structure have been changed
from (< =3.0.x):
wp/archives/category and wp/archives/tag to (>= 3.1.x) wp/category and wp/tag
If you have existing “hard” links to tags or categories, add the following lines (in red) to .htaccess:
RewriteEngine On RewriteBase / RewriteRule archives/category(.*)$ category$1 [L,R=301] RewriteRule archives/tag(.*)$ tag$1 [L,R=301]
You can use Coral free CDN to off-load the WordPress attachments (usually images). In order to use Coral you need to add “.nyud.net” to the site DNS address. For example, http://www.alekz.net will become http://www.alekz.net.nyud.net. Coral is usually too slow to serve all static content, so the most effective solution would be to use it only for the biggest files.
Here’s a simple solution. Add the following to functions.php of your current theme:
add_filter ('wp_get_attachment_url', 'freecdn_url'); function freecdn_url ($url) { if (! is_attachment () ) return $url; $cdn_url = ".nyud.net"; $decomposed_url = explode ("/", $url); $decomposed_url[2] = $decomposed_url[2] . $cdn_url; $url = implode("/", $decomposed_url); return $url; }
Your theme (e.g. the bundled “TwentyTen”) must use wp_get_attachment_url(), of course. If not – you got the idea, didn’t you? 😉
Also, you can use freecdn_url () function to rewrite any URL you want to download from Coral.
Found another cPanel application which you can safely turn off in order to safe some bytes and cycles.
By default dcpumon runs every 5 min to log CPU usage (“top” output) :
and stores the data into /var/log/dcpumon
You can view the report with dcpumonview command: