Cisco Packet Tracer No Login

[Najla Ondik]

Ihave installed packet tracer on a x64 Win 7 laptop and when i open the program it brings up a blank screen and wont allow me to login to the netacad, i have checked the requirements and updated java, flash and silverlight just in case but still nothing.

I am having the same problem. When I click login nothing happens. The screen is blank. When I click guest my web browser automatically opens and redirects to NetAcad's web page to sign up for a packet tracer course. I tried installing Packet Tracer from my Windows 10 pc as well as a Windows 8.1 PC to no avail. I believe the problem lies in Cisco Packet Tracer version 7.

*edit: I have also tried using different default browsers (chrome/IE), and disabling my firewall. Re-downloading the program and restarting my computer. Using the windows compatibility tool on windows 10. Nothing has worked thus far.

Did you manage to solve this? We're experiencing the same problem - it seems to be intermittent too. We're a 3rd level Institution so we have a lot of users in the netacademy. We're considering rolling back to an older release because this is so unreliable.

Only thing that worked for me was to DELETE: C:\Users\userx\Cisco Packet Tracer 7.0 , and reinstall PacketTracer. A different log in window was opened and I was able to use my account and have again use off all PacketTracer functions.

Every time a student in a class room logs into a computer, they have to log into PT. Reducing teaching time and adding admin load to frustrated teachers. Also - we are trying to work with orgs who wish to use PT for U13 students - we are having to encourage them to use a generic login and work around this new feature.

While we acknowledge that there is a desire from Cisco to record metrics. Can this not be accomplished anonymously. As you are now encouraging all academies to create workarounds and lose limited teaching time and irritate a considerable number of teachers.

The Packet Tracer team has worked on the login process. They are trying to get PT to a place where users that are already logged into Cisco NetAcad will not have to login again. In addition, they have changed the process for Packet Tracer assessment so users will not have to login to Packet Tracer when doing a Packet Tracer assessment.

WoW! Yet another feature Cisco is blatantly ignoring their complaints on. Im not shocked at all...... If cisco cared, you would all have a reply. This is the state of this company. DO NOT BUY CISCO PRODUCTS!

Cisco - How come u manage to deliver state of the art OS for switches and routers but cannot seem to FIX A LOGIN PAGE for a tool that is supposed to draw even more traffic towards your company and products. Its just beyond my comprehension .

All of your personal information, including email address, name, and IP address will be deleted from this site. Any feedback you have provided that others have supported will be attributed to "Anonymous". All of your ideas without support will be deleted.

As the title says, the Cisco Packet Tracer crashes when I enter my e-mail and press the "Next" button.

I installed the packet tracer with the install file, which is included when downloading version 7.2.1. It worked without problems and I can also open it. But after I open it, I need to login, but as said before, when I enter my e-mail and press the "Next" button the program freezes and crashes.

The newest version 7.3.0 does work, but unfortunately, I can't use it (because the files aren't backwards-compatible and at my school, we use 7.2.1 so if I use 7.3.0, I can't open them in school).

I already tried to ask them in the cisco forums directly, but unfortunately, they couldn't help me.

I tried already to reinstall libpng12 and openssl-1.0 because they are needed by the packet tracer, but it didn't help. I also tried to install it on Manjaro and it worked, so I think it should also work under Arch. I hope don't miss something major here.

One of the more useful features in troubleshooting on the PIX/ASA (which we used until recently) is the packet tracer, which allows us to enter source/destination IP/port, etc and check to see if a given connection is allowed or blocked, and by which rule. Is there an equivalent feature in the PA units?

The Cisco ASA packet tracer allows you to propose a hypothetical flow and runs it through the engine as if it were real. Evaluating the NAT and route dicisions which would likely apply in addition to the policy/ACL allow/deny logic.

so for argument sake, say user on 10.10.20.111 is trying to connect to say 172.16.50.9 on port 443, but claims the firewall is blocking them. You can emulate that traffic. This is a vital tool for rule querying.

this is up to layer 4 of the OSI, which gives good details on: known route/path, NAT and whether there is a supporting rule. If the packet gets dropped, there is good information which points out where and why it was dropped. Which gives guidance on what needs to be added to resolve it.

Overview

What Is SSH?

Understanding SSH Attacks

Sources of the Attacks

Key Lessons Learned

PermitRootLogin? Why?

Does the Site Have a Password Policy?

Have Administrators Considered Public Key Logins?

Are All Users Allowed? Why?

Is the Server Exposed to Untrusted Hosts? Is It Necessary?

Should You Run the SSH Server on a Different Port?

Conclusions

RFC 4251 describes SSH as "a protocol for secure remote login and other secure network services over an insecure network." Most administrators use SSH as a secure replacement for Telnet and the older BSD r commands such as rsh and rcp. SSH provides similar functionality while offering encrypted communications, password-less logins via public key authentication, and host-based verification.

Because SSH provides mechanisms for remote access or remote file transfer, attacks against SSH typically either attempt to gain remote access to a system or to cause a denial of service condition. This paper will focus on the attempts to gain remote access to a system using data collected from an SSH honeypot on the Internet during a period of approximately 6 months.

Typically, SSH servers listen for connection attempts on TCP port 22. After the three-way handshake completes setting up the TCP connection between the client and server, both client and server exchange SSH version information and cryptographic encryption keys. After the encrypted channel is established, the remote user can attempt authentication. If this authentication fails, the connection is closed. If the authentication succeeds, the user is granted remote access to the system.

The SSH honeypot was configured to allow logins from any location using common username and password combinations. Login attempts for less common usernames were recorded even if they were unable to successfully authenticate to the system. After a user was logged in, he or she entered an emulated environment that allowed observation of the attempted logins and any actions that the user attempted after the successful login. Although the users' attempted actions may be interesting, this paper will focus only on the access attempts. In general, users attempted to gain knowledge about the serversuch as the processes running on the system and the version of the operating systemand to download files that could allow them to increase their system privileges or run software such as an IRC network bouncer.

The most popular account used in the attempted logins was the username root. The root user has superuser privileges and is a well-known account for UNIX-, Linux-, and BSD-based systems. This account is very powerful:

During the observation period, we observed approximately 1.56 million total access attempts. Login attempts for the root user accounted for 34.47 percent of all login attempts in the SSH honeypot. This is best visualized in the following figure, which depicts the top 20 accounts for which logins were attempted:

In the preceding graph, the bar for "All other logins" accounts for 47.26 percent of attempts to log in to the SSH honeypot and represents 17,312 different user IDs that were not in the top 20 user IDs.

There are other account login attempts worth noting. For example, the user IDs oracle, mysql, and postgres are all used for popular database packages. The associated packages are typically installed and configured to run as one of these user IDs. Not to be left out, the user IDs of other database packages such as Informix and Sybase were tried as well, just not often enough to qualify for the top 20.

There are a number of accounts similar to admin in the top 20. Not only did accounts such as admin, administrator, administrador, andadministration get tried, but so did other variants such as admin2, adminsite, sysadmin, and adminroot. There were also some account names with an international twist, such as administrateur.

Those who think that renaming the user ID in a foreign language may offer some protection would be wise to reconsider. Not only didstudent make it into the top 20, but further down in the list is the Spanish version of "student": estudiante.

Brute-force login attacks such as those attempted against the SSH honeypot are usually carried out by using a dictionary of user IDs that are commonly found on a system, along with slight variations on those users. If a known or guessable user ID also has a weak, easily guessable password on a particular system, it is easier to gain access to that system. Some well-known combinations of user IDs and passwords are easy to find on the Internet. Sometimes products are shipped with default accounts and passwords. Common examples might be admin/admin, root/password, or admin/cisco. Continued use of default passwords after the initial configuration of products is highly discouraged, and it is advisable to consider this practice to be a policy violation.

Geographic distance has little relevance when dealing with hosts that are logically located on the Internet, which is physically worldwide. Regardless of the physical location of an attacker, the Internet makes everyone close enough to break in and steal things. Thus it can be important to examine the source of login attempts. For the SSH honeypot, the top 50 attackers were sourced from 19 countries. In the following figure, two countries in particular stand out: the United States (U.S.) and China.

3a8082e126