Date: Wed, 26 Oct 2005 13:12:59 -0400 From: John Fitzgerald <jjfitzgerald@gmail.com> To: "ray@redshift.com" <ray@redshift.com> Cc: freebsd-security@freebsd.org Subject: Re: ipf stopped working on 5.3 Message-ID: <5e49673f0510261012u3ebd85b7if50abd2bbed150f6@mail.gmail.com> In-Reply-To: <5e49673f0510261001o10ccb473m6c363d651fa78a6c@mail.gmail.com> References: <3.0.1.32.20051026094825.00d41100@pop.redshift.com> <5e49673f0510261001o10ccb473m6c363d651fa78a6c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 rule= s 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 i= t 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 =3D 80 flags S/SA keep > state > pass in log quick proto tcp from any to any port =3D 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 =3D 22 flags S= /SA > keep state > pass in log quick proto tcp from MY_SECOND_HOST to any port =3D 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 =3D 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 th= ink > 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 > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5e49673f0510261012u3ebd85b7if50abd2bbed150f6>