Wednesday, April 17, 2013

What is SUID and how to set SUID in Linux/Unix?

http://www.linuxnix.com/2011/12/suid-set-suid-linuxunix.html


There are some other special permission apart from the normal file permissions read, write and execute which we set with chmod and chown commands. They are SUID, SGID, Sticky Bit, ACL’s, SUDO and SELinux etc for granular file/folder management by Linux administrator. In this post we will see
1)What’s SUID?
2)How to set SUID?
3)Where to use SUID?

What is SUID and how to set it in Linux?

SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SUID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file owner rather that the user who is running it. In simple words users will get file owner’s permissions as well as owner UID and GID when executing a file/program/command.
The above sentence is bit tricky and should be explained in-depth with examples.

Learn SUID with examples:

Example1: passwd command
When we try to change our password we will use passwd command which is owned by root. This passwd command file will try to edit some system config files such as /etc/passwd, /etc/shadow etc when we try to change our password. Some of these files cannot be opened or viewed by normal user only root user will have permissions. So if we try to remove SUID and give full permissions to this passwd command file it cannot open other files such as /etc/shadow file to update the changes and we will get permission denied error or some other error when tried to execute passwd command. So passwd command is set with SUID to give root user permissions to normal user so that it can update /etc/shadow and other files.
Example2: ping command
Similarly if we take ping command, when we have to execute this command internally it should open socket files and open ports in order to send IP packets and receive IP packets to remote server. Normal users don’t have permissions to open socket files and open ports. So SUID bit is set on this file/command so that whoever executes this will get owner (Root user’s) permissions to them when executing this command. So when this command start executing it will inherit root user permissions to this normal user and opens require socket files and ports.
Example3: crontab and at command.
When scheduling the jobs by using crontab or at command it is obvious to edit some of the crontab related configuration files located in /etc which are not writable for normal users. So crontab/at commands are set with SUID in-order to write some data.

How can I setup SUID for a file?

SUID can be set in two ways
1) Symbolic way(s, Stands for Set) 
2) Numerical/octal way(4)
Use chmod command to set SUID on file: file1.txt
Symbolic way:
chmod u+s file1.txt
Here owner permission execute bit is set to SUID with +s
Numerical way:
chmod 4750 file1.txt
Here in 4750, 4 indicates SUID bit set, 7 for full permissions for owner, 5 for write and execute permissions for group, and no permissions for others.
How can I check if a file is set with SUID bit or not?
Use ls –l to check if the x in owner permissions field is replaced by s or S
For example: file1.txt listing before and after SUID set
Before SUID set:
ls -l
total 8

-rwxr--r-- 1 xyz xyzgroup 148 Dec 22 03:46 file1.txt
After SUID set:
ls -l
total 8

-rwsr--r-- 1 xyz xyzgroup 148 Dec 22 03:46 file1.txt

Some FAQ’s related to SUID:

A) Where is SUID used?
1) Where root login is required to execute some commands/programs/scripts.
2) Where you don’t want to give credentials of a particular user and but want to run some programs as the owner.
3) Where you don’t want to use SUDO command but want to give execute permission for a file/script etc.
B) I am seeing “S” I.e. Capital “s” in the file permissions, what’s that?
After setting SUID to a file/folder if you see ‘S’ in the file permission area that indicates that the file/folder does not have executable permissions for that user on that particular file/folder.
For example see below example
chmod u+s file1.txt
ls -l
-rwSrwxr-x 1 surendra surendra 0 Dec 27 11:24 file1.txt
If you want to convert this S to s then add executable permissions to this file as show below
chmod u+x file1.txt
ls -l
-rwsrwxr-x 1 surendra surendra 0 Dec 5 11:24 file1.txt
you should see a smaller ‘s’ in the executable permission position now.
SUID with execute permissions:

SUID_Linux

SUID with out execute permissions:
SUID_Linux_without_execute_permissions
C) How can I find all the SUID set files in Linux/Unix.
find / -perm +4000
The above find command will check all the files which is set with SUID bit(4000).
D) Can I set SUID for folders?
Yes, you can if its required(you should remember one thing, that Linux treats everything as a file)
E) What is SUID numerical value?
It has the value 4.
Please comment your thoughts about SUID usage in your company.

How to scan Linux for vulnerabilities with lynis

http://linuxaria.com/pills/how-to-scan-linux-for-vulnerabilities-with-lynis?lang=en


As a system administrator, Linux security technician or system auditor, your responsibility can involve any combination of these: software patch management, malware scanning, file integrity checks, security audit, configuration error checking, etc. If there is an automatic vulnerability scanning tool, it can save you a lot of time checking up on common security issues.
One such vulnerability scanner on Linux is lynis. This tool is actually supported on multiple platforms including CentOS, Debian, Fedora, FreeBSD, Mac OS and Ubuntu.



To install lynis on Linux, open a terminal and run the following commands:
$ wget http://www.rootkit.nl/files/lynis-1.3.0.tar.gz
$ sudo tar xvfvz lynis-1.3.0.tar.gz -C /opt
To scan Linux for vulnerabilities with lynis, run the following.
$ cd /opt/lynis-1.3.0/
$ sudo /opt/lynis-1.3.0/lynis --check-all -Q
Once lynis starts scanning your system, it will perform auditing in a number of categories:
  • System tools: system binaries
  • Boot and services: boot loaders, startup services
  • Kernel: run level, loaded modules, kernel configuration, core dumps
  • Memory and processes: zombie processes, IO waiting processes
  • Users, groups and authentication: group IDs, sudoers, PAM configuration, password aging, default mask
  • Shells
  • File systems: mount points, /tmp files, root file system
  • Storage: usb-storage, firewire ohci
  • NFS
  • Software: name services: DNS search domain, BIND
  • Ports and packages: vulnerable/upgradable packages, security repository
  • Networking: nameservers, promiscuous interfaces, connections
  • Printers and spools: cups configuration
  • Software: e-mail and messaging
  • Software: firewalls: iptables, pf
  • Software: webserver: Apache, nginx
  • SSH support: SSH configuration
  • SNMP support
  • Databases: MySQL root password
  • LDAP services
  • Software: php: php options
  • Squid support
  • Logging and files: syslog daemon, log directories
  • Insecure services: inetd
  • Banners and identification
  • Scheduled tasks: crontab/cronjob, atd
  • Accounting: sysstat data, auditd
  • Time and synchronization: ntp daemon
  • Cryptography: SSL certificate expiration
  • Virtualization
  • Security frameworks: AppArmor, SELinux, grsecurity status
  • Software: file integrity
  • Software: malware scanners
  • Home directories: shell history files
The screenshot of lynis in action is shown below:
lynis

Once scanning is completed, the auditing report of your system is generated and stored in /var/log/lynis.log.
The audit report contains warnings for potential vulnerabilities detected by the tool. For example:
$ sudo grep Warning /var/log/lynis.log
[20:20:04] Warning: Root can directly login via SSH [test:SSH-7412] [impact:M]
[20:20:04] Warning: PHP option expose_php is possibly turned on, which can reveal useful information for attackers. [test:PHP-2372] [impact:M]
[20:20:06] Warning: No running NTP daemon or available client found [test:TIME-3104] [impact:M]
The audit report also contains a number of suggestions that can help harden your Linux system. For example:
$ sudo grep Suggestion /var/log/lynis.log
[20:19:41] Suggestion: Install a PAM module for password strength testing like pam_cracklib or pam_passwdqc [test:AUTH-9262]
[20:19:41] Suggestion: When possible set expire dates for all password protected accounts [test:AUTH-9282]
[20:19:41] Suggestion: Configure password aging limits to enforce password changing on a regular base [test:AUTH-9286]
[20:19:41] Suggestion: Default umask in /etc/profile could be more strict like 027 [test:AUTH-9328]
[20:19:42] Suggestion: Default umask in /etc/login.defs could be more strict like 027 [test:AUTH-9328]
[20:19:42] Suggestion: Default umask in /etc/init.d/rc could be more strict like 027 [test:AUTH-9328]
[20:19:42] Suggestion: To decrease the impact of a full /tmp file system, place /tmp on a separated partition [test:FILE-6310]
[20:19:42] Suggestion: Disable drivers like USB storage when not used, to prevent unauthorized storage or data theft [test:STRG-1840]
[20:19:42] Suggestion: Disable drivers like firewire storage when not used, to prevent unauthorized storage or data theft [test:STRG-1846]
[20:20:03] Suggestion: Install package apt-show-versions for patch management purposes [test:PKGS-7394]
. . . .
So what are you waiting for ?
One run can give you some good suggestion on how to improve the security of your system, a regular scan can help you in notice changes and malware.

Tuesday, April 9, 2013

Wi-Fi Mini Honeypot

http://www.linuxjournal.com/content/wi-fi-mini-honeypot


 Do you have an old, unused wireless router collecting dust? Have some fun and make a Wi-Fi honeypot with it!
Recently, I've been playing with some new wireless gear. It's nothing special: 200mW Atheros-based transceiver and 18dBi yagi antenna. I'm living in an apartment in a city of about 640,000 people. I've pointed the antenna to a window and passively received about 30 wireless ESSIDs, three of which were unsecured (open) and six secured with WEP (easily crackable). I haven't connected to any of them, of course, but that gave me some ideas.
What if I deployed a wireless access point deliberately open? Some people eventually will connect and try to use it for Internet access—some might be malicious, and some might think that it's a hotspot. And, what if I deployed a similar access point, but secured with easily crackable WEP this time? Well, in my humble opinion, it's not possible to unconsciously crack WEP. If somebody that I don't know connects to this AP, I've just been attacked. All I need to do is to monitor.
That's exactly a wireless honeypot: fake access point, deliberately unsecured or poorly secured and monitored, so you can get as much information about attackers as you want. Such honeypots are especially useful in large networks as early threat indicators, but you also can play with them on your home network, just for fun and research.
You can build a wireless honeypot with old hardware, some spare time and, of course, a Linux-based solution. OpenWrt and DD-WRT are the two most popular Linux-based firmware projects for routers. I use them and some old spare routers in this article to show you how to build three kinds of honeypots: a very basic one that logs only information about packets sent by users into its memory, a little more sophisticated one with USB storage that logs a few more details about malicious clients to the storage, and finally, a solution that redirects HTTP traffic through a proxy that not only can log, but also interfere with communication.

Basic Honeypot with DD-WRT

Building a very basic wireless honeypot shouldn't take you more than an hour or two. Just grab your old router and pick up the firmware. Be sure to look at supported routers for both DD-WRT and OpenWrt. In my case, it came up that the router is supported only by DD-WRT, as it has 32MB of RAM and 4MB of Flash memory. OpenWrt's hardware requirements are a little bigger.
Next, flash your router (that's the risky part). Basically, you need to download the firmware for your machine and upload it to the memory. On some routers, it's as easy as clicking a button on the Web interface. On others, you have to connect through a serial cable, for example. Remember, this step can be dangerous. Make a backup first and be sure to read the instructions carefully on the DD-WRT/OpenWrt sites.
After successfully flashing your router, you should see an enhanced (as compared to the original one) Web interface. Now, set up SSH access and wireless network parameters. If you don't know how, you can find detailed instructions on the DD-WRT home page. As it is going to be a honeypot, I would suggest WEP, which should attract potential attackers. At the same time, it won't be so vulnerable to false positives—people with devices automatically connecting to an open network.
If you can log in as root and see the prompt, you're ready for the next step: enabling system logging. You can do this using the Web interface: Services→Services→System Log and Security→Log Enable (Figure 1).
Figure 1. Enabling System Logging
You also can set a few ESSIDs instead of just one: Wireless→Basic Settings→Virtual Interfaces. After that, your honeypot will be seen as a few networks—at least at first glance. This increases the probability of attacks, especially when there are many other networks in your neighborhood.

 Remember, you don't have to connect your honeypot to the Internet. In fact, you shouldn't, as you have no control of what potential users might do with the Internet access. After configuring it as described above, test whether it logs your connections. DD-WRT writes the log in /var/log/messages by default. You can check it using SSH. Here's an example fragment of such a log:

Jan  1 00:43:03 orange user.warn kernel: ACCEPT IN=br0 
 ↪OUT= MAC=00:26:5a:a1:bc:86:00:0c:f1:11:43:0e:08:00 
 ↪SRC=192.168.2.2 DST=192.168.2.1 LEN=84 TOS=0x00 PREC=0x00 
 ↪TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=22535 SEQ=1 
Jan  1 00:43:04 orange user.warn kernel: ACCEPT IN=br0 
 ↪OUT= MAC=00:26:5a:a1:bc:86:00:0c:f1:11:43:0e:08:00 
 ↪SRC=192.168.2.2 DST=192.168.2.1 LEN=84 TOS=0x00 PREC=0x00 
 ↪TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=22535 SEQ=2 

If you can see your packet info logged, just leave the router and wait, looking at the log from time to time.
Unfortunately, with such small resources, you can't do much more—at least within a few hours. This basic honeypot would log only packet headers, IPs and MAC addresses. You can see how a ping command is logged in the previous example. Generally, all the information you can collect is when somebody with a specified MAC and IP try to use your network—that's not much.

Logging Associations to USB Storage with OpenWrt

You can build a little more-advanced wireless honeypot with OpenWrt. Using it, you'll be able to log not only packets, MAC addresses and IP addresses, but also wireless associations, authentications, disassociations, deauthentications and timestamps. With a little effort, you also can expand your honeypot logging capabilities to use USB storage—that gives you a lot more space for logs.
My second router has 32MB of RAM, 8MB of Flash memory and USB support. On such hardware, you easily can install OpenWrt in a similar way as DD-WRT. Detailed instructions are available on the OpenWrt site. After installing it, setting up a wireless access point and logging in via SSH as root, you need to install a few more packages.
First, you'll need USB storage support:

opkg update
opkg install kmod-usb-ohci
opkg install kmod-usb2
insmod usb-ohci
insmod usbcore
insmod ehci-hcd

Now, after connecting a pendrive, dmesg should show it to you, for example, as /dev/sda. Make a directory for mounting your storage: mkdir /storage. Then mount it: mount /dev/sda1 /storage. You'll use it later for gathered data.
Next, you must decide what traffic to log. Let's assume you want to log all traffic forwarded by the router. To do this, use netfilter and iptables: iptables -I FORWARD -j LOG, just as you would do in a typical Linux distribution.
Listing 1 shows an example fragment of a log stored on the pendrive. It was generated by the user associating, authenticating, requesting IP through DHCP and connecting to google.pl:80.

Listing 1. Example Log Generated with OpenWrt and Stored on a Pendrive


Oct 15 10:17:01 white daemon.info hostapd: wlan0: 
 ↪STA 00:0c:f1:11:43:0e IEEE 802.11: authenticated
Oct 15 10:17:01 white daemon.info hostapd: wlan0: 
 ↪STA 00:0c:f1:11:43:0e IEEE 802.11: associated (aid 1)
Oct 15 10:17:01 white daemon.info hostapd: wlan0: 
 ↪STA 00:0c:f1:11:43:0e WPA: pairwise key handshake completed (RSN)
Oct 15 10:17:03 white daemon.info dnsmasq-dhcp[1106]: 
 ↪DHCPDISCOVER(br-lan) 192.168.1.99 00:0c:f1:11:43:0e
Oct 15 10:17:03 white daemon.info dnsmasq-dhcp[1106]: 
 ↪DHCPOFFER(br-lan) 192.168.1.99 00:0c:f1:11:43:0e
Oct 15 10:17:03 white daemon.info dnsmasq-dhcp[1106]: 
 ↪DHCPREQUEST(br-lan) 192.168.1.99 00:0c:f1:11:43:0e
Oct 15 10:17:03 white daemon.info dnsmasq-dhcp[1106]: 
 ↪DHCPACK(br-lan) 192.168.1.99 00:0c:f1:11:43:0e red
Oct 15 10:17:14 white user.warn kernel: IN=br-lan OUT=eth0.2 
 ↪SRC=192.168.1.99 DST=209.85.148.105 LEN=60 TOS=0x00 
 ↪PREC=0x00 TTL=63 ID=59445 DF PROTO=TCP
 ↪SPT=49958 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Oct 15 10:17:14 white user.warn kernel: IN=eth0.2 OUT=br-lan 
 ↪SRC=209.85.148.105 DST=192.168.1.99 LEN=60 TOS=0x00 
 ↪PREC=0x00 TTL=51 ID=6488 PROTO=TCP SPT=80 DPT=49958 
 ↪WINDOW=5672 RES=0x00 ACK SYN URGP=0
Oct 15 10:17:14 white user.warn kernel: IN=br-lan 
 ↪OUT=eth0.2 SRC=192.168.1.99 DST=209.85.148.105 LEN=52 
 ↪TOS=0x00 PREC=0x00 TTL=63 ID=59446 DF PROTO=TCP
 ↪SPT=49958 DPT=80 WINDOW=229 RES=0x00 ACK URGP=0
Oct 15 10:17:14 white user.warn kernel: IN=br-lan 
 ↪OUT=eth0.2 SRC=192.168.1.99 DST=209.85.148.105 
 ↪LEN=200 TOS=0x00 PREC=0x00 TTL=63 ID=59447 DF PROTO=TCP
 ↪SPT=49958 DPT=80 WINDOW=229 RES=0x00 ACK PSH URGP=0
Oct 15 10:17:15 white user.warn kernel: IN=eth0.2 OUT=br-lan 
 ↪SRC=209.85.148.105 DST=192.168.1.99 LEN=52 TOS=0x00 
 ↪PREC=0x00 TTL=51 ID=6489 PROTO=TCP SPT=80
 ↪DPT=49958 WINDOW=106 RES=0x00 ACK URGP=0
Oct 15 10:17:15 white user.warn kernel: IN=eth0.2 OUT=br-lan 
 ↪SRC=209.85.148.105 DST=192.168.1.99 LEN=561 TOS=0x00 
 ↪PREC=0x00 TTL=51 ID=6490 PROTO=TCP SPT=80
 ↪DPT=49958 WINDOW=106 RES=0x00 ACK PSH URGP=0 
This honeypot is a little more advanced, although you still don't have much control over user activity on the Internet. You either shouldn't connect the router to the Internet, filter the traffic with iptables and/or set up a proxy between your router and the Internet. Or, you can set up a proxy on your router!

 OpenWrt and Tinyproxy

If your machine has enough resources, you can go one step further and use a proxy on your router. With this, you will be able to monitor, filter and modify HTTP traffic. Squid is an example of full-blown proxy solution. If you have a router that is capable of running it, go ahead. If you (like me) don't, you'll have to stick with a solution with fewer requirements. An example of such a solution is tinyproxy. To install tinyproxy in your OpenWrt, run:

opkg update
opkg install tinyproxy luci-app-tinyproxy

Then, configure and run it with:

uci set tinyproxy.@tinyproxy[0].enable=1
uci commit
/etc/init.d/tinyproxy enable
/etc/init.d/tinyproxy restart

From now on, your tinyproxy should listen by default on port 8888 on your localhost. You can check this with the netstat command. Since you want to accept connections not only from localhost, but also from LAN, you'll have to change the configuration a little bit. Also, in our case, it's better to run it in so-called stealth mode—that means no added headers in HTTP. You can find the tinyproxy configuration in the /etc/config/tinyproxy file. Listing 2 shows an example of such a configuration. Notice that logfile is specified to be in the /storage directory, which is our pendrive. Another important option is list 'Allow'. These are the IPs that are allowed to connect to the tinyproxy. You should specify your LAN network or a part of it.

Listing 2. Tinyproxy Configuration with Domain Filtering, Stealth Mode and Custom Log Localization


config 'tinyproxy'
        option 'User' 'nobody'
        option 'Group' 'nogroup'
        option 'Port' '8888'
        option 'Listen' '192.168.1.1'
        option 'Timeout' '600'
        option 'DefaultErrorFile' '/usr/share/tinyproxy/default.html'
        option 'StatFile' '/usr/share/tinyproxy/stats.html'
        option 'Logfile' '/storage/tinyproxy.log'
        option 'LogLevel' 'Connect'
        option 'MaxClients' '100'
        option 'MinSpareServers' '5'
        option 'MaxSpareServers' '20'
        option 'StartServers' '10'
        option 'MaxRequestsPerChild' '0'
        list 'Allow' '192.168.1.0/24'
        list 'Allow' '127.0.0.1'
        option 'ViaProxyName' 'tinyproxy'
        option 'DisableViaHeader' '1'
        option 'FilterDefaultDeny' '1'
        option 'Filter' '/storage/filter'
        list 'ConnectPort' '443'
        list 'ConnectPort' '563'
        option 'enable' '1'
Tinyproxy also lets you filter requests by domain. You can specify a blacklist or a whitelist of domains in the Filter file. In our configuration, this is '/storage/filter' Also, here we notify tinyproxy to treat this file as a whitelist (FilterDefaultDeny 1), meaning that requests only for specified domains will be allowed. That way, you can forbid attackers from accessing the Internet with their browsers or let them access only specified domains. An example of a /storage/filter file could be:

linuxjournal.com 

That would let them visit only the Linux Journal Web site.

 Keep in mind that this will block only HTTP requests; all the other traffic will be allowed if you haven't blocked it elsewhere.
Finally, you must tell your router to forward all HTTP traffic to your new proxy. As usual, you can do this with iptables, but first you need to install the iptables-mod-nat-extra package:

opkg install iptables-mod-nat-extra
iptables -A PREROUTING -t nat -p tcp --destination-port 80 
 ↪-j REDIRECT --to-port 8888

From now on, all HTTP requests should be forwarded through tinyproxy and logged to /storage/tinyproxy.log. Listing 3 shows a fragment of such a log. You can see what connections the user tried to make and what has been filtered by the proxy.

Listing 3. tinyproxy.log


CONNECT   Oct 22 16:17:59 [1242]: Connect (file descriptor 7): 
 ↪crimson.lan [192.168.1.200]
CONNECT   Oct 22 16:17:59 [1242]: Request (file descriptor 7): 
 ↪GET / HTTP/1.1
NOTICE    Oct 22 16:17:59 [1242]: Proxying refused on filtered 
 ↪domain "www.google.com"
CONNECT   Oct 22 16:18:05 [1243]: Connect (file descriptor 7): 
 ↪crimson.lan [192.168.1.200]
CONNECT   Oct 22 16:18:05 [1243]: Request (file descriptor 7): 
 ↪GET / HTTP/1.1
CONNECT   Oct 22 16:18:05 [1243]: Established connection to host
 ↪"www.linuxjournal.com" using file descriptor 8.
CONNECT   Oct 22 16:18:06 [1244]: Connect (file descriptor 7): 
 ↪crimson.lan [192.168.1.200]
CONNECT   Oct 22 16:18:06 [1244]: Request (file descriptor 7): 
 ↪GET /pixel/p-a3K3N6enFe9wA.gif HTTP/1.1
NOTICE    Oct 22 16:18:06 [1244]: Proxying refused on filtered 
 ↪domain "pixel.quantserve.com"
CONNECT   Oct 22 16:25:52 [1246]: Connect (file descriptor 7): 
 ↪crimson.lan [192.168.1.200]
CONNECT   Oct 22 16:25:52 [1246]: Request (file descriptor 7): 
 ↪GET / HTTP/1.1
NOTICE    Oct 22 16:25:52 [1246]: Proxying refused on filtered 
 ↪domain "www.google.com"
When tinyproxy filters a connection request, it displays an information page describing what happened. You also can make use of this to hide tinyproxy's presence or to inform or deceive your attackers (or make a joke). The Web site template is in /usr/share/tinyproxy/default.html. You can see a slightly modified version of this in Listing 4 and Figure 2. This doesn't tell users about tinyproxy and the reason for seeing this page; instead, it politely informs them that they shouldn't use this network for Internet access.
Figure 2. Web Site Template

Listing 4. tinyproxy.html






Information

Information

{clienthost} You shouldn't use this network for web access.

Go with the Evolution

The next step in the evolution would be a full-blown wireless honeypot. You can make one using a machine that can run a typical Linux distribution. Then install, for example, dionaea, use a wireless card configured to run as an access point and forward all traffic to your localhost, on which the attacker will see fake services.
Remember, if you want a really good honeypot, make sure that it looks as close as possible to reality. That means, for example, that you might use some dummy clients just to simulate traffic. Or, use WPA instead of WEP. It all depends on your environment.
Also, it is important to be familiar with your country's laws. Make sure it's not prohibited to sniff your attackers' data. Think about whether it's wise to make an Internet connection available for them. Maybe it would be better not to connect your router's WAN port to anything at all, connect it to your machine simulating the Internet or connect it to the Internet but filter the traffic with iptables?
Finally, don't be discouraged by the DD-WRT or OpenWrt systems. They are based on Linux and are very similar in use, but because of the small resources available, they're stripped down. There are no manual pages and slightly different utilities that you may know from you Linux distribution, even though they are named the same. And, the documentation isn't always accurate. If you have any problems, both projects' wikis are very helpful.
And, last but not least, have fun building your solution and (especially) with browsing the collected data!