T-Pot (TCP HoneyPot) idea

T-Pot (TCP HoneyPot) idea

[waltdnes]

  I'm sure every here has seens lots of SYN-packets in their logs,
trying to connect to various ports they shouldn't be talking to.  I
don't run any public servers, and I use passive ftp, so I simply block
all connection attempts.  The general procedure is to drop the packet,
and ignore it.  What would be the effect of sending back a SYN-ACK
packet (and anything else necessary?) to fake the setting up of a
connection... and then dropping the packet and ignoring it ?

  Would an infected machine scanning the net eventually run into
resource limits and DOS itself ?  I'm sure that professional crackers
can work around this, but if we can make things a bit more painful for
skiddies and automatic worms, then let's do it.

  Can such trickery be pulled off with a current bog-standard iptables,
or does someone need to write a new "target"?

-- 
Walter Dnes <waltdnes@waltdnes.org>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.

Re: T-Pot (TCP HoneyPot) idea

[Bob Keyes]

On Thu, 10 Apr 2003 waltdnes@waltdnes.org wrote:

>   I'm sure every here has seens lots of SYN-packets in their logs,
> trying to connect to various ports they shouldn't be talking to.  I
> don't run any public servers, and I use passive ftp, so I simply block
> all connection attempts.  The general procedure is to drop the packet,
> and ignore it.  What would be the effect of sending back a SYN-ACK
> packet (and anything else necessary?) to fake the setting up of a
> connection... and then dropping the packet and ignoring it ?
>
>   Would an infected machine scanning the net eventually run into
> resource limits and DOS itself ?  I'm sure that professional crackers
> can work around this, but if we can make things a bit more painful for
> skiddies and automatic worms, then let's do it.
>
>   Can such trickery be pulled off with a current bog-standard iptables,
> or does someone need to write a new "target"?

This is sort of similar to the NAPTHA program I wrote a couple of years
ago to demonstrate a resource DoS attack.
http://razor.bindview.com/publish/advisories/adv_NAPTHA.html
http://packetstormsecurity.org/0101-exploits/naptha-1.1.tgz
(I have a more recent version if anyone cares)
The program could easily be run with command line options to accomplish
exactly what you are proposing. However it is also fairly easy to defeat
this sort of attack by not keeping state. I have written a port scanner
that does exactly that, it is very fast and effective.

An interesting attack might be to hang all IDENT queries sent back by an
IDS that tries to find out who is scanning them.

Re: T-Pot (TCP HoneyPot) idea

[Michael H. Warfield]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On Thu, Apr 10, 2003 at 06:07:41PM -0400, waltdnes@waltdnes.org wrote:
>   I'm sure every here has seens lots of SYN-packets in their logs,
> trying to connect to various ports they shouldn't be talking to.  I
> don't run any public servers, and I use passive ftp, so I simply block
> all connection attempts.  The general procedure is to drop the packet,
> and ignore it.  What would be the effect of sending back a SYN-ACK
> packet (and anything else necessary?) to fake the setting up of a
> connection... and then dropping the packet and ignoring it ?

	Please check freshmeat for the following references:

	honeyd
	labrea
	arpd
	portsentry
	deception toolkit

	I think you will find more than you ever imagined.

>   Would an infected machine scanning the net eventually run into
> resource limits and DOS itself ?  I'm sure that professional crackers
> can work around this, but if we can make things a bit more painful for
> skiddies and automatic worms, then let's do it.

>   Can such trickery be pulled off with a current bog-standard iptables,
> or does someone need to write a new "target"?

	Use a user space bodger.  You can do much more amusing things
that way.  Honeyd can even fool nmap thinking it different operating
systems.

> -- 
> Walter Dnes <waltdnes@waltdnes.org>
> An infinite number of monkeys pounding away on keyboards will
> eventually produce a report showing that Windows is more secure,
> and has a lower TCO, than linux.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

RE: T-Pot (TCP HoneyPot) idea

[Matt Hellman]

I'm not terribly well versed in the various flag settings during session
setup and tear down, however this doesn't seem likely to be very effective.
The end result would probably just be a lot more traffic on your own little
connection to the Internet.  Or worse, someone could figure out what you're
doing and flood you with SYN packets with spoofed source addresses.  It may
not effect the resources on your firewall (assuming your not keeping the
connection state) but others sure won't appreciate getting a bunch of
SYN-ACK packets from you;) 

>>-----Original Message-----
>>From: netfilter-admin@lists.netfilter.org 
>>[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of 
>>waltdnes@waltdnes.org
>>Sent: Thursday, April 10, 2003 5:08 PM
>>To: Netfilter list
>>Subject: T-Pot (TCP HoneyPot) idea
>>
>>
>>  I'm sure every here has seens lots of SYN-packets in their logs,
>>trying to connect to various ports they shouldn't be talking to.  I
>>don't run any public servers, and I use passive ftp, so I simply block
>>all connection attempts.  The general procedure is to drop the packet,
>>and ignore it.  What would be the effect of sending back a SYN-ACK
>>packet (and anything else necessary?) to fake the setting up of a
>>connection... and then dropping the packet and ignoring it ?
>>
>>  Would an infected machine scanning the net eventually run into
>>resource limits and DOS itself ?  I'm sure that professional crackers
>>can work around this, but if we can make things a bit more painful for
>>skiddies and automatic worms, then let's do it.
>>
>>  Can such trickery be pulled off with a current bog-standard 
>>iptables,
>>or does someone need to write a new "target"?
>>
>>-- 
>>Walter Dnes <waltdnes@waltdnes.org>
>>An infinite number of monkeys pounding away on keyboards will
>>eventually produce a report showing that Windows is more secure,
>>and has a lower TCO, than linux.
>>

RE: T-Pot (TCP HoneyPot) idea

[Bob Keyes]

On Thu, 10 Apr 2003, Matt Hellman wrote:

> I'm not terribly well versed in the various flag settings during session
> setup and tear down, however this doesn't seem likely to be very effective.
> The end result would probably just be a lot more traffic on your own little
> connection to the Internet.

Bandwidth isn't as much of an issue with syn/ack packets as is the load on
the system. This is why the old synflood was so devastating.

>  Or worse, someone could figure out what you're
> doing and flood you with SYN packets with spoofed source addresses.  It may
> not effect the resources on your firewall (assuming your not keeping the
> connection state) but others sure won't appreciate getting a bunch of
> SYN-ACK packets from you;)

This can already be done. If I fake a SYN packet from you do, say, DNS
root server A, you get traffic from root server A. Maybe a lot of traffic.
It does use more bandwidth as most hosts will reply with an RST, so there
is inbound and output traffic. How effective this is depends on the ratio
of bandwidth in control of the attacker to the limits of bandwidth that
the victim has, and also the capabilities of the intermediate system.

RE: T-Pot (TCP HoneyPot) idea

[Matt Hellman]

>>> I'm not terribly well versed in the various flag settings 
>>during session
>>> setup and tear down, however this doesn't seem likely to be 
>>very effective.
>>> The end result would probably just be a lot more traffic on 
>>your own little
>>> connection to the Internet.
>>
>>Bandwidth isn't as much of an issue with syn/ack packets as 
>>is the load on
>>the system. This is why the old synflood was so devastating.
>>
>>>  Or worse, someone could figure out what you're
>>> doing and flood you with SYN packets with spoofed source 
>>addresses.  It may
>>> not effect the resources on your firewall (assuming your 
>>not keeping the
>>> connection state) but others sure won't appreciate getting 
>>a bunch of
>>> SYN-ACK packets from you;)
>>
>>This can already be done. If I fake a SYN packet from you do, say, DNS
>>root server A, you get traffic from root server A. Maybe a 
>>lot of traffic.

I understand this, but wouldn't getting a single SYN-ACK and 65534 RST's (or
none depending on the DNS host) raise less eyebrows than 65535 SYN-ACK'S.
What do you mean by "Maybe a lot of traffic"...wouldn't you just get a
single SYN-ACK [and drop the packet] for each spoofed SYN? One of the
significant differences I see in the suggested setup is that your host would
send a SYN-ACK for every SYN packet on every port, regardless of whether a
service is actually running on that port.

>>It does use more bandwidth as most hosts will reply with an 
>>RST, so there
>>is inbound and output traffic. How effective this is depends 
>>on the ratio
>>of bandwidth in control of the attacker to the limits of 
>>bandwidth that
>>the victim has, and also the capabilities of the intermediate system.