Hmm.. Some problems I think. I went with what you said and put a drop line
right after the rate limit.. and it's having problems. It doesn't seem to
be allowing anything through. Here's the two lines - they are the first
two to be executed - that go into my iptables configuration. What's going
on?
iptables -A INPUT -i eth0 -p tcp --destination-port 22 \
-m limit --limit 6/hour --limit-burst 2
iptables -A INPUT -i eth0 -p tcp --destination-port 22 -j DROP
I tested this by trying to ssh in from a friend's server. First attempt to
connect and nothing happened.. what's going on?
<EOL>
Tib
On Tue, 25 Jan 2005, Tib wrote:
>
> OOOOOOH - I see I think.. the ones that get caught by the limit rule don't
> go to the drop rule, which means they're allowed to connect. The ones that
> don't get caught by the limit rule slip on through to the drop rule.
>
> See - my understanding of what the limit module was doing was completely
> off base! Now I understand what's going on.
>
> <EOL>
> Tib
>
> On Tue, 25 Jan 2005, Mark Moseley wrote:
>
> > It's used very often for logging, so that the logging doesn't swamp
> > the firewall's disk. Imagine you're dropping 100 packet/s and want to
> > log what's going on. You'd want to have the logging rule limited to
> > something like 1/s or whatever.
> >
> >
> >
> > On Tue, 25 Jan 2005 13:56:25 -0600 (CST), Tib <tib@xxxxxxxxxxxxxxx> wrote:
> > >
> > > You're kidding o_O
> > >
> > > I guess it makes sense.. the connections will trip that rule until it is
> > > satisfied and then move onto the next. That's.. bizarre.
> > >
> > > <EOL>
> > > Tib
> > >
> > > On Tue, 25 Jan 2005, Mark Moseley wrote:
> > >
> > > > Heh, forgot to CC the list on my original reply, sorry.
> > > >
> > > > Makes sense on the --limit-burst. :)
> > > >
> > > > As far as adding the DROP/REJECT after that, once the connection limit
> > > > in the --limit rule has been reached, it will simply just fall through
> > > > the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
> > > > So the rule with the --limit just matches up to the rate in --limit
> > > > and then doesn't match. Without a rule later on (or a policy to
> > > > DROP/REJECT), any overflow will just get accepted.
> > > >
> > > >
> > > >
> > > > > Yup - once I saw an example of someone USING the limit options it made
> > > > > sense :]
> > > > >
> > > > > The only thing --limit-burst does is say 'you have x many free tries
> > > > > before you fall under the rate limit of Y/time restrictions'.
> > > > >
> > > > > So on mine, you can effectively connect twice in short succession before
> > > > > you are cut back to once every 10 minutes (6 per hour).
> > > > >
> > > > > > Be sure to add a DROP or REJECT on the same match (unless the default
> > > > > > policy is already that).
> > > > >
> > > > > I don't follow why to do this - explain?
> > > > >
> > > > > <EOL>
> > > > > Tib
> > > > >
> > > >
> > >
> >
>
