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:
Last week, I acquired a small netbook @ work for testing purposes (HP Mini 5103). You don't want to know how handy a second laptop is when you're testing authentication environments.
For flexibility purposes I installed a dual-boot with Microsoft Windows 7 Enterprise and Ubuntu Linux v10.10 from a USB Flashdrive (1, 2), erasing all the preinstalled HP/McAfee crap. This all worked like a charm, up to the installtion of Wireshark in Ubuntu. Starting the sniffer application resulted in an empty list of network adapters. No network adapters mean no capturing capabilities.
This was probably related to the lack of rights while starting the application. Running it from the terminal with sudo resulted in some weird error regarding a display-thingy (which is still the main reason why Linux isn't penetrating the desktop market).
While searching the Interwebs, I found the following solution. Which, after some alterations to the commands, the following worked for me;
In a terminal session, execute these commands:
sudo addgroup –quiet –system wireshark (this command simply didn't work in my case)
sudo chown root:wireshark /usr/bin/dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
usermod -a -G wireshark <my user name>
Reconfigure the Wireshark Common package and answer ‘Yes’ to the question ‘Should non-superusers be able to capture packets?
sudo dpkg-reconfigure wireshark-common (I needed to add the sudo part on this command)
After rebooting the laptop, Wireshark started normally with all the network interfaces available for capturing traffic.
UPDATE: I did a reinstall of the OS, and this time Wireshark started 'properly' from the Terminal application by typing (without the quotes) 'sudo wireshark'.
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.
For testing and development purposes I run a Cisco Secure ACS 5.x in a virtual machine at home. In this environment I also run an Apple Directory Service. I'll be using this setup to test several 802.1x and RADIUS authentication schemes.
To get things going I needed to connect to the ACS to my LDAP Directory. The Apple Directory Service is a bit different from the regular LDAP implementations. They seem to add the 'apple' reference in a lot of attribute values. Thankfully the ACS has a very versatile configuration interface.
;)
Apple references in attribute valuesNormally, the group definition would be 'group' instead of 'apple-group'. So the configuration of the ACS should reflect these variations to the standard.
Earlier this week I got the announcement (I opened an Adobe application) that there was an update for the Adobe Reader app. Security-conscious as I am, I fired up the update process.
Each time, this process stopped at the (near??) end of the installation with the following error:
The operation couldn’t be completed. (com.adobe.ARM error 1807.)
The error also suggested looking at the log file. Examination of this file showed nothing out of the ordinary. At least not that made sense to me.
There were some lines in the log that made me try to do a work-around (in bold);
During the clean-up of my personal data on my Mac's, I found several PGP encrypted containers, and encrypted files. To see what was stored in them, I needed to install PGP (again).
After installing the software I dug up my keyrings and everything worked fine, until I tried to encrypt an e-mail. In the old days you had a button for encrypting the body of an e-mail message, but today things have changed. PGP is using some sort of (local) proxy to encrypt, decrypt, sign and verify e-mail messages. BUT there's also the possibility to do this with text on the clipboard, or text you selected with your mouse/keyboard.
This is where I ran into some missing functionality; Normally the PGP actions are visible under the 'right-mouse' click -> Services, but no PGP actions available. Further investigation showed that no PGP actions were available on (plain) text in editors. PGP actions on entire files were no problem.