Re: ipfw and nmap
daniel quinn wrote: i've been experimenting with ipfw since moving some of my machines from linux to freebsd and i've run across an oddity wrt nmap and freebsd firewalls. it doesn't seem to work and the activity isn't logged either. the firewall is working though. ssh goes through, while other ports are being blocked (and logged). i've confirmed this with telnet. but nmap still comes up empty. i'd like to be able to do a proper portscan, but is this a feature with ipfw or a lack of feature in nmap? I am not entirely sure what problems you are seeing. It sounds like you are saying that the firewall works properly, and nmap correctly identifies open/closed/filtered ports, but you are getting nothing in your ipfw log indicating that a scan is happening. Is that correct? If so, the problem is that nmap has a variety of scans which are designed not to be caught by firewall logs. If you try a TCP connect() port scan (-sT I think) it will show up in the firewall's logs. If you want to catch all manner of port scans, you will have to use something like Snort. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw and nmap
i've been experimenting with ipfw since moving some of my machines from linux to freebsd and i've run across an oddity wrt nmap and freebsd firewalls. it doesn't seem to work and the activity isn't logged either. the firewall is working though. ssh goes through, while other ports are being blocked (and logged). i've confirmed this with telnet. but nmap still comes up empty. i'd like to be able to do a proper portscan, but is this a feature with ipfw or a lack of feature in nmap? for the purposes of this test, i've used a variation on the firewall supplied in the freebsd handbook: www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html -- ...he who in dealing with the empire loves his subjects as one should love one's body is the best person to whom one can commit the empire. - lau tzu, tao te ching: chapter xiii ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw and nmap
You could try using nmap with the -sA (ACK) scanning...this is good for mapping firewall rulesets to see what is being let in. You could also use -f (fragment) with -sS to send fragmented packets...this will show open ports unless most of the time too. But -sA is better since the firewall things its a legitimate request and not a port scan On Mon, 14 Mar 2005 11:52:54 -0500, daniel quinn [EMAIL PROTECTED] wrote: i've been experimenting with ipfw since moving some of my machines from linux to freebsd and i've run across an oddity wrt nmap and freebsd firewalls. it doesn't seem to work and the activity isn't logged either. the firewall is working though. ssh goes through, while other ports are being blocked (and logged). i've confirmed this with telnet. but nmap still comes up empty. i'd like to be able to do a proper portscan, but is this a feature with ipfw or a lack of feature in nmap? for the purposes of this test, i've used a variation on the firewall supplied in the freebsd handbook: www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html -- ...he who in dealing with the empire loves his subjects as one should love one's body is the best person to whom one can commit the empire. - lau tzu, tao te ching: chapter xiii ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- You've officially been Gmailed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw and nmap
On Wed, Feb 23, 2005 at 11:49:39AM -0500, sn1tch wrote: 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. One way of coding up firewall rules to allow incoming SSH connections 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. Now is there a way to allow setup connections but disallow port scanners like nmap from seeing it as being open? If you want people to be able to SSH into your systems from outside, 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: http://www.infracaninophile.co.uk/pgpkey Tilmanstone Tel: +44 1304 617253 Kent, CT14 0JL UK pgpCFyja8UtwR.pgp Description: PGP signature
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
