Re: Problem with "ipfw flush"
On Thu, 25 Jan 2007, Dan Mahoney, System Admin wrote:
> On Fri, 26 Jan 2007, Ian Smith wrote:
>
> Excellent. I'll read up on this for a bit.
I've been reading man ipfw for years, but every time find something new :)
> I suppose my biggest confusion was as to why I could do:
>
> kldload ipfw && ipfw add 65000 allow ip from any to any
>
> but not
>
> ipfw flush && ipfw add 65000 allow ip from any to any
>
> Clearly, the devil is in the output being sent.
>
> Also, the manpage had -q and -f as mutually exclusive, and I missed the
> part about -q implying -f.
I guess the syntax 'ipfw [-f | -q] flush' does imply exclusivity, though
'ipfw -q -f flush' must work fine, when $fwcmd can be 'ipfw -q' ..
> There IS one other issue that I encountered. I have tables and pipes in
> play, and I believe a regular ipfw flush doesn't clear them. Is there a
> universal "reset EVERYTHING" command?
I'm yet to use tables or pipes so can't say, except to see ipfw(8) has:
ipfw table number flush
and
ipfw [-s [field]] {pipe | queue} {delete | list | show} [number ...]
Cheers, Ian
[..]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
On Fri, 26 Jan 2007, Ian Smith wrote:
Excellent. I'll read up on this for a bit.
I suppose my biggest confusion was as to why I could do:
kldload ipfw && ipfw add 65000 allow ip from any to any
but not
ipfw flush && ipfw add 65000 allow ip from any to any
Clearly, the devil is in the output being sent.
Also, the manpage had -q and -f as mutually exclusive, and I missed the
part about -q implying -f.
There IS one other issue that I encountered. I have tables and pipes in
play, and I believe a regular ipfw flush doesn't clear them. Is there a
universal "reset EVERYTHING" command?
-Dan
Re: freebsd-questions Digest, Vol 162, Issue 11
> Message: 31
On Wed, 24 Jan 2007 19:20:47 -0500 (EST), Dan Mahoney wrote:
> On Wed, 24 Jan 2007, Kevin Kinsey wrote:
>
> > Dan Mahoney, System Admin wrote:
> >> Hey all.
> >>
> >> In trying to tweak my firewall setup I'm using a file called
> >> /etc/ipfw.rules
> >>
> >> However, it seems even though I copy my rules perfectly to that file, the
> >> system freezes up and locks me out when I do:
> >
> > /usr/share/examples/ipfw/change_rules.sh?
>
> That is a very cool script, however, it appears as though it calls
> firewall_script on line 131 with "sh", not with ipfw.
>
> nohup sh ${firewall_script} ${firewall_type}.new
>
> Whereas, etc/rc.firewall calls ipfw on line 299 via the "ipfw" command:
>
> ${fwcmd} ${firewall_flags} ${firewall_type}
>
> The difference is that the resulting rules file would not be parseable by
> "sh" since the lines in the file would not contain the "ipfw" command but
> only the arguments. As one's in "examples" and the other's in a live
> startup script, I'd assume the latter to be the correct method.
Either. Check /etc/defaults/rc.conf and you'll notice that the default
for firewall_script="/etc/rc.firewall" so 'sh ${firewall_script}' runs
'sh /etc/rc.firewall' which runs ipfw -f flush, denying all connections,
then later, in your case with a given filename, ipfw $flags $pathname
Do you have firewall_quiet="YES" ? This will help a lot, otherwise ipfw
writes to the terminal, which after the flush, it can't. From ipfw(8):
o If you are logged in over a network, loading the kld(4) version of
ipfw is probably not as straightforward as you would think. I recom-
mend the following command line:
kldload ipfw && \
ipfw add 32000 allow ip from any to any
Along the same lines, doing an
ipfw flush
in similar surroundings is also a bad idea.
> That said, this still does not tell me why a subsequent flush-and-rerun
> isn't working via ssh. It works totally fine via the command line, but
> over ssh it gives:
>
> Jan 24 19:10:55 ads-bsh-fwa4 sshd[845]: fatal: Write failed: Permission
> denied on the console (but by that point my connection's already dropped).
Exactly.
> However, this shouldn't actually stop an already-typed command, should it?
Yes, if it's trying to write to the terminal. The bottom line is that
if you want to run it from a command line over ssh, the command must say
nothing to the terminal until finished. Even then, if your ssh session
was being permitted by a keep-state rule you'll still lose your session,
but as someone else (sorry) mentioned, you can log straight back in.
> Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do
I think you mean /etc/rc.d/ipfw here?
> this, as the "stop" command it lists only disables the kernel firewall
> structure via sysctl, but does NOT flush the rules, pipes, counts, or the
> like, so it's not a true "restart". (the idea being that otherwise, every
> rule will be added twice -- the flush is a necessary step there).
It is necessary, and it's done on (re)start. If you're using
rc.firewall, as it seems you are, then in /etc/rc.d/ipfw:
ipfw_start()
{
# set the firewall rules script if none was specified
[ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
Right? Then:
if [ -r "${firewall_script}" ]; then
# .. nat stuff ..
. "${firewall_script}"
which runs /etc/rc.firewall (in the current shell), starting with a)
setting firewall_type - in your case, to your rules file, b) setting
fwcmd='ipfw -q' if firewall_quiet=yes (you do want this!) and then does
the '${fwcmd} -f flush' then (if not wedged) your rules.
> Even if I add the "flush" command directly to /etc/ipfw.rules, and run
> ipfw -f /etc/ipfw.rules right from the command line, my connection gets
> dropped and the rest of the commands do not run.
Try with -q instead (this also implies -f) RTFM on -q, until grokked.
> In experimenting a bit more, I've found that I can do:
>
> nohup ipfw -f /etc/ipfw.rules
>
> This allows the rest of the ipfw command to run, but the HUP-on-disconnect
> still doesn't explain why the command doesn't even finish running.
I think it will IFF you use ipfw_quiet="yes" - and perhaps add a static
allow rule for your
Re: Problem with "ipfw flush"
Re: freebsd-questions Digest, Vol 162, Issue 11
> Message: 31
On Wed, 24 Jan 2007 19:20:47 -0500 (EST), Dan Mahoney wrote:
> On Wed, 24 Jan 2007, Kevin Kinsey wrote:
>
> > Dan Mahoney, System Admin wrote:
> >> Hey all.
> >>
> >> In trying to tweak my firewall setup I'm using a file called
> >> /etc/ipfw.rules
> >>
> >> However, it seems even though I copy my rules perfectly to that file, the
> >> system freezes up and locks me out when I do:
> >
> > /usr/share/examples/ipfw/change_rules.sh?
>
> That is a very cool script, however, it appears as though it calls
> firewall_script on line 131 with "sh", not with ipfw.
>
> nohup sh ${firewall_script} ${firewall_type}.new
>
> Whereas, etc/rc.firewall calls ipfw on line 299 via the "ipfw" command:
>
> ${fwcmd} ${firewall_flags} ${firewall_type}
>
> The difference is that the resulting rules file would not be parseable by
> "sh" since the lines in the file would not contain the "ipfw" command but
> only the arguments. As one's in "examples" and the other's in a live
> startup script, I'd assume the latter to be the correct method.
Either. Check /etc/defaults/rc.conf and you'll notice that the default
for firewall_script="/etc/rc.firewall" so 'sh ${firewall_script}' runs
'sh /etc/rc.firewall' which runs ipfw -f flush, denying all connections,
then later, in your case with a given filename, ipfw $flags $pathname
Do you have firewall_quiet="YES" ? This will help a lot, otherwise ipfw
writes to the terminal, which after the flush, it can't. From ipfw(8):
o If you are logged in over a network, loading the kld(4) version of
ipfw is probably not as straightforward as you would think. I recom-
mend the following command line:
kldload ipfw && \
ipfw add 32000 allow ip from any to any
Along the same lines, doing an
ipfw flush
in similar surroundings is also a bad idea.
> That said, this still does not tell me why a subsequent flush-and-rerun
> isn't working via ssh. It works totally fine via the command line, but
> over ssh it gives:
>
> Jan 24 19:10:55 ads-bsh-fwa4 sshd[845]: fatal: Write failed: Permission
> denied on the console (but by that point my connection's already dropped).
Exactly.
> However, this shouldn't actually stop an already-typed command, should it?
Yes, if it's trying to write to the terminal. The bottom line is that
if you want to run it from a command line over ssh, the command must say
nothing to the terminal until finished. Even then, if your ssh session
was being permitted by a keep-state rule you'll still lose your session,
but as someone else (sorry) mentioned, you can log straight back in.
> Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do
I think you mean /etc/rc.d/ipfw here?
> this, as the "stop" command it lists only disables the kernel firewall
> structure via sysctl, but does NOT flush the rules, pipes, counts, or the
> like, so it's not a true "restart". (the idea being that otherwise, every
> rule will be added twice -- the flush is a necessary step there).
It is necessary, and it's done on (re)start. If you're using
rc.firewall, as it seems you are, then in /etc/rc.d/ipfw:
ipfw_start()
{
# set the firewall rules script if none was specified
[ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
Right? Then:
if [ -r "${firewall_script}" ]; then
# .. nat stuff ..
. "${firewall_script}"
which runs /etc/rc.firewall (in the current shell), starting with a)
setting firewall_type - in your case, to your rules file, b) setting
fwcmd='ipfw -q' if firewall_quiet=yes (you do want this!) and then does
the '${fwcmd} -f flush' then (if not wedged) your rules.
> Even if I add the "flush" command directly to /etc/ipfw.rules, and run
> ipfw -f /etc/ipfw.rules right from the command line, my connection gets
> dropped and the rest of the commands do not run.
Try with -q instead (this also implies -f) RTFM on -q, until grokked.
> In experimenting a bit more, I've found that I can do:
>
> nohup ipfw -f /etc/ipfw.rules
>
> This allows the rest of the ipfw command to run, but the HUP-on-disconnect
> still doesn't explain why the command doesn't even finish running.
I think it will IFF you use ipfw_quiet="yes" - and perhaps add a static
allow rule for your ssh access, before using any stateful rules, as any
existing dynamic connections will get clobbered on a flush, of course.
Cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
--On January 24, 2007 4:18:12 PM -0500 "Dan Mahoney, System Admin" <[EMAIL PROTECTED]> wrote: Well, I'm trying to be compliant with /etc/rc.firewall's expectations for a rules file, which IS called with ipfw "rules.file" Are you aware that you can run /etc/rc.d/ipfw restart? You'll get locked out of that ssh session, but you can start another one immediately. (Assuming you didn't screw up your rules, of course.) Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Problem with "ipfw flush"
Dan Mahoney, System Admin <[EMAIL PROTECTED]> wrote: > Even if I add the "flush" command directly to /etc/ipfw.rules, and run > ipfw -f /etc/ipfw.rules right from the command line, my connection gets > dropped and the rest of the commands do not run. > In experimenting a bit more, I've found that I can do: > nohup ipfw -f /etc/ipfw.rules > This allows the rest of the ipfw command to run, but the HUP-on-disconnect > still doesn't explain why the command doesn't even finish running. If I understands rightly you need -q option. ipfw(8): -q While adding, zeroing, resetlogging or flushing, be quiet about actions (implies -f). This is useful for adjusting rules by exe- cuting multiple ipfw commands in a script (e.g., `sh /etc/rc.firewall'), or by processing a file of many ipfw ^ rules across a remote login session. It also stops a table add or delete from failing if the entry already exists or is not present. If a flush is performed in normal (verbose) mode (with the default kernel configuration), it prints a message. Because all rules are flushed, the message might not be delivered to the login session, causing the remote login session to be closed and the remainder of the ruleset to not be processed. Access to the console would then be required to recover. ^^ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
On Wed, 24 Jan 2007, Kevin Kinsey wrote:
Dan Mahoney, System Admin wrote:
Hey all.
In trying to tweak my firewall setup I'm using a file called
/etc/ipfw.rules
However, it seems even though I copy my rules perfectly to that file, the
system freezes up and locks me out when I do:
/usr/share/examples/ipfw/change_rules.sh?
That is a very cool script, however, it appears as though it calls
firewall_script on line 131 with "sh", not with ipfw.
nohup sh ${firewall_script} ${firewall_type}.new
Whereas, etc/rc.firewall calls ipfw on line 299 via the "ipfw" command:
${fwcmd} ${firewall_flags} ${firewall_type}
The difference is that the resulting rules file would not be parseable by
"sh" since the lines in the file would not contain the "ipfw" command but
only the arguments. As one's in "examples" and the other's in a live
startup script, I'd assume the latter to be the correct method.
That said, this still does not tell me why a subsequent flush-and-rerun
isn't working via ssh. It works totally fine via the command line, but
over ssh it gives:
Jan 24 19:10:55 ads-bsh-fwa4 sshd[845]: fatal: Write failed: Permission
denied on the console (but by that point my connection's already dropped).
However, this shouldn't actually stop an already-typed command, should it?
Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do
this, as the "stop" command it lists only disables the kernel firewall
structure via sysctl, but does NOT flush the rules, pipes, counts, or the
like, so it's not a true "restart". (the idea being that otherwise, every
rule will be added twice -- the flush is a necessary step there).
Even if I add the "flush" command directly to /etc/ipfw.rules, and run
ipfw -f /etc/ipfw.rules right from the command line, my connection gets
dropped and the rest of the commands do not run.
In experimenting a bit more, I've found that I can do:
nohup ipfw -f /etc/ipfw.rules
This allows the rest of the ipfw command to run, but the HUP-on-disconnect
still doesn't explain why the command doesn't even finish running.
-Dan
--
"What's with the server farm down in the basement?"
-Spider, Three Skulls Commons at Selden House, 4/15/00
Dan Mahoney
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
Dan Mahoney, System Admin wrote: Hey all. In trying to tweak my firewall setup I'm using a file called /etc/ipfw.rules However, it seems even though I copy my rules perfectly to that file, the system freezes up and locks me out when I do: /usr/share/examples/ipfw/change_rules.sh? HTH, KDK -- English literature's performing flea. -- Sean O'Casey on P. G. Wodehouse ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
On Thu, 25 Jan 2007, [EMAIL PROTECTED] wrote: In trying to tweak my firewall setup I'm using a file called /etc/ipfw.rules However, it seems even though I copy my rules perfectly to that file, the system freezes up and locks me out when I do: ipfw -f flush; ipfw /etc/ipfw.rules I've also tried doing it as ipfw -f flush && ipfw /etc/ipfw.rules But to no avail. Firewall script is a common shell script. You don't need to run 'ipfw
Re: Problem with "ipfw flush"
In trying to tweak my firewall setup I'm using a file called /etc/ipfw.rules However, it seems even though I copy my rules perfectly to that file, the system freezes up and locks me out when I do: ipfw -f flush; ipfw /etc/ipfw.rules I've also tried doing it as ipfw -f flush && ipfw /etc/ipfw.rules But to no avail. Firewall script is a common shell script. You don't need to run 'ipfw
Re: Problem with "ipfw flush"
On Wednesday 24 January 2007 15:59, Jeff Royle wrote: > Jeff Royle wrote: > > Dan Mahoney, System Admin wrote: > >> In trying to tweak my firewall setup I'm using a file called > >> /etc/ipfw.rules > >> > >> However, it seems even though I copy my rules perfectly to that file, > >> the system freezes up and locks me out when I do: > >> > >> ipfw -f flush; ipfw /etc/ipfw.rules > >> > >> I've also tried doing it as > >> > >> ipfw -f flush && ipfw /etc/ipfw.rules > >> > >> But to no avail. > >> > >> if it matters, ipfw is loaded as a kernel module, not compiled in. > > > > I haven't used IPFW in a while but if I recall right IPFW has a default > > policy of drop. So when you flush the ruleset your pass rules are all > > gone. > > > > You could run the command like: ipfw -f flush && ipfw /etc/ipfw.rules > > > > That should allow you flush and load your ruleset. You may also want > > to look into changing the default policy to accept. However this may > > require you to adjust your rules depending on how you wrote them. > > Opps I am sorry, I got pulled away while reading your original email, > guess I didn't finish reading it. I see you are trying &&. > > You still may want to look into a default policy of accept for IPFW, > this way its a non issue. Three things to remember when modifying ipfw rules remotely: 1) Make sure that you have a way to recover when you lock yourself out. Once you get the hang of it this doesn't happen very often, but it can definitely happen. 2) Put whatever rules you need to access your session at the top of your ruleset. (e.g. allow tcp from any to me 22 and allow tcp from me 22 to any) 3) Make sure to use "nohup" at the beginning of your reload command(s). It's helpful to make a script that flushes and reloads the firewall so all you have to do is "nohup reload.sh". If you use screen or the like you can get the same result. The point is to keep the system from hanging up on you and interrupting your session while you're momentarily not allowed in. Changing the default to accept would alleviate the need for some or all of the above, but I've never thought that to be a good approach in situations where I actually want a firewall. JN ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
Jeff Royle wrote: Dan Mahoney, System Admin wrote: Hey all. In trying to tweak my firewall setup I'm using a file called /etc/ipfw.rules However, it seems even though I copy my rules perfectly to that file, the system freezes up and locks me out when I do: ipfw -f flush; ipfw /etc/ipfw.rules I've also tried doing it as ipfw -f flush && ipfw /etc/ipfw.rules But to no avail. if it matters, ipfw is loaded as a kernel module, not compiled in. -Dan -- I haven't used IPFW in a while but if I recall right IPFW has a default policy of drop. So when you flush the ruleset your pass rules are all gone. You could run the command like: ipfw -f flush && ipfw /etc/ipfw.rules That should allow you flush and load your ruleset. You may also want to look into changing the default policy to accept. However this may require you to adjust your rules depending on how you wrote them. Cheers, Jeff ___ Opps I am sorry, I got pulled away while reading your original email, guess I didn't finish reading it. I see you are trying &&. You still may want to look into a default policy of accept for IPFW, this way its a non issue. Sorry for the wasted bandwidth! :) Cheers, Jeff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with "ipfw flush"
Dan Mahoney, System Admin wrote: Hey all. In trying to tweak my firewall setup I'm using a file called /etc/ipfw.rules However, it seems even though I copy my rules perfectly to that file, the system freezes up and locks me out when I do: ipfw -f flush; ipfw /etc/ipfw.rules I've also tried doing it as ipfw -f flush && ipfw /etc/ipfw.rules But to no avail. if it matters, ipfw is loaded as a kernel module, not compiled in. -Dan -- I haven't used IPFW in a while but if I recall right IPFW has a default policy of drop. So when you flush the ruleset your pass rules are all gone. You could run the command like: ipfw -f flush && ipfw /etc/ipfw.rules That should allow you flush and load your ruleset. You may also want to look into changing the default policy to accept. However this may require you to adjust your rules depending on how you wrote them. Cheers, Jeff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
