Increment IP packet timestamp

I recently had a need to specify and increment the IP timestamp values of packets in a PCAP. In this example, the starting second value is specified and we increment the microsecond value. This requires the use of Scapy. If you have any questions or recommendations for improvement, please leave a comment below.

#! /usr/bin/python

# Script to parse a PCAP and modify timestamps
# Requires Scapy
# 0.1 - 03012012
# Stephen Reese

from scapy.all import *
import sys

# Get input and output files from command line
if len(sys.argv) < 2:
        print "Usage: rewritetimestamp.py inputpcapfile"
        sys.exit(1)

# Assign variable names for input and output files
infile = sys.argv[1]

def process_packets():
    pkts = rdpcap(infile)
    cooked=[]
    timestamp = 1234567890.000000
    for p in pkts:
        p.time = timestamp
        timestamp += 0.000001
        pmod=p
        p.time
        cooked.append(pmod)

    wrpcap("out.pcap", cooked)

process_packets()
Posted in network | Tagged , | Leave a comment

Running SnortAD

I recently fired up a Snort Anomaly Detection instance provided by the SnortAD project and wanted to share my experience for those who might be interested in trying it on your network. SnortAD is the third generation anomaly detection preprocessor for Snort and is a little different than its predecessors but don’t take my word for it, check out their site.

First you need to create a log file based on your network, the log file will contain a profile of your network traffics characteristics. Although a log file has been provided with the SnortAD virtual machine (VM) that contains null entries it will not do you much good aside from alerting on everything. In order to characterize your network, you will need to create a log file with enough data to be statistically relevant. For the impatient, you can create a day or two worth of data and duplicate the data. Duplicating the data will have adverse effects though. Think about a university in which a majority of classes occur on Monday and Wednesday. If you only create a profile for Monday and duplicate it for the rest of the week, you can quickly understand how your results might be skewed.

To get going, use the snort.conf included on SnortAD VM and begin creating a log file but remember to backup or remove the original log file in the event you need it for reference. Also, always backup your configuration files before making changes for good measure.

Configure the snort.conf file to log. Something like the following should work fine:

preprocessor AnomalyDetection: LogPath /var/log/snort log time 60

Next, run Snort to generate log data. As mentioned, you should create enough data to make it statistically relevant. The evaluator script expects three weeks. As an alternate, you might be able to use tcpreplay to replay existing PCAP if you have enough data.

$ sudo /usr/local/bin/snort -c /etc/snort.conf -i eth0

You should start seeing messages to stdout that look like the following:

Loged transfer between 06-01-13 15:33:52 - 06-01-13 15:34:52
Loged transfer between 06-01-13 15:34:52 - 06-01-13 15:35:52

Now you should have a log with a number of entries saved in /var/log/snort. The profile generation script is next run. In this example we specify a week rather than opt for the three week default but again, YMMV and you made need to adjust these values. Also, make sure you check the help of the profile generator as there are other algorithms, five to be specific: Moving average (default), Naive method, Autoregressive time series model, Holt-Winters model, and HW model with Brutlag's confidence band.

/usr/local/src/profilegenerator/ad_profilegenerator.r -m AVG --avg 'WEEKLY,1' -l Log_Data.txt -p profile.txt -e evaluator.txt -P pattern.txt

The previous command creates the profile.txt file which is a CSV file, i.e. you could respectively name it profile.csv. The CSV file will be used by your updated snort.conf file. In order to enable anomaly detection, we need to download or create a few Snort configuration files:

$ ls -l /etc/snort
total 4200
-rw-r--r--. 1 root root    3621 Jan  5 15:35 classification.config
-rw-r--r--. 1 root root   29596 Jan  5 15:35 gen-msg.map
-rw-r--r--. 1 root root    7897 Jan  5 15:35 preprocessor.rules
-rw-r--r--. 1 root root 1484013 Jan  5 15:35 profile.csv
-rw-r--r--. 1 root root     746 Jan  5 15:35 reference.config
-rw-r--r--. 1 root root 2696705 Jan  5 15:35 sid-msg.map
-rw-r--r--. 1 root root     255 Jan  5 15:35 snort.conf
-rw-r--r--. 1 root root    2556 Jan  5 15:35 threshold.conf
-rw-r--r--. 1 root root   53841 Jan  5 15:35 unicode.map

I found it simplest to pull down the latest Snort signature as they have the additional required files that are not included in the provide SnortAD build. You can pull down the needed preprocessor.rules from one of the authors bitbucket. The snort.conf was populated with the following contents:

include classification.config
include reference.config
include preprocessor.rules
preprocessor AnomalyDetection: ProfilePath /etc/snort/profile.csv LogPath /var/log/snort alert log time 60

If you have everything in the /etc/snort directory, you should be able to run Snort and see alerts when anomalies are detected:

$ sudo /usr/local/bin/snort -c /etc/snort/snort.conf -i eth0

Here are some sample alerts from some early testing. It will probably take some tuning to begin seeing useful alerts:

[**] [1000100:1000101:1] AD_UNUSUALLY_HIGH_TCP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000107:1] AD_HIGH_LAN_TCP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000108:1] AD_UNUSUALLY_LOW_UDP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000114:1] AD_LOW_LAN_UDP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000134:1] AD_LOW_ARP_REQUEST_NUMBER [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000138:1] AD_LOW_NOT_TCP_IP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000140:1] AD_LOW_OVERALL_PACKET_NUMBER [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

If you have any questions, leave a comment and/or check out the authors Readme.txt for some additional usage insight.

Posted in network, security | Tagged | 9 Comments

Mailing Lists

Here are a few technology and information security related mailing-lists that I subscribe to in no particular order. Leave a comment if you think I missed one.

asterisk-users.lists.digium.com
beginners.perl.org
snort-users.lists.sourceforge.net
nessus.list.nessus.org
pauldotcom.mail.pauldotcom.com
samurai-devel.lists.sourceforge.net
ptk-forensics-mail.lists.sourceforge.net
gcfa.lists.sans.org
framework-hackers.spool.metasploit.com
framework.spool.metasploit.com
secureideas-base-user.lists.sourceforge.net
python-list.python.org
nexpose-users.lists.rapid7.com
winquisitor-beta.googlegroups.com
securitybsides.googlegroups.com
datarecoverycertification.googlegroups.com
full-disclosure.lists.grok.org.uk
scap_interest.ietf.org
cipp.news.infracritical.com
scadasec.news.infracritical.com
debian-security-announce.lists.debian.org
bugtraq.list-id.securityfocus.com
ietf.ietf.org
dfir.lists.sans.org
webappsec.list-id.securityfocus.com
sleuthkit-users.lists.sourceforge.net
vol-users.volatilesystems.com
emerging-sigs.emergingthreats.net

Posted in network, security | Tagged | Leave a comment

Podcasts

Here’s a list of information technology and security podcasts. Some are technical, others are higher level so YMMV. Essentially a source of information to keep me up to date on what’s going on in the information technology realm. If you think of something I have missed, leave a commment. *Note some of these may be explicit so please use discretion and they are in no particular order.

Wired Features
ArcSight Podcasts
The CyberJungle
Tech Talk
The Digita
l Underground Podcast

Forensic 4cast » Forensic 4cast
Imperva Data Security Podcast
The Linux Action Show! MP3
AudioParasitics – The Official Podcast of Mc
Afee Labs

McAfee SaaS Security Buzz
Packet Pushers Podcast
The Silver Bullet Security Podcast
Social-Engineer.Org PodCast
The Southern Fried Security Podcast
Internet Storm Center Threat Update
RB2
Security Now!
NPR Topics: Technology Podcast
Network Security Podcast
PaulDotCom Security Weekly
Sophos Podcasts
Tenable Network Security Podcast
Risky Business
Exotic Liability
Eurotrash Security Podcast: Security with funny accents
SecuraBit
Security Justice
The Security Catalyst
CERT’s Podcast Series: Security for Business Leaders
My Hard Drive Died – w/Scott Moulton
CyberSpeak’s Podcast
OWASP Security Podcast
Crypto-Gram Security Podcast
Cisco TAC Security Podcast Series
Off The Hook: high-bitrate MP3 feed
Security Wire Weekly
InfoSec Daily Podcast
An Information Security Place Podcast
Security Insider – Podcast Edition
Wall Street
Journal Tech News Briefing

The 404 (MP3)
Click
Security.Exe powered by The CISO Group with Alan Shimel
FLOSS Weekly
The Stack Exchange Podcast
Down the Security Rabbithole
AuditCasts with David Hoelzer
CERIAS Security Seminar Podcast

Posted in network, security | Tagged | Leave a comment

Decoding XOR payload using first few bytes as key

I recently came across the need to decode an exclusive or (XOR) payload. In my case, the key to de-obfuscating the traffic was the first three bytes of each packets payload. While it is trivial to decode each payload, it was not reasonable for a large number of packets.

For testing purposes, create a packet:

$ scapy
Welcome to Scapy (2.1.0)
>>> p = (IP(ttl=10)/TCP(sport=1024,dport=443,flags="S")/"   WHATSTHESECRET0000ABCD0000ABCD0000ABCD")
>>> wrpcap("p.pcap", p)
>>> quit()

Should see something similar to this:

04:29:31.255470 IP 127.0.0.1.1024 > 127.0.0.1.443: Flags [S], seq 0:41, win 8192, length 41
        0x0000:  4500 0051 0001 0000 0a06 b2a4 7f00 0001  E..Q............
        0x0010:  7f00 0001 0400 01bb 0000 0000 0000 0000  ................
        0x0020:  5002 2000 751d 0000 2020 2057 4841 5453  P...u......WHATS
        0x0030:  5448 4553 4543 5245 5430 3030 3041 4243  THESECRET0000ABC
        0x0040:  4430 3030 3041 4243 4430 3030 3041 4243  D0000ABCD0000ABC
        0x0050:  44                                       D

Next, the payload is XOR’d using the first three bytes of the payload for the entire payload. If you note the first tcpdump, the three bytes of the payload were left empty, here I am placing the key that will be used to XOR the rest of the payload within the first three bytes of the payload.

The payload has been obfuscated using the key ‘the’.

Next we can use the script below or here to decode all of the packets. The script is not intelligent enough to know which need to be de-obfuscated so it is best to probably filter these into a new PCAP. Secondly, the script requires Scapy to be installed.

#! /usr/bin/python

# Script to parse a PCAP and XOR data based on a byte offset
# Requires Scapy
# 0.1 - 07172012
# Default is two bytes, change at line 35
# Stephen Reese and Chris Gragsone
#
# todo: add two more args, offset length and static offset option

from scapy.all import *
import sys

# Get input and output files from command line
if len(sys.argv) < 2:
        print "Usage: decodexorpayload.py [input pcap file]"
        sys.exit(1)

# Assign variable names for input and output files
infile = sys.argv[1]

def many_byte_xor(buf, key):
    buf = bytearray(buf)
    key = bytearray(key)
    key_len = len(key)
    for i, bufbyte in enumerate(buf):
        buf[i] = bufbyte ^ key[i % key_len]
    return str(buf)

def process_packets():
    pkts = rdpcap(infile)
    cooked=[]
    for p in pkts:
        # You may have to adjust the payload depth here:
        # i.e. p.payload.payload.payload
        pkt_payload = str(p.payload.payload)
        pkt_offset = str(p.payload.payload)[:3]
        if pkt_payload and pkt_offset:
              pmod=p
              # You may have to adjust the payload depth here:
              p.payload.payload=many_byte_xor(pkt_payload, pkt_offset)
              cooked.append(pmod)

    wrpcap("dump.pcap", cooked)

process_packets()

After script completion, viewing the packet does indeed show the de-obfuscated packet:

reading from file dump.pcap, link-type RAW (Raw IP)
04:24:44.415262 IP 127.0.0.1.1024 > 127.0.0.1.443: Flags [S], seq 0:41, win 8192, length 41
        0x0000:  4500 0051 0001 0000 0a06 b2a4 7f00 0001  E..Q............
        0x0010:  7f00 0001 0400 01bb 0000 0000 0000 0000  ................
        0x0020:  5002 2000 751d 0000 0000 0057 4841 5453  P...u......WHATS
        0x0030:  5448 4553 4543 5245 5430 3030 3041 4243  THESECRET0000ABC
        0x0040:  4430 3030 3041 4243 4430 3030 3041 4243  D0000ABCD0000ABC
        0x0050:  44                                       D

There are a number of features that could be added and of course the code can probably be improved upon. Have some ideas? Leave a comment below.

Posted in network, security | Tagged , | 4 Comments

World IPv6 Day

World IPv6 Day (June 8th 2012) is rapidly approaching. It is an exciting and scary reality. For my personal assets, there was a small investment on my part to get everything up to par. My internet provider Comcast is dual-stack ready which is nice because I experienced some serious latency from time to time when using a tunnel-broker (note that other factors probably contributed). You can see more information about the Comcast IPv6 trial and preparation here. First, I had to invest in a new cable-modem as my old Motorola SB1000 was not up to the task. Comcast has created a hardware compatibility list. From the list I decided to go with the Motorola SB6121 as I have had pretty good success with their modems in the past. Secondly you need a device that is capable of filtering and distributing addresses to your internal devices. I am not going into details here, but a Cisco ASA5500 or a home-brew Linux device usually will work quite nicely. The most important part to read into is that you are also filtering v6 IP traffic along with the v4 so you do not have evil-doers sneaker-netting into your network. Your network devices will not hide behind network address translation (NAT). Lastly, keep the images, firmware, or distributions patched and monitor your traffic from time to time. Kind of like a cavity, you usually do not know you have one until it is too late.

My blog has also moved to a dual-stack (Linode awesome service and support) from a tunnel-broker! This was really straightforward to implement as Linode provides some great documentation in their library. As with any setup, you need to filter unwanted traffic from entering/exiting your node(s), Iptables makes quick work of this. In this scenario, I am going with a deny-by-default posture and log everything that is dropped. This is by no means definitive but just a place to get started.

*filter
# Drop everything
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

# Allow the loopback
-A INPUT -i lo -j ACCEPT
-A INPUT -d ::1/128 ! -i lo -j REJECT --reject-with icmp6-port-unreachable

# All returning connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Let the web server respond
-A INPUT -p tcp --sport 1024:65535 --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --sport 1024:65535 --dport 443 -m state --state NEW -j ACCEPT

# All SSH session but limit attempt, also see fail2ban
-A INPUT -p tcp --sport 1024:65535 --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -m limit --limit 1/min --limit-burst 3 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -j DROP

# Allow ICMP but need to restrict based on type
-A INPUT -p ipv6-icmp -j ACCEPT

# Drop everything else and log it
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "ipv6 input denied: " --log-level 7

# Respective outbound rules
-A OUTPUT -p ipv6-icmp -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "ipv6 output denied: " --log-level 7
COMMIT
Posted in network | Tagged | 3 Comments

How-to setup an Upside-Down-Ternet

In an effort to replicate the amusing idea of a transparent proxy that manipulates traffic in a fun way found here and made even better with some great scripts that you can pull down from here. A Debian box was stood up with two network cards; one connects to the internal LAN and the other connected to an access-point which your guests connect to. I chose to post this how-to as the initial idea did not provide a complete reference on how to setup the needed components.

First, we are using an access-point we take care of the DHCP and DNS duties but the access-point or another host could perform these duties if they support said services. I choose to install the following DHCP service:

$ sudo apt-get install isc-dhcp-server

The following configuration provides the scope for the clients. We only define a scope for the client side which will use a 192.168.0.0 network for the example purposes.

$ grep ^[^#] /etc/dhcp/dhcpd.conf
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.100 192.168.0.200;
  option domain-name-servers 192.168.0.1;
  option domain-name "kittenwar.com";
  option routers 192.168.0.1;
  option broadcast-address 192.168.0.255;
  default-lease-time 600;
  max-lease-time 7200;
}

Secondly, the guests are going to need some resolution, rather than have their queries pass through the network, lets setup a simple resolver for them using BIND:

$ sudo apt-get install bind9

Setup some forwarders and the interface we want to listen on, for example sake, the same subnet servicing the clients:

$ grep ^[^#] /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";
        version "tbd";
        forwarders { 8.8.8.8; 8.8.4.4; };
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
        listen-on { 192.168.0.1; 127.0.0.1; };
};

Some of the fun scripts require a HTTP service to serve up flipped images and all sorts of other goodness so Apache and ImageMagick are needed:

$ sudo apt-get install apache2
$sudo apt-get -y install imagemagick

The last service is Squid caching proxy. Install version 3 was installed from the repositories:

$ sudo apt-get install squid3

Edit the Squid configuration, this is a default configuration but the acl for the clients has been enabled along with interception mode (read transparent) and finally call the script via url_rewrite_program:

$ grep ^[^#] /etc/squid3/squid.conf
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 3128 intercept
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
url_rewrite_program /home/us3r/squidScripts/flipImages.pl
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

Execute the following to create some protection from the subnet being advertised and furthermore forces all of the web request to use the Squid cache. The rule-set is by no means perfect or definitive, feel free to tailor to your needs and provide feedback.

$ grep ^[^#] fw-script
PATH=/sbin
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth2 -p tcp --dport 3128 -j ACCEPT
iptables -A INPUT -i eth2 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth2 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth2 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth2 -p udp --dport 67 -j ACCEPT
iptables -A OUTPUT -o eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8000 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 68 -j ACCEPT
iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --dport 67 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --dport 443 -j ACCEPT
iptables -A OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -j LOG --log-prefix "iptables denied: " --log-level 7
iptables -I OUTPUT -j LOG --log-prefix "iptables denied: " --log-level 7
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.1:3128
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.0.0/24 -d 192.168.0.1 -j SNAT --to 192.168.0.1
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j REDIRECT --to-port 3128

You can down pull down a script from the Google code repository mentioned above which you have referenced in the Squid configuration. There are variables in the top of the scripts that you downloaded earlier. The variables need to be updated to reflect your system. A few Perl module prerequisites are also listed in the top of said scripts, access CPAN and install them:

$ sudo perl -MCPAN -e shell

After the required Perl modules are installed, you should be able to place a client on the guest network and they will retrieve sites, although it will not take long for to notice that in this case all of the images are inverted. Do not forget to checkout the other scripts.

ternet-pinterest-scaled

Lots of fun! If I missed something or you have some feedback, use the comment form below.

Posted in internet | Tagged , , | Leave a comment

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