# REALLY tough security problem - honeypot. [almost solved]

## poly_poly-man

So, I have a reasonably complex (not too much, not too little) setup for my network, but with this new idea, I'm letting it get out of hand - and am happy to do so.

topic 706104 has some background as to what I am attempting - basically, I'm setting up a virtual machine to be AS INSECURE AS POSSIBLE, and open it up to the web.

My gentoo box is using bonding, eth0 and eth2 are null-setup, attached as slaves to bond0. I'd like to set my network up so that I can use the tun/tap network setup for kvm/qemu (and give the virtual machine its own device on the network).

From here, I'd like to set up iptables on my openwrt box (or on my gentoo server) so that it can only access penguin (the gentoo box) at port 80 (and nowhere else on the network), as well as the internet.

To clarify:

http://omploader.org/vcHM5 is what I want - the honeypot given a lan IP, except only allowed to access penguin and the internet, no other ports of penguin, and no other computers.

Alternatively, the honeypot doesn't need to have a lan IP - if it's easier to do networking/iptables through penguin, I'll do it, but the same restrictions apply.

how should I do this? I need step-by-step for some of it - last time I tried to set up the tun/tap qemu, I broke all my networking...

Thanks!

----------

## kevstar31

You cannot setup a NAT if you are using a wireless connection

Enable the config options:

CONFIG_NF_NAT

CONFIG_TUN

----------

## poly_poly-man

 *kevstar31 wrote:*   

> You cannot setup a NAT if you are using a wireless connection
> 
> Enable the config options:
> 
> CONFIG_NF_NAT
> ...

 

a NAT inside my system? sure...

it's not wireless - the only wireless is abstracted behind the openwrt router (as the internet).

How do I get at NAT - it's not in my config.gz at all... tun is on, though.

From there, what do I do to set up qemu?

----------

## Hu

Approach this as two steps.  First, get a KVM guest with TAP support working where it can send IP datagrams to the host system.  Once you have that, we can put together some firewall rules to restrict the guest's activities.  I suggest:

IP forwarding is enabled on the host

The host can either NAT the guest or use proxy ARP to set up a simple bridge.  NAT is more commonly used, so more people can help you configure it.

The host should then be given firewall rules that treat the guest interface much like you treat your WAN interface:

```
iptables -A INPUT -i tap_honeypot -j input_honeypot

iptables -A input_honeypot -p tcp -m tcp --dport 80 -j ACCEPT

iptables -A input_honeypot -j DROP

iptables -A FORWARD -i tap_honeypot -j forward_honeypot

iptables -A forward_honeypot -d 192.168.0.0/16 -j DROP

iptables -A forward_honeypot -d 172.16.0.0/12 -j DROP

iptables -A forward_honeypot -d 10.0.0.0/8 -j DROP

iptables -A forward_honeypot -o eth_WAN -j ACCEPT

iptables -A forward_honeypot -j DROP
```

This redirects all honeypot activity into dedicated chains to make it easier to manage.  Once there, traffic destined to the local machine on port 80 is allowed.  Everything else destined locally is dropped.  For forwarding, anything sent to an RFC1918 reserved address is dropped.  Anything left over is accepted if if it sent out the interface eth_WAN.  This provides a last line of defense to protect your internal network.  It may not be entirely effective since the host is not the connection between LAN and WAN, but it should not hurt.  At nothing else, it protects other guests from the honeypot.  Anything left at the end of that is dropped, but nothing should reach the last forwarding rule.

For configuring QEMU/KVM, use tunctl from sys-apps/usermode-utilities to create a persistent TAP device accessible to the KVM user.  Start kvm with -net nic -net tap,ifname=tap_honeypot,script=no.  This should be enough to get the guest going if you will use static addressing.  You will need to do a bit more if you want to configure the guest via DHCP.

Since you do not have NAT enabled, you will need to turn it on.  Run make menuconfig and use / to search for NAT.  It will show you were to go.

----------

## poly_poly-man

 *Hu wrote:*   

> For configuring QEMU/KVM, use tunctl from sys-apps/usermode-utilities to create a persistent TAP device accessible to the KVM user.  Start kvm with -net nic -net tap,ifname=tap_honeypot,script=no.  This should be enough to get the guest going if you will use static addressing.  You will need to do a bit more if you want to configure the guest via DHCP.
> 
> Since you do not have NAT enabled, you will need to turn it on.  Run make menuconfig and use / to search for NAT.  It will show you were to go.

 

jeez.. rebooting is annoying on this thing.

Done.

Created the tap device... tap_honeypot using tunctl -u mkern -g users -t tap_honeypot (mkern is my username).

so, I'm still a little shaky on this - to set up static networking, I should set up tap_honeypot on the host, and the created device on the client? trying it out now...

is there an easy way to use my existing DHCPCD (serving the lan) on penguin for the tun/tap?

----------

## poly_poly-man

okay... static addresses set up, no need for dhcp.

Appears to work - I can ping and ssh both ways (ubuntu<->gentoo).

For reference: penguin's address in the tun/tap is 192.168.5.1, ubuntu's is 192.168.5.2.

I am a total iptables noob - I'm surprised it's even on this computer.

Are those commands all I have to do, or is there preliminary stuff I have to do?

and I assume eth_WAN should be replacedd by bond0?

thanks

----------

## Hu

 *poly_poly-man wrote:*   

> 
> 
> so, I'm still a little shaky on this - to set up static networking, I should set up tap_honeypot on the host, and the created device on the client? trying it out now...

 

Yes.

 *poly_poly-man wrote:*   

> is there an easy way to use my existing DHCPCD (serving the lan) on penguin for the tun/tap?

 

DHCPCD is a DHCP client.  You need a DHCP server, such as dhcpd.  If you have a dhcpd on penguin, then yes, you can use it to configure the guest.

 *poly_poly-man wrote:*   

> 
> 
> Are those commands all I have to do, or is there preliminary stuff I have to do?

 

That should be sufficient, assuming you have the required Netfilter support built into the kernel.  Please test the rules once they are loaded to ensure they do what you want.

 *poly_poly-man wrote:*   

> and I assume eth_WAN should be replacedd by bond0?

 

Yes.  I was trying to make the commands somewhat generic, so I did not plug in your particular values.

----------

## poly_poly-man

 *Hu wrote:*   

>  *poly_poly-man wrote:*   is there an easy way to use my existing DHCPCD (serving the lan) on penguin for the tun/tap? 
> 
> DHCPCD is a DHCP client.  You need a DHCP server, such as dhcpd.  If you have a dhcpd on penguin, then yes, you can use it to configure the guest.

 mm... yeah.. typo, they're all one letter off  :Razz:  . It's not important now - I got static working so it's not worth the hassle. *Quote:*   

> 
> 
>  *poly_poly-man wrote:*   
> 
> Are those commands all I have to do, or is there preliminary stuff I have to do? 
> ...

 

I've seen some wacky substitutions in iptables commands - just making sure.

Trying it out now.

----------

## poly_poly-man

iptables -A INPUT -i tap_honeypot -j input_honeypot

results in:

iptables v1.4.1.1: Couldn't load target `input_honeypot':/lib64/xtables/libipt_input_honeypot.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

the help is spaghetti - no help at all to someone new at this like me... how do I create a target?

----------

## poly_poly-man

okay... had to give iptables -N input_honeypot and iptables -N forward_honeypot first.

is there a way to save iptables rules so that they come back next reboot?

also, how should the rule to allow port 22 input to go to the virtual machine look?

and also - it works connecting from it to penguin, only on the port specifed (80) - I tried to get DNS to work, but failed (not worth it anyway).

It also cannot connect to anything else on the lan (192.168.1.*)... unfortunately, it can't connect to anything on the internet...

Getting closer, at least.

----------

## cyrillic

 *poly_poly-man wrote:*   

> is there a way to save iptables rules ... 

 

```
# /etc/init.d/iptables save 
```

 *poly_poly-man wrote:*   

> ... so that they come back next reboot? 

 

```
# rc-update add iptables default 
```

----------

## Hu

 *poly_poly-man wrote:*   

> okay... had to give iptables -N input_honeypot and iptables -N forward_honeypot first.

 

Yes, sorry about that.

 *poly_poly-man wrote:*   

> also, how should the rule to allow port 22 input to go to the virtual machine look?

 

Are you trying to allow the honeypot to connect to port 22 on penguin or allow penguin to connect to port 22 on the honeypot?  For the former, modify the rule that I gave for port 80.  For the latter, nothing should be required.  I left the rules open to allow penguin unrestricted access to honeypot, just the way many people allow their systems unrestricted access to the Internet, even when they aggressively filter traffic from the Internet.

Depending on your default policy on the FORWARD chain, it may be the case that no other system is able to send to honeypot.  If this is the case, you need to add a rule to FORWARD of the form -o tap_honeypot -m conntrack --ctstate ESTABLISHED -j ACCEPT.

 *poly_poly-man wrote:*   

> and also - it works connecting from it to penguin, only on the port specifed (80) - I tried to get DNS to work, but failed (not worth it anyway).

 

This should just be a matter of allowing port 53 on penguin if you have a local DNS server.  If you want honeypot to use some other DNS server, then the rule I mentioned above should fix the problem.

 *poly_poly-man wrote:*   

> It also cannot connect to anything else on the lan (192.168.1.*)... unfortunately, it can't connect to anything on the internet...
> 
> Getting closer, at least.

 

This is also consistent with a default policy of DROP on FORWARD.  Could you post the output of iptables-save -c so that we can see your full ruleset?

----------

## poly_poly-man

 *Hu wrote:*   

>  *poly_poly-man wrote:*   okay... had to give iptables -N input_honeypot and iptables -N forward_honeypot first. 
> 
> Yes, sorry about that.
> 
>  *poly_poly-man wrote:*   also, how should the rule to allow port 22 input to go to the virtual machine look? 
> ...

 okay... added that to FORWARD, going to try it out in a minute... should it automatically forward, or do I have to specify something on the host I'm connecting from? *Quote:*   

> 
> 
>  *poly_poly-man wrote:*   and also - it works connecting from it to penguin, only on the port specifed (80) - I tried to get DNS to work, but failed (not worth it anyway). 
> 
> This should just be a matter of allowing port 53 on penguin if you have a local DNS server.  If you want honeypot to use some other DNS server, then the rule I mentioned above should fix the problem.

 yeah, I think it's a bind problem, because I did all the correct steps, even according to guiides online et. al.... oh well, when the internet starts to work, I can just point it at 4.2.2.1 or so... *Quote:*   

> 
> 
>  *poly_poly-man wrote:*   It also cannot connect to anything else on the lan (192.168.1.*)... unfortunately, it can't connect to anything on the internet...
> 
> Getting closer, at least. 
> ...

 

```
# Generated by iptables-save v1.4.1.1 on Wed Sep  3 06:59:52 2008

*raw

:PREROUTING ACCEPT [370753:315120701]

:OUTPUT ACCEPT [317102:70574858]

COMMIT

# Completed on Wed Sep  3 06:59:52 2008

# Generated by iptables-save v1.4.1.1 on Wed Sep  3 06:59:52 2008

*nat

:PREROUTING ACCEPT [19372:1726925]

:POSTROUTING ACCEPT [64497:4463046]

:OUTPUT ACCEPT [64497:4463046]

COMMIT

# Completed on Wed Sep  3 06:59:52 2008

# Generated by iptables-save v1.4.1.1 on Wed Sep  3 06:59:52 2008

*filter

:INPUT ACCEPT [349390:313223805]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [317102:70574858]

:forward_honeypot - [0:0]

:input_honeypot - [0:0]

[1319:148062] -A INPUT -i tap_honeypot -j input_honeypot 

[0:0] -A FORWARD -i tap_honeypot -j forward_honeypot 

[0:0] -A FORWARD -o tap_honeypot -m conntrack --ctstate ESTABLISHED -j ACCEPT 

[0:0] -A forward_honeypot -d 192.168.0.0/16 -j DROP 

[0:0] -A forward_honeypot -d 172.16.0.0/12 -j DROP 

[0:0] -A forward_honeypot -d 10.0.0.0/8 -j DROP 

[0:0] -A forward_honeypot -o bond0 -j ACCEPT 

[0:0] -A forward_honeypot -j DROP 

[0:0] -A forward_honeypot -j ACCEPT 

[0:0] -A forward_honeypot -j ACCEPT 

[0:0] -A forward_honeypot -o bond0 -j ACCEPT 

[15:1975] -A input_honeypot -p tcp -m tcp --dport 80 -j ACCEPT 

[9:502] -A input_honeypot -p tcp -m tcp --dport 53 -j ACCEPT 

[1295:145585] -A input_honeypot -j DROP 

[0:0] -A input_honeypot -p udp -m udp --dport 53 -j ACCEPT 

[0:0] -A input_honeypot -p udp -m udp --sport 1024:65535 --dport 53 -j ACCEPT 

[0:0] -A input_honeypot -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT 

COMMIT

# Completed on Wed Sep  3 06:59:52 2008
```

----------

## Hu

Forwarding should be automatic, assuming you turned on IP forwarding via /proc/sys/net/ipv4/ip_forward.

I see a few problems with your iptables rules.  Your FORWARD policy is ACCEPT, so the honeypot can receive NEW, RELATED, and INVALID packets via the default policy.  Your bottom three rules on forward_honeypot are placed after a terminating DROP target, and therefore can never be hit.  Your bottom three rules for input_honeypot have the same problem.  The only effective input_honeypot rules are for HTTP and DNS-over-TCP.  Since most DNS queries are sent over UDP, this effectively means that penguin DROPs typical DNS queries from honeypot.  Your first unreachable input_honeypot rule is broader than the second, and so the second unreachable rule will never match.  I suggest deleting the third input_honeypot rule, since it allows honeypot to send UDP to any unprivileged port just by setting the source port to 53.  It is unlikely that honeypot would ever legitimately generate traffic with a source port of 53, unless you plan to use it as a DNS server.

----------

## poly_poly-man

kay.... ip_forward is 1, and:

```
# Generated by iptables-save v1.4.1.1 on Thu Sep  4 20:29:39 2008

*raw

:PREROUTING ACCEPT [689367:526462755]

:OUTPUT ACCEPT [626566:116328845]

COMMIT

# Completed on Thu Sep  4 20:29:39 2008

# Generated by iptables-save v1.4.1.1 on Thu Sep  4 20:29:39 2008

*nat

:PREROUTING ACCEPT [22362:2040184]

:POSTROUTING ACCEPT [116328:8144840]

:OUTPUT ACCEPT [116319:8144260]

COMMIT

# Completed on Thu Sep  4 20:29:39 2008

# Generated by iptables-save v1.4.1.1 on Thu Sep  4 20:29:39 2008

*filter

:INPUT ACCEPT [663748:524091239]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [626566:116328845]

:forward_honeypot - [0:0]

:input_honeypot - [0:0]

[4210:461799] -A INPUT -i tap_honeypot -j input_honeypot 

[35:2284] -A FORWARD -i tap_honeypot -j forward_honeypot 

[0:0] -A FORWARD -o tap_honeypot -m conntrack --ctstate ESTABLISHED -j ACCEPT 

[0:0] -A forward_honeypot -d 192.168.0.0/16 -j DROP 

[0:0] -A forward_honeypot -d 172.16.0.0/12 -j DROP 

[0:0] -A forward_honeypot -d 10.0.0.0/8 -j DROP 

[35:2284] -A forward_honeypot -j ACCEPT 

[0:0] -A forward_honeypot -o bond0 -j ACCEPT 

[0:0] -A forward_honeypot -j DROP 

[27:4250] -A input_honeypot -p tcp -m tcp --dport 80 -j ACCEPT 

[10:629] -A input_honeypot -p udp -m udp --dport 53 -j ACCEPT 

[25:4103] -A input_honeypot -j DROP 

COMMIT

# Completed on Thu Sep  4 20:29:39 2008
```

I'm getting DNS from penguin (192.168.5.1) (http works too), but connections to the internet don't work - as in, pings, firefox, wget, etc. all just stop after the dns.

btw - I didn't realize that order mattered for iptables  :Razz: 

should be a quick fix from here?

----------

## Hu

You have not created a SNAT or MASQUERADE rule to rewrite the source address for packets that penguin forwards from honeypot to the outside world.  I initially ignored this on the assumption that you would be using proxy ARP and not need it.  If you have not enabled proxy ARP, then you need to rewrite the source address.  Otherwise, outside systems will see a message from 192.168.5.2, but not be able to find a route to deliver the return traffic.  Thus, you can reach the Internet, but none of its responses reach you.

----------

## ibins

In standard situations I would prefer using proxy-arp, but in the case for a honeypot, I would recommend using SNAT for security reason. Otherwize you would be open for arp-spoofing, arp-poisoning ..attacks

Implementing a arpfirewall would be another option

----------

## poly_poly-man

got SNAT working - thanks!

I'd ompload a screenshot, but omploader isn't working.

Solved  :Very Happy: 

----------

## poly_poly-man

umm... I still can't reach the honeypot with ssh from my computer...  :Sad: 

```
# Generated by iptables-save v1.4.1.1 on Sun Sep  7 21:17:46 2008

*raw

:PREROUTING ACCEPT [1841943:1666018722]

:OUTPUT ACCEPT [1606638:277210398]

COMMIT

# Completed on Sun Sep  7 21:17:46 2008

# Generated by iptables-save v1.4.1.1 on Sun Sep  7 21:17:46 2008

*nat

:PREROUTING ACCEPT [26043:2517218]

:POSTROUTING ACCEPT [239483:16760321]

:OUTPUT ACCEPT [238973:16729681]

[30:1800] -A POSTROUTING -s 192.168.5.2/32 -j SNAT --to-source 192.168.1.122

COMMIT

# Completed on Sun Sep  7 21:17:46 2008

# Generated by iptables-save v1.4.1.1 on Sun Sep  7 21:17:46 2008

*filter

:INPUT ACCEPT [1800203:1658440912]

:FORWARD ACCEPT [2:1152]

:OUTPUT ACCEPT [1606627:277209317]

:forward_honeypot - [0:0]

:input_honeypot - [0:0]

[9260:1024424] -A INPUT -i tap_honeypot -j input_honeypot

[5400:345383] -A FORWARD -i tap_honeypot -j forward_honeypot

[2833:3960004] -A FORWARD -o tap_honeypot -m conntrack --ctstate ESTABLISHED -j ACCEPT

[0:0] -A forward_honeypot -d 192.168.0.0/16 -j DROP

[0:0] -A forward_honeypot -d 172.16.0.0/12 -j DROP

[0:0] -A forward_honeypot -d 10.0.0.0/8 -j DROP

[2355:162499] -A forward_honeypot -o bond0 -j ACCEPT

[0:0] -A forward_honeypot -j DROP

[39:5216] -A input_honeypot -p tcp -m tcp --dport 80 -j ACCEPT

[325:20100] -A input_honeypot -p udp -m udp --dport 53 -j ACCEPT

[4748:546291] -A input_honeypot -j DROP

COMMIT

# Completed on Sun Sep  7 21:17:46 2008

```

ideas?

----------

## Hu

Add a rule to allow ESTABLISHED traffic in the INPUT chain, just like you have in the FORWARD chain.

----------

