REDELIJKHEID
The earlier posts on my logging experiences didn't include the logrotation solution I used on my OS X Server.
When you create a new logfile (and have syslog fill that file up), you're gonna run into a lack of space sooner or later. This happens because the syslog server keeps writing data to that file, and the system doesn't 'recognize' (read: isn't configured) the file for logrotation. So, you need to tell the logrotation process to include the new logfile (and what to do with it).
Now that I have a SRX running at home and a syslog server powered by Splunk (free version) it's time to be able to understand the logging. The raw logging is pretty unreadable for the average Joe. Thankfully, Splunk can be used to make more sense of it.
Downside is that I haven't found any add-ons / plugins etc. for Splunk to analyze the logging of a Juniper SRX firewall. There is a post on the Splunk forum which offers two regular expression which can be used to define the RT_FLOW fields.
This post contains several useful Junos SRX commands for the CLI. Mainly for myself, because I don't use those command regularly....
This post will be updated over time... Here it goes:
View session information:
root@srx100> show security flow session summary
Clear sessions through the firewall:
root@srx100> clear security flow session all
Switch to other node in a cluster via CLI (over the HA-link):
root@srx100> request routing-engine login node 1
By default, the J-Web interface (GUI for the Juniper SRX firewalls) has SSL enabled. Like most devices with SSL out-of-the-box, the protection is based on a self-signed certificate. Self-signed certificates are easy (they come basically out-of-the-box), but they tend to nag you every time you connect to the GUI. So, it's time to install a proper certificate.
In this case, I use the XCA (1) software to create a new certificate. This certificate is signed by my own root CA, which I installed on all of my devices and Operating Systems. Basically, I trust myself.....
According to the Juniper support pages on SSL certificate usage, I found out that the certificates are to be in the PEM format. No problem for XCA.
The Fritzbox 7340 is the only real available VDSL modem/router in the Netherlands. Too bad, since it has some bugs (but what piece of software hasn't???). Fortunately, the router works well, just as long as you use it as the only networking device in your (small) network.
In the last couple of days I've been busy to add the Juniper SRX100 branch firewall to my local home network. The idea was the following:
Juniper started to migrate their firewalls from Netscreen to the Junos environment 'a couple of' months back. The advantage is that there's a universal OS for routers, switches and firewalls. Just like Cisco IOS. The disadvantage is that the Junos OS is being adapted for the firewalls. So the foundations are there, but there are still lots of features missing and bugs are also still abundant.
The bugs are thankfully mostly related to the WebGUI. On the commandlinethe bugs are in the same league as the Cisco, Checkpoint and every other vendor bugs. No piece of software is perfect.
Today was one of those days. First the two NSMXpress appliances failed yesterday (version 2008.2r2). No way of connecting the client gui. The webinterface and SSH connections worked fine though. Picked one up for examination, and since I had some *cough*good*cough* experiences a while back I assumed the latest software had some undocumented bug.
A back to factory defaults (version 2007.3r1) worked fine, but due to certain hardware the 2008 version was needed. So I upgraded the appliance (again) and found (while waiting) that the security certificate, used between the NSM server and the client gui, had expired on Juli 20th, 2009....... So someone forgot to update the certificates in the 2008.2r2 software.
After fixing that, the client gui worked like a charm.
While in the mids of my Juniper exam preparation I ran into a problem with my Apple equipment. Managing the Juniper firewall (SSG5 in this case) with SSH was not possible from OSX. The connection itself would work, but after entering the password the connection was closed by the remote host (the firewall).
Trying this from a Windows laptop (with SecureCRT) everything worked as expected.
Some searching revealed that this is an OpenSSH bug. To manage your Juniper with SSH from OSX you need to add a parameter to the ssh command (or edit the SSH config file).
Parameter to add:
-o ControlMaster=auto
e.g. ssh willem@127.0.0.1 -o ControlMaster=auto
Or add the following line to the global SSH config (/etc/ssh_config) or the user config (~/.ssh/config).
ControlMaster auto
Juniper has a knowledgebase article (KB12409) on the issue.