April 2017

S M T W T F S
      1
2345678
910111213 1415
16171819 2021 22
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags

April 12th, 2010

marcmagus: Me playing cribbage in regency attire (Default)
Monday, April 12th, 2010 02:18 pm

I now have 0 living grandparents.

marcmagus: (regexp)
Monday, April 12th, 2010 09:25 pm

Seem to have solved the problem where the wireless would drop connection after a few seconds. Apparently it had something to do with the 802.11 rate control algorithm [I was using the PID algorithm as recommended by the kernel docs; switching to Minstrel and compiling out PID seems to have fixed things. Go figure.].

Once I got things working properly, it took kismet about 2 hours to break my neighbor's WEP using the included passive WEP-breaking algorithm. That's the "I'm not doing anything except listening to what's going over the air and figuring it out from that" approach. The implication is that there are things you can do to make it a lot faster. This algorithm depends on how much traffic is going on over the wireless. There was very little. The moral of this story is that WEP sucks. But we knew that already.

That accomplished, I had an outside computer (my netbook) to test my new iptables configuration. This starts dropping attempts to create new ssh connections once you exceed an average of 3/minute. Hopefully this will slow down people pounding at the gate enough to encourage them to look elsewhere and stop wasting my time.

# Rate limit incoming SSH
iptables -I FORWARD 7 -p tcp --dport 22 -j logdrop
iptables -I FORWARD 7 -p tcp --dport 22 -m state --state NEW -m limit --limit "3/min" --limit-burst 3 -j ACCEPT

[Note that this is inserting at 7 so it's just after the line which accepts all RELATED or ESTABLISHED packets. If the DD-WRT configurations moves things around, this will have to be fiddled with. That could be exciting.]