Ask a Question related to FreeBSD, Design and Development.
-
sn1tch #1
ipfw and nmap
I am fairly new to IPFW, I have question regarding the stateful part
of it. Now I may just be misunderstanding this so set me straight if I
am. From what I understand when you add a check-state rule and then
following that a rule to keep-state, if a packet destined for that
port is new and "setup" was not added to the keep-state rule then
wouldn't it get denied at the check-state rule since keep-state did
not add a dynamic rule? My problem is this, and again this may not
even be correct but I have a bsd box that is simply providing me SSH
capabilities..here are the rules for it:
add check-state
add allow all from any to any 22 in via fxp0 keep-state
then the default to deny rule.
Now is there a way to allow setup connections but disallow port
scanners like nmap from seeing it as being open?
Thanks for any help
sn1tch Guest
-
Anybody using Nmap::Scanner?
Hi, I'm having difficulties with that module because it cannot leverage nmap's ability to take arguments ftom stdin. After having looked at it,... -
IPFW config
SigmaX wrote: You can put your rules in /etc/rc.firewall. This is executed at startup. See rc(8) and rc.conf(5). Chris -
ipfw fwd problem - FreeBSD 5.3
Hi, I'm running a 5.3 gateway/proxy. To it is connected an ADSL modem with the 5.3 box performing the PPPoE, as well as a cisco router on... -
free nmap portscan on website
Hi, I want to build a web page that offers a free nmap portscan for the remote site. Sort of like: http://www.derkeiler.com/Service/PortScan/ ... -
Solaris and NMAP
: there are sets of ndd tweaks which will throw off nmap. this looks like a nice page: http://secinf.net/info/unix/dubrawsky/913secsol.shtml... -
Matthew Seaman #2
Re: ipfw and nmap
On Wed, Feb 23, 2005 at 11:49:39AM -0500, sn1tch wrote:
One way of coding up firewall rules to allow incoming SSH connections> I am fairly new to IPFW, I have question regarding the stateful part
> of it. Now I may just be misunderstanding this so set me straight if I
> am. From what I understand when you add a check-state rule and then
> following that a rule to keep-state, if a packet destined for that
> port is new and "setup" was not added to the keep-state rule then
> wouldn't it get denied at the check-state rule since keep-state did
> not add a dynamic rule? My problem is this, and again this may not
> even be correct but I have a bsd box that is simply providing me SSH
> capabilities..here are the rules for it:
>
> add check-state
> add allow all from any to any 22 in via fxp0 keep-state
> then the default to deny rule.
and disallow generic port probes would be something like this:
add check-state
deny tcp from any to any established
add allow tcp from any to me 22 setup in via fxp0 keep-state
[ ... other rules for tcp services you want open ... ]
ie. You're testing for the first incoming packet, with the SYN flag
set -- which results in a dynamic rule being created that effectively
slots into the rule set at the 'add check-state' line. Then deny any
TCP packets flowing in any direction that *don't* have the SYN flag
set. So TCP connections that are generated in the correct sequence
will be allowed, but bouncing random TCP packets with weird flag
combinations off your server will be filtered. You will need
additional rules to support starting up outgoing connections.
Note that this only works for TCP --- UDP, ICMP and other protocols
have no corresponding concept of 'open' or 'closed' connection state.
Note too that there is nothing to prevent port scanners simply setting
the 'SYN' flag in the probe packets they send to your server.
If you want people to be able to SSH into your systems from outside,> Now is there a way to allow setup connections but disallow port
> scanners like nmap from seeing it as being open?
then you have to have port 22 (or some port with sshd listening on it)
open. In that case, you can not prevent people using tools like nmap
to discover that the port is open.
In recent months there has been a lot of automated scanning for SSH
servers and attempts to break in via some account/password pairs which
were created by default on some Linux distros. The answer to securing
your server against such probes is not to attempt to hide the fact
that you're running a SSH server, but to enforce security policies on
how ssh is used:
-- root login via SSH is not permitted (The 'PermitRootLogin no'
setting in /etc/ssh/sshd_config).
-- Make sure that all accounts that do not correspond to real
users have locked passwords and /sbin/nologin as their shell.
-- Force all users either to use key-based auth for remote
acccess, or use one-time passwords (opie), or use Kerberos, or
failing that (and only as a last resort) permit password auth,
but enforce a strict "good password" policy. That means
regularly running a password cracker against your password file
and locking out accounts where the password can be broken.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 8 Dane Court Manor
School Rd
PGP: [url]http://www.infracaninophile.co.uk/pgpkey[/url] Tilmanstone
Tel: +44 1304 617253 Kent, CT14 0JL UK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iQCVAwUBQh28fZr7OpndfbmCAQLneQP9G9c5pUIMIG6LbCxDDv UhBnjYoJz8PT3K
qjnOhrGOBKkToKQJ/Nw0ZhBn+xBCR4nD9ADW2jiYSLz1X3sOVdNa4Kd34lf03XLy
QNShrG2HlKd6i1Q8JFgZC5fAJY/GsghsfCFqvOEdwODS0zwadxCAP/zeP4WsRmLs
49YSrktPcNw=
=znwt
-----END PGP SIGNATURE-----
Matthew Seaman Guest



Reply With Quote

