From: Onsite S. <dav...@gm...> - 2005-02-24 06:24:03
|
Yes that's what I realized as I was writing the email-That's why I referenced spoofing your IP- it dawned on me while I was writing-I wasn't being very clear but it was the best start I had.I'm not being that clear as to why I really want to roll a reactive FW. I understand that the FW would be so "busy reacting" that it would really become a liability. It would make a DDOS or DOS a whole lot easier in the long run. This Is my reasoning behind a maliciously reactive firewall-OPSEC-Sarbanes Oaxley-Archived Storage That just HAS to be kept and is only available to a select few. And the ability to prove that. Try as you might YOU AIN'T GETTIN TO THIS DATA WITH OUT BEING IN THE LOOP,Lets say that internally the machine or machines behind the reactive firewall are to be accessed by only machines with the xxxxxxx mac address' and xxx.xxx.xxx.xxx IP address' and only the keyholders know from which mac and which IP is valid and ultimately what the ip address is of the firewalled box.The firewall won't be connected to a network it'll be the front end to the network or machines behind it basically and of course a single point of failure-If the firewall is down you ain't gettin in period, Maybe thats not a good way to say it but that's what I'm seeing- I guess what I'm envisioning is a firewall that reacts in the following ways: 1-It will warn & then crash any machine that tries to connect to it that is not on its ACL of Macs & IPs-Can you spoof all of the possible ip's typically used in a lan-Of course Spoofing MACS is "easy" too but an array of MACS-Sure that's possible but in this scenario you have twice to fail. The rest is BSOD for you. 2-The machine doesn't care who it crashes because it shouldn't have been connected to in the first place.If you went on the ACL you shouldn't have been there. The firewall is meant to be a defence mechanism. Basically because we can spoof Ips and Macs the keyholders know them and that is how we will access the machines hard storage to both load and unload data. The machine is offline except that it be accessed in this manner you've got to know where the jack is to plug into and what to put on the wire. Never mind the fact that the jack is hidden to begin with that's just obscurity, This type of defence is ideal because it doesn't depend on say kerberos or anything else on the machine that may prove vulnerable over time. The protected machine will be OS'ed never patched never used for nothing more than storage -its just a physically locked up NAS accessible PHYSICALLY only through great DEPTHS, BIOMETRICS & LOCKS I'm sure early on you've thought- Alternatively you could just back up the data to a tape and lock it in a safe off site and not have any of the above hassles. But there is solid reasoning behind the above. The archived stuff isn't accessible easily yet it is accessible onsite and as such is valuable because the data will on occasion be brought up for use thus eliminating the need to go offsite and get a tape or tons of tapes. Notwithstanding the fact that the data will be backed up to tape,the protected onsite archive needs to exsist. If its taken out it goes back through the Porter Machine that is the resposibility of the keyholders-Thats where the IP & Mac Spoofing comes in-the porter machine can be any bodies machine the keyholder just takes possesion of it and does the spoofing and loading to the secure store behind the reactive firewall. Any thoughts, feelings, flames and otherwise feedback is appreciated. On Wed, 23 Feb 2005 15:23:22 -0600 (CST), Heiko Zuerker <he...@zu...> wrote: > > > Bruce Smith wrote: > > > > > >>> Your familiar with the term reactive firewall right? I was wondering > >>> if DL can be tweaked to say connect back to an attacker and spawn a > >>> shell and execute code against their box or perhaps be conditional > >>> like warn and if attacker persists execute a command-to say block > >>> their IP and crash their machine.Of course if they poisoned their arp > >>> cache and spoofed their IP the IP Block wouldn't do much more than > >>> bog down the machine-I'm going to try to roll my own and test it-but > >>> I'd > >>> like to see if I can make it reactive in the process. > >>> > >>> > >> > >> To attack other machines could be illegal in many areas, so we will > >> _NOT_ add anything like that to DL. > >> > >> > >> You can use the "recent" module of iptables to drop/reject excessive > >> connection attempts to your machine, but it does not initiate any packets > >> to the source of the attack. You'd have to write that manually since we > >> have any code or examples of the "recent" module in the default DL > >> firewall rules. > >> > >> - BS > >> > >> > >> > >> > >> > > I had a SnapGear firewall linux appliance with IDB (Intrusion Detection > > and Blocking) - it actually worked fairly well. You set it up to trigger on > > obvious TCP ports like MSSql (1433) or Netbios (137/8/9). Anybody who > > scans me on those ports I don't want in on any port... UDP is not good > > because it's too easy too forge. > > > > I don't know if that was proprietary or opensource tho... but it's not > > really rocket science. It might be nice to auto-expire the entries if > > possible. > > > > Does iptables now do this? > > > > > > I agree automated counter attacks are a really bad idea. > > The problem with any automated procedures is, that you're very vulnerable > to DoS attacks. > Scenario: > You automatically block all IPs with invalid connection attempts. > I 'attack' your firewall, but forge the sender IPs. You will automatically > block all those IPs for a while. > I can get you to block your mail servers, access to the root DNS server > and to whatever *I* please. > > You see although it's in theory a good idea, it's just to exploitable. > > -- > > Regards > Heiko Zuerker > http://www.devil-linux.org > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- David Frohwerk Onsite Services Computer7.com |