RE: T-Pot (TCP HoneyPot) idea

["Matt Hellman" <netfilter@taxandfinance.com>]

>>> 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.