block scanners..
hi! how can i block scanners from scanning my network? thanx. jp
Re: block scanners..
On Thu, Jan 16, 2003 at 05:38:00PM +0800, jeffrey payao wrote: > hi! how can i block scanners from scanning my network? You put a packet filter between the scanners and your network, which blocks all incoming connections: block in on $ext_if quick all *) pass out on $ext_if quick all keep state Daniel *) either with or without return-rst/-icmp, possibly depending on protocols/ports, see pf.conf(5)
Re: ftp-proxy reverse question
On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: > Anyhow, I patched ftp-proxy for reverse and have it up and running. > Question is, how robust is this? (am wondering why it was not merged > into 3.2). Can anyone comment on security/performance comparison > between ftp-proxy reverse and alternative solutions such as jftpgw? I haven't used jftpgw myself, but it serves about the same purpose, I'd say. It also supports sftp, which ftp-proxy doesn't. $ wc -l /usr/ports/net/jftpgw/w-*/jftpgw*/*.c 9531 total $ wc -l /usr/libexec/ftp-proxy/*.c 1909 total Having carefully read ftp-proxy but not jftpgw, I trust ftp-proxy more. That is not to imply that jftpgw is insecure, I just haven't studied it. jftpgw has its own access controls, ftp-proxy doesn't. I'd rather have my pf.conf do that, myself. jftpgw by default blocks data connections to reserved ports, ftp-proxy doesn't. So if your internal ftp server can be tricked into asking the client to connect to a reserved port for a passive data connection, ftp-proxy will allow that. If there are vulnerable services running on the ftp server, you'd have to block connections to them with pf (on the internal interface). Otherwise the two are similar. With either proxy, you should only allow the proxy to establish connections that are expected and needed, blocking by default using pf. As to why the reverse proxy patch is not in the tree, ask beck@. If he doesn't reply, there's your answer :) Daniel
Re: incoming ftp config with nat
On Tue, Jan 14, 2003 at 10:33:32AM -0700, Ken Gunderson wrote: > configuration is 3 legged routing firewall. ext_if is aliased to a /29 > subnet. one of the aliases, ext_ftp_ip resolves to ftp.example.com. > leg 2 is a 192.168.2.0/24 dmz subnet and leg 3 is a 192.168.1.0/24 > private network. i know ftp-proxy can be used for outgoing ftp, but > could somebody please clue me into the rdr and filter rules to do > incoming passive ftp properly. If you can use a unique external address just for the ftp server, you can solve it with a single binat rule, mapping $ext_ftp_ip to the internal ftp server. You don't need any additional rdr/nat rules for that (both incoming and outgoing connections to/from the ftp server would be translated). You can block traffic from/to the ftp server by default, and add filter rules to allow the expected ftp control and data connections (passive/active mode). binat on $ext_if from $int_ftp_ip to any -> $ext_ftp_ip # address translation occurs before filtering, so outgoing packets # have source $ext_if_ip, while incoming packets have destination # $int_if_ip. block in on $ext_if from any to $int_ftp_ip pass in on $ext_if proto tcp from any to $int_ftp_ip \ port { ftp, ftp-data, >1024 } keep state pass out on $ext_if from $ext_ftp_ip to any keep state Daniel
Re: incoming ftp config with nat
Forgot to mention that the simple binat solution will of course require the ftp daemon to send the $ext_ftp_ip address in its replies inviting passive clients. Several ftp servers have such options, if yours does, that's the easiest solution. If it can't, you might consider moving the ftp server into a DMZ and directly assigning it the $ext_ftp_ip address, while the firewall is still in front of it. If that's no option, either, you might need ftp-proxy (with reverse patch) to translate the private address in the control connection. But since you do have a dedicated routable address for it, I'd try the simpler setups first :) Daniel
Re: ftp-proxy reverse question
On Thu, Jan 16, 2003 at 12:08:04PM +0100, Daniel Hartmeier wrote: > On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: > > > Anyhow, I patched ftp-proxy for reverse and have it up and running. > > Question is, how robust is this? (am wondering why it was not merged > > into 3.2). Can anyone comment on security/performance comparison > > between ftp-proxy reverse and alternative solutions such as jftpgw? > > I haven't used jftpgw myself, but it serves about the same purpose, I'd > say. It also supports sftp, which ftp-proxy doesn't. pureftpd has the required feature to use the external address in-band. I use it here heavily, and I have checked the chunks of code I use (base and ldap-auth; didn't bother to check mysql auth and the other stuff I don't even compile in; I trust it. Well, as long as you don't use the virtual chroot stuff. Didn't check it, but that gives me a bad feeling. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
PF NAT and Oracle/Linux mystery
Hi, I have a problem with access to an Oracle database over an OpenBSD PF NAT setup. We (a particle physics institute) have a Linux cluster for our computations; the nodes have private IP addresses and contact the outside world via an OpenBSD/PF NAT machine. The NAT machine works perfectly fine for SSH/SCP, DNS and everything else we tried. Everything except access to an Oracle database on a Linux machine, that is. A connection can be opened, and a query can be sent. However, after a few lines of results printed out, the connection freezes. pfctl -s state reports the connection as ESTABLISHED:ESTABLISHED, even minutes after the connection went south. It is interesting to notice that two variations of this situation do indeed work well: access via an OpenBSD/PF NAT to an Solaris Oracle database works, and access via a Linux/iptables NAT to both Oracle on Solaris and on Linux works, too. The problem seems to be an interference of the OpenBSD/PF NAT with the Linux/Oracle. Any ideas? Cheers, Steve _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: PF NAT and Oracle/Linux mystery
On Thu, Jan 16, 2003 at 02:54:29PM +, Steve Schmitz wrote: > Any ideas? Could be fragments. Can you try with scrub in on $ext_if all no-df scrub out on $ext_if all no-df If you run pfctl -si, do you see any of the 'Counters' at the bottom increase when you get a stalled connection? Also, can you enable debug loggin (pfctl -x m) and check /var/log/messages for relevant entries, after reproducing the problem? Daniel
Re: incoming ftp config with nat
On Thursday 16 January 2003 04:28 am, Daniel Hartmeier wrote: > Forgot to mention that the simple binat solution will of course > require the ftp daemon to send the $ext_ftp_ip address in its replies > inviting passive clients. Several ftp servers have such options, if > yours does, that's the easiest solution. > > If it can't, you might consider moving the ftp server into a DMZ and > directly assigning it the $ext_ftp_ip address, while the firewall is > still in front of it. > > If that's no option, either, you might need ftp-proxy (with reverse > patch) to translate the private address in the control connection. > But since you do have a dedicated routable address for it, I'd try > the simpler setups first :) > > Daniel wish i could just take the binat route, but the ftp server is still on m$ ;-( had to raid the unix box to build the firewall, so mostly everything is running on single m$ server at present. it will be migrated to unix box in near future, but this was a rapid deployment to solve some immediate nasties. -- Regards, Ken Gunderson
Re: ftp-proxy reverse question
On Thursday 16 January 2003 04:51 am, Henning Brauer wrote: > On Thu, Jan 16, 2003 at 12:08:04PM +0100, Daniel Hartmeier wrote: > > On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: > > > Anyhow, I patched ftp-proxy for reverse and have it up and > > > running. Question is, how robust is this? (am wondering why it > > > was not merged into 3.2). Can anyone comment on > > > security/performance comparison between ftp-proxy reverse and > > > alternative solutions such as jftpgw? > > > > I haven't used jftpgw myself, but it serves about the same purpose, > > I'd say. It also supports sftp, which ftp-proxy doesn't. > > pureftpd has the required feature to use the external address > in-band. I use it here heavily, and I have checked the chunks of code > I use (base and ldap-auth; didn't bother to check mysql auth and the > other stuff I don't even compile in; I trust it. Well, as long as you > don't use the virtual chroot stuff. Didn't check it, but that gives > me a bad feeling. i've typically used proftp, but pure ftp was looking actractiveto me and i was planning to take it for a test drive. thanks for the recommendation. presently this guy's ftp server is still on windoze, and he doesn't know how/if to restrict ftp-data port range, so it looks like i may have to opt for jftpgw until we can get a unix server deployed. -- Regards, Ken Gunderson
Re: PF NAT and Oracle/Linux mystery
Could be fragments. Can you try with scrub in on $ext_if all no-df scrub out on $ext_if all no-df If you run pfctl -si, do you see any of the 'Counters' at the bottom increase when you get a stalled connection? Also, can you enable debug loggin (pfctl -x m) and check /var/log/messages for relevant entries, after reproducing the problem? I included the two scrub lines into the ruleset and flushed and reloaded the pf, but to no avail. Log attached. The firewall is running not quite the newest version of OpenBSD/PF (a 3.2 beta). Is it advisable to upgrade, given the interruption in service? Cheers, Steve _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?page=features/virus 192.168.101.14 - the node which tries to connect to Oracle/Linux 141.225.240.34 - the Oracle/Linux server 139.33.102.140 - the OpenBSD/PF NAT (and FW) machine Jan 16 18:41:32 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777 win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] 4:4 PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=130 dir=out,fwd Jan 16 18:41:32 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777 win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] 4:4 PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=130 dir=out,fwd Jan 16 18:41:32 firewall /bsd: pf: State failure on: 1 Jan 16 18:41:32 firewall /bsd: pf: State failure on: 1 Jan 16 18:41:44 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] 4:4PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=131 dir=out,fwd Jan 16 18:41:44 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777 win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] 4:4 PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=131 dir=out,fwd Jan 16 18:41:44 firewall /bsd: pf: State failure on: 1 Jan 16 18:41:44 firewall /bsd: pf: State failure on: 1 Counters match 308080.0/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory 00.0/s [ shortly after ] Counters match 325000.0/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory 00.0/s