On 12/10/06, Chris <[EMAIL PROTECTED]> wrote:

The thing is... I generally have the kernel setup to allow by default.
Then I
create rules denying traffic as I either know up front, or can deduct from
logging a last rule denying traffic.

IE: the rule you have set to allow any, my same rule is deny any. This way I
can create allow and deny rules earlier, then view my log to see what
are still being denied via /var/log/security

This will allow you to concentrate on what items may be causing the

I know I had some issues with IPFW working for about 15 minutes, then
It was due to me not having any rules allowing MAC, or layer2 traffic.
see this if you set your logging up properly with an ending rule just
the last one.

I see.. Yes, what you suggest is a better idea and i think now is even more
clear why the manual suggests to start by allowing everything
I had it different in my mind but still i don't think i wasted my time.
I also have in mind about the layer2, ARP etc traffic and i also think of
using snort's output to create better rules.
However I stuck with the ssh rule since i mainly want to work remotely on
I will go for it in the way you suggest.


p.s. Apologies for messing with the receipients..I tried not to include ipfw
list after the first post, but
it was in someone's reply to me..etc..sorry

On Thursday 12 October 2006 20:22, Spiros Papadopoulos wrote:
Thanks for your replies,

On 12/10/06, *Chris* <[EMAIL PROTECTED]> wrote:
>If you have your kernel set to deny all by default, you can set a rule
>65534 to allow any to any

>as rule 65535 will deny any to any

>Then work your way back from there.

Could you please make the above last part of your though more clear for

I already have done what you said and i can su normally.
So there is definitely something that must be allowed before which i am
aware of
and from the messages and behaviour i get i cannot identify.

On 12/10/06, vladone <[EMAIL PROTECTED]> wrote:
> Hello Spiros,
> Thursday, October 12, 2006, 12:53:28 AM, you wrote:
> > Hi,
> > I am trying to configure a firewall using ipfw for a machine running
> FreeBSD
> > 5.4.
> > Without NAT.
> > I am nearly a newbie on this (since i never had time until now..) but
> still
> > i believe i understand exactly the
> > concepts and what needs to be done.
> > Except the manual page and chapter 26.1 in the handbook I am using
> > references such as:
> >
> > I need to connect remotely to the machine using ssh and this is where
> get
> > the problem:
> > Initially i can connect properly using a normal user account.
> > When later i am trying to su to root it does nothing and the
> > closes.
> > I have ipfw enabled in the kernel to deny everything by default.
> > I have used both (one at a time) the following rules concerning ssh,
> > /etc/ipfw.rules
> > and also other combinations, such as taking off setup and keep-state
> etc
> > which would then make my firewall stateless as far as i understood,
> which is
> > something i don't want anyway.
> > ${addcmd} 300 allow log logamount 5 tcp from any to me 22 setup
> keep-state
> > -
> > ${addcmd} 300 allow log logamount 5 tcp from any to any ssh keep-state
> > In a first investigation (not thorough) i found this post:
> >
> > where from, i cannot realize what is wrong or how to fix this.
> > I run the sshd in debug mode and below is the portion, for when i am
> trying
> > to su to root
> > /* sshd -d */
> > Write failed: Permission denied
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug1: session_pty_cleanup: session 0 release /dev/ttyp7
> > And here are related logs:
> > /* line from /var/log/messages */
> > Oct 11 20:25:54 username sshd[26251]: fatal: Write failed: Permission
> denied
> > /* /var/log/auth.log */
> > Sep 26 11:17:34 username sshd[50073]: Connection from
> > 1545
> > Sep 26 11:17:46 username sshd[50073]: Accepted
> for
> > user from port 1545 ssh2
> > Sep 26 10:17:49 username su: user to root on /dev/ttyp4
> > Sep 26 11:17:51 username sshd[50068]: Read error from remote host
> > Connection reset by peer
> > Sep 26 13:29:40 username sshd[50076]: Read error from remote host
> > Operation timed out
> > Is it trying to write to a
> > socket? I cannot see what is trying to do and the permission is denied
> > (of course maybe it is in front of me..but..)
> > Could anyone please advice?
> > Thanks in advance
> > Spiros
> > _______________________________________________
> > mailing list
> >
> > To unsubscribe, send any mail to
> Isn't very clear. U can connect, and then when try to switch to root,
> your connection is lost?

Yes It is not doing anything and gives me the message i mentioned earlier

Or after some inactivity?
> Try firs to leave ipfw open, and test ssh to be shure that this one
> work right. Then use ipfw, i think that the right form for what u
> want is (acording with documentation):
> add 1000 check-state
> add 2000 allow tcp from any to any 22 in setup keep-state

I have used my laptop with the same fbsd version and sshd for months and I
am sure it works if ipfw is off.
Also it works when adding the rule mentioned above

I have tried to capture the packets coming in and out with tcpdump just
before and after the permission denied mesg,
but I suppose i could not "see" any blocked ones.
Other small changes to the existing rules made things worst..not better.

I am still not sure what it's trying to do and is denied and i have in
the reply i
got yesterday that it worked as is in a fbsd7.0. I have a second machine
running the same fbsd
5.4 (but amd64) version which is next to test.
I was expecting this to be easier and solved by now...

> Best regards,
> vladone                            mailto:[EMAIL PROTECTED]
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to " [EMAIL PROTECTED]"

Spiros Papadopoulos
_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Spiros Papadopoulos
_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to