iptables question - Slackware

This is a discussion on iptables question - Slackware ; trying to slow down people trying to ssh into my box and wasting bandwidth... got this from aols a while ago, but it doesn't seem to be working: iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: iptables question

  1. iptables question

    trying to slow down people trying to ssh into my box and wasting
    bandwidth...

    got this from aols a while ago, but it doesn't seem to be working:

    iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    extgateway -m recent --update --seconds 15 -j DROP

    suggestions?
    I've read the man page and get overwhelmed by the options list... the
    more I look at it, the less sure I am about how correct it is...

    Ray

  2. Re: iptables question

    Ray wrote:
    > trying to slow down people trying to ssh into my box and wasting
    > bandwidth...
    >
    > got this from aols a while ago, but it doesn't seem to be working:
    >
    > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    > extgateway -m recent --update --seconds 15 -j DROP
    >
    > suggestions?
    > I've read the man page and get overwhelmed by the options list... the
    > more I look at it, the less sure I am about how correct it is...
    >
    > Ray

    is extgateway supposed to be a variable ?
    if so it's missing the dollar sign $ in front of it: $extgateway

  3. Re: iptables question

    goarilla wrote:
    > Ray wrote:
    >> trying to slow down people trying to ssh into my box and wasting
    >> bandwidth...
    >>
    >> got this from aols a while ago, but it doesn't seem to be working:
    >>
    >> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >> extgateway -m recent --update --seconds 15 -j DROP
    >>
    >> suggestions?
    >> I've read the man page and get overwhelmed by the options list... the
    >> more I look at it, the less sure I am about how correct it is...
    >>
    >> Ray

    > is extgateway supposed to be a variable ?
    > if so it's missing the dollar sign $ in front of it: $extgateway


    extgateway is the replacement for the ip address of this box's default
    gateway. It's behind a firewall (Linksys router) if it matters - is it
    only seeing the IP of the firewall and thus never actually dropping the
    connection because the Linksys is doing NAT?

    Hmmm.

    If that's the case, other than a cron job that parses the log files once
    a minute and adds them to hosts.deny or something, what are my options?

    Ray

  4. Re: iptables question

    Ray wrote:
    > goarilla wrote:
    >> Ray wrote:
    >>> trying to slow down people trying to ssh into my box and wasting
    >>> bandwidth...
    >>>
    >>> got this from aols a while ago, but it doesn't seem to be working:
    >>>
    >>> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >>> extgateway -m recent --update --seconds 15 -j DROP
    >>>
    >>> suggestions?
    >>> I've read the man page and get overwhelmed by the options list... the
    >>> more I look at it, the less sure I am about how correct it is...
    >>>
    >>> Ray

    >> is extgateway supposed to be a variable ?
    >> if so it's missing the dollar sign $ in front of it: $extgateway

    >
    > extgateway is the replacement for the ip address of this box's default
    > gateway. It's behind a firewall (Linksys router) if it matters - is it
    > only seeing the IP of the firewall and thus never actually dropping the
    > connection because the Linksys is doing NAT?


    so yes it's a variable but i don' t know why you want to do this
    iirc your pc sends stuff through your default gateway in this case
    your linksys router only at the ethernet level headers eg mac address
    since they are part of your local network

    you're filtering on the tcp protocol in this case in which it still receives
    the real source address which is usually at your WAN side
    so in essence this is futile. run tcpdump or wireshark and you'll see
    what i mean

    > Hmmm.
    >
    > If that's the case, other than a cron job that parses the log files once
    > a minute and adds them to hosts.deny or something, what are my options?
    >
    > Ray


    i ain't no iptables guru i admit that's why i built on templates which
    can be found at http://www.slackwiki.org
    still i don't really know what you're trying to acomplish ... explain
    your goals more clearly please

  5. Re: iptables question

    On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:

    > trying to slow down people trying to ssh into my box and wasting
    > bandwidth...
    >
    > got this from aols a while ago, but it doesn't seem to be working:
    >
    > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    > extgateway -m recent --update --seconds 15 -j DROP
    >
    > suggestions?


    Is your "box" some server for open access thru ssh to anyone
    in the world? (I mean is this a wanted feature like being a GW?)
    If your "box" is, like I'd have supposed, a personal machine
    with maybe one to one hundred occasional users accessing to it
    thru the Internet your prefered solution will be to firstly use
    just the correct number of nails for the coffin and:
    deny any ssh in
    then
    allow @IPs in your users with fixed @IPs list
    occasionally build a VPN or a MASQ behind selected RFC1918
    @IPs you'd know how to manage within your frontal router.

    Also, enforce (that won't stop for long people able to
    easily pass your FW/router+BoxFW+AUTHs but that'll give you and
    your survey tools some time to be aware you're attacked) your
    user rules in the ssh config, like allowed accounts|@IPS,
    whatever can be used at a level you understand that *may*
    slow down any access trial just worths the pain.

    Remember password auth is the weakest link,
    especially if you're a server for real world users as they
    have a noticeable tendency to think that

    In short, when you're the only one to be accessing to your "box"
    you don't have to make it a secured open target, it's much safer
    to make it a LAN "box" and take care of the future openings within
    the net admin domain, not in the "box" admin area.

  6. Re: iptables question

    On Jun 28, 6:20 pm, loki harfagr wrote:
    > On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    > > trying to slow down people trying to ssh into my box and wasting
    > > bandwidth...

    >
    > > got this from aols a while ago, but it doesn't seem to be working:

    >
    > > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    > > extgateway -m recent --update --seconds 15 -j DROP

    >
    > > suggestions?

    >
    > Is your "box" some server for open access thru ssh to anyone
    > in the world? (I mean is this a wanted feature like being a GW?)
    > If your "box" is, like I'd have supposed, a personal machine
    > with maybe one to one hundred occasional users accessing to it
    > thru the Internet your prefered solution will be to firstly use
    > just the correct number of nails for the coffin and:
    > deny any ssh in
    > then
    > allow @IPs in your users with fixed @IPs list
    > occasionally build a VPN or a MASQ behind selected RFC1918
    > @IPs you'd know how to manage within your frontal router.
    >
    > Also, enforce (that won't stop for long people able to
    > easily pass your FW/router+BoxFW+AUTHs but that'll give you and
    > your survey tools some time to be aware you're attacked) your
    > user rules in the ssh config, like allowed accounts|@IPS,
    > whatever can be used at a level you understand that *may*
    > slow down any access trial just worths the pain.
    >
    > Remember password auth is the weakest link,
    > especially if you're a server for real world users as they
    > have a noticeable tendency to think that
    >
    > In short, when you're the only one to be accessing to your "box"
    > you don't have to make it a secured open target, it's much safer
    > to make it a LAN "box" and take care of the future openings within
    > the net admin domain, not in the "box" admin area.




    here is an iptables rules that i use.
    it will block the ip after a certain amount of attempts.

    #SSH flooding
    iptables -N mylimit
    iptables -A FORWARD -i eth0 -p tcp -m tcp --dport 22 -m state --state
    NEW -j mylimit
    iptables -A mylimit -m recent --update --seconds 3600 --name floods --
    rsource -j REJECT --reject-with icmp-port-unreachable
    iptables -A mylimit -m limit --limit 2/min --limit-burst 3 -j RETURN
    iptables -A mylimit -m recent --set --name floods --rsource -j REJECT
    --reject-with icmp-port-unreachable

    and you can tun teh limits etc/


  7. Re: iptables question

    On Jun 28, 7:33 pm, slackwaresupport
    wrote:
    > On Jun 28, 6:20 pm, loki harfagr wrote:
    >
    >
    >
    > > On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    > > > trying to slow down people trying to ssh into my box and wasting
    > > > bandwidth...

    >
    > > > got this from aols a while ago, but it doesn't seem to be working:

    >
    > > > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    > > > extgateway -m recent --update --seconds 15 -j DROP

    >
    > > > suggestions?

    >
    > > Is your "box" some server for open access thru ssh to anyone
    > > in the world? (I mean is this a wanted feature like being a GW?)
    > > If your "box" is, like I'd have supposed, a personal machine
    > > with maybe one to one hundred occasional users accessing to it
    > > thru the Internet your prefered solution will be to firstly use
    > > just the correct number of nails for the coffin and:
    > > deny any ssh in
    > > then
    > > allow @IPs in your users with fixed @IPs list
    > > occasionally build a VPN or a MASQ behind selected RFC1918
    > > @IPs you'd know how to manage within your frontal router.

    >
    > > Also, enforce (that won't stop for long people able to
    > > easily pass your FW/router+BoxFW+AUTHs but that'll give you and
    > > your survey tools some time to be aware you're attacked) your
    > > user rules in the ssh config, like allowed accounts|@IPS,
    > > whatever can be used at a level you understand that *may*
    > > slow down any access trial just worths the pain.

    >
    > > Remember password auth is the weakest link,
    > > especially if you're a server for real world users as they
    > > have a noticeable tendency to think that

    >
    > > In short, when you're the only one to be accessing to your "box"
    > > you don't have to make it a secured open target, it's much safer
    > > to make it a LAN "box" and take care of the future openings within
    > > the net admin domain, not in the "box" admin area.

    >
    > here is an iptables rules that i use.
    > it will block the ip after a certain amount of attempts.
    >
    > #SSH flooding
    > iptables -N mylimit
    > iptables -A FORWARD -i eth0 -p tcp -m tcp --dport 22 -m state --state
    > NEW -j mylimit
    > iptables -A mylimit -m recent --update --seconds 3600 --name floods --
    > rsource -j REJECT --reject-with icmp-port-unreachable
    > iptables -A mylimit -m limit --limit 2/min --limit-burst 3 -j RETURN
    > iptables -A mylimit -m recent --set --name floods --rsource -j REJECT
    > --reject-with icmp-port-unreachable
    >
    > and you can tun teh limits etc/




    also one thing you can do is move the port that ssh is listening on to
    something high.. ie.. 9800


  8. Re: iptables question

    On Thu, 28 Jun 2007 23:34:28 +0000, slackwaresupport wrote:

    > On Jun 28, 7:33 pm, slackwaresupport wrote:
    >> On Jun 28, 6:20 pm, loki harfagr wrote:
    >>
    >>
    >>
    >> > On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    >> > > trying to slow down people trying to ssh into my box and wasting
    >> > > bandwidth...

    >>
    >> > > got this from aols a while ago, but it doesn't seem to be working:

    >>
    >> > > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >> > > extgateway -m recent --update --seconds 15 -j DROP

    >>
    >> > > suggestions?

    >>
    >> > Is your "box" some server for open access thru ssh to anyone
    >> > in the world? (I mean is this a wanted feature like being a GW?)
    >> > If your "box" is, like I'd have supposed, a personal machine
    >> > with maybe one to one hundred occasional users accessing to it thru
    >> > the Internet your prefered solution will be to firstly use just the
    >> > correct number of nails for the coffin and: deny any ssh in
    >> > then
    >> > allow @IPs in your users with fixed @IPs list
    >> > occasionally build a VPN or a MASQ behind selected RFC1918
    >> > @IPs you'd know how to manage within your frontal router.

    >>
    >> > Also, enforce (that won't stop for long people able to
    >> > easily pass your FW/router+BoxFW+AUTHs but that'll give you and your
    >> > survey tools some time to be aware you're attacked) your user rules
    >> > in the ssh config, like allowed accounts|@IPS, whatever can be used
    >> > at a level you understand that *may* slow down any access trial just
    >> > worths the pain.

    >>
    >> > Remember password auth is the weakest link,
    >> > especially if you're a server for real world users as they have a
    >> > noticeable tendency to think that

    >>
    >> > In short, when you're the only one to be accessing to your "box"
    >> > you don't have to make it a secured open target, it's much safer to
    >> > make it a LAN "box" and take care of the future openings within the
    >> > net admin domain, not in the "box" admin area.

    >>
    >> here is an iptables rules that i use. it will block the ip after a
    >> certain amount of attempts.
    >>
    >> #SSH flooding
    >> iptables -N mylimit
    >> iptables -A FORWARD -i eth0 -p tcp -m tcp --dport 22 -m state --state
    >> NEW -j mylimit
    >> iptables -A mylimit -m recent --update --seconds 3600 --name floods --
    >> rsource -j REJECT --reject-with icmp-port-unreachable iptables -A
    >> mylimit -m limit --limit 2/min --limit-burst 3 -j RETURN iptables -A
    >> mylimit -m recent --set --name floods --rsource -j REJECT --reject-with
    >> icmp-port-unreachable
    >>
    >> and you can tun teh limits etc/

    >
    >
    >
    > also one thing you can do is move the port that ssh is listening on to
    > something high.. ie.. 9800


    That might not be such a good idea. Some ISPs give preference to
    packets for standard ports; connections to non-standard ones might run
    quite slow.




  9. Re: iptables question

    goarilla wrote:
    > Ray wrote:
    >> goarilla wrote:
    >>> Ray wrote:
    >>>> trying to slow down people trying to ssh into my box and wasting
    >>>> bandwidth...
    >>>>
    >>>> got this from aols a while ago, but it doesn't seem to be working:
    >>>>
    >>>> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >>>> extgateway -m recent --update --seconds 15 -j DROP

    >
    > i ain't no iptables guru i admit that's why i built on templates which
    > can be found at http://www.slackwiki.org
    > still i don't really know what you're trying to acomplish ... explain
    > your goals more clearly please


    extgateway is actually 169.254.100.4 on the box - I was obsfucating the IP.

    And what I'm trying to do is drop packets from people who have nothing
    better to do than try to ssh or ftp to this box 10,000 times in 24 hours.

    When I found the iptables line, it was supposed to drop the connection
    to ip "x" if they failed an ssh login for 15 seconds. This way if it's
    a legit user (me) you don't get totally dropped on the floor for typing
    your password wrong, but it also means that joe blow with a script can't
    pound the snot out of this box because it slows him down to one attempt
    every 15 seconds instead of about 15 attempts per second.

    Ray

  10. Re: iptables question

    loki harfagr wrote:
    > On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    >
    >> trying to slow down people trying to ssh into my box and wasting
    >> bandwidth...
    >>
    >> got this from aols a while ago, but it doesn't seem to be working:
    >>
    >> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >> extgateway -m recent --update --seconds 15 -j DROP
    >>
    >> suggestions?

    >
    > Is your "box" some server for open access thru ssh to anyone
    > in the world? (I mean is this a wanted feature like being a GW?)
    > If your "box" is, like I'd have supposed, a personal machine
    > with maybe one to one hundred occasional users accessing to it
    > thru the Internet your prefered solution will be to firstly use
    > just the correct number of nails for the coffin and:
    > deny any ssh in
    > then
    > allow @IPs in your users with fixed @IPs list
    > occasionally build a VPN or a MASQ behind selected RFC1918
    > @IPs you'd know how to manage within your frontal router.
    >


    I'd like to do that, but the connection we have at work may come from
    one of three IP ranges, and I'm on the dev side now and not the network
    side, so if there's any changes in addressing I won't know until I can't
    get in. And for my friends on cable/dsl in other towns, I don't know
    their IP address either, so I'm trying to avoid a bunch of manual config
    -I'll do it if I have to, it's just more of a PITA.

    fwiw, this box sits in a dmz inbetween two firewalls. I'm not paranoid,
    I just used to work as a sysadmin - I've seen logs... yikes.

    Ray

  11. Re: iptables question

    slackwaresupport wrote:
    >
    > here is an iptables rules that i use.
    > it will block the ip after a certain amount of attempts.
    >
    > #SSH flooding
    > iptables -N mylimit
    > iptables -A FORWARD -i eth0 -p tcp -m tcp --dport 22 -m state --state
    > NEW -j mylimit
    > iptables -A mylimit -m recent --update --seconds 3600 --name floods --
    > rsource -j REJECT --reject-with icmp-port-unreachable
    > iptables -A mylimit -m limit --limit 2/min --limit-burst 3 -j RETURN
    > iptables -A mylimit -m recent --set --name floods --rsource -j REJECT
    > --reject-with icmp-port-unreachable
    >
    > and you can tun teh limits etc/
    >


    ok, thanks. I'm going to replace mine with that.
    The log files will tell if it works or not...

  12. Re: iptables question

    On Fri, 29 Jun 2007 03:20:30 +0000, ray wrote:

    > loki harfagr wrote:
    >> On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    >>
    >>> trying to slow down people trying to ssh into my box and wasting
    >>> bandwidth...
    >>>
    >>> got this from aols a while ago, but it doesn't seem to be working:
    >>>
    >>> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >>> extgateway -m recent --update --seconds 15 -j DROP
    >>>
    >>> suggestions?

    >>
    >> Is your "box" some server for open access thru ssh to anyone
    >> in the world? (I mean is this a wanted feature like being a GW?)
    >> If your "box" is, like I'd have supposed, a personal machine
    >> with maybe one to one hundred occasional users accessing to it thru the
    >> Internet your prefered solution will be to firstly use just the correct
    >> number of nails for the coffin and: deny any ssh in
    >> then
    >> allow @IPs in your users with fixed @IPs list
    >> occasionally build a VPN or a MASQ behind selected RFC1918
    >> @IPs you'd know how to manage within your frontal router.
    >>
    >>

    > I'd like to do that, but the connection we have at work may come from
    > one of three IP ranges, and I'm on the dev side now and not the network
    > side, so if there's any changes in addressing I won't know until I can't
    > get in. And for my friends on cable/dsl in other towns, I don't know
    > their IP address either, so I'm trying to avoid a bunch of manual config
    > -I'll do it if I have to, it's just more of a PITA.


    OK, that's understandable :-)

    > fwiw, this box sits in a dmz inbetween two firewalls. I'm not paranoid,
    > I just used to work as a sysadmin - I've seen logs... yikes.


    OK, if it is then that you want to be a the very safe part you can use
    the usual trick 'slackwaresupport' posted (almost the usual one,
    his one was nicely set in a new independent table, that's nice :-)

    If you want to have fun with something that will really enforce the
    others (by selecting only high level and highly motivated
    attackers) you can also try "portknocking" technique, here's a
    paragraph I incorporate in most of my iptables scripts (and rarely
    activate, read the idea and you'll guess why )

    (mind the line wrapping, it'd make all this unreadable !)

    (
    As you can see it's here prompted desactivated, to activate
    just uncomment the lines starting with only two #
    )
    ################################################## ######################
    ################################################## ######################
    ###
    ### Port knocking
    ### _knock_knock(22,1111,2022,30033,5)
    ### would open port 22 if the sequence of three access using
    ### ports 1111 then 2022 then 30033 would be received with less than
    ### 5 seconds between each access.
    ###
    ###
    ## _knock_knock(sp,p1,p2,p3,tot) {
    ## ${IPTA} -N kc0
    ## ${IPTA} -N kc1
    ## ${IPTA} -N kc2
    ##
    ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $sp -m recent --rcheck --name portKnock --seconds $tot -j kc0
    ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p1 -m recent --name portKnock2 --set -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p2 -m recent --rcheck --name portKnock2 --seconds $tot -j kc1
    ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p3 -m recent --rcheck --name portKnock1 --seconds $tot -j kc2
    ##
    ## ${IPTA} -A kc0 -m recent --name portKnock --remove -j ACCEPT
    ##
    ## ${IPTA} -A kc1 -m recent --name portKnock2 --remove
    ## ${IPTA} -A kc1 -m recent --name portKnock1 --set -j DROP
    ##
    ## ${IPTA} -A kc2 -m recent --name portKnock1 --remove
    ## ${IPTA} -A kc2 -m recent --name portKnock --set -j DROP
    ##
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p1 - 1] -m recent --name portKnock2 --remove -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p1 + 1] -m recent --name portKnock2 --remove -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p2 - 1] -m recent --name portKnock1 --remove -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p2 + 1] -m recent --name portKnock1 --remove -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p3 - 1] -m recent --name portKnock --remove -j DROP
    ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p3 + 1] -m recent --name portKnock --remove -j DROP
    ## }
    ################################################## ######################
    ################################################## ######################

  13. Re: iptables question

    loki harfagr wrote:
    > On Fri, 29 Jun 2007 03:20:30 +0000, ray wrote:
    >
    >> loki harfagr wrote:
    >>> On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    >>>
    >>>> trying to slow down people trying to ssh into my box and wasting
    >>>> bandwidth...
    >>>>
    >>>> got this from aols a while ago, but it doesn't seem to be working:
    >>>>
    >>>> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >>>> extgateway -m recent --update --seconds 15 -j DROP
    >>>>
    >>>> suggestions?
    >>> Is your "box" some server for open access thru ssh to anyone
    >>> in the world? (I mean is this a wanted feature like being a GW?)
    >>> If your "box" is, like I'd have supposed, a personal machine
    >>> with maybe one to one hundred occasional users accessing to it thru the
    >>> Internet your prefered solution will be to firstly use just the correct
    >>> number of nails for the coffin and: deny any ssh in
    >>> then
    >>> allow @IPs in your users with fixed @IPs list
    >>> occasionally build a VPN or a MASQ behind selected RFC1918
    >>> @IPs you'd know how to manage within your frontal router.
    >>>
    >>>

    >> I'd like to do that, but the connection we have at work may come from
    >> one of three IP ranges, and I'm on the dev side now and not the network
    >> side, so if there's any changes in addressing I won't know until I can't
    >> get in. And for my friends on cable/dsl in other towns, I don't know
    >> their IP address either, so I'm trying to avoid a bunch of manual config
    >> -I'll do it if I have to, it's just more of a PITA.

    >
    > OK, that's understandable :-)
    >
    >> fwiw, this box sits in a dmz inbetween two firewalls. I'm not paranoid,
    >> I just used to work as a sysadmin - I've seen logs... yikes.

    >
    > OK, if it is then that you want to be a the very safe part you can use
    > the usual trick 'slackwaresupport' posted (almost the usual one,
    > his one was nicely set in a new independent table, that's nice :-)
    >
    > If you want to have fun with something that will really enforce the
    > others (by selecting only high level and highly motivated
    > attackers) you can also try "portknocking" technique, here's a
    > paragraph I incorporate in most of my iptables scripts (and rarely
    > activate, read the idea and you'll guess why )
    >
    > (mind the line wrapping, it'd make all this unreadable !)
    >
    > (
    > As you can see it's here prompted desactivated, to activate
    > just uncomment the lines starting with only two #
    > )
    > ################################################## ######################
    > ################################################## ######################
    > ###
    > ### Port knocking
    > ### _knock_knock(22,1111,2022,30033,5)
    > ### would open port 22 if the sequence of three access using
    > ### ports 1111 then 2022 then 30033 would be received with less than
    > ### 5 seconds between each access.
    > ###
    > ###
    > ## _knock_knock(sp,p1,p2,p3,tot) {
    > ## ${IPTA} -N kc0
    > ## ${IPTA} -N kc1
    > ## ${IPTA} -N kc2
    > ##
    > ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $sp -m recent --rcheck --name portKnock --seconds $tot -j kc0
    > ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p1 -m recent --name portKnock2 --set -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p2 -m recent --rcheck --name portKnock2 --seconds $tot -j kc1
    > ## ${IPTA} -A INPUT -m state --state NEW -p tcp --dport $p3 -m recent --rcheck --name portKnock1 --seconds $tot -j kc2
    > ##
    > ## ${IPTA} -A kc0 -m recent --name portKnock --remove -j ACCEPT
    > ##
    > ## ${IPTA} -A kc1 -m recent --name portKnock2 --remove
    > ## ${IPTA} -A kc1 -m recent --name portKnock1 --set -j DROP
    > ##
    > ## ${IPTA} -A kc2 -m recent --name portKnock1 --remove
    > ## ${IPTA} -A kc2 -m recent --name portKnock --set -j DROP
    > ##
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p1 - 1] -m recent --name portKnock2 --remove -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p1 + 1] -m recent --name portKnock2 --remove -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p2 - 1] -m recent --name portKnock1 --remove -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p2 + 1] -m recent --name portKnock1 --remove -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p3 - 1] -m recent --name portKnock --remove -j DROP
    > ## ${IPTA} -A INPUT -m state --state NEW -m tcp -p tcp --dport $[p3 + 1] -m recent --name portKnock --remove -j DROP
    > ## }
    > ################################################## ######################
    > ################################################## ######################


    that would be really cool if I could get it to work from work - the
    number of outbound ports that are open is limited - 20,21,22,34,80,443
    is pretty much it.
    And because I don't work on the systems side anymore, I probably won't
    have much luck getting them to open other ports. (I'm running VNC over
    443 when I need it...)

    Ray

  14. Re: iptables question

    On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:

    > trying to slow down people trying to ssh into my box and wasting
    > bandwidth...
    >
    > got this from aols a while ago, but it doesn't seem to be working:
    >
    > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    > extgateway -m recent --update --seconds 15 -j DROP
    >
    > suggestions?
    > I've read the man page and get overwhelmed by the options list... the
    > more I look at it, the less sure I am about how correct it is...
    >


    The above rule will drop NEW packets from sources that are registered in
    the "recent" list in the last 15 seconds. You don't have a rule that puts
    the entries into the recent list. Here is what I am using.

    IPT=/usr/sbin/iptables
    # allow only one attempt to log in to sshd every 60 sec
    $IPT -A INPUT -p tcp -i eth0 -m state --state NEW --dport ssh \
    -m recent --update --seconds 60 -j DROP
    $IPT -A INPUT -p tcp -i eth0 -m state --state NEW --dport ssh \
    -m recent --set -j ACCEPT

    The first attempt to contact will activate the second rule and this will
    set the recent list. A second attempt to contact will then trip the
    first rule. Look in "man iptables" and search for "recent". To check that
    it's working you can look at the recent list with,

    less /proc/net/ipt_recent/DEFAULT

    You should also check that the ipt_recent module is loaded.

    As a variation on the above,
    ## alternatively, rate limit the ssh connections to allow three
    # attempts to login.
    #$IPT -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW \
    # -m recent --hitcount 3 --seconds 180 --update -j DROP
    #$IPT -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW \
    # -m recent --set -j ACCEPT

    Mike

  15. Re: iptables question

    Mike Denhoff wrote:
    > On Thu, 28 Jun 2007 14:00:28 -0500, Ray wrote:
    >
    >> trying to slow down people trying to ssh into my box and wasting
    >> bandwidth...
    >>
    >> got this from aols a while ago, but it doesn't seem to be working:
    >>
    >> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -s
    >> extgateway -m recent --update --seconds 15 -j DROP
    >>
    >> suggestions?
    >> I've read the man page and get overwhelmed by the options list... the
    >> more I look at it, the less sure I am about how correct it is...
    >>

    >
    > The above rule will drop NEW packets from sources that are registered in
    > the "recent" list in the last 15 seconds. You don't have a rule that puts
    > the entries into the recent list. Here is what I am using.
    >
    > IPT=/usr/sbin/iptables
    > # allow only one attempt to log in to sshd every 60 sec
    > $IPT -A INPUT -p tcp -i eth0 -m state --state NEW --dport ssh \
    > -m recent --update --seconds 60 -j DROP
    > $IPT -A INPUT -p tcp -i eth0 -m state --state NEW --dport ssh \
    > -m recent --set -j ACCEPT
    >
    > The first attempt to contact will activate the second rule and this will
    > set the recent list. A second attempt to contact will then trip the
    > first rule. Look in "man iptables" and search for "recent". To check that
    > it's working you can look at the recent list with,
    >
    > less /proc/net/ipt_recent/DEFAULT
    >
    > You should also check that the ipt_recent module is loaded.
    >
    > As a variation on the above,
    > ## alternatively, rate limit the ssh connections to allow three
    > # attempts to login.
    > #$IPT -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW \
    > # -m recent --hitcount 3 --seconds 180 --update -j DROP
    > #$IPT -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW \
    > # -m recent --set -j ACCEPT
    >
    > Mike


    ahh... that helps clear things up. I buggered up the copy & paste.
    iptables is on the "to learn in detail" pile, but in the meantime, I
    just want it to work.

  16. Re: iptables question

    Ray trolled:
    > ahh... that helps clear things up. I buggered up the copy & paste.


    The copy & paste? That's the linux gui system. Pretty hard to
    bugger that up.

    > iptables is on the "to learn in detail" pile, but in the meantime, I
    > just want it to work.


    Sometimes menus are a blessing, aren't they?

    cordially, as always,

    rm

  17. Re: iptables question

    On 2007-06-29, Ray wrote:

    > iptables is on the "to learn in detail" pile, but in the meantime, I
    > just want it to work.


    Try arno's iptables-firewall script. Read the help/installation for
    quick setup. This will allow you to learn about iptables and bash
    scripting while your system is locked down pretty damned tight (all
    blocked). A few easy script edits opens ports you want like web
    access, email, etc, which it defaults to statefull inspection mode.

    http://rocky.molphys.leidenuniv.nl/

    nb


  18. Re: iptables question

    On Thu, 28 Jun 2007 14:00:28 -0500
    Ray wrote:

    > trying to slow down people trying to ssh into my box and wasting
    > bandwidth...

    ....
    > suggestions?


    http://slackworld.berlios.de/04/tips.html#ssh_attacks

    M.

+ Reply to Thread