A Splunk server I installed was configured such that it could only communicate with hosts within the corporate network so it did not have direct internet access. This posed a problem when trying to use the “Browse Splunkbase” option in the Splunk administrator web interface. I also could not use the “iplocation” data-processing command.
This was the suggestion I got from Splunk Support which didn’t work for me for some reason. I am including it here for reference for someone where this solution may work for them:
You can set the environment variable HTTP_PROXY in the session shell.
You can set it in your /etc/bashrc or /etc/profile.
# Proxy Settings
I also found something in the forums:
The Splunk install I was running was version 3.4.9 which was on a CentOS 5 server. The Splunk installation was configured to autostart on boot. I ended up getting this to work by editing the /etc/init.d/splunk startup script file by adding the following to it:
# Proxy settings
Change “proxy.domain.com:8080” to be the proxy server address and port for the proxy server that you want to use. So with the above lines added to my /etc/init.d/splunk file, the top portion of the file looked like this:
# init script for Splunk.
# generated by 'splunk enable boot-start'.
# chkconfig: 2345 90 60
# description: Splunk indexer service
# Proxy settings
I put the setting into effect by restarting my Splunk service with the command: /sbin/service splunk restart
Firestarter is a GNOME program which offers a GUI interface to the IP Tables firewall.
If you have Firestarter configured to allow all IPs addresses to all ports or a particular port on your server, you can’t block a specific IP from accessing those ports using the GUI interface. However, Firestarter does allow you to manually specify IP Tables rules to either load up BEFORE or AFTER the Firestarter firewall rules by editing configuration files. On CentOS 5, the file to put the rules you want to load before Firestarter’s rules is /etc/firestarter/user-pre. For rules you want to load after Firestarter loads its firewall rules, edit the file /etc/firestarter/user-post. When you add your rules, instead of using the command “iptables” you need to use the variable name “$IPT” instead. To block an IP address from accessing any of your ports, you will need to add the IP Tables rule to the user-post file.
For example, say you want to block the IP address 220.127.116.11 from accessing your server on any port. The normal IPTables rules for this is:
iptables -I INPUT -s 18.104.22.168 -j DROP
To make this rule work with Firestarter, add the following line to the /etc/firestarter/user-post file:
$IPT -I INPUT -s 22.214.171.124 -j DROP
After you edit the user-pre or user-post files, you have to restart the Firestarter service to put them into effect. On CentOS 5 you can run the following terminal command to restart the Firestarter service:
service firestarter restart
If you want to block a range of IP addresses from accessing your CentOS server you can issue the following IPTables firewall command:
/sbin/iptables -I INPUT -m iprange --src-range 192.168.1.1-192.168.1.2.100 -j DROP
Replace “192.168.1.1-192.168.1.2.100” with the IP range you want to block. This command only works with the IPTables firewall so if your operating system is using a different firewall then this command will not work.
Here is another example which uses CIDR notation to specify the IP range:
/sbin/iptables -I INPUT -s 192.168.1.1/25 -j DROP
If you restart your server, the drop command will be removed. If you want this command to persist through reboots, then you’ll need to add it to a startup script.
The NSA recently declassified a document which revels the story behind how the United States first discovered the security threat of TEMPEST. TEMPEST is defined in Wikipedia as:
TEMPEST is a codename referring to investigations and studies of compromising emanations (CE). Compromising emanations are defined as unintentional intelligence-bearing signals which, if intercepted and analyzed, disclose the information transmitted, received, handled, or otherwise processed by any information-processing equipment.
The concept of TEMPEST is fairly simple. Basically every electronic device emits an electrical transmission while in use. These electrical transmissions are similar to radio waves in that you can build something that can receive and process these transmissions like how a car radio receives a radio station’s broadcast. Every electronic device due to the way the electronic components are laid out in the device emit unique signals. So if you can find a similar electornic device you could map out what signal a device emits for any action performed on that device. For example, say when you press the “W” key on your keyboard it sends a signal through your keyboard wire to your computer and this signal has a frequency of 1Hz. Then when you press the “Y” key on your keyboard the signal sent though the keyboard wire is 2Hz. Then someone in theory who already knows that the particular model of keyboard that you are using has this signal behavior could stand somewhere near your desk and determine what you are typing on your keyboard based on the electrical signals traveling through the air which are being emitted from the wire going from your keyboard to your computer. Now these electrical signals being given off by devices are usually VERY weak and a person would have to be standing very close to receive and decode them so you are relatively safe in this regard but it is something to consider if you are processing extremely sensitive information. Supposivly there are techniques to pull these electrical signals from power lines since in theory if your computer is plugged into the power outlet in your wall then the electrical signals from your computer are being leaked into the power line.
Here is a direct link to the NSA TEMPEST document: http://www.nsa.gov/public/pdf/tempest.pdf
A copy of the NSA document is also available on this web server at this link: nsa_tempest_a_signal_problem