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 Cheers, JJ
I think you should try to implement a pf-based and/or a ipfw-based firewall (both works quite well for me) immediately, so that your system is not so much endangered... This is just a workaround... -Arne --- John Fitzgerald <jjfitzgerald@gmail.com> 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 > > Cheers, > JJ > _______________________________________________ > 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" >__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Tue, 25 Oct 2005, John Fitzgerald wrote:> > 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 processLooks like a version mismatch. What does 'ipf -V' say? Are you using ipf compiled-in or as a KLD? Fer
I had this same problem and found out there is a parimeter that needs to be added to the kernel config that was not needed previously. When I get back to my office, I will look it up and send it to you. Chris Odell -----Original Message----- From: owner-freebsd-security@freebsd.org [mailto:owner-freebsd-security@freebsd.org] On Behalf Of John Fitzgerald Sent: Tuesday, October 25, 2005 10:33 AM To: freebsd-security@FreeBSD.org Subject: ipf stopped working on 5.3 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 Cheers, JJ _______________________________________________ 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"
Yeah, options INET6 is already in there (by default). It's curious that it would stop working on one of my servers, yet remain functional on the other. -JJ On 10/26/05, Krzysztof Stryjek <wtp@wtp3.org> wrote:> > Hello, > > Check if you have INET6 in your kernel. I've found this via Google, that > ipf needs inet6 to be compiled. > > Greetings > -- > /~\ The ASCII Krzysztof Stryjek > \ / Ribbon Campaign wtp (at) wtp3.org <http://wtp3.org> > X Against HTML http://fw.wtp3.org/~wtp/ > / \ Email! GG: 3608113 JID:wtp@chrome.pl > > Intolerance is the last defense of the insecure. > > >
In some mail from John Fitzgerald, sie said:> > 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 processMore than likely you have a rule referring to a group before you've used "head" in a rule. Darren
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