Re: Nat ports
On Sunday 27 July 2003 05:41 am, Daniel Hartmeier wrote: > On Sat, Jul 26, 2003 at 08:29:35PM -0700, Bryan Irvine wrote: > > Is there a way to get pf to never use specific ports? For example a > > client on my LAN might send a request for a certain webpage which gets > > sent to the gateway from a certain port we'll say, 43101. The Request > > hits the gateway and then get's changed to another source port like > > 12754. The problem is that 12754 will trigger a false postive in snort > > that someone is scanning for a ddos mstream client handler. How (if > > possible) can you create a list of ports than will never be used by pf? > > The default proxy port range used by pf is 50001-65535, so it won't use > 12754. > > You can change the proxy port range like this > > nat on $extif from 10.0.0.0/8 to any -> $extif port 2:3 > > which would cause pf to use proxy ports 2-3 for connections > matching this rule. > > Why are you running snort on the external interface, and not the > internal one? It's an intrusion detection system, and packets that don't > pass your firewall don't constitute an intrusion... > > Daniel I am no expert but wouldn't it be nice to know if someone is running a scan or some sort of flood attack? If one starts to have limited bandwidth available all of a sudden, the nids might help uncover the reason why if it is a flood. -- PGP public key http://www.krytosvirus.com/public.asc
Re: pf.conf gui ?
I know there is syntax hightling in VIM for pf.conf floating around somewhere, search the archives for that. On Thursday 23 October 2003 08:57 pm, Gabriel WARE wrote: > Hi, > I'd like to know if a gui to generate a pf.conf is being (or maybe has > been) developped. If not, what do you think of this ? > Maybe I could write a gtk tool. > > Also is there a todo list about pf ? I was unable to find it. > [ I do not have already checked the sources ;] > > > I hope i'll be able to help in some way. > Have a good day. > Gabriel -- PGP public key http://www.krytosvirus.com/public.asc
pf / pf.conf problem
This is a weird problem that took me a while to track down. First off I
have 3 openbsd servers, 1 linux machine, and a couple of windows
workstations on my network. My firewall running NAT is openbsd 3.5. It is
doing NAT for the linux and windows computers. The other two openbsd
servers are outside of the firewall each running pf. Now all of a sudden
(it seemed this way) I could not maintain a session from a host behind the
firewall to either of the two openbsd servers (all internet traffic was
fine). What would happen if I tried to access my webserver (one of the two
openbsd servers) is the page would start to load and only show about 1/3 of
the page, then freeze. My other server (mail server) would not allow me to
download my email via pop/imap but looking at tcpdump I was able to fully
log into the server. I could ssh to the server and hit enter a few times
but as soon as I did anything like "ps axu" it would freeze half way into
the output.
Since I had not changed any of my pf.conf files in several months (server
uptimes all were around 40-50 days) and I saw no signs of hacking (log
files, mtree, etc) I was stumped. I tried moving my linux machine outside
the firewall and I had the same problem accessing the servers. I tried
rebooting all of my servers and even my switch with no change. Then I
started looking at my pf.conf rules and removing several at a time and
figured out that there was one rule that was causing the whole problem.
Here is from one of my servers, the first "pass in" rule is the problem, as
soon as I removed "keep state" there are no problems with anything and when
I add "keep state" back in, the problems return.
What does this mean? what can I do? I mean, I guess I don't NEED keep
state, but I would like to use it if possible. The hardware is adequate:
350mhz AMD and p2 450, 128mb RAM and 128mb RAM for my web and mail servers
respectively.
ExtIf="dc0"
Public="{ 80, 21, 22 }"
scrub in all
pass in log quick on $ExtIf inet proto tcp from any to any port $Public \
keep state
#pass in log quick on $ExtIf inet proto tcp from any to any port $Public
block in log all label "block in all"
pass out log quick on $ExtIf inet proto tcp all modulate state
pass out log quick on $ExtIf inet proto udp all keep state
pass out log quick on $ExtIf inet proto icmp all keep state
pass in log quick on $ExtIf inet proto icmp all keep state
--
Public key http://www.krytosvirus.com/public.asc
Re: Problem with binat and Ftp... Please very important...
I might not completely understand your network setup but it seems like you
have your IP addresses setup incorrectly in your pf.conf. When you BINAT your
second server you will need to direct it to the internal IP address of the
server itself.
I think something like this would work for you.
emtelZ-internal=192.168.0.26
binat on $Net from $emtelZ-internal to any -> $emtelZ
On Wednesday 31 August 2005 06:56 am, lukas wrote:
> Heloo
>
> My problem situation is:
>
> I've OB 3.6
>
> Two FTP serwers in my network (linux, cyberFTP on win xp)
>
> I've two public IP adreses, one for serwer
>
> One serwer (proftpd) is working. but i can only connect in passive mode
> (from windows with SFTP)
>
> The second one is behind binat, because its second company with they
> internal router on linux (all is working from lan)
>
> I need to use both servers.
> Mayby i should use something else no binat...
>
>
> My PF
>
> Net="xl0"
> Lan="xl1"
> VIP="xl2"
> Lan2="xl3"
>
> teleprofZ=217.153.216.25 - first serwer on linux
> teleprofW=172.17.70.:)
> emtelW=192.168.0.:)
> emtelZ=217.153.216.26 - - second serwer on win xP
>
>
> scrub in all
>
> nat on $Net from $Lan:network to any -> $Net
> nat on $Net from $VIP:network to any -> $Net
> nat on $Net from $Lan2:network to any -> $Net
> binat on $Net from $emtelW to any -> $emtelZ
>
> ###FTP
> rdr on $Lan proto { tcp, udp } from any to any port 21 -> 127.0.0.1 port
> 8021
> rdr on $VIP proto { tcp, udp } from any to any port 21 -> 127.0.0.1 port
> 8021
> rdr on $Lan2 proto { tcp, udp } from any to any port 21 -> 127.0.0.1
> port 8021
>
> rdr on $Net proto { tcp, udp } from any to any port 25 -> $teleprofW port
> 25 rdr on $Net proto { tcp, udp } from any to any port 143 -> $teleprofW
> port 143
> rdr on $Net proto { tcp, udp } from any to any port 110 -> $teleprofW
> port 110
> rdr on $Net proto { tcp, udp } from any to any port 822 -> $teleprofW
> port 22
> rdr on $Net proto { tcp, udp } from any to any port 995 -> $teleprofW
> port 995#TELEPROF
> rdr on $Net proto { tcp, udp } from any to any port 80 -> $teleprofW port
> 80 rdr on $Net proto tcp from any to any port 443 -> $teleprofW port 443
>
> #FTP
> rdr on $Net proto tcp from any to any port 825 -> $teleprofW port 825
> rdr on $Net proto tcp from any to any port 49152:65535 -> $teleprofW
> port 49152:65535
> rdr on $Net proto tcp from any to any port 20 -> $teleprofW port 20
> #Second FTP
> #rdr on $Net proto tcp from any to any port 49152:65535 -> $emtelW port
> 49152:65535 - its usless :)
>
> block in on $Net all
> block in on $Net proto icmp all
> block in on $Net proto { tcp, udp } from any to $Net
> block from $Lan:network to $Lan2:network
> block from $Lan2:network to $Lan:network
> block from $VIP:network to $Lan
>
>
> #Second ftp
> pass in on $Net proto { icmp, tcp, udp} from any to $emtelW
> #Second ftp
> pass in on $Net proto icmp from 195.94.194.108 to 217.153.216.22
> pass in on $Net proto { tcp, udp, icmp } from $tamka to any
> #WWW
> pass in on $Net proto { tcp, udp } from any to $teleprofW port 80 keep
> state pass in on $Net proto { tcp, udp } from any to $teleprofW port 443
> keep state
> pass in on $Net proto { tcp, udp } from any to $teleprofW port 993 keep
> state
> pass in on $Net proto { tcp, udp } from any to $teleprofW port 995 keep
> state
> pass in on $Net proto { tcp, udp } from any to $teleprofW port 25 keep
> state pass in on $Net proto { tcp, udp } from any to $teleprofW port 822
> keep state
> pass in on $Net proto { tcp, udp } from any to $teleprofW port 110 keep
> statepass in quick on $Net proto tcp from any to $teleprofW port 825
> keep state
> pass in quick on $Net proto tcp from any to $teleprofW port 20 keep state
> pass in quick on $Net proto tcp from any to $teleprofW port > 49151 keep
> state
> #Second Ftp
> pass in quick on $Net proto tcp from any to $emtelW port > 49151 keep state
>
> pass out quick on $Lan proto tcp from any to $teleprofW port 825 keep state
> pass out quick on $Lan proto tcp from any to $teleprofW port 20 keep state
> pass out quick on $Lan proto tcp from any to $teleprofW port > 49151
> keep state
> #Second Ftp
> pass out quick on $Lan2 proto tcp from any to $emtelW port > 49151 keep
> state
>
> pass out on $Net inet proto { udp, icmp } all keep state
> pass out on $Net inet proto tcp all flags S/SA keep state
>
> pass quick on lo0 all
>
> #FTP
>
> pass in quick on $Net proto tcp from any to $teleprofW port 825 keep state
>
> :network
>
> Thnkyou for any ideas to improve security of my PF :)
>
> Morty
Re: [Soekris] Home Network Setup
On Sunday 16 April 2006 09:25 pm, Phusion wrote: > I have a cable connection at home and was wondering if the following > would work. If I put a Cisco 851 series router in front of a pair of > Soekris firewalls running OpenBSD using CARP and pfsync. So the Cisco > router would get a dynamic WAN IP and have a static LAN IP. The two > Soekris firewalls would sit behind it. Behind the redundant firewalls > would be the network. How could I get the computers behind the > firewall Internet access? Also would port forwarding work? The thing > is that I don't have a static IP address. Let me know. You can do NAT on the 851 to say 10.1.0.0/24. Then put 10.2.0.0/24 as the subnet used on the LAN. Then just put a static route and any of your server redirects on the 851 to the 10.2.0.0/24 addresses. Internet - Public IP - 851 - 10.1.0.0/24 - Soekris/CARP - 10.2.0.0/24 - LAN 851 internet facing nic: public IP a.b.c.d 851 lan facing nic: 10.1.0.1 soekris/carp 851 facing: 10.1.0.2 soekris/carp lan facing: 10.2.0.1 851 route config: ip route 10.2.0.0 255.255.255.0 10.1.0.2 Now, the better approach would be to just get rid of the 851 and do the NAT on the Soekris/CARP boxes. What is the purpose of the 851 in the first place? VoIP? ---
RE: Restricting source with dDNS (dynamic DNS)
While also not what the OP specifically requested but a good option to consider in general is to use the overload option to allow PF to dynamically add abusing IPs to a table which is then blocked from ssh access. This is more for frequent TCP connections on port 22 (or any other) for brute force type activity. This is similar to but not the same as the fail2ban type scripts. I get about 5-10 IP's added to my block table every day which is cleared daily via cron. -Original Message- From: owner...@benzedrine.cx [mailto:owner...@benzedrine.cx] On Behalf Of Alvaro Mantilla Gimenez Sent: Friday, December 18, 2009 5:31 PM To: Karl O. Pinc Cc: pf@benzedrine.cx Subject: Re: Restricting source with dDNS (dynamic DNS) El 18/12/2009, a las 12:20, "Karl O. Pinc" escribió: > On 12/18/2009 10:16:44 AM, Peter N. M. Hansteen wrote: >> Jim Flowers writes: >> >>> To lock down services (particularly ssh) as tightly as possible, I >> like to allow >>> administrative access to a firewall only from specific ip >> addresses. > >>> Unfortunately, some of the administrators are working from dynamic >> ip addresses >>> that change with some frequency. >>> >>> Is there a straightforward way to incorporate dynamic ip source >> addresses in the >>> pf ruleset? >> >> I'd say this sounds like a situation where authpf could come in quite >> handy. > > How? I thought authpf grants additional rights to those who > can ssh. But he wants to restrict those allowed to ssh period. > > If I remember well, sometime ago somebody did a port knocking program and he asked in the OpenBSD misc list about to include it into the ports tree. He had very bad responses and a very ugly discussion. All the people involved into the discussion ( I wasn't ) didn't understood special cases like this: if you want to "close" ssh access from the world and let some people open ports for administration, maintenance, or whatever you want then authpf is not a solution but port knocking is. Google about that and you see your solution there. You can, for example, define a port combination to execute some script to send you a sms with the status of one specifical service and/or another to open, for the IP which is doing the combination (of course), the redirection port to the SWAT (samba web administration) in one specifical server so you can define different port combinations for different groups of users... Google it. Regards, Alvaro
RE: Restricting source with dDNS (dynamic DNS)
I think it is tangentially related to the discussion as OP is obviously looking for some advice on security and I think what I mentioned was likely applicable to maybe other firewalls separate from this one specifically OP is configuring, perhaps on other networks altogether. But you are right it is not directly related, which I stated at the start of my message. I agree that an auto dns checker updating a pf table is a pretty decent way to do this with built in openbsd tools but it leaves one prone to DNS poisoning which can happen on non-openbsd systems completely out of OP's control on the internet. I dont particularly like relying on something like public DNS for who has TCP layer access. What if the DNS servers are down or having issues and a remote user then cant connect? Maybe that is an acceptable risk. What if the DNS zones get poisoned and now an attacker's own IP address is the only one allowed to access SSH (aside from any other statically allowed IPs)? Maybe that is an acceptable risk. Solely relying on dynamic DNS in this way is not acceptable to me. -Original Message- From: owner...@benzedrine.cx [mailto:owner...@benzedrine.cx] On Behalf Of Alvaro Mantilla Gimenez Sent: Saturday, December 19, 2009 12:28 PM To: Justin Krejci Cc: 'Karl O. Pinc'; pf@benzedrine.cx Subject: RE: Restricting source with dDNS (dynamic DNS) On Sat, 2009-12-19 at 06:05 -0600, Justin Krejci wrote: > While also not what the OP specifically requested but a good option to > consider in general is to use the overload option to allow PF to dynamically > add abusing IPs to a table which is then blocked from ssh access. This is > more for frequent TCP connections on port 22 (or any other) for brute force > type activity. This is similar to but not the same as the fail2ban type > scripts. > > I get about 5-10 IP's added to my block table every day which is cleared > daily via cron. > Yes, that is a good option but it is not the purpose of the discussion. He wants to have the ssh port closed and open the ports in a "dynamic" way. His approach to do that with a dns resolution is not the right approach to solve the issue. Port Knocking is, by far, the best option to do that. The problem here is...there is no port knocking support in OpenBSD then the only solution he has in hands is authpf + bruteforce tables "to defend" itself from the offenderswhich, again, is not the best approach to solve his problem. Regards, Alvaro > -Original Message- > From: owner...@benzedrine.cx [mailto:owner...@benzedrine.cx] On Behalf Of > Alvaro Mantilla Gimenez > Sent: Friday, December 18, 2009 5:31 PM > To: Karl O. Pinc > Cc: pf@benzedrine.cx > Subject: Re: Restricting source with dDNS (dynamic DNS) > > > > El 18/12/2009, a las 12:20, "Karl O. Pinc" escribió: > > > On 12/18/2009 10:16:44 AM, Peter N. M. Hansteen wrote: > >> Jim Flowers writes: > >> > >>> To lock down services (particularly ssh) as tightly as possible, I > >> like to allow > >>> administrative access to a firewall only from specific ip > >> addresses. > > > >>> Unfortunately, some of the administrators are working from dynamic > >> ip addresses > >>> that change with some frequency. > >>> > >>> Is there a straightforward way to incorporate dynamic ip source > >> addresses in the > >>> pf ruleset? > >> > >> I'd say this sounds like a situation where authpf could come in quite > >> handy. > > > > How? I thought authpf grants additional rights to those who > > can ssh. But he wants to restrict those allowed to ssh period. > > > > > > If I remember well, sometime ago somebody did a port knocking program > and he asked in the OpenBSD misc list about to include it into the > ports tree. He had very bad responses and a very ugly discussion. All > the people involved into the discussion ( I wasn't ) didn't understood > special cases like this: if you want to "close" ssh access from the > world and let some people open ports for administration, maintenance, > or whatever you want then authpf is not a solution but port knocking > is. Google about that and you see your solution there. You can, for > example, define a port combination to execute some script to send you > a sms with the status of one specifical service and/or another to > open, for the IP which is doing the combination (of course), the > redirection port to the SWAT (samba web administration) in one > specifical server so you can define different port combinations for > different groups of users... > > Google it. > > Regards, > >Alvaro
