Re: ipf stopped working on 5.3

From: John Fitzgerald (jjfitzgerald_at_gmail.com)
Date: 10/26/05

  • Next message: Nathan Goulding: "Re: ipf stopped working on 5.3"
    Date: Wed, 26 Oct 2005 13:12:59 -0400
    To: "ray@redshift.com" <ray@redshift.com>
    
    

    Another strange symptom is that if I ipf -D and then ipf -E -f
    /etc/ipf.rules, my terminal (I'm remote) will freeze and I'll be forced to
    power cycle the server, after which time it will come back up (with no rules
    running). I'm assuming that after the ipf -E -f /etc/ipf.rules somehow the
    firewall stops all traffic since apache won't respond to web requests
    either.

    As a side note, I did put the sshd server listening on an obscure port so it
    should take awhile for the bots to find it. The ipf.rules I left at 22 as a
    testament to it not working. However this obviously isn't a permanent
    solution as I should be able to get ipf working.

    JJ

    On 10/26/05, John Fitzgerald <jjfitzgerald@gmail.com> wrote:
    >
    > Hi Ray,
    >
    > Here's a cleaned up version of ipf.rules:
    >
    >
    > #--------------------------------------------------------------------------
    > # block nasty packets
    > #--------------------------------------------------------------------------
    >
    > block in log quick all with short
    > block in log quick all with opt lsrr
    > block in log quick all with opt ssrr
    >
    >
    > #--------------------------------------------------------------------------
    > # loopback packets left alone
    >
    > #--------------------------------------------------------------------------
    > pass in log quick on lo0 all
    > pass out log quick on lo0 all
    >
    > #--------------------------------------------------------------------------
    >
    > # 100 incoming bge0
    > # 150 outgoing bge0
    >
    > #--------------------------------------------------------------------------
    > block in log on bge0 all head 10
    > block in log on bge0 all head 100
    > block out log on bge0 all head 150
    >
    >
    > #--------------------------------------------------------------------------
    > # allow all traffic to 80 and 443
    >
    > #--------------------------------------------------------------------------
    > pass in log quick proto tcp from any to any port = 80 flags S/SA keep
    > state
    > pass in log quick proto tcp from any to any port = 443 flags S/SA keep
    > state
    >
    >
    > #--------------------------------------------------------------------------
    > # allow only traffic from known hosts to localhost:ssh
    >
    > #--------------------------------------------------------------------------
    > pass in log quick proto tcp from MY_FIRST_HOST to any port = 22 flags S/SA
    > keep state
    > pass in log quick proto tcp from MY_SECOND_HOST to any port = 22 flags
    > S/SA keep state
    >
    >
    > #--------------------------------------------------------------------------
    > # allow outgoing keystrokes and syslog to logger
    >
    > #--------------------------------------------------------------------------
    > pass out log quick proto udp from any to MY_LOGGER port = 514 group 150
    >
    >
    > #--------------------------------------------------------------------------
    > # block all other outgoing traffic
    >
    > #--------------------------------------------------------------------------
    > block out log quick from any to any group 100
    >
    >
    > #--------------------------------------------------------------------------
    > # block all
    >
    > #--------------------------------------------------------------------------
    > block in log quick on bge0 all
    >
    > The group 10 is for my script to block ip's on the fly. I think someone
    > from the FreeBSD Diary wrote a script that I use when attacks come in. I
    > suppose I could use 100 for that, but I just used 10 to separate and I think
    > that's what the example used. Probably not the best ipf.rules but it
    > (seemed) to work.
    >
    > JJ
    >
    >
    > On 10/26/05, ray@redshift.com < ray@redshift.com> wrote:
    > >
    > > At 01:32 PM 10/25/2005 -0400, John Fitzgerald wrote:
    > > | I've had ipf working on a few 5.3 servers for quite awhile. Not too
    > > long ago
    > > | some developers had to do some coding work and were coming from
    > > dynamic
    > > | IP's. I (reluctantly) opened up SSH to the world. Immediately I
    > > started
    > > | seeing the attacks where bots of some sort would try to break in with
    > > a
    > > | variety of different users.
    > > |
    > > | So, I (thought) I closed it up again and told the developers to use a
    > > | dedicated proxy. They did, but I realized that I hadn't actually
    > > closed
    > > | things off. I was still getting attacked. I had tried, but ipf
    > > suddenly
    > > | wasn't working. Whenever I would change the firewall rules and ipf -D
    > > and
    > > | the ipf -E -f /etc/my.rules it would simply return:
    > > |
    > > | 1:ioctl(add/insert rule): No such process
    > > |
    > > | I didn't have the time to look into it at the time, but am now trying
    > > to
    > > | figure it out. Ipf is obviously not working and I don't know why. I
    > > have
    > > | tried recompiling the kernel a myriad of different ways. With/without
    > > ipfw,
    > > | with/without ipsec, etc. All to no avail. Is this a bug, did I get
    > > hacked?
    > > |
    > > | I have googled this quite a bit and the only thing that I found was
    > > possibly
    > > | a buildworld scenario where something got updated and it doesn't work
    > > now. I
    > > | didn't install src so I'm a bit out of luck on that one.
    > > |
    > > | FreeBSD 5.3-RELEASE
    > > | OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7d 17 Mar 2004
    > > |
    > >
    > > usually that means you are trying to run it without being root, or you
    > > have a
    > > rule that doesn't belong to a group/head.
    > >
    > > I ran into something else once that caused that, but now I can't
    > > remember it.
    > > Feel free to send your ipf.rules if it's not to sensitive.
    > >
    > > Ray
    > >
    > >
    >
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"


  • Next message: Nathan Goulding: "Re: ipf stopped working on 5.3"

    Relevant Pages

    • Re: SCO 5.0.7 AS ROUTER
      ... Subject: SCO 5.0.7 AS ROUTER ... > That 'broken' script also starts ipf. ... > As long as you only run it at startup AND before tcp starts, ...
      (comp.unix.sco.misc)
    • Re: install ie shortcuts
      ... This way whoever logs into the desktop gets the icon and the script doesnt fail because the account it was compiled on is the only account it will run on. ... Installation Expert), and then switch back to the Script view (View> ... Document Type: IPF ... Japanese Font Name=MS Gothic ...
      (microsoft.public.sms.installer)
    • Re: ipf / pf
      ... that ipf used to be in openbsd, until some sort of license dispute. ... Then the openbsd people supposedly wrote their own pf ... ... >of the ipf rules can not process a script. ... To unsubscribe, ...
      (freebsd-questions)
    • Re: ssh brute force
      ... >Is it posible to make in this way with ipfw, ipf or pf on freebsd? ... I'm looking at having a script look at SSH's log output for repeated ...
      (freebsd-isp)
    • Re: Compacting the "pf -v -s rules" output similar to "ipfstat -ionh"
      ... > I am currently trying pf instead of ipf; ... > easily besides the user errors. ... > pass out on lo0 all ... > block drop in on em0 all ...
      (freebsd-questions)