From: David <David@Computer7.com> - 2005-02-23 04:19:37
|
I have been following off & on for a while. Adding Bits & Pieces would be cool, do you think it would be possible to make DL reactive. If it could be made truly reactive what would we use to do it. Any caveats or liability involved with this. |
From: Heiko Z. <he...@zu...> - 2005-02-23 13:47:29
|
David wrote: > I have been following off & on for a while. Adding Bits & Pieces would > be cool, do you think it would be possible to make DL reactive. If it > could be made truly reactive what would we use to do it. Any caveats > or liability involved with this. > What do you mean by making DL reactive? -- Regards Heiko Zuerker http://www.devil-linux.org |
From: Onsite S. <dav...@gm...> - 2005-02-23 15:22:25
|
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. On Wed, 23 Feb 2005 07:44:12 -0600, Heiko Zuerker <he...@zu...> wrote: > David wrote: > > > I have been following off & on for a while. Adding Bits & Pieces would > > be cool, do you think it would be possible to make DL reactive. If it > > could be made truly reactive what would we use to do it. Any caveats > > or liability involved with this. > > > > What do you mean by making DL reactive? > > -- > > 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 |
From: Ishida <is...@ma...> - 2005-02-23 16:14:15
|
> 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. > So you think best defence is offence? I personally do not like firewalls like you described. Firstly: If you initate an attack against an attacker then you will be the attacker (or should i say criminal) Secondly: If you block every suspicious connection or port scan then after a while you will find yourself alone locked away from internet :) Consider DSL connections with dynamic IP or I know ISP's that share local (10.x.x.x or 192.168.x.x) IPs to your users and NAT them. Or I have already scanned IPs (and ranges) but (I swear :)) I am not an attacker. (never been) IMHO it is not the proper way to tighten security. cheers, Peter |
From: Bruce S. <bw...@ar...> - 2005-02-23 16:33:43
|
> 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 |
From: Tim <t....@co...> - 2005-02-23 17:17:07
|
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. Tim |
From: Heiko Z. <he...@zu...> - 2005-02-23 21:23:56
|
> 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 |
From: Bruce S. <bw...@ar...> - 2005-02-23 22:12:11
|
> > 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? > > 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. You can do limited automated blocking under some circumstances if you're careful. For example, look at the logs for a machine with an open SSH port to the internet. I'm being hit with dictionary attacks trying to guess a valid SSH login on all my boxes that allow SSH (and I bet you are too). You can "solve" the problem by not allowing password authentication (only allowing RSA/DSA keys or some better method), but it doesn't stop crackers from trying to login anyway (and filling your logs with crap). So I started playing with some iptables rules ... Here are my rules from a web/ftp server - only one NIC - NOT a firewall: (some IP numbers in the following example have been changed) ------------------------------------------------------------------------------------- ${IPTABLES} -P INPUT DROP ${IPTABLES} -P OUTPUT ACCEPT ${IPTABLES} -P FORWARD DROP # special handling for SSH (to dwarf SSH dictionary attacks) ${IPTABLES} -N SSH-attack ${IPTABLES} -A SSH-attack -m recent --name SSHattack --set -j LOG --log-level DEBUG --log-prefix "SSH-attack: " ${IPTABLES} -A SSH-attack -j DROP # ${IPTABLES} -N SSH ${IPTABLES} -A SSH -s 192.168.1.22 -j ACCEPT # allow my desktop without restriction ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHattack --rcheck --seconds 300 -j DROP ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --rcheck --seconds 60 --hitcount 3 -j SSH-attack ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --set ${IPTABLES} -A SSH -p TCP --syn -j ACCEPT # Local interface - do not delete! ${IPTABLES} -A INPUT -i lo -j ACCEPT # Allow established connections. ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow all Pings, FTP, HTTP, NTP ${IPTABLES} -A INPUT -p icmp -j ACCEPT ${IPTABLES} -A INPUT -p tcp -i ${OUT_DEV} -m mport --ports 20:21,80 -j ACCEPT ${IPTABLES} -A INPUT -p udp -i ${OUT_DEV} -s 192.168.1.0/24 --dport 123 -j ACCEPT # special SSH connection limiting ${IPTABLES} -A INPUT -p tcp --dport 22 -i ${OUT_DEV} -j SSH ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "INPUT policy: " --log-level DEBUG ------------------------------------------------------------------------------------- It _always_ allows the standard services of the box (HTTP, FTP, etc.) so they CANNOT be DoS'ed no matter what. It also allows established SSH connections to keep running, even if new connections are blocked from the same IP address. If it receives more than 3 SSH new connects (valid or invalid) within 60 seconds from the same IP, it blocks the source IP from connecting to port 22 for 5 minutes. SSH only logs the first three invalid connects and iptables logs the special message of "SSH-Attack:" once, then it shuts down the IP for 5 minutes. By the time 5 minutes expires the cracker has given up and moved on to a different box. (maybe yours? :) These rules be a problem if I do a bunch of "scp" commands in a short amount of time, but I'm aware of this and it's usually not a problem. I also bypass my primary workstation from this test, so I only have to worry about connecting too frequently when I'm home or "on the road". And sure, someone could DoS me from SSH'ing into that box, but it's highly unlikely since I do it so infrequently, and they'd have to know the random IP I get at home, or on the road. BTW, the "recent" module can be used to create a port-knocking setup too, which I may play with next ... - BS |
From: <Her...@sp...> - 2005-02-24 15:23:29
|
> BTW, the "recent" module can be used to create a port-knocking setup > too, which I may play with next ... WOW!!! I'd love to see that!! Herbert > > - BS > > > > > ------------------------------------------------------- > 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 |
From: Tim <t....@co...> - 2005-03-01 17:34:24
|
Bruce Smith wrote: >>>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? >>> >>> >>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. >> >> > >You can do limited automated blocking under some circumstances if you're >careful. > >For example, look at the logs for a machine with an open SSH port to the >internet. I'm being hit with dictionary attacks trying to guess a valid >SSH login on all my boxes that allow SSH (and I bet you are too). > >You can "solve" the problem by not allowing password authentication >(only allowing RSA/DSA keys or some better method), but it doesn't stop >crackers from trying to login anyway (and filling your logs with crap). >So I started playing with some iptables rules ... > >Here are my rules from a web/ftp server - only one NIC - NOT a firewall: >(some IP numbers in the following example have been changed) > >------------------------------------------------------------------------------------- >${IPTABLES} -P INPUT DROP >${IPTABLES} -P OUTPUT ACCEPT >${IPTABLES} -P FORWARD DROP > ># special handling for SSH (to dwarf SSH dictionary attacks) >${IPTABLES} -N SSH-attack >${IPTABLES} -A SSH-attack -m recent --name SSHattack --set -j LOG --log-level DEBUG --log-prefix "SSH-attack: " >${IPTABLES} -A SSH-attack -j DROP ># >${IPTABLES} -N SSH >${IPTABLES} -A SSH -s 192.168.1.22 -j ACCEPT # allow my desktop without restriction >${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHattack --rcheck --seconds 300 -j DROP >${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --rcheck --seconds 60 --hitcount 3 -j SSH-attack >${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --set >${IPTABLES} -A SSH -p TCP --syn -j ACCEPT > ># Local interface - do not delete! >${IPTABLES} -A INPUT -i lo -j ACCEPT > ># Allow established connections. >${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > ># Allow all Pings, FTP, HTTP, NTP >${IPTABLES} -A INPUT -p icmp -j ACCEPT >${IPTABLES} -A INPUT -p tcp -i ${OUT_DEV} -m mport --ports 20:21,80 -j ACCEPT >${IPTABLES} -A INPUT -p udp -i ${OUT_DEV} -s 192.168.1.0/24 --dport 123 -j ACCEPT > ># special SSH connection limiting >${IPTABLES} -A INPUT -p tcp --dport 22 -i ${OUT_DEV} -j SSH >${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "INPUT policy: " --log-level DEBUG >------------------------------------------------------------------------------------- > >It _always_ allows the standard services of the box (HTTP, FTP, etc.) >so they CANNOT be DoS'ed no matter what. It also allows established SSH >connections to keep running, even if new connections are blocked from >the same IP address. > >If it receives more than 3 SSH new connects (valid or invalid) within 60 >seconds from the same IP, it blocks the source IP from connecting to >port 22 for 5 minutes. SSH only logs the first three invalid connects >and iptables logs the special message of "SSH-Attack:" once, then it >shuts down the IP for 5 minutes. By the time 5 minutes expires the >cracker has given up and moved on to a different box. (maybe yours? :) > >These rules be a problem if I do a bunch of "scp" commands in a short >amount of time, but I'm aware of this and it's usually not a problem. > >I also bypass my primary workstation from this test, so I only have to >worry about connecting too frequently when I'm home or "on the road". > >And sure, someone could DoS me from SSH'ing into that box, but it's >highly unlikely since I do it so infrequently, and they'd have to know >the random IP I get at home, or on the road. > >BTW, the "recent" module can be used to create a port-knocking setup >too, which I may play with next ... > > - BS > > > > SSH is over TCP, so if the attacker actually wants to send password attempts, they can't forge their return IP can they? Therefore sites failing logon numerous times could be blocked completely without fear of DOS attack? Tim |
From: Les G. <le...@to...> - 2005-03-01 18:36:55
|
Tim wrote: > Bruce Smith wrote: > >>>> 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? >>>> >>> >>> 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. >>> >> >> >> You can do limited automated blocking under some circumstances if you're >> careful. >> >> For example, look at the logs for a machine with an open SSH port to the >> internet. I'm being hit with dictionary attacks trying to guess a valid >> SSH login on all my boxes that allow SSH (and I bet you are too). >> >> You can "solve" the problem by not allowing password authentication >> (only allowing RSA/DSA keys or some better method), but it doesn't stop >> crackers from trying to login anyway (and filling your logs with >> crap). So I started playing with some iptables rules ... >> >> Here are my rules from a web/ftp server - only one NIC - NOT a firewall: >> (some IP numbers in the following example have been changed) >> >> ------------------------------------------------------------------------------------- >> >> ${IPTABLES} -P INPUT DROP >> ${IPTABLES} -P OUTPUT ACCEPT >> ${IPTABLES} -P FORWARD DROP >> >> # special handling for SSH (to dwarf SSH dictionary attacks) >> ${IPTABLES} -N SSH-attack >> ${IPTABLES} -A SSH-attack -m recent --name SSHattack --set -j LOG >> --log-level DEBUG --log-prefix "SSH-attack: " >> ${IPTABLES} -A SSH-attack -j DROP >> # >> ${IPTABLES} -N SSH >> ${IPTABLES} -A SSH -s 192.168.1.22 -j ACCEPT # allow my >> desktop without restriction >> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHattack --rcheck >> --seconds 300 -j DROP >> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --rcheck >> --seconds 60 --hitcount 3 -j SSH-attack >> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --set >> ${IPTABLES} -A SSH -p TCP --syn -j ACCEPT >> >> # Local interface - do not delete! >> ${IPTABLES} -A INPUT -i lo -j ACCEPT >> >> # Allow established connections. >> ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >> >> # Allow all Pings, FTP, HTTP, NTP >> ${IPTABLES} -A INPUT -p icmp -j ACCEPT >> ${IPTABLES} -A INPUT -p tcp -i ${OUT_DEV} -m mport --ports 20:21,80 -j >> ACCEPT >> ${IPTABLES} -A INPUT -p udp -i ${OUT_DEV} -s 192.168.1.0/24 --dport >> 123 -j ACCEPT >> >> # special SSH connection limiting >> ${IPTABLES} -A INPUT -p tcp --dport 22 -i ${OUT_DEV} -j SSH >> ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG >> --log-prefix "INPUT policy: " --log-level DEBUG >> ------------------------------------------------------------------------------------- >> >> >> It _always_ allows the standard services of the box (HTTP, FTP, etc.) >> so they CANNOT be DoS'ed no matter what. It also allows established SSH >> connections to keep running, even if new connections are blocked from >> the same IP address. >> >> If it receives more than 3 SSH new connects (valid or invalid) within 60 >> seconds from the same IP, it blocks the source IP from connecting to >> port 22 for 5 minutes. SSH only logs the first three invalid connects >> and iptables logs the special message of "SSH-Attack:" once, then it >> shuts down the IP for 5 minutes. By the time 5 minutes expires the >> cracker has given up and moved on to a different box. (maybe yours? :) >> >> These rules be a problem if I do a bunch of "scp" commands in a short >> amount of time, but I'm aware of this and it's usually not a problem. >> >> I also bypass my primary workstation from this test, so I only have to >> worry about connecting too frequently when I'm home or "on the road". >> >> And sure, someone could DoS me from SSH'ing into that box, but it's >> highly unlikely since I do it so infrequently, and they'd have to know >> the random IP I get at home, or on the road. >> >> BTW, the "recent" module can be used to create a port-knocking setup >> too, which I may play with next ... >> >> - BS >> >> >> >> > SSH is over TCP, so if the attacker actually wants to send password > attempts, they can't forge their return IP can they? Therefore sites > failing logon numerous times could be blocked completely without fear of > DOS attack? > > Tim > > Well, yes, if you assume that the purpose of the attack is to gain access. If I merely want to DoS the SSH server, then I don't care if the access denied packets go into the bit bucket; it's the automatic blocking of the (forged) IP that is of interest to me. Les |
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 |
From: Dan S. <str...@dc...> - 2005-02-23 18:19:53
|
I've always considered this sort of thing a bad idea. Setting off some alarms is perfectly appropriate, but if you're running something against the "attacking" machine, someone could spoof an attack to make it look like it came from another machine they -really- want to target - in which case they have a pretty easy distributed denial of service attack - or worse. On Wed, 2005-02-23 at 10:22 -0500, Onsite Services 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. >=20 >=20 > On Wed, 23 Feb 2005 07:44:12 -0600, Heiko Zuerker <he...@zu...> wro= te: > > David wrote: > >=20 > > > I have been following off & on for a while. Adding Bits & Pieces woul= d > > > be cool, do you think it would be possible to make DL reactive. If it > > > could be made truly reactive what would we use to do it. Any caveats > > > or liability involved with this. > > > > >=20 > > What do you mean by making DL reactive? > >=20 > > -- > >=20 > > Regards > > Heiko Zuerker > > http://www.devil-linux.org > >=20 > > ------------------------------------------------------- > > 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=3D6595&alloc_id=3D14396&op=3Dclick > > _______________________________________________ > > Devil-linux-discuss mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > >=20 >=20 >=20 |
From: Heiko Z. <he...@zu...> - 2005-02-23 21:17:40
|
> 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. Nothing like that will ever go into DL, since it doesn't make sense to attack an attacker, you'll just get more attention. The only thing which would make sense is auto-blocking of attackers, but this has too many down sides too. For example a DoS is very easy if you implemented it. -- Regards Heiko Zuerker http://www.devil-linux.org |
From: Tim <t....@co...> - 2005-03-02 04:28:56
|
Les Gondor wrote: > > > Tim wrote: > >> Bruce Smith wrote: >> >>>>> 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? >>>>> >>>> >>>> >>>> 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. >>>> >>> >>> >>> >>> You can do limited automated blocking under some circumstances if you're >>> careful. >>> >>> For example, look at the logs for a machine with an open SSH port to the >>> internet. I'm being hit with dictionary attacks trying to guess a valid >>> SSH login on all my boxes that allow SSH (and I bet you are too). >>> >>> You can "solve" the problem by not allowing password authentication >>> (only allowing RSA/DSA keys or some better method), but it doesn't stop >>> crackers from trying to login anyway (and filling your logs with >>> crap). So I started playing with some iptables rules ... >>> >>> Here are my rules from a web/ftp server - only one NIC - NOT a firewall: >>> (some IP numbers in the following example have been changed) >>> >>> ------------------------------------------------------------------------------------- >>> >>> ${IPTABLES} -P INPUT DROP >>> ${IPTABLES} -P OUTPUT ACCEPT >>> ${IPTABLES} -P FORWARD DROP >>> >>> # special handling for SSH (to dwarf SSH dictionary attacks) >>> ${IPTABLES} -N SSH-attack >>> ${IPTABLES} -A SSH-attack -m recent --name SSHattack --set -j LOG >>> --log-level DEBUG --log-prefix "SSH-attack: " >>> ${IPTABLES} -A SSH-attack -j DROP >>> # >>> ${IPTABLES} -N SSH >>> ${IPTABLES} -A SSH -s 192.168.1.22 -j ACCEPT # allow my >>> desktop without restriction >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHattack --rcheck >>> --seconds 300 -j DROP >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --rcheck >>> --seconds 60 --hitcount 3 -j SSH-attack >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --set >>> ${IPTABLES} -A SSH -p TCP --syn -j ACCEPT >>> >>> # Local interface - do not delete! >>> ${IPTABLES} -A INPUT -i lo -j ACCEPT >>> >>> # Allow established connections. >>> ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >>> >>> # Allow all Pings, FTP, HTTP, NTP >>> ${IPTABLES} -A INPUT -p icmp -j ACCEPT >>> ${IPTABLES} -A INPUT -p tcp -i ${OUT_DEV} -m mport --ports 20:21,80 >>> -j ACCEPT >>> ${IPTABLES} -A INPUT -p udp -i ${OUT_DEV} -s 192.168.1.0/24 --dport >>> 123 -j ACCEPT >>> >>> # special SSH connection limiting >>> ${IPTABLES} -A INPUT -p tcp --dport 22 -i ${OUT_DEV} -j SSH >>> ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG >>> --log-prefix "INPUT policy: " --log-level DEBUG >>> ------------------------------------------------------------------------------------- >>> >>> >>> It _always_ allows the standard services of the box (HTTP, FTP, etc.) >>> so they CANNOT be DoS'ed no matter what. It also allows established SSH >>> connections to keep running, even if new connections are blocked from >>> the same IP address. >>> >>> If it receives more than 3 SSH new connects (valid or invalid) within 60 >>> seconds from the same IP, it blocks the source IP from connecting to >>> port 22 for 5 minutes. SSH only logs the first three invalid connects >>> and iptables logs the special message of "SSH-Attack:" once, then it >>> shuts down the IP for 5 minutes. By the time 5 minutes expires the >>> cracker has given up and moved on to a different box. (maybe yours? :) >>> >>> These rules be a problem if I do a bunch of "scp" commands in a short >>> amount of time, but I'm aware of this and it's usually not a problem. >>> >>> I also bypass my primary workstation from this test, so I only have to >>> worry about connecting too frequently when I'm home or "on the road". >>> >>> And sure, someone could DoS me from SSH'ing into that box, but it's >>> highly unlikely since I do it so infrequently, and they'd have to know >>> the random IP I get at home, or on the road. >>> >>> BTW, the "recent" module can be used to create a port-knocking setup >>> too, which I may play with next ... >>> >>> - BS >>> >>> >>> >>> >> SSH is over TCP, so if the attacker actually wants to send password >> attempts, they can't forge their return IP can they? Therefore sites >> failing logon numerous times could be blocked completely without fear >> of DOS attack? >> >> Tim >> >> > > Well, yes, if you assume that the purpose of the attack is to gain > access. If I merely want to DoS the SSH server, then I don't care if the > access denied packets go into the bit bucket; it's the automatic > blocking of the (forged) IP that is of interest to me. > > Les > Yes, but the connection could never progress past the initial tcp handshake, never mind actually negotiate encryption and send login attempts unless the attacker acknowledges tcp packets from the DL box, right? And to get those packets, it needs to be capable of receiving at the IP address it is supposedly sending from right? Which implies that it is the real address, or perhaps it is on the same subnet and is stealing it, or perhaps a compromised router. So the potential for DOS seems limited to me. Tim |
From: Bruce S. <bw...@ar...> - 2005-03-02 16:03:49
|
> Yes, but the connection could never progress past the initial tcp > handshake, never mind actually negotiate encryption and send login > attempts unless the attacker acknowledges tcp packets from the DL box, > right? And to get those packets, it needs to be capable of receiving at > the IP address it is supposedly sending from right? Which implies that > it is the real address, or perhaps it is on the same subnet and is > stealing it, or perhaps a compromised router. So the potential for DOS > seems limited to me. It doesn't work for every situation, but it works great for my needs. First someone could only DoS the maintenance port 22, occasional access (only I use port 22). Production ports (80, etc.) are always open. All of my desktops with static IP's are hard coded to ALLOW, so they can NEVER be DoS'ed. (where I connect from 99% of the time) When I'm traveling or at home I have a random IP. Someone trying to DoS me would have to know my current random IP, or they'd have to DoS the entire Internet IP range. They'd also have to know WHEN I'm trying to connect, since the DoS only lasts the timeout of 5 minutes. And since I only connect to this server from home/road a couple few a year, good luck DoS'ing me! I'll give you the IP if you want to try! :-) BTW, I don't see this is as a great security feature, I'm mainly doing it to screw with the bots trying dictionary login attacks on my boxes, and to keep the annoying invalid login messages out of my logs. I figure if I allow a couple attempts and then DROP their connections for five minutes, that'll cause their bot to hang for a TCP timeout. And any time they are hung, they are not attacking me or anyone else! - BS |