attached mail follows:
Many thanks to:
Mr George Gallen who pointed me some ports to filter
and specially to
Mr.Nestor Ruiz, who spent his valuable time writing
the following tutorial. As he promissed me, the second part
will be on the way as soon as possible. I will forward it to
you all.
Thanks again.
Orson Voerckel Galvão
Universidade Estadual de Santa Cruz
Ilhéus - Bahia - Brasil
Nestor Ruiz wrote:
>
> Hi
>
> First, sorry for the delay, here I had some "extra" work... ;)
>
> Well, here it goes.
>
> The main steps to complete this "port filtering", are :
>
> 1.- know those "ugly" ports numbers we want to "block"
> 2.- define the order and politic of our filter
> 3.- define the incoming filters and outgoing filters
> 4.- create the filter
> 5.- apply the filter to an interface
>
> Easy ;)
>
> 1.- Know Ports Number
>
> This is the most interesting part of the "bussines", you have to
> know the port numbers, for example, SMTP uses the port 25, POP3
> uses the port 110, etc.
>
> Here you may use public port list :
> http://www.isi.edu/in-notes/iana/assignments/port-numbers
> or you can use a network traffic "watcher" like sniffers an those
> things (you MAY try IPTRAF - who comes in every linux distro).
>
> Once you have the port number(s) you want to block/filter, let's
> pass to the second step.
>
> 2.- Define the order and the "politic"
>
> Yes, you may choose the politic :
> A.- My list will contain every port I want to BLOCK, and by default,
> the not listed ports numbers will be allowed.
> B.- My list will contail those ports that I want to FORWARD, and by
> default, those other not listed, will be blocked.
>
> And the order, in this case, the Access List (this is the command
> used in "port filtering") is like the "case of" command of pascal,
> each "case" will contain the specific action for if the rule match
> with incoming packet.
>
> If a rule has been processed, the rest are ignored. If no one rule
> has match, you may have already defined a "default" rule (that's
> why I said to choose the politic). This "default" rule, may agree or
> deny the pass of the packet.
>
> 3.- Define incoming and outgoing filters
>
> Here there are some things that we must care, to get our filter
> work as we want.
>
> In the "usual" internet connection, you may have a graph containing
> (reading from left to right) :
> - Internet Cloud, containing those "good sites" and "bad ones"
> - Internet router (also known as "gateway") <- the filter goes here
> - Internal lan, which contains "allowed" hosts, and "filtered" hosts
>
> So, we may define :
> - I want those allowed hosts (includying the mine) to reach all
> those good and bad sites (he he, yes you can DO it)
> - I want those filtered hosts to reach good sites, but no bad ones
> - I want those filtered hosts to reach good sites but only on some
> "allowed ports".
> - I don't want internet users to reach my workstations in SMB ports
> (to disable "nuke" attaks)
> - Also I don't want internet to reach my workstations in NETBUS
> port (12345)
> - And I don't want internet to be able to telnet some servers, just a
> few ones. (like a basic firewall)
>
> Once we defined our "requirements", let's do the filters...
>
> 4.- Make those filters!
>
> Yes, here is the mos exciting part (don't you think it?), this part took
> me about two months to figure out, but I guess I can explain you
> this in about... ten minutes? well, I hope you understand this...
>
> As everybody knows, ip numbers have the IP address and the
> mask, for example 192.168.1.1/255.255.255.0 is a valid "class C" ip
> number (private one).
>
> BUT in access list, depending on the version of IOS you may have,
> you may need to use "simple" words (like "any" or "host") or if you
> have an old one (I can provide you the lastest one I have and the
> procedure to upgrade your 90T2), you may use complete mask
> description :
>
> any = "0.0.0.0 255.255.255.255"
> host <ip num> = "<ip num> 0.0.0.0"
>
> As you can see, here in access-list, the "any" we used to know
> (for default routes for example) differs from the "any" I show here.
>
> That's because access-list takes the inverse of the "bit mask" to
> define the "masked" addresses who match the rule.
> (hmm... includying my bad english, I figure you may be confused)
>
> Well, I'll put here a "working" filter and I'll comment it...
>
> --- my first rule ---
> access-list 102 deny ip host 200.37.10.10 any
> access-list 102 deny ip host 200.37.10.219 any
> access-list 102 deny ip host 200.37.10.220 any
> access-list 102 permit icmp host 200.37.10.225 any
> access-list 102 permit tcp host 200.37.10.225 any eq www
> access-list 102 deny ip host 200.37.10.225 any
> access-list 102 permit ip 200.37.10.0 0.0.0.255 any
> access-list 102 permit ip 200.37.11.0 0.0.0.255 any
> access-list 102 permit ip 200.37.12.0 0.0.0.255 any
> access-list 102 permit ip 200.37.13.0 0.0.0.255 any
> access-list 102 permit ip 200.37.14.0 0.0.0.255 any
> access-list 102 deny ip any any
> --- end of this "complex" rule ---
>
> As you can see, the last rule, denies ip traffic, this means, that my
> politic is "every port listed in my filter is forwarded, but the other
> ones, are rejected"
>
> Now, this is an "outgoing" list, and before getting more confused,
> let me tell you that I have five class C networks comming to my
> router, the 200.37.10.x is my lan class, the other, are redirected to
> our wan, so they are subnetted.
>
> Why it's outgoing, by the sintax, in the first rule
>
> access-list 102 deny ip host 200.37.10.10 any
>
> here it says :
>
> access-list 102 : this means this is an extended IP access list
> deny : the action defined (if rule match), is to deny the access
> ip : the protocol, by IP I mean "tcp + udp + icmp"
> host 200.37.10.10 : the "source", it's a lan workstation
> any : the "target", any means "every host matches"
>
> In other words, if the host 200.37.10.10 tryes to connect to any
> host outside my lan, that connection will be rejected (the host may
> report "no route to host").
>
> Now, let's see a "group" of rules for a host (lines 4th thru 6th)
>
> access-list 102 permit icmp host 200.37.10.225 any
> access-list 102 permit tcp host 200.37.10.225 any eq www
> access-list 102 deny ip host 200.37.10.225 any
>
> In this case, these three rules refer to the same host, and the order
> is VERY important, the first rule means :
> host 200.37.10.255 can make ping's to outside.
> The second rule means :
> host 200.37.10.255 can access to any web server (port 80 =
> www) outside the lan.
> The third rule means :
> Any other transaction from host 200.37.10.255 is not allowed.
>
> So, this host (200.37.10.255), can make pings outside, access via
> web browser to any web server (only port 80), but nothing else.
>
> Now the "class C filter rules" :
>
> access-list 102 permit ip 200.37.10.0 0.0.0.255 any
> access-list 102 permit ip 200.37.11.0 0.0.0.255 any
> access-list 102 permit ip 200.37.12.0 0.0.0.255 any
> access-list 102 permit ip 200.37.13.0 0.0.0.255 any
> access-list 102 permit ip 200.37.14.0 0.0.0.255 any
>
> Those rules permit the five C classess to be allowed to pass
> trough the router. Once again, the order is so important, because if
> I put the first of this rules as the first rule of my "main" filter, there
> will not be "filtering", because the first rule will match all the
> following rules. (rule includes the rest of rules).
>
> Remember, only the first rule match is performed, the rest are
> discarded (for each packet).
>
> Then, I hope you understood this last explanation, now, I'll describe
> the incoming filter....
>
> --- incoming filter ---
> access-list 100 deny tcp any 200.37.0.0 0.0.255.255 range 137
> 139
> access-list 100 deny tcp any 200.37.0.0 0.0.255.255 eq 12345
> access-list 100 permit tcp any host 200.37.10.7 eq smtp
> access-list 100 permit tcp any host 200.37.10.7 eq pop3
> access-list 100 deny ip any host 200.37.10.7
> access-list 100 permit ip host 200.10.84.74 host 200.37.10.17
> access-list 100 deny ip any host 200.37.10.17
> access-list 100 deny ip any host 200.37.10.18
> access-list 100 deny ip any host 200.37.10.211
> access-list 100 deny ip any host 200.37.10.212
> access-list 100 deny ip any host 200.37.10.213
> access-list 100 deny ip any host 200.37.10.214
> access-list 100 deny ip any host 200.37.10.215
> access-list 100 deny ip any host 200.37.10.216
> access-list 100 deny ip any host 200.37.10.217
> access-list 100 deny ip any host 200.37.10.218
> access-list 100 deny ip any host 200.37.10.247
> access-list 100 deny ip any host 200.37.10.248
> access-list 100 deny ip any host 200.37.10.249
> access-list 100 deny ip any host 200.37.10.250
> access-list 100 permit ip any 200.37.10.0 0.0.0.255
> access-list 100 permit ip any 200.37.11.0 0.0.0.255
> access-list 100 permit ip any 200.37.12.0 0.0.0.255
> access-list 100 permit ip any 200.37.13.0 0.0.0.255
> access-list 100 permit ip any 200.37.14.0 0.0.0.255
> --- end of incoming filter ---
>
> This is a bit more complex rule, but I'll try to show as simple as it is...
>
> Well, I'll send you this part-message, and tomorrow I'll continue...
>
> ---
>
> Date sent: Wed, 07 Apr 1999 12:26:23 -0300
> From: Orson Voerckel Galvão
> <galvao_at_jacaranda.uescba.com.br>
> Organization: Universidade Estadual de Santa Cruz
> To: nruiz_at_bvl.com.pe
> Subject: Re: Port connection filtering
>
> > Hello Mr. Ruiz
> >
> > Nestor Ruiz wrote:
> > >
> > > I made some filtering many time ago, ICQ (tcp 4000), IRC (tcp 6660-
> > > 6669), Yahoo Chat (tcp 5050), NetBus (tcp 12345) and Lan Manager (also
> > > known as SMB - Samba tcp 137-139), on my DECBrouter 90T2.
> > >
> >
> > This is what I need...
> >
> >
> > > Incoming and outgoing connections, and maybe the info I have, can
> > > helo you in your trouble, let me know if you need it.
> > >
> > > I can send you some examples, and then you may make it suite all
> > > your needs...
> > >
> >
> > Thank you very much. I am waiting you examples anxiously.
> > They will save me from this trouble. With your permision, I would like to
> > summarize all examples you send me.
> >
> > My best regards
> >
> > Orson Voerckel Galvao
> > Universidade Estadual de Santa Cruz
> > Ilhéus - Bahia - Brazil
> > galvao_at_jacaranda.uescba.com.br
>
> PD : As now is so late, and I feel an incoming headache, I'll finish
> this mail tomorrow, as soon as I can...
> sorry again for the delay...
> -
> Nestor Ruiz
> Soporte Tecnico - ELEX
Received on Tue Apr 13 1999 - 15:49:23 NZST