IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Common ploy by....
Overflowing a routers ARP Table... especially older ones that only have 2K or so to use.


What happens is that with routers that are possibly vulnerable due to "UN-attentive Administration" can be caused to restart themselves... which then reverts EVERYTHING cponnected to it to the same network until fully init'd. This is especially true with Real Routers that also do VLAN 802.1Q tagging as well as Layer-3 Switches posing as routers doing the VLAN taggin crap they *CAN* do.

The common ploy allows crackers to spoof things in that brief instant to get further along on a crack. I know I've used it to humble some admins that say thier CheckPoint Firewall is impervious... Well, when they change the default rule from anything other than REJECT, changing from Negative logic to Positive Logic or a combo of both as well as a bad order of rules... Well what you expect?

So, overall I see those errors alot on Misconfigured Public Interfaces and on Properly Configured Public Interfaces... just that someone is testing your Firewall... of course since your are Masqurading... and you have a *NIX machine in place... you should be good if they are testing... provided you have your rules right and config'd properly... Wrong Subnet mask still allows some trickery that few people would really catch, but yet allow info out or in.

The best part of the whole thing... unless you have remote logging enabled... The evidence is gone as soon as the router barfs and resets...

[link|mailto:curley95@attbi.com|greg] - Grand-Master Artist in IT
[link|http://www.iwethey.org/ed_curry/|REMEMBER ED CURRY!!!]

Your friendly Homeland Security Officer reminds:
Hold Thumbprint to Screen for 5 seconds, we'll take the imprint, or
Just continue to type on your keyboard, and we'll just sample your DNA.
New Re: Common ploy by....
gfolkert said:

The common ploy allows crackers to spoof things in that brief instant to get further along on a crack. I know I've used it to humble some admins that say thier CheckPoint Firewall is impervious... Well, when they change the default rule from anything other than REJECT, changing from Negative logic to Positive Logic or a combo of both as well as a bad order of rules... Well what you expect?

Yeah, what he said. The pity of it is that this is such an elementary, dumbass error: Practically the first thing you learn, in setting up routers, is that you should ensure that they reject everything as the very first step upon initialising the interfaces.

People don't realise that filtering routers are actually much trickier than application-level proxy gateways, in that sense. With the latter, only traffic that's been explicitly permitted will be handled at all. With the former, one little error with the rulesets, or a ruleset enacted only in the runtime state but not in the NVRAM, and you're vulnerable.

But routers with only 2K RAM should be dumpster fodder, no?

Rick Moen
rick@linuxmafia.com


If you lived here, you'd be $HOME already.
New Ok, what do you think of this firewall script?

I'm using ipchains on this one.

\r\n
\r\n
#!/bin/sh                                                                   \r\n                                                                            \r\n# This script sets up the NAT and firewall for the box, and is run when the \r\n# ppp connection to Bell comes up.                                          \r\n                                                                            \r\n/sbin/ipchains -A input -j ACCEPT -i ppp0 -s 0/0 67 -d 0/0 68 -p udp        \r\n                                                                            \r\n/sbin/depmod -a                                                             \r\n/sbin/modprobe ip_masq_ftp                                                  \r\n/sbin/modprobe ip_masq_raudio                                               \r\n                                                                            \r\necho "1" > /proc/sys/net/ipv4/ip_dynaddr                                    \r\necho "1" > /proc/sys/net/ipv4/ip_forward                                    \r\necho "1" > /proc/sys/net/ipv4/ip_always_defrag                              \r\necho "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose                            \r\n                                                                            \r\n/sbin/ipchains -M -S 7200 10 160                                            \r\n                                                                            \r\nipchains -F input                                                           \r\nipchains -F output                                                          \r\nipchains -F forward                                                         \r\n                                                                            \r\nipchains -P input ACCEPT                                                    \r\nipchains -P output ACCEPT                                                   \r\nipchains -P forward DENY                                                    \r\nipchains -A input -s 192.168.0.0/24 -i ppp0 -j DENY                         \r\nipchains -A input -s 127.0.0.0/8 -i ppp0 -j deny                            \r\nipchains -A forward -s 192.168.0.0/24 -i ppp0 -j MASQ                       \r\n

\r\n

I'd like to be able to set the policy of input deny, but whenever I do I end up being able to send things out by explicitly allowing input traffic from 192.168.0.0 to eth1 (internal interface) but I never get anything back as the incoming packets get killed.

At any rate... pointers on this one would be welcome. Thanks!

--\r\n-------------------------------------------------------------------\r\n* Jack Troughton                            jake at consultron.ca *\r\n* [link|http://consultron.ca|http://consultron.ca]                   [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\r\n* Laval Qu\ufffdbec Canada                   [link|news://news.consultron.ca|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
     Wierd Debian Networking problem - (jake123) - (32)
         Hmm - (deSitter) - (2)
             Brainstorm - (deSitter)
             Card... - (jake123)
         neighbor table overflow sounds like RIP problem -NT - (boxley) - (4)
             Newb to unix... what's RIP? - (jake123) - (3)
                 RIP is a routing protocol - (boxley)
                 Routing Interchange Protocol - (deSitter) - (1)
                     Re: Routing Interchange Protocol - (pwhysall)
         Re: Wierd Debian Networking problem - (pwhysall) - (20)
             ifconfig -a output: - (jake123) - (19)
                 eth1 is having collision issues and eth0 is not addressed -NT - (boxley) - (6)
                     Re: eth1 is having collision issues and eth0 is not addresse - (jake123) - (5)
                         Re: eth1 is having collision issues and eth0 is not addresse - (deSitter) - (4)
                             also swap the cable and see if it makes a difference -NT - (boxley)
                             This is using the mii-diag program, I take it? -NT - (jake123) - (2)
                                 Re: This is using the mii-diag program, I take it? - (deSitter) - (1)
                                     :) - (jake123)
                 Re: ifconfig -a output: - (rickmoen) - (11)
                     Yikes - (jake123) - (10)
                         Re: Yikes - (rickmoen) - (1)
                             Well, time will tell - (jake123)
                         Re: Yikes - (deSitter) - (7)
                             Debian thing? - (pwhysall) - (2)
                                 Slip of fingers? - (deSitter) - (1)
                                     Re: Slip of fingers? - (pwhysall)
                             Re: Yikes - (rickmoen) - (3)
                                 lo (and bug, incidentally) - (kmself) - (2)
                                     Re: lo (and bug, incidentally) - (jake123) - (1)
                                         Re: lo (and bug, incidentally) - (rickmoen)
         Common ploy by.... - (folkert) - (2)
             Re: Common ploy by.... - (rickmoen) - (1)
                 Ok, what do you think of this firewall script? - (jake123)

For Thanks-giv-ing we had ta-ters, suc-co-tash and ru-ta-ba-gas.
133 ms