Block Command and Control requests using ASA 5500

I recently came across a blog post demonstrating how to use the Emerging Threats rule sets in order to block malware calls to command and control (C&C) hosts. Using the script referenced in the blog post may work fine, but I want to review and update when I feel like it via SSH. Per the Emerging Threats wiki these rules probably only need to be updated once a week but YMMV.

Setup the ASA (one time):

configure terminal
access-list dynamic-filter_acl extended permit ip any any 
dynamic-filter enable interface outside classify-list dynamic-filter_acl 
dynamic-filter drop blacklist interface outside 
dynamic-filter blacklist 

Download the C&C list from Emerging Threats:

$ wget http://rules.emergingthreats.net/fwrules/emerging-PIX-CC.rules

Convert the list to the required format:

$ sed 's/ET-drop/ET-cc/g' emerging-PIX-CC.rules | egrep "^access-list ET-cc deny" \
emerging-PIX-CC.rules | sed 's/access-list ET-cc deny ip/address/g;s/host //g;s/any \
/255.255.255.255/g' | awk '{print $1,$2,$3}' > emerging-PIX-CC.rules.asa

Paste the list using Putty or similar. At current there are around 3000 rules so it takes a minute:

configure terminal
no dynamic-filter blacklist
blacklist dynamic-filter blacklist
address x.x.x.x y.y.y.y

Finally, it is important to note that there could be performance implications with implementing too many rules. Be warned you may shun legitimate sites on shared hosting providers and the like.

Posted in internet, security | Tagged , , | Leave a comment

Amazon S3 Server-Side Encryption using GSUtil

If you would like to enable server-side encryption which is a relatively new feature for your Amazon S3 data using GSUtil then you need specify the header value when pushing files to their cloud.

$ gsutil -h "x-amz-server-side-encryption: AES256" cp /backups/files* s3://bucket

Note that server-side encryption protects your data at rest and that Amazon is managing the keys on your behalf by default, see post here. A better practice is to provide the encryption and decryption before and after you send and receive your data from S3.

Posted in security | Tagged , , | Leave a comment

Block IRC and other communications with McAfee VirusScan

After taking a peak at some McAfee’s logs I decided to try mucking about with some of the Access Protection functionality, specifically IRC communication. I noticed there were a number of useful entries that could be sent to log or even block attempts and said settings are not enabled by default (see end of post). A test environment was setup using a IRC daemon on Remnux and a Nmap plug-in called irc-info.nse. An initial baseline scan/connect is made to confirm that a service does reside on the virtual guest.

The host indeed has a IRC server running. We do not want our host communicating with IRC daemons so we can leverage McAfee to help us block this attempt. First, open up the Auto Protect settings in the VirusScan console.

Next, “Prevent IRC communication” was enabled as this hosts processes should not be making outgoing requests. If there were such requests from a process it could be indicative of malicious software contacting a C&C.

Now the policy is being enforced, we again test the ability to connect the remote hosts IRC service.

Nmap is able to elicit responses from the host but is unable to complete a connection to interact with the IRC server. The last screen shot depicts log entries; a reporting, and a blocking and reporting entry.

Be cautious of shunning all processes for a specific check as some applications may inadvertently use a port that a malicious process would typically use. Instead, consider white-listing those or one selecting known evil.

Posted in security | Tagged , | Leave a comment

Variance in rwfilter results from netflow v5 and YaF

Looking over some netflow data I notice some variance between the two sensors. Sensor s0 is v5 netflow data from a Cisco switch, s1 is from a network tap listening between a Router on a Stick and said Cisco switch. The latter is a capture from YaF listening on a promiscuous network interface. I needed some data so a movie streaming took care of this for me. Here is the first difference between the two data sources.

$ rwfilter --start-date=$today --end-date=$today --proto=0-255 --pass=stdout --sensor=s0 | rwstats --protocol --top --count=5 --flows
INPUT: 675 Records for 1 Bin and 675 Total Records
OUTPUT: Top 5 Bins by Records
pro|   Records|  %Records|   cumul_%|
  6|       675|100.000000|100.000000|
$ rwfilter --start-date=$today --end-date=$today --proto=0-255 --pass=stdout --sensor=s1 | rwstats --protocol --top --count=5 --flows
INPUT: 2640 Records for 3 Bins and 2640 Total Records
OUTPUT: Top 5 Bins by Records
pro|   Records|  %Records|   cumul_%|
 17|      1927| 72.992424| 72.992424|
  6|       712| 26.969697| 99.962121|
  1|         1|  0.037879|100.000000|

The difference between the flow data here is the v5 data only shows TCP connections at this point where as the tap is seeing ICMP, TCP and UDP. The next set of queries are from a streaming movie which the output has been cut for brevity.

$ rwfilter --start-date=$today --end-date=$today --sensor=s0 --type=all --proto=1,6,17 --pass=stdout --daddress=172.16.0.10 | rwsort --fields=bytes | rwcut --fields=sip,sport,dip,dport,bytes
                           69.241.37.66|   80|                            172.16.0.10|65184|  57713601|
                           69.241.37.66|   80|                            172.16.0.10|65183|  58666986|
                           69.241.37.66|   80|                            172.16.0.10|65183| 146904926|
                           69.241.37.66|   80|                            172.16.0.10|65184| 153098218|

$ rwfilter --start-date=$today --end-date=$today --sensor=s1 --type=all --proto=1,6,17 --pass=stdout --daddress=172.16.0.10 | rwsort --fields=bytes | rwcut --fields=sip,sport,dip,dport,bytes
                           69.241.37.66|   80|                            172.16.0.10|65183| 110759034|
                           69.241.37.66|   80|                            172.16.0.10|65184| 111370758|
                           69.241.37.66|   80|                            172.16.0.10|65183| 148760315|
                           69.241.37.66|   80|                            172.16.0.10|65184| 150597449|

The item to note here is the v5 netflow is reporting more bytes than the network tap for similar source and IP addresses for the respective destination IP addresses. Same results with the next filter.

$ rwfilter --start-date=$today --end-date=$today --protocol=1,6,17 --sensor=s0 --type=all --pass=stdout --saddress=69.241.37.66 --daddress=172.16.0.10 | rwstats --count=10 --fields=sip,dip,scc,bytes,sport
INPUT: 4 Records for 4 Bins and 4 Total Records
OUTPUT: Top 10 Bins by Records
                                    sIP|                                    dIP|scc|     bytes|sPort|   Records|  %Records|   cumul_%|
                           69.241.37.66|                            172.16.0.10| us| 111370758|   80|         1| 25.000000| 25.000000|
                           69.241.37.66|                            172.16.0.10| us| 150597449|   80|         1| 25.000000| 50.000000|
                           69.241.37.66|                            172.16.0.10| us| 110759034|   80|         1| 25.000000| 75.000000|
                           69.241.37.66|                            172.16.0.10| us| 148760315|   80|         1| 25.000000|100.000000|
$ rwfilter --start-date=$today --end-date=$today --protocol=1,6,17 --sensor=s1 --type=all --pass=stdout --saddress=69.241.37.66 --daddress=172.16.0.10 | rwstats --count=10 --fields=sip,dip,scc,bytes,sport
INPUT: 4 Records for 4 Bins and 4 Total Records
OUTPUT: Top 10 Bins by Records
                                    sIP|                                    dIP|scc|     bytes|sPort|   Records|  %Records|   cumul_%|
                           69.241.37.66|                            172.16.0.10| us|  57713601|   80|         1| 25.000000| 25.000000|
                           69.241.37.66|                            172.16.0.10| us| 153098218|   80|         1| 25.000000| 50.000000|
                           69.241.37.66|                            172.16.0.10| us| 146904926|   80|         1| 25.000000| 75.000000|
                           69.241.37.66|                            172.16.0.10| us|  58666986|   80|         1| 25.000000|100.000000|

The output difference between the two sensors are minimal in most cases and a large portion could be due to traffic that the tap may have better insight to report though more analysis needs to be done using tcpdump or Wireshark. Nevertheless this should be considered when determine the senor requirements and the type of data that you would like to view reporting for. That said, any reporting is be better than none.

Posted in security | Tagged , | Leave a comment

Configure YAF on Linux for NetFlow collection from a network tap or SPAN

In a previous post SiLK was setup on a Debian host using NetFlow v5 from a Cisco switch. This worked well but I also have a network tap and said Cisco switch is capable of capturing data via SPAN port(s). This got me thinking about what difference I may see between the two NetFlow sources. This guide walks through setting up YAF on a Debian Linux host to receive data from a network tap or Switched Port Analyzer (SPAN) and converting it using Yet Another Flowmeter (YAF).

First, your host will need to obtain data from your network tap or SPAN port. I have two network interface cards in my box so I connected the non-management interface to the tap and started the interface without an IP in promiscuous mode. If you would like to use a SPAN port seek guidance here.

Note that this guide assumes that you already have compiled and successfully built SiLK. If not checkout this post.

You first need libfixbufIPFIX Protocol Library. Before building IPFIX will need glib2 and its respective development libraries, I did not have the latter so a little APT action takes care of that for me.

$ sudo apt-get install libglib2-dev

Building libfixbuf is straigtforward once the prerequetes are in place.

$ ./configure --prefix=/usr
$ make
$ make install

Next we are going to build YAF is Yet Another Flowmeter which has several prerequisites. libpcap needs to be installed along with its respective development libraries. I also installed the required PCRE required libraries for application labeling.

$ sudo apt-get install libpcap-dev
$ sudo apt-get install libpcre3-dev

Next we can build YAF.

$ ./configure --prefix=/usr --enable-applabel
$ make
$ sudo make install

Now that everything is ready to go we have a little housekeeping to do on the YAF configuration files. I placed the YAF configuration file in /etc/silk/yaf.conf. This file contains all of the setting such as which interface to listen on, IPFIX port, etc.

## ------------------------------------------------------------------------
## yaf.conf
## YAF daemon startup script configuration file
## ------------------------------------------------------------------------
## Copyright (C) 2007-2011 Carnegie Mellon University. All Rights Reserved.
## ------------------------------------------------------------------------
## Authors: Brian Trammell
## ------------------------------------------------------------------------
## GNU General Public License (GPL) Rights pursuant to Version 2, June 1991
## Government Purpose License Rights (GPLR) pursuant to DFARS 252.227-7013
## ------------------------------------------------------------------------

# Must be non-empty to start YAF
ENABLED=yes

##### Capture Options ##########################################################

# Live capture type. Must be pcap, or dag for Endace DAG if YAF was built
# with libdag.
YAF_CAP_TYPE=pcap

# Live capture interface name.
YAF_CAP_IF=eth0

##### Export Options ###########################################################

# IPFIX transport protocol to use for export. Must be one of tcp or udp, or
# sctp if fixbuf was built with SCTP support.
YAF_IPFIX_PROTO=tcp

# Hostname or IP address of IPFIX collector to export flows to.
YAF_IPFIX_HOST=localhost

# If present, connect to the IPFIX collector on the specified port.
# Defaults to port 4739, the IANA-assigned port for IPFIX
YAF_IPFIX_PORT=18000

##### Logging and State Options ################################################

# Path to state location directory; contains the log and pidfiles unless
# modified by the following configuration parameters.
# Defaults to ${prefix}/var.
#YAF_STATEDIR=

# Path to PID file for YAF. Defaults to YAF_STATEDIR/yaf.pid
#YAF_PIDFILE=

# File or syslog facility name for YAF logging. If file, must be an absolute
# path to a logfile. Defaults to YAF_STATEDIR/yaf.log
#YAF_LOG=

# File or syslog facility name for YAF airdaemon logging. If file, must be an
# absolute path to a logfile. Defaults to YAF_STATEDIR/airdaemon-yaf.log
#YAF_DAEMON_LOG=

##### Miscellaneous Options ####################################################

# If present, become the specified user after starting YAF
#YAF_USER=

# Additional flags to pass to the YAF process. Use --silk --ip4-only for
# export to SiLK rwflowpack or SiLK flowcap.
YAF_EXTRAFLAGS="--silk"

Made sure there was a sensor definition in the /netflow/silk.conf.


sensor 0 s0    "v5 netflow from router"
sensor 1 s1    "YAF converted from tap"

class all
    sensors s0 s1
end class

The /etc/silk/sensor.conf configuration file also need to be updated with the new sensor definition. In this case s1 is our tap.

probe s0 netflow-v5
    listen-on-port 9990
    protocol udp
    accept-from-host 172.16.0.1
end probe

sensor s0
    netflow-v5-probes s0
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor

probe s1 ipfix
    listen-on-port 18000
    protocol tcp
    accept-from-host 127.0.0.1
end probe

sensor s1
    ipfix-probes s1
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor

Lastly, start YAF assuming that you have rwflowpack running from the SiLK package per the previous post.

$ sudo yaf --silk --ipfix=tcp --live=pcap --in=eth0 --out=127.0.0.1 --ipfix-port=18000 &


You should now be capturing data and converting into a format that SiLK can process via YAF.

Posted in security | Tagged , , , | Leave a comment

Configure SiLK on Linux for NetFlow collection from a Cisco router

This guide walks through configuring SiLK from a source install on a Debian 6 host in order to collect NetFlow data from a Cisco router. The guides here and here written by CERT NetSA are quite good but lack some detail specific to the Debian distribution which required a bit of mucking about to get everything functioning correctly. This assumes that you have a Cisco router to send NetFlow data to a host on your network, in this case, a Debian host.

Installation:

First install a prerequisite.

$ sudo apt-get install libpcap-dev

Next untar and change into the SiLK directory. For Debian I found that using the /usr directory worked well. By default the configure script uses /usr/local in which it places the binaries, libraries, etc outside of Debian’s default paths.

$ ./configure --prefix=/usr --sysconfdir=/etc/silk --enable-data-rootdir=/netflow \
--enable-ipv6 --enable-output-compression

Your output should be something along the following:

    * Configured package:           SiLK 2.4.5
    * Host type:                    x86_64-unknown-linux-gnu
    * Source files ($top_srcdir):   .
    * Install directory:            /usr
    * Root of packed data tree:     /netflow
    * Packing logic:                via run-time plugin
    * Timezone support:             UTC
    * Default compression method:   SK_COMPMETHOD_ZLIB
    * IPv6 support:                 YES
    * IPFIX collection support:     YES (-pthread -lfixbuf -lgthread-2.0 -lrt -lglib-2.0)
    * Transport encryption support: NO (gnutls not found)
    * IPA support:                  NO
    * LIBPCAP support:              YES (-lpcap)
    * ADNS support:                 NO
    * Python support:               NO
    * Build analysis tools:         YES
    * Build packing tools:          YES
    * Compiler (CC):                gcc
    * Compiler flags (CFLAGS):      -I$(srcdir) -I$(top_builddir)/src/include -I$(top_srcdir)/src/include -DNDEBUG -O3 -fno-strict-aliasing -Wall -W -Wmissing-prototypes -Wformat=2 -Wdeclaration-after-statement -Wpointer-arith
    * Linker flags (LDFLAGS):
    * Libraries (LIBS):             -lz -ldl -lm

Lastly:

$ make
$ sudo make install

Configuration:

Example files are available in the tarball that you extracted. Modified versions or notes for Debian and similar architectures available below.

/netflow/silk.conf in your data directory, the default is /data but I used /netflow as you can see in the configure toggle above. The changes I made were to reduce the number of sensors.


# The syntactic format of this file
#    version 2 supports sensor descriptions, but otherwise identical to 1
version 2

sensor 0 s0    "Description for sensor S0"
sensor 1 s1

class all
    sensors s0 s1
end class

# Editing above this line is sufficient for sensor definition.

/etc/silk/sensor.conf is the definition for the data coming in from your Cisco router:


probe s0 netflow-v5
    listen-on-port 9990
    protocol udp
    accept-from-host 172.16.0.1
end probe

sensor s0
    netflow-v5-probes s0
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor

/etc/silk/rwflowpack.conf:


### Packer configuration file  -*- sh -*-
##
## The canonical pathname for this file is /usr/local/etc/rwflowpack.conf
##
## RCSIDENT("$SiLK: rwflowpack.conf.in 16306 2010-09-15 18:14:41Z mthomas $")
##
## This is a /bin/sh file that gets loaded by the init.d/rwflowpack
## wrapper script, and this file must follow /bin/sh syntax rules.

# Set to non-empty value to enable rwflowpack
ENABLED=yes

# These are convenience variables for setting other values in this
# configuration file; their use is not required.
statedirectory=/var/lib/rwflowpack

# If CREATE_DIRECTORIES is set to "yes", the directories named in this
# file will be created automatically if they do not already exist
CREATE_DIRECTORIES=yes

# Full path of the directory containing the "rwflowpack" program
BIN_DIR=/usr/sbin

# The full path to the sensor configuration file.  Used by
# --sensor-configuration.  YOU MUST PROVIDE THIS (the value is ignored
# when INPUT_MODE is "respool").
SENSOR_CONFIG=/etc/silk/sensor.conf

# The full path to the root of the tree under which the packed SiLK
# Flow files will be written.  Used by --root-directory.
DATA_ROOTDIR=/netflow

# The full path to the site configuration file.  Used by
# --site-config-file.  If not set, defaults to silk.conf in the
# ${DATA_ROOTDIR}.
SITE_CONFIG=/netflow/silk.conf

# Specify the path to the packing-logic plug-in that rwflowpack should
# load and use.  The plug-in provides functions that determine into
# which class and type each flow record will be categorized and the
# format of the files that rwflowpack will write.  When SiLK has been
# configured with hard-coded packing logic (i.e., when
# --enable-packing-logic was specified to the configure script), this
# value should be empty.  A default value for this switch may be
# specified in the ${SITE_CONFIG} site configuration file.  This value
# is ignored when INPUT_MODE is "respool".
PACKING_LOGIC=

# Data input mode.  Valid values are:
#  * "stream" mode to read from the network or from probes that have
#    poll-directories
#  * "fcfiles" to process flowcap files on the local disk
#  * "respool" to process SiLK flow files maintaining the sensor and
#    class/type values that already exist on those records.
INPUT_MODE=stream

# Directory in which to look for incoming flowcap files in "fcfiles"
# mode or for incoming SiLK files in "respool" mode
INCOMING_DIR=${statedirectory}/incoming

# Directory to move input files to after successful processing.  When
# in "stream" mode, these are the files passed to any probe with a
# poll-directory directive.  When in "fcfiles" mode, these are the
# flowcap files.  When in "respool" mode, these are the SiLK Flow
# files.  If not set, the input files are not archived but are deleted
# instead.
ARCHIVE_DIR=${statedirectory}/archive

# When using the ARCHIVE_DIR, normally files are stored in
# subdirectories of the ARCHIVE_DIR.  If this variable's value is 1,
# files are stored in ARCHIVE_DIR itself, not in subdirectories of it.
FLAT_ARCHIVE=0

# Directory to move an input file into if there is a problem opening
# the file.  If this value is not set, rwflowpack will exit when it
# encounters a problem file.  When in "fcfiles" mode, these are the
# flowcap files.  When in "stream" mode, these are the files passed to
# any probe with a poll-directory directive.
ERROR_DIR=  #${statedirectory}/error

# Data output mode.  Valid values are "local" and "remote".  "local"
# writes the hourly data files to the local disk.  "remote" creates
# small files (called incremental files) that must be processed by
# rwflowappend to create the hourly files.
OUTPUT_MODE=local

# Directory in which the incremental files are written when the
# OUTPUT_MODE is "remote".  Typically there is an rwsender deamon that
# polls this directory for new incremental files.
SENDER_DIR=${statedirectory}/sender-incoming

# Temporary directory in which to build incremental files prior to
# handing them to rwsender.  Used only when OUTPUT_MODE is "remote".
INCREMENTAL_DIR=${statedirectory}/incremental

# The type of compression to use for packed files.  Left empty, the
# value chosen at compilation time will be used.  Valid values are
# "best" and "none".  Other values are system-specific (the available
# values are listed in the description of the --compression-method
# switch in the output of rwflowpack --help).
COMPRESSION_TYPE=best

# Interval between attempts to check the INCOMING_DIR or
# poll-directory probe entries for new files, in seconds.  This may be
# left blank, and will default to 15.
POLLING_INTERVAL=

# Interval between periodic flushes of open SiLK Flow files to disk,
# in seconds.  This may be left blank, and will default to 120.
FLUSH_TIMEOUT=

# Maximum number of SiLK Flow files to have open for writing
# simultaneously.  This may be left blank, and will default to 64
FILE_CACHE_SIZE=

# Whether rwflowpack should use advisory write locks.  1=yes, 0=no.
# Set to zero if messages like "Cannot get a write lock on file"
# appear in rwflowpack's log file.
FILE_LOCKING=1

# Whether rwflowpack should include the input and output SNMP
# interfaces and the next-hop-ip in the output files.  1=yes, 0=no.
# The default is no, and these values are not stored to save disk
# space.  (The input and output fields contain VLAN tags when the
# sensor.conf file contains the attribute "interface-values vlan".)
PACK_INTERFACES=0

###

# The type of logging to use.  Valid values are "legacy" and "syslog".
LOG_TYPE=syslog

# The lowest level of logging to actually log.  Valid values are:
# emerg, alert, crit, err, warning, notice, info, debug
LOG_LEVEL=info

# The full path of the directory where the log files will be written
# when LOG_TYPE is "legacy".
LOG_DIR=/var/log

# The full path of the directory where the PID file will be written
PID_DIR=${LOG_DIR}

# The user this program runs as; root permission is required only when
# rwflowpack listens on a privileged port.
USER=root
#USER=`whoami`  # run as user invoking the script

# Extra options to pass to rwflowpack
EXTRA_OPTIONS=

/etc/init.d/rwflowback directory, the only change was to line 38 in order to change to the configuration specified in the configure statement.

SCRIPT_CONFIG_LOCATION="/etc/silk" 

With everything installed in their respective locations it is time to move on to setting up the Cisco device.

Router(config)# ip cef
Router(config)# ip flow-export source Loopback0
Router(config)# ip flow-export version 5
Router(config)# ip flow-export destination x.x.x.x 9990
Router(config)# interface  f1/0
Router(config-if)# ip flow ingress
Router(config-if)# ip flow egress 

I hope this helps. If you have any comments or questions, leave a comment below.

Posted in security | Tagged , , , | 2 Comments

Setting Google Storage object ACL for authenticated downloads

Google’s gsutil is a great tool for pushing, retrieving and setting permissions on objects uploaded to Google Storage. I was reviewing the documentation on the Sharing and Collaboration page, specifically the Authenticated Browser Download section and realized there were a couple of small mistakes, err typos. I wanted to give someone read privileges to an object via their email address. The correct format is posted in this Paste.

The EmailAddress tag needs to be closed and the Permission tags need to be moved outside of the Scope tag. With all of this said I later came across Access Control page which is documented correctly. Go figure.

Posted in internet | Tagged , , | Leave a comment

Running NIX Retina and Nessus vulnerability scans with least privileges

When you are running those vulnerability scans of Linux and UNIX hosts I hope that you are following best practices for keeping a host secure during the process. Both Retina and Nessus rely upon SSH in order to connect to a remote host and run a number of commands to compare the query’s to their respective databases of known issues, vulns and configuration faults. Removing the directive in the sshd_config file to enable root login is definitely not best practice, and is borderline “hacking naked”. Lucky for us both Tenable and eEye have documented the methods for running scans with su or sudo (the latter preferred).

As the Retina publication states, you may want to limit the commands that the sudo user may run. To do this you can look at the Retina logs on your Windows client; or after a successful scan with take a peek at the NIX user history in order to determine what commands were run. This could also be useful for scripting up a self-scan for a host that may lack a SSH service. Another method may beside reviewing the scanners logs might be to check the history of the secure or messages log to determine what commands were run and successfully returned a response.

After determining what commands the host needs to correctly run a credentialed scan you can limit the users’ sudo privileges in the /etc/sudoers file. This allows users bob and alice to execut cmd0, cmd1 and cmdn, though disables su and the ability to change to a shell that may not log correctly.

Cmnd_Alias    SHELLS = /usr/bin/sh,  /usr/bin/csh, \
/usr/bin/ksh, /usr/local/bin/tcsh, \
/usr/bin/rsh, /usr/local/bin/zsh
Cmnd_Alias    RETINA = /usr/sbin/cmd0, /usr/sbin/cmd1, /usr/sbin/cmdn
User_Alias    RETINA_USERS = alice, bob
RETINA_USERS  ALL = !/usr/bin/su, !SHELLS, RETINA

As usual, YMMV so let me know if this is helpful or misinforming.

Posted in security | Tagged , | Leave a comment

Use Facebook CDN to host website photo gallerys

I was thinking about how to retrieve photos from Facebook photo gallery’s and came across a number of solutions. Most of the solutions were for blog or CMS and furthermore required caching your credentials in a database along with a few other hoops in order to access your albums and display them on a third party site. I thought this was a bit odd as if you want to share photos on your blog or site you should be able to just make the album public and use Facebooks API to connect since they are going to be public at that point. After poking around this ended up being much easier than expected and it works with Facebook Fan Pages which is where I think this would be most useful.

  1. You need to create a Facebook application account which will provide you with your appId and secret.
  2. Next you need to get the PHP SDK from GitHub. All you need is the facebook.php page but feel free to grab the ZIP and explore. There is an example to experiment with.
  3. Lastly you can use the code provided on Google Code as a basic start to implementing a photo gallery on your site.

The code displays thumbnails, source images along with name’s (caption’s) below each image that have them and finally the source which you can use to derive other goodies that you might want to use in you gallery. Some examples are different size thumbnails, id, comments, etc.

*Note that the script does not parse double quotes in photo captions well at this point.

If you notice any issues, room for improvement or features feel free to leave a comment or post an issue over at the Google Code page.

Posted in coding | Tagged , , , | 9 Comments

New blog header image

I would like to take a moment and thank the guys over at Xen for allowing me to use their “light bike” logo for my blog’s header image. Please take a moment to checkout their site for your virtualization needs.

Posted in web design | Tagged , | Leave a comment