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