ipf stopped working on 5.3
John Fitzgerald
jjfitzgerald at gmail.com
Wed Oct 26 10:13:01 PDT 2005
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 at 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 at redshift.com < ray at 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
> >
> >
>
More information about the freebsd-security
mailing list