Ummm, thanks for the prompt reply but that's not what I really asked.
Yes, we have troubleshooting procedures and intrusion detection. But I am not
concerned about a possible
security breach (in this case) as my FW denied these packets.
I just wanted to know how packets arrived at my firewall destined for some
other part of the world.(See below)
Thanks for the additional info but I don't really believe router ACLs etc
are really necessary infront of my firewall because the FW itself does it
and it's unnecessary overhead.
[EMAIL PROTECTED] wrote:
> Since you are asking these type of questions, then I am assuming that a
> security escalation matrix and troubleshooting procedures have not been
> written at your organization.
>
> The simplest way is to assemble a basic packet filter on your external
> router if maintained by your organization, dropping those packets. If you
> do not maintain your internet router, than contact your ISP to institute a
> packet filter dropping the listed address as in not just the specific ip
> address listed in your log file, but the whole address range. In the
> meantime, this buys you some time to devise or re-architect your packet
> filtering rules, compose a RFP or RFQ to send out to the various security
> consultants that have real experience in constructing viable and scaleable
> organizational networks with active/reactive security features.
>
> Your revised architecture should incorporate some of the following:
>
> Approval from upper management to spend lots of money on building the
> internal and DMZ network correctly.(usually this take a long time, once
> this happens, asking them for money for hardware gets easier. )
>
It is built correctly, hey we only have 10 nodes, no DMZ, one FW, one dial up
modem, ISP's router; how
hard could it be? (tongue in cheek)
>
> If you do not get approval to spend lots of money seek out URL's like the
> following:http://www.clark.net/pub/mjr/pubs/pdf/VPN-homebrew.pdf. to get
> your through, remember if you do use ideas in the URL, please remember to
> send a considerable contribution to the author.
>
> Security Policy and Procedures that are customized to your work culture
> and environment.
> Buy-in from the end users.
> A well developed and though out network architecture that can scale and
> can last at least 24 - 36 months. Refer to Building Internet Firewalls
> for avg number of when to rebuild your security architecture.
>
> A well developed Intrusion Detection System with a proper constructed
> policy that identified anomalous traffic and not every day crud ( again,
> refer to Network Flight Recorder for some hints on what an real IDS system
> is: www.nfr.net)
>
> An A-OK Firewall certificate from Marcus Ranum. If you decide to go for
> an A-OK firewall certificate, it will cost you but definitely much cheaper
> than an ICSA certification.. :)
>
> If those on the list do not know what the A-OK firewall certificate is,
> drop Marcus Ranum an email say you want your firewall to be A-OK
> certified.. Be prepared to have your checkbook ready.. :)
>
What's his address?
>
> /m
>
> Dave Harris <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 02/20/00 02:23 PM
>
>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> cc:
> Subject: Packets not destined for my network
>
> Hi all
>
> Some interesting discussion going on here re: 'Someone is scanning me'
>
> Do you guys actually get time to do any work? (kidding)
>
> I get scans all the time but lately these alerts have been showing in my
> FW log
> with a destination of who knows?
>
> Feb 19 08:06:45 gw kernel: securityalert: tcp if=ppp0 from
> 24.27.38.162:3721 to 210.9.41.5 on unserved port 8080
> Feb 19 08:06:45 gw kernel: securityalert: tcp if=ppp0 from
> 24.27.38.162:3719 to 210.9.41.4 on unserved port 8080
> Feb 19 08:06:45 gw kernel: securityalert: tcp if=ppp0 from
> 24.27.38.162:3723 to 210.9.41.6 on unserved port 8080
> Feb 19 08:06:45 gw kernel: securityalert: tcp if=ppp0 from
> 24.27.38.162:3725 to 210.9.41.7 on unserved port 8080
> Feb 19 08:42:19 gw kernel: securityalert: udp if=ppp0 from
> 199.4.142.161:137 to 210.9.41.5 on unserved port 137
> Feb 19 08:42:27 gw kernel: securityalert: udp if=ppp0 from
> 199.4.142.161:137 to 210.9.41.6 on unserved port 137
> Feb 19 08:42:34 gw kernel: securityalert: udp if=ppp0 from
> 199.4.142.161:137 to 210.9.41.7 on unserved port 137
> Feb 19 17:02:07 gw kernel: securityalert: tcp if=ppp0 from
> 200.16.84.11:25685 to 210.9.41.5 on unserved port 143
>
> My traceroute to 24.27.38.162 got cs2738-162.austin.rr.com
>
> My traceroute to 210.9.41.5 got as far as FFAVA-RECYT4-128.secyt.gov.ar
> (200.9.245.18) 1029.140 ms 1021.824 ms
>
> Looks like Austin, Texas going to somewhere in Argentina?
>
> The question is how did these packets end up at my firewall? Is it
> routing? DNS?
>
> We do not support or advertise a webserver in our domain.
>
> Who can I talk to about this? My ISP? Their ISP?
>
> Cheers
>
> TIA
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
