I first posted about this issue back in Dec 18th of 2011, Handcent SMS one of the most popular SMS applications on the android market with over 10,000,000 downloads was doing some things that raised a few privacy questions.  As stated in my last post Handcent was  logging all your sent messages even after you deleted them from within the application.

I tried contacting them via email and twitter but the refused to comment on my findings. However 5 days later to my amazement I noticed the released a new version “3.9.9.9″. Take a look at the change log:

• #3.9.9.9

• Improve Galaxy Nexus (Android 4.0) support

• New Skin for XMas 2012,Cool.

• Add auto delete old message option

• Add Mms signature option

• Merry XMas to all users

Now after installing the new version I noticed I was still able to see my sent messages after I deleted them so I am not so certain the issue was addressed. I would however like to know if “Add auto delete old message option

“ means the will purge the messages from the database on a random schedule at some point. Again since Handcent refuse to comment on this issue we can only assume for now.

Don’t think that all hope is lost or that you are stuck with the stock messaging application, thanks to brilliant mind of Moxie Marlinspike and others over at Whisper System, “TextSecure Beta” was birthed on Dec 21, 2011.

TextSecure is a security enhanced text messaging application that serves as a full replacement for the default text messaging application. Messages to other TextSecure users are encrypted over the air, and all text messages are stored in an encrypted database on the device. If your phone is lost or stolen, your messages will be safe, and communication with other TextSecure users can’t be monitored over the air.

In short if you are ready to give up on Handcent this might be a good alternative, I know so far I feel much more secure using this application. I even tried browsing the db and I can confirm that the messages are indeed encrypted.

Objective:  I goal of this document is meant to outline a few steps that will allow you to troubleshoot the cause behind why users were unable to access the internet while behind a Fortigate 100A device.

Problem: I received a ticket today stating that users in one our computer labs were unable to access the internet.

After arriving onsite I discounted the device and plugged directly into the ISP link and confirmed that they were no issues with the ISP connection. Now is time to open a ticket with support and start the series of troubleshooting to figure out the root cause of the issue.

Step one: Information gathering

After opening the ticket I was told that the issue could have possibly been caused by a bad firmware image, or a corrupted configuration. I needed to log into the device to find out more information and the only way to do so was via the console port.

Connecting to the Fortigate 100A console port:

• Start your favorite terminal emulator program use the following settings:
• Baud rate: 9600
• Data bits: 8
• Parity: None
• Stop bit: 1
• Flow control: None
• Next, reboot the device and watch the screen for any error message.

After rebooting the first time I got the following message, “You must format the boot device”,  I then rebooted a second time and got the following message “The config file may contain errors, Please see details by the command ‘diagnose debug config-error-log read”.  This was somewhat good news because I would have had to RMA the device if the system RAM was corrupted.

At this point I know I had the following options:

• Backup the current configs
• Reset the device to it’s default state
• Reload a new configs

Backing up the device to USB via the console port:

• Plug a usb device into one of the ports on the back of the device
• Login to the device, if you are unable to use your admin login you can login with the maintainer account, this account is only valid for 30 sec after the device has been rebooted; so copy the username and password to a text file then cut/paste to the console. Username: maintainer Password: bcpb<input device serial number using uppercase letters>

• Issue the following command: execute backup configs usb filename<use any name here>
  FG100 # execute backup full-config usb fg100a-10-15-11
  Please wait…
  Copy onfigs fg100a-10-15-11 to USB disk …
  Copy onfigs file to USB disk OK.
  Setting timestamp

Before reloading a new configs its best to run a few diagnostic commands to try and understand what happened:

FG100 #  diag sys top –> Look at CPU load and any processor that running hot

FG100 # diag debug crashlog –> Look for clues as to what service crashed

          Ex Output:

89: 2011-11-14 16:06:42 <04434> application cmdbsvr

 290: 2011-11-14 16:06:42 <04434> *** signal 7 (Bus error) received ***

 291: 2011-11-14 16:06:42 <04434> Register dump:

298: 2011-11-14 16:06:42 <04434> Backtrace:

 299: 2011-11-14 16:06:42 <04434> [0x0893277b] => /bin/cmdbsvr 

 300: 2011-11-14 16:06:42 <04434> [0x08932a96] => /bin/cmdbsvr 

 301: 2011-11-14 16:06:42 <04434> [0x08910473] => /bin/cmdbsvr 

Reload new configs via console port:

• Rename your most recent backup configs file to fgt_system.conf, then place file on the root of your USB drive.
• Plug the USB into one of USB ports on the back of the unit and reboot the unit and you should see a similar output:

Reading boot image 1370111 bytes.
Initializing firewall…
System is started.
Get image from USB disk …Can not get image from USB disk.
Get config file from USB disk OK.
File check OK.

The system is going down NOW !!

 If you are not certain and you leave the drive in after the system reboots you will see the following message indication that the configs file on the disk is the same as the file on the system.

 Get config file from USB disk OK.
Checksum check synced! Don’t need restore config.

 Additional Troubleshooting:

After I restored the config file I was still unable to connect out to the internet, so I issued the following command to verify my IP address setting:

FG100A # get system interface  

After discovering that the IP address for my external interface WAN1 had a different subnet than the one I wrote down previously when I connected directly to my ISP modem with my PC. I decided to change the interface type to DHCP.

Configuring external interface for DHCP:

FG100A #  configs system interface –> To enter into Interface config mode

FG100A (interface) # edit wan1 –> Choose your external interface in our case it was wan1

FG100A (wan1) # unset ip –>  Removing current static IP entry

FG100A (wan1) # set mode dhcp –> To change mode to DHCP from static

FG100A (wan1) # show –> To confirm that the change was made

config system interface
edit “wan1″
set vdom “root”
set mode dhcp
set allowaccess https ssh fgfm
set type physical
next
end

 FG100A (wan1) # end

 I was now able to access the internet!!

Discovering what happened:

Wrap-up:

Given that the logs were lost due the fact the FortiGate was reset and the unit is storing it’s logs in RAM, I can’t diagnose the exact cause. But we did see in the Crashlog “diag debug crashlog read”, which is written to flash that the cmdbsvr was crashing. We have identified a issue with cmdbsvr on the version of fortios on your fortigate.

Bug #’s : 117281, 144277
Summary : cmdbsvr crash in conserve mode may cause configuration loss

I updated the device to MR3 patch 2, since this version addressed the issue.
Reference Documentation:

http://emea.fortinet.net/fortinet/bht/index.php

http://bit.ly/uRSdYJ

http://docs.fortinet.com/fscan/fortiscan_cli_40.pdf

I needed a way to effectively troubleshoot a given traffic issue on our FortiGate 100A device and the out of the box configuration didn’t have this configured. This can be accomplish using the web GUI or via an SSH session, and since I already have SSH configure I went with this option for most of the configuration.

Step 1: Enable Logging

SSH to the device with your favorite client and issue the following commands:

FG100A # show firewall policy (this command will display the details for all policies)

edit 1
set srcintf “internal”
set dstintf “wan1″
set srcaddr “all”
set dstaddr “all”
set action accept
set schedule “always”
set service “ANY”
set logtraffic disable
set nat enable

next
end

Once you know which policy you would like to troubleshoot it’s now time to enable logging

FG100A # edit 1 (to edit policy id 1)

FG100A (1) # set logtraffic enable (to enable logging for this policy)

Once you are finish you can always review your changes on the GUI if you would to do so click on Firewall tab –> Policy –> select the policy in question and click edit on the top –> Then click the check box for “Log Violation Traffic”

Next, click on the “Log&Report” tab –>Log Setting –> and check off “Local Logging & Archiving”, “Memory” –> Minimum log level “Information” –> check off “Enable IPS Packet Archive”

Apply settings!

Step 2:  Diagnose Sniffer Packet

Launch another SSH session and issue the follow command just makes sure you put the filter expressions in quotes:

diag sniffer packet <interface> <’filter’> <verbose> <count>

Simple test do a continuous ping from your workstation to an IP on the internet and then issue the command below and keep the windows open:

diag sniff packet any ‘host <workstation ip> and icmp’ 4

Step 2:  Enabling debug mode

Lastly in a another SSH window enable debug mode, set the source IP address and watch as a series of useful information flows across the console to help you narrow down the problem at hand.

diag debug enable
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow filter proto 1 (protocol 1 is for icmp)
diag debug flow filter addr <workstation ip>
diag debug flow trace start 400 (400 is a random number it’ the number of traces)

To disable the debug when you are finish run the following command:
diag debug disable

References:

http://docs.fortinet.com/fgt/techdocs/fortigate-admin.pdf

http://docs.fortinet.com/fgt/techdocs/fortigate-cli.pdf

In most cases port base filtering  is an all or none approach. For example if you want to block  a user from accessing a certain website, blocking that user’s access to port 80/443 outbound will stop them from accessing all websites not just that one. If you would like to get more granular then you would need some sort of  web content filtering systems.

Good news is, if you are still using iptables you are now able to filter traffic destined to sites such as Facebook, Twitter, Gmail etc. You can accomplish this by using iptables to block a given hex string that will appear in the initial packet handshake. I first saw this technique being discussed in a full-disclouser posting and I figured it was worth trying out.

The tools of choice here is Ngrep (Network Grep) and IPTables .

Step one: Capture the X.509 certificate

You will be doing this by using ngrep:

[infolookup@Test ~]# ngrep -d eth2 -q -x ‘Twitter’
interface: eth2 (10.100.0.0/255.255.255.128)
match: Twitter

You will then notice the following output in your terminal:

<snip>

T 199.59.148.11:443 -> 10.100.0.119:38414 [A]

1. 30 30 31 16 30 14 06 03    55 04 0a 14 0d 54 77 69    001.0…U….Twi
2. 74 74 65 72 2c 20 49 6e    63 2e 31 1c 30 1a 06 03    tter, Inc.1.0…
3. 55 04 0b 14 13 54 77 69    74 74 65 72 20 20 4f 70    U….Twitter  Op

</snip>

Step two: Creating your IPtable rule

You will be building your rule based on the hex string obtained above.

Prior to applying the rule I able to run the following command:

[infolookup@Test]$ curl –connect-timeout 60 https://www.twitter.com/
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>301 Moved Permanently</title>
</head><body><h1>Moved Permanently</h1>
<p>The document has moved <a href=”https://twitter.com/”>here</a>.</p>
</body></html>

IPtable rules to use:
http://pastebin.com/1HQD017A

sudo iptables -I INPUT -m string –algo bm –hex-string ‘|303031163014060355040a140d547769747465722c20496e632e311c301a060355040b141354776974|’ -j DROP

sudo iptables -I INPUT -m string –algo bm –hex-string ‘|303031163014060355040a140d547769747465722c20496e632e311c301a060355040b141354776974|’ -j LOG

The first rule will drop the connection to twitter and the second rule will log the entry. If you take a look at your /var/log/message you will see the following entry over and over:

Apr  7 00:05:11 Test kernel: [870656.036848] IN=eth2 OUT= MAC=00:50:56:b2:53:90:00:23:5e:a4:f2:bf:08:00 SRC=199.59.148.11 DST=10.100.0.119 LEN=1420 TOS=0×00 PREC=0×00 TTL=44 ID=58494 DF PROTO=TCP SPT=443 DPT=49542 WINDOW=23 RES=0×00 ACK URGP=0

Apr  7 00:05:19 Test kernel: [870664.675930] IN=eth2 OUT= MAC=00:50:56:b2:53:90:00:23:5e:a4:f2:bf:08:00 SRC=199.59.148.11 DST=10.100.0.119 LEN=1420 TOS=0×00 PREC=0×00 TTL=44 ID=58496 DF PROTO=TCP SPT=443 DPT=49542 WINDOW=23 RES=0×00 ACK URGP=0

If you try to access www.twitter.com you will get to the site, but when you try login the session will set there and just timeout.

[infolookup@Test]$ curl –connect-timeout 60 https://www.twitter.com/
curl: (35) SSL connect error

Note:

I was unable to use the following IPtable rule on a Ubuntu based system but it worked fine on my Fedora 14 test box. Also another thing to look out for is if you use too short of a hex string will will get an error the one I used was about 85 characters give or take.

Have fun filtering and post your comments about how you are currently using IPtables.

NetworkMiner is a Network Forensic Analysis Tool (NFAT) for Windows. NetworkMiner can be used as a passive network sniffer/packet capturing tool in order to detect operating systems, sessions, hostnames, open ports etc. without putting any traffic on the network. NetworkMiner can also parse PCAP files for off-line analysis and to regenerate/reassemble transmitted files and certificates from PCAP files.

Now that we have the explanation out of the way, I would like to really start by saying how excited I was when I saw an announcement on the Pauldotcom mailing list about version 1.0 being released. I have been using this tool for a while after being introduced to it on an episode of hak5 a while back, and since then its been one of my favorite applicatioin of choice for parsing PCAP files and looking for goodies.

This new release has  lots of new features to keep you busy for a while:

• Support for Per-Packet Information header (WTAP_ENCAP_PPI) as used by Kismet and sometimes Wireshark WiFi sniffing.

• Extraction of Facebook as well as Twitter messages into the message tab. Added support to extract emails sent with Microsoft Hotmail (I.e.windows Live) into Messages tab.

• Extraction of twitter passwords from when settings are changed. Facebook user account names are also extracted (but not Facebook passwords).

• Extraction of gmailchat parameter from cookies in order to identify users through their Google account logins.

• Protocol parser for Syslog. Syslog messages are displayed on the Parameter tab.

You can read the complete change-log here for more details here.

If that is not enough to make you want to try this application out, I don’t know what else is. I  fired-up  version 1.0 for a few mins  before writing this article and I was pretty impressed with my results. I was able to quickly and easily harvest all images browsed from my PC, IRC chat logs, identify key information about hosts on my network (ports, OS type, service version numbers) and much more without needing to run a noisy port scanner.

Q&A with Main developer of NetworkMiner

Question: What was the purpose behind developing NetworkMiner?

Answer: I started developing NetworkMiner back in 2006 while I was working with SCADA security for a major electric utility company in Europe. My idea was to give network admins and process control engineers a view of what hosts that are actually on the network as opposed to what their documentation said. The reason for building a passive sniffer instead of yet another port scanner was that SCADA and process control networks tend not to handle port scans very well, and I sure didn’t
wanna bring down the network of a running plant!

Q: How many core developers are involved with this project?
A: I’m the only developer of NetworkMiner.

Q: Which group of individuals do you think can benefit mostly from this application (Forensics investigators, pentesters, network admins, etc)?

A: NetworkMiner today is primarily designed for computer security incident responders and law enforcement who need to do forensic analysis of network traffic.

Q: How long has version 1.0 been in development?

A: I’ve been working on the 1.0 release of NetworkMiner since June 2010. The last three months before the release were spent on testing and validating the release. I also have a beta testing group,
consisting of talented network forensics professionals, who have provided additional validation of the release.

Q: What key features would you like highlight in this release; free as well as the paid version.

A: Some of the major improvements are:
In addition to whats listed about, the Professional version of NetworkMiner also includes a protocol identification feature, which can identify what application layer protocol that is being used in order to apply the appropriate protocol parser. This means that running an FTP or web server on a non-standard port will not be sufficient to fool NetworkMiner Professional.

You can also export the results from the various tabs in NetworkMiner Professional into a CSV file that can be opened with Excel or OpenOffice. The Professional release also includes a command line version of NetworkMiner, which comes in very handy when you need to wrap the pcap parsing functionality into a shell script or an automatized environment for traffic analysis.

Q: Are there any plans to make a Nix version of this application?

A: I have plans to look further into Mono (http://www.mono-project.com ) to build cross-platform support for NetworkMiner, but implementing new features have to this date had higher priority for me. It is, however, possible to run NetworkMiner from Linux by using Wine already today.

Q: What is the recommended deployment strategy to properly maximize NetworkMiner’s potential (GB nic, dual nic, physical vs vmware guest etc)?

A: My recommendation for achieving reliable and fast traffic capture solution is to use a physical FreeBSD machine running dumpcap for traffic capture. You can then open the pcap files from dumpcap with NetworkMiner for analysis on a Windows machine. When analyzing malware I actually recommend running NetworkMiner on a virtualized Windows machine without any network support, in order to minimize the risk of spreading the malware. NetworkMiner does not use much RAM, but can be fairly CPU and disk intensive. So make sure you have a fast processor and an HDD with fast access times and high write speed.

Q: If someone wants to learn more about this application, provide feedback or report bugs what’s the best way to go about this?

A: The best way to learn more about NetworkMiner is to follow my blog on http://www.netresec.com/?page=Blog .Feedback in the form of for example help or feature requests can be posted
to SourceForge on http://sourceforge.net/projects/networkminer/support

You can download NetworkMiner from any of the following urls,so go get your copy and start to spread the word:
http://www.netresec.com/?page=NetworkMiner
http://sourceforge.net/projects/networkminer/
http://networkminer.sourceforge.net/

I must give a special THANK You to Erik Hjelmvik, developer of NetworkMiner for taking time out of his busy week to help us understand a little bit more about this awesome project.

FWKNOP Tech Segment

In computer networking, port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specific port(s). A variant called Single Packet Authorization exists, where only a single ‘knock’ is needed, consisting of an encrypted packet.[1

Single Packet Authorization

Single Packet Authorization (a form of Port Knocking), is a technique for securely communicating authentication and authorization information across closed firewall ports, usually with the goal of opening certain ports to allow temporary access. By keeping most or all ports closed on a server hosting remotely-accessible services, it is possible to make that host invisible to the outside, thus protecting each listening service.

fwknop stands for the “FireWall KNock OPerator”, and implements an authorization scheme called Single Packet Authorization (SPA).

Steps to take:

Install fwknop Server

pre-requisite for fwknop:
# apt-get install libgdbm-dev

Download and install fwknop(client and server)
# wget -c http://www.cipherdyne.org/fwknop/download/fwknop-2.0.0rc2.tar.gz
# tar -zxvf fwknop-2.0.0rc2.tar.gz
# ./configure
# make
# make install

Side note: If you get the following error while loading  “shared libraries: libfko.so.0: cannot open shared object file: no such file or directory” then you may need to create a symbolic link in the /usr/lib directory for the library file:

# cd /usr/lib
# ln -s /usr/local/lib/libfko.so.o.o.2 libfko.so.0

Config files:

Browse to –> /usr/local/etc/fwknop), you will see two files access.conf and fwknop.conf.

Edit the  fwknop.conf file, and  uncomment and set the options  for your interface “PCAP_INTF eth0″.

Next edit your access.conf file to allow access  based on your liking (users, port, key, etc).

A simple suitable config:

SOURCE: ANY;
KEY: P@$$W0r); //must be over 8 characters
REQUIRE_USERNAME: infolookup;
OPEN_PORTS: tcp/222;
FW_ACCESS_TIMEOUT: 30;

clear out your old IP rules and some default rules to drop all incoming traffic.

IP Tables rule:

#!/bin/sh
# Script to reset your iptable rules

# Load modules for  tracking and NAT
modprobe iptable_nat

# Initialize all the chains by removing all rules
iptables –flush
iptables -t nat –flush
iptables -t mangle –flush

# Delete any user-defined chains
iptables –delete-chain
iptables -t nat –delete-chain
iptables -t mangle –delete-chain

# Set default policies
iptables –policy INPUT DROP
iptables –policy OUTPUT ACCEPT
iptables –policy FORWARD DROP

# Accept all traffic on the loopback (lo) device
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A OUTPUT -o lo -p all -j ACCEPT

# log all incoming and forward traffic on eth0 device
#iptables -A INPUT -i eth0 -p all -j DROP
iptables -A INPUT -i eth0 -j LOG –log-prefix “DROP”
iptables -A FORWARD -i eth0 -j LOG –log-prefix “DROP”

# Accept internally-requested input
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Accept internally-requested forward
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# Accept user-specified traffic
iptables -A INPUT -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -p udp –dport 53 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
echo “iptables policy enabled”

Start the server with –> # fwknopd -f -vv

Testing rules after configuration:

I tried to ssh to the Ubuntu server via my windows box which is IP 192.168.19.1 on port 22 and as you can see from the below image I was block and it was logged as expected:

Next I launched the windows client and typed in my configured information that was set-up during the config stage. Once you click “Send SPA” then try to login again via your SSH client within 30 secs and you should be able to now get in.

Additional reading:

http://www.cipherdyne.org/fwknop/

http://www.securitygeneration.com/single-packet-authorization/

http://aerokid240.blogspot.com/

http://www.cipherdyne.org/fwknop/download/ –> Windows client

I noticed an email this morning mentioned a openssl issue that affects the FreeBSD platform and I wanted to mention it again in case anyone missed it when it came out yesterday.

I just  patched my system  according to the steps in the advisory and I will report back if I experience any issues after patching.

I. Background

FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured
Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II. Problem Description

A race condition exists in the OpenSSL TLS server extension code
parsing when used in a multi-threaded application, which uses
OpenSSL’s internal caching mechanism. The race condition can lead to
a buffer overflow. [CVE-2010-3864]

A double free exists in the SSL client ECDH handling code, when
processing specially crafted public keys with invalid prime
numbers. [CVE-2010-2939]

III. Impact

For affected server applications, an attacker may be able to utilize
the buffer overflow to crash the application or potentially run
arbitrary code with the privileges of the application. [CVE-2010-3864].

It may be possible to cause a DoS or potentially execute arbitrary in
the context of the user connection to a malicious SSL server.
[CVE-2010-2939]

IV. Workaround

No workaround is available, but CVE-2010-3864 only affects FreeBSD 8.0
and later.

It should also be noted that CVE-2010-3864 affects neither the Apache
HTTP server nor Stunnel.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the
RELENG_8_1, RELENG_8_0, RELENG_7_3, or RELENG_7_1 security branch
dated after the correction date.

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to FreeBSD 7.1, 7.3,
8.0 and 8.1 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 7.x]
# fetch http://security.FreeBSD.org/patches/SA-10:10/openssl7.patch
# fetch http://security.FreeBSD.org/patches/SA-10:10/openssl7.patch.asc

[FreeBSD 8.x]
# fetch http://security.FreeBSD.org/patches/SA-10:10/openssl.patch
# fetch http://security.FreeBSD.org/patches/SA-10:10/openssl.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/secure/lib/libssl
# make obj && make depend && make && make install

NOTE: On the amd64 platform, the above procedure will not update the
lib32 (i386 compatibility) libraries. On amd64 systems where the i386
compatibility libraries are used, the operating system should instead
be recompiled as described in
<URL:http://www.FreeBSD.org/handbook/makeworld.html>

3) To update your vulnerable system via a binary patch:

Systems running 7.1-RELEASE, 7.3-RELEASE, 8.0-RELEASE or 8.1-RELEASE
on the i386 or amd64 platforms can be updated via the
freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Links:

http://www.freebsd.org/security/advisories.html

http://security.freebsd.org/advisories/FreeBSD-SA-10:10.openssl.asc

Being a father of four with my oldest already at the age where he needs to use the computer I started asking myself do I have the ideal setup? And the answer was not really. Don’t get me wrong I have a PF sense firewall and a few other protections in place however I wanted to build a solution from the ground up instead of just installing a bunch of  packages on my firewall and not really understanding whats going on in the back end.

My proposed solution is to have a system that caches and scans web traffic for viruses as well as preform some sort of content filtering  based on various detection methods (phrase matching, PICS filtering and URL filtering etc) and most importantly the solution must be **FREE** to implement. I am sure the are other solutions in place that does a better job than the one I have outlined and by all means feel free to comment or email me.

Tools I plan on using:

• FreeBSD 8.1
• ClamAV
• Squid
• Dansguardian
• Privoxy
• HAVP

FreeBSD: If you are going to choose an OS I would suggest BSD, because in my opinion its one of the most secure and well build system out there.

ClamAV: Is an open source (GPL) anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail gateways. It provides a number of utilities including a flexible and scalable multi-threaded daemon, a command line scanner and advanced tool for automatic database updates.

Squid: Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. It reduces bandwidth and improves response times by caching and reusing frequently-requested web pages.

Dansguardian: Is an award winning Open Source web content filter which currently runs on Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X, HP-UX, and Solaris. It filters the actual content of pages based on many methods including phrase matching, PICS filtering and URL filtering. It does not purely filter based on a banned list of sites like lesser totally commercial filters.

Privoxy: Is a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk. Privoxy has a flexible configuration and can be customized to suit individual needs and tastes.

HAVP (HTTP AntiVirus proxy): is a proxy with an anti-virus filter. It does not cache or filter content.

Setup Phase

The first thing you need to do before you start installing your apps is to make sure you set a static address up on your BSD box, in my case I have freeBSD 8.1:

vi /etc/rc.conf and add the following lines, my gateway was 192.168.1.1 and IP 192.168.1.5

defaultroute=”192.168.1.1″
hostname=”bsdsrvr.infolookup.com”
ifconfig_le0=”192.168.1.5 netmask 255.255.255.0″
inetd_enable=”YES”

I would also run freebsd-update fetch and  freebsd-update install since it never hurts to have an updated repo. Now this is as far as I will go with this post, in my next post I will go through the install, config and testing. Comments and suggestions are always welcome.

–Sherwyn AKA Infolookup

References

http://www.br.freebsd.org/where.html

http://www.clamav.net/lang/en/

http://www.server-side.de/

http://www.privoxy.org/

http://wiki.linuxmce.org/index.php/Installing_Dansguardian

http://www.mustnofee.com/tutorials/37-tutorials/67-setting-up-squid-on-freebsd

http://bsdmag.org/

http://www.squid-cache.org/

I needed a way to remotely access and manage an admin workstation at one of our  satellite locations with low bandwidth. We didn’t want to use the VPN function because the last time we tried this it was really slow when pulling over the user profile.

Configuring SSH Access:

You can configure this device via https, telnet, or SSH. Since I prefer SSH I will begin by showing you how to enable SSH.

• Log into your Fortigate appliance via the https://ipaddress then click on the “Dashboard” sub-menu on the left.

• Scroll down and click on “CLI Console” from there enter the following command to enable SSH access on your WAN/DMZ/Internal interface:

FG100A #config system interface
edit WAN1
set allowacess ssh https
end

Now you can fire up your favorite SSH client and connect!

Adding a virtual IP to enable port forwarding:

To forward TCP or UDP ports received by your FortiGate unit external interface to an internal server, you need to follow two steps.

=> Add a virtual IP
=>Add a firewall policy with a virtual IP

This example describes how to configure port forwarding to allow access to an internal Windows XP PC (IP 172.29.19.10) with the Dameware remote access utility on port of 5555 externally and 6129 internally.

Adding a virtual IP

First run the following command to see if any VIP are already configured on the firewall.

FG100A #  show firewall vip

Once you verify you don’t have any old rule to update you can simply add one of your own (Test-VIP) with the following command:

FG100A # config firewall vip
FG100A (vip) # edit Test-VIP
FG100A (Test-VIP) # set extip 192.168.10.10 => setting up the external IP
FG100A (Test-VIP) # set extintf wan2 => binding to an external interface
FG100A (Test-VIP) # set portforward enable => enable port forwarding
FG100A (Test-VIP) #  set mappedip 172.29.19.10 => mapping to an internal IP
FG100A (Test-VIP) # set extport 5555 => setting up external port
FG100A (Test-VIP) # set mappedport 6129 => mapping to internal destination port
FG100A (Test-VIP) # end

Now you can do a “show firewall vip “ to verify your virtual IP configuration:

Now all that’s left is to define a firewall policy that accepts DameWare traffic from the Internet on port 5555 and forwards it to the internal Windows PC.

To add a firewall policy with a virtual IP
You can do so following these steps:

1-  Set Source Interface to WAN1.
2-  Set Source Address to all.
3- Set Destination Interface to internal.
4- Set Destination Address to the name of the virtual IP.
Usually, the remainder of the options in this firewall policy does not need to be changed. For example, Service can remain ANY, because the virtual IP only forwards packets using port 5555.

FG100A # config firewall policy
FG100A # show => view all configured policy
FG100A  (policy) # edit 2 => to create new policy
FG100A (2) # set ? => notice some are require others  are optional.
FG100A (2) # set srcintf wan2 => set source interface name
FG100A (2) # set dstintf internal => set destination interface name
FG100A (2) # set srcaddr all
FG100A (2) # set dstaddr Test-VIP
FG100A (2) # set action accept
FG100A (2) # end
FG100A # show firewall policy => review changes and test

Reference

http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=12945&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=10078518&stateId=0%200%2010080217

What is Ncrack?

Taken from the author’s site…

Ncrack is a high-speed network authentication cracking tool. It was built to help companies secure their networks by proactively testing all their hosts and networking devices for poor passwords. Security professionals also rely on Ncrack when auditing their clients. Ncrack was designed using a modular approach, a command-line syntax similar to Nmap and a dynamic engine that can adapt its behavior based on network feedback. It allows for rapid, yet reliable large-scale auditing of multiple hosts.

Ncrack’s features include a very flexible interface granting the user full control of network operations, allowing for very sophisticated brute-forcing attacks, timing templates for ease of use, run-time interaction similar to Nmap’s and many more.

Ncrack was started as a “Google Summer of Code” Project in 2009. While it is already useful for some purposes, it is still unfinished, alpha quality software. It is released as a standalone tool and can be downloaded from the section below. Be sure to read the Ncrack man page to fully understand Ncrack usage.

Modules

Ncrack’s architecture is modular with each module corresponding to one particular service or protocol. Currently, Ncrack supports the protocols FTP, TELNET, SSH and HTTP(S) (basic authentication). Below we describe some key points for each of them.

FTP Module

FTP authentication is quite fast, since there is very little protocol negotiation overhead. Most FTP daemons allow 3 to 6 authentication attempts but usually impose a certain delay before replying with the results of a failed attempt. Filezilla is one of the most characteristic examples of this case, where the time delay is so great, that it is usually faster to open more connections against it, with each of them doing only 1 authentication per connection.

TELNET Module

Telnet daemons have been largely substituted by their safer ‘counterpart’ of SSH. However, there are many boxes, mainly routers or printers, that still rely on Telnet for remote access. Usually these are also easier to crack, since default passwords for them are publicly known. The drawback is that telnet is a rather slow protocol, so you shouldn’t be expecting really high rates against it.

SSH Module

SSH is one of the most prevalent protocols in today’s networks. For this reason, a special library, named opensshlib and based on code from OpenSSH, was specifically build and tailored for Ncrack’s needs. Opensshlib ships in with Ncrack, so SSH support comes out of the box. OpenSSL will have to be installed in Unix systems though. Windows OpenSSL dlls are included in Ncrack, so Windows users shouldn’t be worrying about it at all.

SSH brute-forcing holds many pitfalls and challenges, and you are well advised to read a paper that was written to explain them. The latest version of the “Hacking the OpenSSH library for Ncrack” document can be found under docs/openssh_library.txt or at http://sock-raw.org/papers/openssh_library

HTTP(S) Module

The HTTP Module currently supports basic authentication only, however additional methods will be added soon. Ncrack tries to use the “Keepalive” HTTP option, whenever possible, which leads to really high speeds, since that allows dozens of attempts to be carried out per connection. The HTTP module can also be called over SSL.

SMB Module

The SMB module currently works over raw TCP. NetBIOS isn’t supported yet. This protocol allows for high parallelization, so users could potentially increase the number of concurrent probes against it. SMB is frequently used for file-sharing among other things and is one of the most ubiquitous protocols, being present in both Unix and Windows environments.

RDP Module

RDP (Remote Desktop Protocol) is a proprietary protocol developed by Microsoft for the purpose of providing remote terminal services by transferring graphics display information from the remote computer to the user and transporting input commands from the user to the remote computer. Fortunately, Microsoft recently decided to open the protocol’s internal workings to the public and has provided official documentation, which can be found at http://msdn.microsoft.com/en-us/library/cc240445%28v=PROT.10%29.aspx

RDP is one of the most complex protocols, requiring the exchange of many packets, even for just the authentication phase. For this reason, cracking it takes a lot of time and this is probably the slowest module. The connection phase is briefly described at http://msdn.microsoft.com/en-us/library/cc240452%28v=PROT.10%29.aspx where you can also see a diagram of the various packets involved. Care must be taken against RDP servers in Windows XP versions, since they can’t handle multiple connections at the same time. It is advised to use a very slow timing template or even better limit the maximum parallel connections using timing options such as CL (Connection Limit) or cd (connection delay) against Windows XP (and relevant) RDP servers. Windows Vista and above don’t suffer from the same limitation.

POP3(S) Module

POP3 support is still experimental and hasn’t been thoroughly tested. You can expect it to work against common mail servers, nevertheless.

Installation and Basic usage:

Once you have download the latest version from the Ncrack website, the installation process is as follows:

tar -xzf ncrack-0.3ALPHA.tar.gz
cd ncrack-0.3ALPHA
./configure
make
su root
make install

Or download the development svn:

svn co –username guest –password “” svn://svn.insecure.org/ncrack

Before you attempt to start  using this tool its recommended that you first read the Manual, either online or issue “man ncrack”, from your console.

Quick Examples:

I first fired up nmap and ran it against a Lexmark network printer.

infolookup@TestSrvr:~# nmap -A 172.29.19.85

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-09-22 22:26 EDT
Nmap scan report for rnp92a8d6.localhost (172.29.19.85)
Host is up (0.00020s latency).
Not shown: 992 closed ports
PORT     STATE SERVICE    VERSION
21/tcp   open  ftp        Lanier LP125cx/LP126cn ftpd 4.15.1
|_ftp-bounce: bounce working!
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
23/tcp   open  tcpwrapped
80/tcp   open  http       Ricoh Aficio printer web image monitor (Web-Server httpd 3.0)
|_html-title: Web Image Monitor
|_http-methods: No Allow or Public header in OPTIONS response (status code 501)
139/tcp  open  tcpwrapped
514/tcp  open  login      Aficio/NRG/Ricoh printer logind
515/tcp  open  printer    lpd (error: Illegal service request)
631/tcp  open  ipp        NRG copier or Ricoh Aficio printer (Embedded Web-Server 3.0)
9100/tcp open  jetdirect?
MAC Address: 00:00:23:92:G8:F1 (Ricoh Company)
Device type: printer
Running: Ricoh embedded, Savin embedded
OS details: Ricoh Aficio 3045/3245C multifunction printer, Savin 8025e multifunction printer
Network Distance: 1 hop
Service Info: Device: printer

Now that we have our open ports  we can now  feed them to ncrack to test if we have any weak passwords. As you can see from the below command I am using NCrack to look for weak authentication via Telnet, FTP, HTTP. You can either specify the port number, the service name or both.

infolookup@TestSrvr:~# ncrack -v –log-errors /tmp/ncrack.txt  172.29.19.85 -p telnet,ftp:21,http

Starting Ncrack 0.3ALPHA ( http://ncrack.org ) at 2010-09-22 22:41 EDT

Failed to resolve given hostname/IP: . Note that you can’t use ‘/mask’ AND ’1-4,7,100-’ style IP ranges
http://172.29.19.85:80 finished.
Discovered credentials on ftp://172.29.19.85:21 ‘root’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘administrator’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘guest’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘info’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘security’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘support’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘abuse’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘admin’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘postmaster’ ’123456′
Discovered credentials on ftp://172.29.19.85:21 ‘lists’ ’123456′
caught SIGINT signal, cleaning up
Saved current session state at: /root/.ncrack/restore.2010-09-22_22-42

We can conclude from the above test that our FTP service was mis-configured because we left “Anonymous FTP login ” turned on. Our Nmap scan shown us this and we were able to confirm it, since every possible login via FTP was granted access.

Now this was just a basic test, however you can do much more like stop and restart your session, specify your own username and password list, and much more. If you don’t have a good password list visit –>  SkullSecurity , and I must end by saying ” for an Alpha release I am very impressed”, and I cant wait to see what the future has to offer for this program.

Reference links:

http://nmap.org/ncrack/man.html